人類制定政策下的代理型支付
代理型支付，是由軟體而非結帳台前的真人所發起的支付。AI 代理持有憑證，判斷應該進行一筆採購，然後自行轉出資金——它支付帳單、續訂服務、預訂包機——而不需要有人按下最後一個按鈕。關鍵在於發起者。真人點下購買，只是前面多了個聊天機器人的一般信用卡支付；代理型支付則是由軟體在資金實際流動的那一刻，自己做決定、自己授權、自己完成結算。這個領域所有的難題都源於這一點：花錢的不是人，它不會像人在匯款給陌生人之前那樣疲倦、起疑或緊張。
這也是為什麼真正有意思的問題從來不是代理會不會花錢——它們現在就能。問題在於：誰來制定它們花錢所依循的規則，這些規則是由平台強制執行，還是只靠代理自己承諾。
失敗模式顯而易見，而這正是重點
給代理一組可用的支付憑證卻不設上限，就等於打造了一起尚未發生的匯款詐騙事件。出錯的方式並不罕見：藏在網頁裡的提示注入，指示代理付款給攻擊者；格式錯誤的工具描述，把一筆正當採購導向錯誤的收款方；重試迴圈因為始終收不到成功訊號，而把同一筆扣款嘗試上千次。這些都不需要高明的攻擊者——它們只是自主運作軟體的尋常錯誤，差別在於輸出的是從你帳戶流出的錢。
誘人的解法是讓代理更謹慎：更好的系統提示、更嚴厲的指示、對花錢更深思熟慮的模型。但這等於把控管放在系統中最不可信的地方——代理自己的推理，也就是最容易被說服放棄原則的部分。代理能夠辯過去的預算，就不是預算。控管必須放在代理觸及不到的地方，也就是代理之外。
政策才是產品，而不是提示詞
這套控管模型是一套政策，由平台在資金流動之前強制執行，而不是等代理做出決定之後。每個代理都有單筆上限與每日額度——在我們的示範政策中是每筆 €150.00、每日 €500.00——再加上更高一層的每月上限 €6,000.00。這些是由平台檢查的硬性限制，而不是代理自己遵守的承諾。示範中的旅遊機器人試圖以 €640.00 預訂包機時，付款當場遭到拒絕：超出上限，一分錢都沒有動。即使代理每一天都表現完美，也無法超出當月額度所允許的範圍。
預算規定「花多少」，允許清單規定「付給誰」。代理只能付款給你事先指定的商家。示範中的 Ops Agent 剛好只認得四家，而一筆 €180.00、對象為未列名廠商的付款嘗試，則因「不在名單內」而被拒絕。兩者合起來畫出一個框：這麼多錢，只能付給這些對象。在框內，代理全速運作，不需要請示；而這個框，由人擁有。
問題從來不是 AI 代理會不會花錢，而是誰寫下了它花錢所依循的規則——答案應該永遠是人，事先，白紙黑字。
界線之上由人把關
有些決定太重大，不能交給一個框來處理。因此政策設有門檻：超過某個明訂金額，就必須由人核准後才能付款。在示範中，這條線設在 €100.00。當 Ops Agent 標記出 Nord Logistics 的 #088 號帳單——€120.00，雖然遠在每日 €500.00 預算之內，卻高於核准線——它沒有付款。它暫停下來，把提案送到真人面前，然後等待。一行回覆就放行了；款項以參考編號 9F21-0716 完成結算，並在 09:41 寫入稽核日誌。線以下，代理自行處理；線以上，由人先回答。
核准不是一個轉眼即逝的勾選框。它會記錄是誰核准、使用哪台裝置、在什麼時間，並附上簽章——於 App 內核准，手機金鑰，09:41:12。日後若有人問起某筆款項為何發生，答案是一位具名的人和一個時間戳記，而不是一聲聳肩。
終止開關，以及不能被悄悄修改的日誌
即使有良好的限制，代理仍會出錯，政策也可能不盡正確。有兩項控管來處理這種情況。第一項是終止開關：一鍵即可暫停代理，並立即中止它可能發起的所有付款。金鑰仍保持有效，因此其他功能不受影響——代理只是無法花錢，直到有人重新啟用；它待處理的提案會原地凍結，而不是消失。在示範的代理群中，旅遊機器人處於暫停狀態，已支出 €0.00，佇列完整保留。
第二項是僅可追加（append-only）的稽核日誌。每一項決策都有紀錄：代理嘗試了什麼、哪項政策檢查通過或未通過、誰核准了什麼，乃至金鑰輪替。單一紀錄就能還原整筆付款——決策 DEC-4471 會顯示請求、每項政策檢查及其結果（允許清單通過、上限通過、門檻觸發升級審核）、人工簽核，以及最終結算的金額、支付通道與參考編號。每筆紀錄都帶有自身的雜湊值、前一筆紀錄的雜湊值，以及在鏈中的位置（示範中為 #4,471），因此只要改動任何欄位，其後的每一筆紀錄都會失效。日誌可匯出為 JSON，並包含雜湊值：它是交給稽核人員的憑據，而不是由我們代為保管的資料。
讓結算保持平淡，把創新留給授權
人們很容易想把代理支付從頭到尾都做成全新的東西：新的通道、新的工具、新的資金流動方式。請抗拒這個誘惑。真正新的部分是授權：代理如何證明自己有權付款、依據誰的政策、經過何種核准。付款一旦通過這道關卡，就應該在多年來平淡無奇的通道上結算。在示範中，一筆獲核准的 €120.00 付款提案會變成一般的 SEPA 轉帳，並在核准後數分鐘內由 SEPA Instant 完成結算，在下游看來與真人發起的付款毫無差別。銀行並不知道，也不在意это是代理發起的。
這樣的切分是刻意的。平淡的通道可預測，在支付機制允許時可撤回，而且每一位財務人員與稽核人員都熟悉。把創新放在政策、把付款放在成熟的通道上，意味著風險高、變動快的部分由你完全掌控，而與他人銀行接觸的部分則不需要任何人重新學習。代理動用的資金，來自支付產品線其餘成員所共用的同一個核心（詳見 /products/pay），而不是為機器人另建的平行世界。
協定版圖尚未底定，請為此而建
代理該如何向商家出示身分與授權，目前仍是懸而未決的問題。多項提案正在競爭：代理如何證明自己是誰、獲授權購買什麼，以及商家如何在收款前驗證這些資訊。目前沒有任何一項勝出，現在就把全部籌碼押在其中一項，未免言之過早。較穩健的做法，是把授權協定視為可抽換的部分，並讓其後的一切保持穩定：前端的傳輸格式改變時，政策引擎、稽核模型與結算通道都不必跟著變。
實務上，這代表一個小而平淡的整合介面。代理透過 MCP 連線至 mcp.protocore.io/agents；任何支援該協定的框架都能持有錢包。介面刻意保持精簡：提出付款、接收決策，因為真正有意思的邏輯在平台上，而不在提示詞裡。待業界對代理如何向商家自證身分有了定論，改變的是前端，後方的高牆則原地不動。
定位
代理支付並不是賭自主運作的軟體應該毫無限制地花錢，恰恰相反：它賭的是軟體終將花錢，所以限制最好是真實的、來自外部的、清楚易讀的。預算與允許清單劃出邊界，門檻把大額決策交給真人，緊急停止開關能讓一切立即停下，僅可追加的日誌則讓每一筆付款日後都能還原。/products/agents 的產品頁面會以此處使用的示範資料走完整個流程：建立代理、設定政策、看著一筆付款升級審核並完成結算；而 /products/pay 則是這些付款所運行的核心。自主性是真的，韁繩也是真的，而握著韁繩的是人。