摘要

  • draft-mih-agent-settlement-records-00 提议由付款方和收款方各自签封本端观察，再由验证者判断两端是否一致；任何一端都不能自行宣称已经形成双边结算。
  • 付款一致与交付完成是两种彼此独立的状态。草案明确允许付款为 agreed、交付却为 none；签名和两端一致都不能证明商品、内容或服务已经到达。

支付系统最危险的界面，往往不是一个明显错误的红灯，而是一个含义过宽的绿灯。它写着“已结算”，采购、财务、客服和自动代理便可能把这四个字继续解释为“交易已经完成”。2026 年 10 月 2 日提交的 Two-Party Settlement Records for Agent Payments 第 00 版，真正有价值的不是又增加一种收据格式，而是拒绝让一枚绿色徽章承担它没有证据支持的结论。

草案从一个无法靠单边日志消除的事实出发：付款方的钱包或银行看见资金离开，收款方的系统看见资金到达。双方观察的是同一次交换的不同边缘。现有协议常常只保留一边的说法，至于承诺换回的商品、数字内容或服务是否交付，则可能完全留在另一个系统里。

它把记录拆成最多四类 leg：交易条款、付款方观察、收款方观察和交付观察。每个参与者只能签封自己系统实际看见的事实。付款方收到收款方的证据后，可以引用那份证据，却不能把它重新包装成“付款方观察”；反过来也一样。引用证明持有和关联，不改变一项主张的出处。

因此，组合结论必须留给验证者。任何成员记录都不包含 agreed 或 mismatch 这种总判定。验证者先检查 Agent Action Capsule、producer envelope、结构、被包装对象、角色以及本地密钥政策，再按条款引用和带类型的付款引用把可接受记录组合起来，最后根据原始字节推导状态。这是一个重要的权力边界：证据提供者不能顺手授予自己“双方已经同意”的资格。

只有一端时，结果只是 stated claim。payer_stated 只表示付款方系统报告了一笔支出，payee_stated 只表示收款方系统报告了一笔入账。缺少另一端不是冲突证据：对方记录可能尚未生成、被暂时扣留，或者永远不会出现。相关 evidence-request 草案也刻意区分正式回答、签名拒绝和有记录的缺席；三者不能压缩成同一个“失败”。

agreed 的门槛更窄。两个观察必须能够连接，使用两个不同且被接受的密钥，给出相同的规范化付款引用，通过金额规则，并报告相同状态。金额比较不是模糊近似：同一种资产、同一个小数尺度下，付款方金额必须精确等于收款方实收金额加上收款端 receive fee。这里没有误差带。若只把付款方金额与收款方实收直接比较，一笔诚实披露的手续费反而会被错误标记为不一致。

即使全部条件满足，agreed 也只回答“两套付款系统是否对资金移动给出同一说法”。草案另行报告观察金额是否符合原始条款。付款方和收款方可能彼此完全一致，同时一起偏离交易约定。手续费在商业上能否接受，要由条款和补救规则回答，不能从密码学上的一致偷偷推导出来。

交付有自己的状态机。没有 delivered leg 时，状态就是 none；只有一端且不存在冲突时是 stated；发送和接收记录中的内容摘要相同才是 matched；摘要冲突则是 mismatch。这条独立性是双向的：付款可以 agreed 而交付为 none，交付也可以 matched 而付款仍只有 payee_stated。

内容摘要能够缩小争议，却不能消灭所有争议。相同摘要可以说明两份记录指向相同字节，却无法单独证明实体商品质量合格、服务准时完成、软件达到承诺效果、接收者有权验收，或合同补救期已经结束。把“字节相同”显示成“义务履行”，仍然是把一个现实层的信号冒充另一个现实层的裁决。

状态词本身也必须保持本地含义。settled 表示在签封者本端已经最终：对付款方是已扣账，对收款方是已入账或已收到。模型同时允许 reversed，并要求后续观察取代较早观察。因此，“settled”不能被升级成跨支付轨道、跨司法环境且永远不可撤销的保证。

签名证明某个密钥控制者签过字，却不任命这个密钥代表谁。草案把信任政策明确留在范围之外。验证者仍须决定哪个密钥有权代表所声称的付款方或收款方。不同密钥可以防止一个密钥单独伪造 agreed 的两端，但两把不同的钥匙并不会自动成为两个获授权交易对手。

被包装的付款对象也保留类似边界。已有签名的收据通过摘要被携带，不应重新签名。包装层只能证明某个签封者纳入了特定字节，不能把包装者变成原始发行者。同样，SCITT 回执可以证明某条记录进入指定透明日志；它不证明内容真实，更不能把单边记录变成双边协议。

这些都是提案语义，不是部署事实。Datatracker 把该文件列为个人 Internet-Draft，没有工作组流，也没有标准等级。文件对 x402、AP2、Payment HTTP、Open Payments、Lightning 和 ISO 20022 的映射，是作者提供的交叉参照，并不表示这些社区已经采用该记录格式。研究资料保留了草案中的 ISO 映射，但 ISO 网页抓取受阻，因此本文不会把那项映射描述成 ISO 背书。

Lu Heng 的 Minimum Initial Specification 给出适合这种记录的制度姿态：共享足以让独立观察相遇的最小形状，把有后果的判断留在本地。Running-Code Primacy 追问实际运行的是哪一种轨道对象、密钥政策、规范化规则和 supersession head。Reality Layers 则阻止签名观察、双边付款一致、交付证据和合同履行被压成一个“完成”标签。

领导者真正需要的不是更大的绿色徽章，而是一份可复演的决策回执。它应保存被接受和拒绝的 legs、密钥到主体的政策、推导出的付款状态、条款比较、推导出的交付状态、被包装对象验证、轨道状态、取代关系以及最终采取的商业动作。发生争议时，组织才能精确指出：事实在哪一步相遇，判断又从哪一步开始。

来源