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