Fireblocks 拆解 AI Agent 支付全鏈路：託管與策略引擎才是真戰場

Fireblocks 在其博客發佈《How AI Agents Execute Payments, End to End》，同步推出面向 PSP 與金融科技公司的 Agentic Payments Suite。這篇材料的技術價值不在概念宣示，而在於它把一筆由 AI 代理發起的支付，從意圖生成到資金最終劃轉的全過程拆成了可審計的環節——對正在評估 Agent 支付落地的機構來說，這是目前少見的、由託管與安全廠商給出的鏈路級描述。

一筆代理支付要穿過幾道閘門

按 Fireblocks 的拆解，Agent 支付的端到端流程大致沿這條線走：代理基於用戶或業務系統給出的授權意圖（mandate）發起支付請求，請求進入策略引擎（Policy Engine）接受規則校驗，通過後由託管錢包完成簽名與廣播，最終在鏈上或通過支付網絡完成結算，交易記錄迴流至對賬與合規模塊。

這條鏈路裡，真正決定「這筆錢能不能出去」的不是代理本身，而是中間那層策略引擎。它承擔的是額度控制與規則執行：單筆額度（per-tx limit）、單日累計（daily velocity）、收款白名單（payee allowlist）這類約束在簽名之前生效，而不是事後審計。Fireblocks 同時把合規集成與財務數據模塊掛在這條鏈路上，意味著交易在被簽名的一刻就已經帶著可歸因的身份與規則上下文。

值得注意的是託管位置。Fireblocks 的路徑是代理不直接持有私鑰，簽名動作發生在託管環境內，代理只提交意圖。這個設計選擇直接決定了風險邊界：代理被劫持或提示注入（prompt injection）成功時，攻擊者拿到的是「發起請求的能力」，而不是「動用資金的能力」——前提是策略引擎的規則足夠緊。

為什麼這份材料值得行業認真讀

過去一年 Agent 支付的討論集中在協議層：x402 讓 HTTP 402 重新可用，MCP 把工具調用標準化，穩定幣提供了 7×24 的結算軌道。但協議解決的是「怎麼付」，沒有解決「誰在付、憑什麼付、付錯了怎麼辦」。Fireblocks 這份拆解補的正是後半段——它把 KYA（Know-Your-Agent）從概念落到了具體位置：代理身份需要在策略引擎裡被識別，授權意圖需要被結構化表達，額度與白名單需要在結算前生效。

這與 OceanAlt 長期關注的結算前防火牆邏輯一致：Agent 支付的風險不在於單筆金額大小，而在於執行速度遠超人工複核速度。一個被汙染的代理可以在幾秒內發起數十筆合規外觀正常的轉賬，事後追索的成本遠高於事前攔截。把額度、白名單、身份核驗前置到簽名環節，是目前唯一在工程上可行的做法。

對 PSP 和金融科技公司而言，這份材料的實際含義是：接入 Agent 支付不等於接一個 API，而是要同時具備託管能力、策略引擎和可審計的合規鏈路。缺少任何一環，代理支付就只能停留在小額試驗階段，無法進入真實商戶場景。Fireblocks 把這三塊打包成 Suite 出售，本質上是把「Agent 支付的基礎設施門檻」明確定義了出來。

對錢包與託管服務商，競爭焦點會從「支持多少條鏈」轉向「策略引擎能表達多複雜的授權邏輯」。單筆額度是最低要求，真正的差異化在於能否處理多級授權、條件觸發、跨會話累計額度這類場景——這些恰恰是代理自主運行時最需要的約束形式。

還沒被回答的問題

這份拆解描述的是 Fireblocks 自身產品路徑下的執行機制，不是行業標準。授權意圖（mandate）目前沒有跨廠商的統一格式，KYA 的身份憑證也沒有公認的簽發與驗證體系，RAP 這類標準仍在早期討論階段。這意味著今天接入某家託管方案的機構，未來可能面臨遷移成本。

另一個未被展開的環節是爭議處理。鏈上結算的不可逆性與代理誤操作之間存在結構性張力：當代理在授權範圍內、但違背用戶真實意圖執行了一筆支付，責任歸屬在託管方、代理開發者還是用戶，現有材料沒有給出答案。這個問題不解決，Agent 支付的天花板就不會由技術決定，而由法律與商業信任決定。

---

原文來源：Fireblocks 博客 · https://www.fireblocks.com/blog/ai-agent-payments-execution-stages