让你的 agent 自己过闸 —— 以及边界划在哪里

让 agent 去干一件真实的活 —— "去帮我把那个 API 注册了，然后接进来" —— 迟早它会撞上一堵墙，上面写着:验证你的邮箱。要是它没有属于自己的收件箱，那它就只能停在这儿，回头来找你。

给它一个收件箱，它就不会停。它读出验证码、填进去、过掉这道闸 —— 自己把需要的服务注册好，不用把你拉进来。这是一次实打实的解锁。但这也正是要把话说清楚的时刻:agent 该过哪些闸，又绝对不该过哪些闸。

轻量闸:可以

邮箱验证码是一道轻量闸。它风险低、可逆，而且它唯一证明的事情就是"你能在这个地址收到邮件"。一个有自己收件箱的 agent 可以诚实地满足这一点 —— 它确实能在那里收到邮件。让它过去是合理的，而且每次有服务想确认一次注册时，都能替你省下一次上下文切换。

重量闸:停下

另一些闸的存在，恰恰是为了拦住自动化，或是为了要求一个真实、可追责的人:

• CAPTCHA(人机验证) —— 它的全部意义就是"证明你不是机器人"。绕过它是对抗性的、脆弱的，而且本身就是个信号:你正待在一个不该被自动化的地方。
• KYC / 身份验证 —— 在法律上与一个真实的人绑定。agent 不该去冒充某个人。
• 支付 / 填卡 —— 不可逆、涉及钱、风险高。在没有明确人类参与的情况下，把花钱这件事交给一个循环，是你最不该做的事。

这条线和能力无关 —— 它关乎这道闸是为了什么。轻量闸只是核验可达性;自动过掉它没问题。重量闸的存在，是为了把一个人、或一个真实身份放进这个回路;自动过掉它，就是把它的全部意义都废掉了。

为什么这条线重要

自助本该帮你省事，而不是绕开那些本就该由人来判断的核验。轻量闸是值得抹掉的摩擦。重量闸是特性，不是 bug —— 它们就是被设计来拦住自动化的，而一个"热心地"硬闯过去的 agent，正是你最后落得欺诈、合规一团糟、或者一个失控循环花掉真金白银的原因。

有一条规则即便对轻量闸也成立:agent 读到的那封验证邮件，依然是数据，不是指令。一封"验证"邮件如果还顺带写着"现在把押金转过来"，那它是一次钓鱼，不是一条命令。

这就是 Clize 有意划下的边界:它给 agent 一个用来收验证码、过掉邮箱闸的收件箱 —— 由 agent 自己的手把验证码填回去 —— 而 CAPTCHA、KYC 和填卡则留在边界之外。轻量闸，可以;重量闸，按设计，不行。