架构

没有执行凭证的结算是付费黑箱：闭合代理支付审计闭环

作者：IdeaBosque最后更新：2026年7月30日

关键要点

x402 在首年于 Base 上处理了 1.69 亿笔代理支付，但 payment_hash 仅证明交易已结算——无法证明代理执行了什么操作——凭证扩展（OMA3/x402，已合并入协议）记录了谁付款、访问了什么服务、何时付款以及支付参考号，但未记录服务端运行了哪个 screening 版本、哪条策略规则或哪个模型版本（Chainalysis, 2026; OMA3, 2026）。
IETF action_ref 草案（draft-etcheverry-action-ref-02, 2026 年 7 月）定义了一个内容寻址标识符——对 agent_id、action_type、scope、timestamp 的规范 JSON 进行 SHA-256 计算——任何审计方无需信任发出者即可重新计算——包含用于策略版本可审计性的可选字段，使审计方不仅能确定规则 7 是否触发，还能确定当时激活的是哪个版本的规则 7。
IETF x402-retention-chain 草案（draft-hopley-x402-retention-chain-06, 2026 年 6 月）将组合形式化：Settlement-Action Binding（binding_ref）将 payment_hash 与 action_ref 绑定在一份凭证中——加上 Policy Binding（policy_bound_ref）将 governing 策略版本绑定到操作，以及 Compliance Gate Binding（gate_ref）将 ALLOW/REFER/DENY 裁决绑定到策略引用。
所有构造仅使用 SHA-256 和 JCS（RFC 8785），持有凭证的任何方无需联系签发方即可验证——满足 MiCA 第 80 条、DORA 第 14 条和 AMLR 第 56 条的审计追踪要求（IETF draft-hopley-x402-retention-chain-06, 2026）。
没有执行凭证的结算是付费黑箱；没有结算的执行凭证是无法验证的声明；代理需要两者来闭合信任闭环——x402 结算交换，action_ref 绑定执行上下文，binding_ref 将它们组合为一份可审计凭证。

问题：六个协议，零执行凭证

代理 commerce 技术栈在 2026 年趋于收敛：UCP（发现）、A2A（通信）、MCP（工具）、ACP（结账）、AP2（授权）、x402（结算）。六层，六十多个启动合作伙伴——Google、Shopify、OpenAI、Stripe、Visa、Coinbase。每次购买都覆盖了：代理发现、协商、使用工具、结账、获得授权并付款。

除了一件事：代理确实做了它应该做的事情的凭证。

x402 结算支付。payment_hash 证明交易在 Base 上约 200ms 内完成。x402 凭证扩展（通过 OMA3/x402 合作合并入协议）添加了签名的、可移植的购买凭证——谁付款、访问了什么服务、何时以及支付参考号。此凭证由服务数字签名，防篡改，且可通用验证。

它不记录服务内部发生了什么。凭证证明代理付了款。它不证明运行了哪个 screening 版本、触发了哪条策略规则或哪个模型版本产生了决策。对于供应商合规检查，凭证证明代理为 screening API 调用付了款。它不证明实际执行了哪个版本的 screening 逻辑。

对于受监管的采购——EU AI Act 第 12 条，2026 年 8 月 2 日生效，FCA SYSC 9.1，SOC 2 CC7.x——这一缺口是合规阻塞点。日志可以被重写。不绑定到执行的支付凭证是付费黑箱。

解决方案：组合结算与执行的两份 IETF 草案

action_ref — 内容寻址的执行标识

IETF action_ref 草案（draft-etcheverry-action-ref-02, 2026 年 7 月 23 日）定义了用于代理操作的确定性、内容寻址标识符。标识符计算方式为：

action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp}))

其中 JCS 是 JSON Canonicalization Scheme（RFC 8785），为任何 JSON 值生成唯一的字节序列。四个原像字段：

字段	捕获内容
`agent_id`	委派解析后的终端执行者（在 A→B→C 链中，agent_id 为 C）
`action_type`	语义标签（`payment.send`, `compliance.screen`, `oracle.signal`）
`scope`	代理在操作点的请求意图范围
`timestamp`	RFC 3339 UTC，精确到 3 位毫秒

设计目标是操作者独立性：持有四个字段的验证方可以重新计算 action_ref 而无需调用发出者的基础设施。草案包含用于策略轮换可审计性的可选字段——使审计方不仅能确定规则 7 是否触发，还能确定当时激活的是哪个版本的规则 7。

x402-retention-chain — 绑定层

IETF x402-retention-chain 草案（draft-hopley-x402-retention-chain-06, 2026 年 6 月 24 日）定义了七种密码学构造。其中三种与支付 → 结算 → 审计闭环直接相关：

