沒有執行憑證的結算是付費黑箱：閉合代理支付審計閉環

關鍵要點

• 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 日）定義了七種密碼學構造。其中三種與支付 → 結算 → 稽核閉環直接相關：

1. Settlement-Action Binding（binding_ref）——將 x402 的 payment_hash 與 action_ref 綁定在一份憑證中。結算證明現在不僅證明支付發生，還證明其對應哪個已驗證的代理操作。持有憑證的審計方從 payment_hash 追溯到 action_ref 再到操作記錄，無需聯絡簽發方即可確認兩者。

2. Policy Binding（policy_bound_ref）——將 governing 策略的內容尋址快照綁定到操作。screening 決策可針對做出時生效的確切策略版本進行驗證。策略輪替可透過重新計算檢測——策略變更時雜湊值變化，審計方因此能看到轉換。

3. Compliance Gate Binding（gate_ref）——將 ALLOW/REFER/DENY 合規裁決和無 PII 付款方參考綁定到策略參考。screening 結果可證明地與產生它的規則版本綁定，綁定記錄中無個人資料。

所有構造僅使用 SHA-256 和 JCS。無需外部基礎設施。無需聯絡簽發方。持有憑證的任何方均可驗證。

稽核閉環：支付 → 結算 → 可稽核日誌

受監管代理 commerce 交易的完整閉環：

1. 支付——代理呼叫付費 API（供應商合規 screening、供應商驗證、產品查詢）。伺服器回傳 HTTP 402 及支付條款。

2. 結算——代理簽署授權，以 PAYMENT-SIGNATURE 重試，促進方驗證並在 Base 上約 200ms 內結算。伺服器回傳資源及包含 payment_hash 的結算憑證。

3. 執行——代理執行操作（screening、查詢、決策）。它發出 action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp}))——任何第三方均可從四個原像欄位重新計算的內容尋址識別碼。

4. 綁定——binding_ref 將 payment_hash 與 action_ref 在一份憑證中關聯。policy_bound_ref 將 governing 策略版本關聯到操作。gate_ref 將合規裁決關聯到策略參考。

5. 稽核——審計方（監管者、對手方、內部合規）持有組合憑證。他們從四個欄位重新計算 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 構造從一份憑證滿足三者。

相關閱讀

• 當代理下單時：代理式支付如何閉環 B2B 採購流程——從 RFQ 到支付對帳的 procure-to-pay 週期，使用代理式支付協定
• Kill-Switch by Design：代理治理架構——決定代理何時可以行動、何時必須停止的治理層
• 比例化代理治理：為什麼二元信任會失敗——將自主級別與風險匹配，包括支付授權檢查點
• EU AI Act 代理部署：合規——稽核閉環滿足的第 12 條記錄保存要求

---

一個每週執行代理篩選 85 個供應商合規性的中端分銷商需要的不僅是支付憑證。它需要 screening 在正確策略版本下、在正確時間、以正確裁決執行的憑證——綁定到資助它的支付。binding_ref 構造將 x402 結算和 action_ref 執行組合為一份憑證，任何審計方無需信任操作者即可驗證。這就是稽核閉環：支付 → 結算 → 可稽核日誌。兩層，一份憑證，對發出者零信任。