ACT 协议：让用户意图贯穿 Agent 下单、支付与履约

用户让助手在周五前买到一个替换墨盒。“买最便宜的兼容款”还留下许多问题：具体是哪台打印机，价格是否包含运费，能不能换品牌。如果用户不在付款现场，这些模糊之处就会变成授权问题。

ACT 把购买看成一条连续链路：从意图到权限，从商业约定到执行证据。真正值得评估的是，这些关系能否跨系统保留下来。

资料边界： 本文于 2026 年 11 月 1 日核对 ACT 官方框架和各域文档。墨盒采购为概念示例，没有接入商户或支付方，也不据此声称特定服务已经可用或互通。

先澄清任务，再生成授权

委托授权域文档 区分了意图结构化结果 ISR 与意图授权凭证 IAC：前者表达澄清后的任务，后者以可验证形式承载约定的权限边界。哪些内容进入签名范围，需要明确界定，不能默认整段对话都被签入。

对墨盒场景，应先区分硬约束与偏好。“必须兼容这台打印机”和“优先环保包装”不是同一种条件。如果兼容性是批准购买的前提，就要检查它如何进入后续核验所依赖的数据。

机器生成的摘要，也不能在必要确认完成前被当作用户批准。JSON 再整齐，也可能表达了错误理解。

基于 ACT 的委托购买概念图，非实测收银流程。用户实时确认的即时支付，采用不同的授权路径。

支付网络之上的协作框架

ACT 总纲 按委托授权、商业交互、支付服务和信任服务划分职责，并明确把底层清算结算排除在范围之外。同一家公司可以承担多个角色，但角色本身仍应区分。

因此，接入审查还需要具体的实现方名单：谁签发或验证凭证，谁确认购物车，谁移动资金，谁保存记录，谁有权查询。框架图并不能证明这些系统已经向你的业务开放。

购物车要与批准内容对应

应用可以把一条业务原则写进验收：支付时检查的商品、商户、总价和交付限制，应与用户批准的任务对应。墨盒价格或交付日期发生变化时，不能静默沿用针对旧条件的批准。

建议保留可串联的任务引用、凭证引用、购物车或订单引用、付款尝试，以及履约证据。这是运营记录建议，不是声称所有 ACT 实现使用同一套 API 字段。

这样的设计也有助于控制数据暴露。商户可能需要兼容型号和交付要求，却不需要用户的完整聊天内容。每个字段传给谁、哪些证据供谁验证，都应事先明确。

付款成功，只是其中一个事件

支付服务域规范 区分了用户在场的即时支付与委托场景，并描述支付和履约相关状态。其基于 HTTP 402 的 A402 流程涉及支付诉求与支付证明，但使用同一个状态码，不意味着与其他 402 协议自动兼容。

对墨盒采购，支付方确认扣款后，任务还没有结束：商户仍要交付。取消或退款也应形成自己的状态，而不是覆盖之前发生过的付款事实。

示例事件	产品需要事先定义的行为
商户替换了另一款墨盒	重新核对兼容性与授权范围
付款前授权已过期	暂停，并在需要时重新取得决定
支付结果不确定	查询已有尝试，不直接再次付款
付款成功但商户缺货	进入商户履约或退款流程
用户停止后续委托	区分未来权限与已经形成的订单

这些是建议验收场景，不是 ACT 参与方的实测结果。

先评估一个完整的小场景

可以先选一个商户、一种支付方式和一项边界明确的委托任务。要求实现方证明：约定的条件没有在链路中丢失，失败或中断的购买也能被完整解释。这个过程尚未跑通前，增加更多协议模块可能只是扩大复杂度。

ACT 是协议框架，不能作为相关企业生态里所有 Agent 商业产品的统称。目录中应与 AMP、APASS 等不同协议或身份实现分开。官方材料见 ACT 目录条目；支付幂等设计 则讨论了跨实现都需要面对的实际问题。