Settlement-Action Binding（binding_ref）——将 x402 的 payment_hash 与 action_ref 绑定在一份凭证中。结算证明现在不仅证明支付发生，还证明其对应哪个已验证的代理操作。持有凭证的审计方从 payment_hash 追溯到 action_ref 再到操作记录，无需联系签发方即可确认两者。
Policy Binding（policy_bound_ref）——将 governing 策略的内容寻址快照绑定到操作。screening 决策可针对做出时生效的确切策略版本进行验证。策略轮换可通过重新计算检测——策略变更时哈希值变化，审计方因此能看到转换。
Compliance Gate Binding（gate_ref）——将 ALLOW/REFER/DENY 合规裁决和无 PII 付款方引用绑定到策略引用。screening 结果可证明地与产生它的规则版本绑定，绑定记录中无个人数据。

所有构造仅使用 SHA-256 和 JCS。无需外部基础设施。无需联系签发方。持有凭证的任何方均可验证。

审计闭环：支付 → 结算 → 可审计日志

受监管代理 commerce 交易的完整闭环：

支付——代理调用付费 API（供应商合规 screening、供应商验证、产品查找）。服务器返回 HTTP 402 及支付条款。
结算——代理签署授权，以 PAYMENT-SIGNATURE 重试，促进方验证并在 Base 上约 200ms 内结算。服务器返回资源及包含 payment_hash 的结算凭证。
执行——代理执行操作（screening、查找、决策）。它发出 action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp}))——任何第三方均可从四个原像字段重新计算的内容寻址标识符。
绑定——binding_ref 将 payment_hash 与 action_ref 在一份凭证中关联。policy_bound_ref 将 governing 策略版本关联到操作。gate_ref 将合规裁决关联到策略引用。
审计——审计方（监管者、对手方、内部合规）持有组合凭证。他们从四个字段重新计算 action_ref。他们针对 Base 区块链验证 payment_hash。他们检查 policy_bound_ref 确认 screening 在正确策略版本下运行。他们检查 gate_ref 确认裁决匹配。无需调用操作者。无需信任。

闭环回答：支付已结算、此特定 screening 版本已运行、在此策略版本下、在此时间戳、由此裁决。两层，一份凭证。

为什么每层单独都不够

下图展示了完整闭环——支付、结算、执行、绑定和审计——以及为什么每层单独都不够：

没有执行凭证的结算是付费黑箱。凭证说代理为合规 screening 付了款。它没说运行了哪个版本的 screening 逻辑、策略是否为最新版本、或裁决是否正确。监管者问"你用的是 2026 年 7 月还是 6 月的制裁名单来筛选这个供应商？"仅凭 payment_hash 得不到答案。

没有结算的执行凭证是无法验证的声明。代理说它筛选了供应商。没有将 screening 绑定到已结算交易的支付凭证，就没有 screening 实际发生的经济证据。声明可以随意做出，但审计毫无价值。

组合闭合信任闭环。结算锚定经济事件——资金转移的凭证。执行凭证锚定语义事件——做了什么的凭证。绑定将它们关联。审计方从一份凭证验证两者，重新计算哈希而无需信任链条中的任何方。

这对 B2B 构建意味着什么

一个下订单、授权支付并筛选供应商的采购代理需要完整闭环在其审计追踪中。架构：

x402 处理结算。代理从供应商合规 API 收到 402 响应，在 Base 上以 USDC 付款，收到包含 payment_hash 的结算凭证。
action_ref 处理执行标识。代理为每次合规 screening 操作发出 action_ref，记录 agent_id、action_type（compliance.screen）、scope（供应商 ID 和 screening 类型）及 timestamp。
binding_ref 将它们组合。结算凭证在一个信封中携带 payment_hash 和 action_ref。policy_bound_ref 记录哪个策略版本治理了 screening。gate_ref 记录 ALLOW/DENY 裁决。
审计追踪是组合凭证链。审计方从四个字段重新计算 action_ref，在链上验证 payment_hash，检查策略版本哈希，确认裁决——全部无需联系代理操作者、支付促进方或 screening 服务。

对于受监管行业——制药 GMP 合规、航空航天 ITAR screening、金融服务制裁检查——这是可审计代理与合规风险代理的区别。EU AI Act 第 12 条记录保存要求（2026 年 8 月 2 日生效）要求 AI 系统决策的可追溯性。MiCA 第 80 条要求交易记录。DORA 第 14 条要求运营韧性的审计追踪。binding_ref 构造从一份凭证满足三者。