負責任的 Agent 支付框架
當付款方從「人」變成「代碼」，一整套建立在「交易背後有人、交易慢到能人工審」之上的合規體系同時失效。RAP 是一份開放、協議中立的標準，讓機器發起的支付可歸因、可控制、可審計、可合規，東西兩岸都能採用。
為什麼需要它
Agent 支付（x402 + 穩定幣）把付款方變成代碼，以機器速度、微額、高頻發生，無人在環。既有 KYC / AML 工具將大面積失效，而監管尚未給出答案。本框架不綁定任何單一協議或廠商。
四條原則
問責優先
每一筆機器發起的支付，都必須能追溯到一個可問責的法律實體。
縱深防禦
從 Agent 端防火牆，到網絡層篩查，到結算層合規，分層設防。
協議中立
適配 x402 / AP2 / Visa Intelligent Commerce / Mastercard Agent Pay，不鎖定單一棧。
隱私相稱
只取合規所需最小數據，清晰的跨境與管轄邊界。
七大支柱
身份與歸因 · KYA
Know-Your-Agent。每個支付 Agent 綁定到可問責實體，並可被對手方驗證。這是整個框架的地基，也是開放、可核查層面上最大的空白。
- ·每個 Agent 擁有唯一、可驗證的身份（可驗證憑證 / 鏈上憑證）
- ·身份綁定到已 KYC 的法律實體
- ·對手方能在交易前驗證歸因與授權有效性
授權與限額
人給機器的授權必須有邊界，寫明能花在哪、花給誰、花多少。
- ·明確授權範圍（用途、對手方、時間窗）
- ·單筆 / 單日 / 累計限額，超限攔截或升級
- ·授權可隨時撤銷並即時生效
控制與防護
在 Agent 和它的錢包之間，需要一道防火牆。
- ·花費策略引擎：白名單、黑名單、規則攔截
- ·抗提示注入（prompt injection）劫持；異常熔斷
- ·緊急 kill-switch + 高風險交易人工升級
篩查與反洗錢
機器速度下的 AML，必須前置、自動、可解釋。
- ·對手方地址的制裁名單 / 混幣器 / 風險評分篩查（可接入第三方數據）
- ·Agent 間轉賬的 Travel Rule 合規信息傳遞
- ·基於手法圖譜的持續監控與紅旗告警
可審計與問責
出事時，能回答：誰授權的、機器做了什麼、責任在誰。
- ·不可篡改的完整交易與決策日誌
- ·清晰的責任歸屬鏈（實體 → 授權 → agent → 交易）
- ·事件響應與追索流程
隱私與數據治理
可信不等於監控；跨境數據要有清晰邊界。
- ·數據最小化
- ·明確的管轄與跨境處理規則
- ·正當程序與用戶救濟
互操作與治理
標準的生命力在於被廣泛採用與共同維護。
- ·身份與授權憑證格式，跨主流協議互認
- ·由中立機構維護，開放徵求意見
- ·版本化演進，變更可追溯
框架實現分級
下面三檔說的是「實現了哪些控制」，是給實施方看的清單。
Agent 已歸因 + 基本限額 + 制裁名單篩查。適合小額低風險。
在分級 1 之上再加：花費防火牆 + Travel Rule + 完整審計 + 抗劫持。適合商用平臺。
在分級 2 之上再加：持續手法監控 + 人工升級 + 事件響應 + 第三方審計。面向受監管機構與跨境結算。
v1.1 增補 · 雙向決策條款
一筆負責任的 Agent 支付，付款方與收款方各自都要在結算前給出決策，且兩邊的決策都可核驗、可留痕。付款方一側（allow / review / decline）已由七支柱覆蓋；本條增補收款方一側。
結算前置條件滿足，可結算。決策編號應隨結算一起留痕。
終態，帶原因碼。付款方不能靠重付改變結果。
非終態。requested_fields 說清缺什麼；付款方補交後進入第二輪，最多兩輪；超期（48 小時）自動作 decline。
收款方自身未就緒：未登記、未上線、或被降級且掛著未解決爭議。這一態是登記與懲戒階梯的出口。
- 每個狀態都必須附證據（kind / ref / complete_through），證據可由第三方點開核驗。
- 決策由規則得出，不由模型判斷；原因碼錶公開，每條都能在註冊表或規則頁找到依據。
- 收款方的就緒狀態由註冊表的四級階梯決定；我們不沒收財產、不下有罪結論。
收款地址必須得到控制該網站（源站）的一方授權，不要求由賣家自己控制。支付服務商的充值地址、託管或預授權結算合約、替很多商戶收款的平臺、每張發票換一個地址，這些都合法，而且都不歸賣家控制。地址歸誰控制，外人驗證不了；源站有沒有授權它，可以驗證。
源站授權的密鑰簽過這個地址（這條鏈、這個源站）。和上次付款相比換了地址，但仍是同一源站授權的，按正常換錢包處理，不升級判定。
源站簽名發佈了這條鏈上的收款地址清單，這個地址不在裡面。至少複核；如果地址相對上次還換了，拒絕。
什麼都沒發佈、簽名驗不過、簽名者沒有源站授權，或查詢沒做完。這不是失敗，大多數賣家現在什麼都沒發佈；其他檢查照常進行。
- 證據按順序查：先看 x402 簽名報價，簽名者要經源站的 did:web 或 DNS _controllers 記錄授權。只由收款地址自己籤的不算，換地址的人也能自己籤。再看源站簽名發佈的 /.well-known/x402 清單。
- 連續性按「授權密鑰 + 源站」判斷，不按裸地址。查詢失敗一律記為 inconclusive，不當成「沒授權」。
- bound 只說明源站授權了這個地址，不說明賣家是誰、是否可信。
v1.1 舊規則（保留原文供對照）
收款方連續性：收款地址、鏈或幣種和上一次付款不同，判定至少升到複核（payee_changed_since_previous），不論變化是否得到源站授權。當前付款條件由賣家以前用過的密鑰簽名，或新地址通過賣家控制的名稱綁定到源站時，報 corroborated: true，但是否維持 allow 由付款方策略決定。
治理與參與
由 OceanAlt 維護。規範正文按 CC BY 4.0、測試向量按 Apache-2.0 公開授權；修改在 GitHub（github.com/rap-spec/rap）公開討論，版本化演進。這是一份活的文件，歡迎引用與提出修改。
利益衝突與中立性聲明：RAP 是一份開放標準，任何機構都可免費引用、採用或實現。OceanAlt 是 RAP 的召集方與首個實現者 / 評估方——但不是唯一。我們同時提供基於 RAP 的商業合規產品，因此是標準的利益相關方；為管理這一衝突：①RAP 的方法論、評級標準與利益衝突一律公開、可複核；②任何被評對象都享有申辯與更正權（right-of-reply）;③評級結論不因商業關係而偏。當 RAP 達到採用里程碑，其標準與評級治理將遷往一個與 OceanAlt 商業產品相獨立的中立機構。
如何引用
OceanAlt. "負責任的 Agent 支付框架 (RAP), v1.0." 2026. https://oceanalt.com/zh/rap參與共建 RAP
你是發行方、協議方、平臺、合規或安全從業者？我們邀請你評審、引用、或把 RAP 接入你的產品。想看它如何運行，去 AI Security Lab 親手跑一遍合規攔截。