架構

三方承諾：我們的技術棧如何將支付意圖、執行憑證和結算綁定為一個可驗證憑證

作者：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。承諾要麼覆蓋所有步驟，要麼不覆蓋。這就是使代理商務可端到端審計的原語。