架构

三方承诺：我们的技术栈如何将支付意图、执行凭证和结算绑定为一个可验证凭证

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

要点

三方承诺将支付意图、执行凭证摘要和结算 txid 哈希为一个凭证——审计者独立验证每一项，然后确认组合哈希覆盖全部三者——承诺要么覆盖所有步骤，要么不覆盖；不存在部分覆盖（IETF draft-hopley-x402-retention-chain-06, 2026）。
跨会话重放通过哈希不匹配检测，而非通过策略预防——因为 binding_ref 将 payment_hash 和 action_ref 一起哈希，将会话 A 的支付与会话 B 的执行交换会产生不同的组合哈希；验证者重新计算并得到不匹配结果（x402 GitHub issue #2332, 2026）。
MCP 模块原生生成执行凭证——每次工具调用（供应商合规筛查、供应商查找、报价起草）都记录了参数、结果和时间戳；凭证摘要是 action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp}))，持有这四个字段的任何方都可以重新计算（IETF draft-etcheverry-action-ref-02, 2026）。
x402 在 Base 上的结算在约 200ms 内生成 payment_hash——链上交易哈希可通过查询 Base 区块链独立验证；不需要信任运营商或 facilitator（Chainalysis, 2026）。
所有构造都使用 SHA-256 和 JCS（RFC 8785）——与 Hermes Agent 审计追踪使用的相同规范化标准（GitHub issue #487），因此执行凭证摘要是由代理自身的审计系统原生生成的，而非事后附加。

问题：分别审计每个步骤是必要但不充分的

六协议代理商务栈（UCP、A2A、MCP、ACP、AP2、x402）涵盖发现、通信、工具化、结账、授权和结算。每个协议生成自己的证据：x402 生成支付哈希，MCP 生成工具调用日志，AP2 生成授权 mandate。分别审计每个步骤是必要的——你需要验证支付已结算、执行已发生、授权有效。

但分开的审计追踪并不充分。没有绑定，攻击者可以将会话 A 的真实支付与会话 B 的真实执行混合。两者都是真实的工件。两者都没有伪造。但它们并未发生在同一会话中。支付凭证证明发生了支付。执行日志证明运行了筛查。没有将它们加密链接的绑定，就没有证据表明它们是同一笔交易。

这就是跨会话重放攻击：从已完成交易中获取真实的 payment_hash，从不同交易中获取真实的 action_ref，并将它们配对。如果审计系统因为两个工件各自有效就信任这个配对，它就接受了伪造的组合。审计追踪显示了一笔已结算的支付和一次已执行的筛查——但它们来自不同交易。

绑定步骤就是检测这种攻击的地方——或者未检测到的地方。

架构：我们的技术栈如何生成每个组件

下图展示了完整的三方承诺流程——每个系统生成哪个工件、绑定层如何组合它们，以及审计者如何验证：

每个组件在我们的技术栈中如何生成

支付意图：x402 签名报价

当代理调用付费供应商合规筛查 API 时，服务器返回 HTTP 402 及签名报价。offer-receipt 扩展（已合并到 x402 协议中）使服务器承诺特定支付条款：amount、asset、payTo address、正在 fulfill 的确切 resource 以及有效期。报价使用 EIP-712（基于 Ethereum wallet）或 JWS（任何非对称密钥，包括 Solana Ed25519）签名。

报价是支付意图——代理即将支付的内容。审计者独立对其哈希：

offer_hash = SHA-256(JCS(signed offer terms))

审计者从签名报价条款重新计算并验证服务器签名。不需要联系 payment backend——报价是一个可移植的签名工件。

执行凭证：MCP 工具调用日志

我们的 MCP 模块将代理连接到供应商合规 API、供应商目录和支付 rails。每次 MCP 工具调用都会被记录：调用了哪个模块、传递了什么参数、返回了什么结果、在什么时间戳、在哪个策略版本下。这就是执行凭证。

Hermes Agent 审计追踪（GitHub issue #487）实现了使用 SHA-256 哈希链和 RFC 8785（JCS）规范化的操作日志记录——action_ref 和 binding_ref 使用相同的标准。执行凭证摘要是代理自身审计系统原生生成的：

action_ref = SHA-256(JCS({
  agent_id: "procurement-agent-001",
  action_type: "compliance.screen",
  scope: "vendor:acme-corp screening-type:sanctions",
  timestamp: "2026-07-31T19:45:23.482Z"
}))

