负责任的 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 亲手跑一遍合规拦截。