讓你的 agent 自己過閘——以及界線該畫在哪裡

把一個 agent 指向一項真實任務——「去幫我註冊那個 API，然後把它接起來」——遲早會撞上一道寫著這樣字樣的牆：驗證你的電子郵件。要是它沒有屬於自己的收件匣，這裡就是它停下來、轉而呼叫你的地方。

給它一個收件匣，它就不會停下。它會讀取驗證碼、填進去、然後過閘——自行註冊它所需的服務，不必把你拉進來。這是一項實打實的解鎖。而這也正是該精準界定的時刻：agent 應該過哪些閘，又有哪些閘是它絕對不該碰的。

輕量閘：可以

電子郵件驗證碼是一道輕量閘。它風險低、可逆，而它所證明的全部，不過是「你能在這個位址收到信」。一個擁有自己收件匣的 agent 可以誠實地滿足這項要求——它確實能在那裡收到信。讓它通過是合理的，而且每當某項服務想要確認一次註冊時，這都替你省下一次上下文切換。

重量閘：停

還有些閘的存在，恰恰就是為了攔住自動化，或是要求一個真實、可究責的人類：

• CAPTCHA——它的全部重點就是「證明你不是機器人」。攻破它是對抗性的、脆弱的，而且本身就是一個訊號：你正在某個本不該自動化的地方動手。
• KYC / 身分驗證——在法律上綁定到一個真實的人。agent 不該去冒充這樣的人。
• 付款 / 輸入卡號——不可逆、涉及金錢、利害重大。花錢，是你在沒有明確人類參與的情況下，最不該交給一個迴圈去做的事。

界線並不取決於能力——而取決於這道閘是為了什麼而設。輕量閘只是檢查可達性；自動把它過掉是可以的。重量閘的存在，是為了把一個人類或一個真實身分放進迴圈裡；自動把它過掉，就徹底背離了它的初衷。

為什麼這條界線重要

自助服務本應替你省下工作，而不是繞開那些本就該有人類判斷的檢查。輕量閘是值得移除的摩擦。重量閘則是功能，而非瑕疵——它們的設計目的就是攔住自動化，而一個「樂於助人」地硬闖過去的 agent，正是讓你最終落入詐欺、合規爛攤子，或一個花著真金白銀的失控迴圈的途徑。

有一條規則即便對輕量閘也成立：agent 讀到的那封驗證郵件，仍然是資料，不是指令。一封同時還說「現在把押金轉過去」的「驗證」訊息，是一場釣魚攻擊，而不是一道命令。

這正是 Clize 刻意劃下的範圍：它給 agent 一個收件匣，去接收驗證碼並過掉一道電子郵件閘——由 agent 自己的手把它填回去——而 CAPTCHA、KYC 以及輸入卡號則一律不在範圍之內。輕量閘，可以；重量閘，按設計，不行。