审计者从这四个 preimage 字段重新计算 action_ref。不需要联系代理或其操作者。规范化由 RFC 8785 定义，而非由序列化器定义——因此哈希在不同实现间是确定性的。

policy_bound_ref 绑定执行操作时有效的策略版本。如果制裁列表在 2026 年 6 月和 7 月之间更新了，策略哈希会改变，审计者可以检测哪个版本处于活动状态。gate_ref 将合规筛查的 ALLOW/DENY 裁决绑定到策略引用，因此结果可证明地与产生它的规则版本相关联。

结算：Base 上的链上 txid

x402 facilitator 验证代理的签名支付授权，构建链上交易，并在 Base 上广播。结算在约 200ms 内完成。facilitator 将交易哈希（payment_hash）返回给服务器，服务器将其在 PAYMENT-RESPONSE header 中传递给代理。

审计者通过查询 Base 区块链来验证 payment_hash——txid 是一个公开的、不可变的记录。不需要信任 facilitator 或 payment backend。审计者确认：

交易存在于 Base 上
amount 与报价条款匹配
payTo address 与报价匹配
交易已确认（非待处理）

绑定：binding_ref 如何组合三者

binding_ref（IETF draft-hopley-x402-retention-chain-06）将三个哈希组合为一个承诺：

binding_ref = SHA-256(JCS({
  offer_hash,      // 承诺的内容（支付意图）
  action_ref,      // 执行的内容（MCP 凭证摘要）
  payment_hash     // 结算的内容（链上 txid）
}))

这是一个三方承诺。审计者独立验证每个组件：

offer_hash — 从签名报价条款重新计算，验证服务器签名
action_ref — 从四个 preimage 字段重新计算 SHA-256，无需联系代理
payment_hash — 查询 Base 区块链，确认 txid 存在且已结算

然后审计者从三者重新计算 binding_ref 并确认匹配。如果任何组件被交换——会话 A 的支付与会话 B 的执行配对——组合哈希将不匹配。承诺要么覆盖全部三个步骤，要么不覆盖。不存在部分覆盖。

如何检测跨会话重放

跨会话重放攻击的工作方式如下：攻击者从会话 A 的已完成交易中获取真实的 payment_hash，从会话 B 的不同交易中获取真实的 action_ref。两个工件都是真实的。两者都没有伪造。但它们并未发生在同一会话中。

没有绑定，审计系统分别检查 payment_hash 和 action_ref，发现两者都有效，并接受这个组合。审计追踪显示了一笔已结算的支付和一次已执行的筛查——但它们来自不同交易。

使用 binding_ref，审计者从凭证中实际的 payment_hash 和 action_ref 重新计算组合哈希。如果攻击者从不同会话交换了一个，哈希来自不同的 preimage 上下文，组合的 binding_ref 将不匹配凭证中的值。验证者检测到不匹配。承诺未覆盖所有步骤，因此被拒绝。

这就是使绑定步骤成为信任原语的原因：它不添加新证据，而是加密链接现有证据。Base 上的支付哈希是可验证的。执行日志是可验证的。绑定证明使它们之间的链接可验证。没有链接，每一个都是独立的声明。有了链接，它们是一个审计者可以端到端验证的组合凭证。

这对构建意味着什么

一个每周为合规性筛查 85 个供应商的采购代理需要在其审计追踪中实现三方承诺。我们技术栈中的实现：

MCP 模块 生成执行凭证。每次工具调用都记录了参数、结果、时间戳和策略版本。凭证摘要是 action_ref，由 Hermes Agent 审计系统使用 JCS 规范化原生计算。
x402 处理结算。facilitator 在 Base 上结算并返回 payment_hash。offer-receipt 扩展在 402 响应时签名支付意图。
审计层（非代理，非 payment backend）从 offer_hash、action_ref 和 payment_hash 计算 binding_ref。它还计算 policy_bound_ref 和 gate_ref 以绑定策略版本和合规裁决。
人在环中的检查点 在支付授权时看到组合凭证：报价条款、执行结果、结算确认、策略版本和裁决——全部通过 binding_ref 链接。
外部审计者（监管者、交易对手、内部合规）通过独立重新计算每个哈希来验证组合凭证。不需要联系代理、payment backend 或审计层操作者。

验证只需几秒钟：查询 Base 获取 txid，从四个字段重新计算 action_ref，从签名条款重新计算 offer_hash，从三者重新计算 binding_ref。承诺要么覆盖所有步骤，要么不覆盖。这就是使代理商务可端到端审计的原语。