我以为Coinbase和Google会在代理之间如何互相付款上达成一致。打开两个仓库后发现他们的做法完全相反

我正在构建一个研究代理，它将任务分发给三个其他代理（搜索、总结、翻译），这些代理由不同的人拥有，各自支付自己的LLM费用。需要它们每次调用时互相付款，但发现实际上没有工具可以实现。Stripe立即被排除，因为最小30美分的手续费对0.001美元的调用来说是300倍的费率。链上L1 gas费也一样。订阅需要人为每一对代理预先设置合约，这完全违背了代理自主发现和雇佣彼此的目的。我所知的任何支付方式都无法进行低于1美分的机器对机器支付。然后我发现了x402，这是Coinbase对HTTP 402“Payment Required”状态码的实现，该状态码在规范中保留并几乎未使用约28年。它是一个无状态中介，从不接触资金，通过Base上的EIP-3009使用预签名授权，结算时间约2秒，费用约0.0001美元，并且你将支付作为头部传递，因此它可以沿着调用链组合。这正是我需要的。开始构建时遇到了一个我以为已经解决的问题：验证很快，结算很慢，那么在实际工作周围应该按什么顺序执行它们？三个选项： * A：验证 → 执行 → 结算 * B：验证 → 结算 → 执行 * C：验证 → 预留 → 执行 → 扣款（信用卡保留） EIP-3009是一次性操作，没有预留原语，因此C不可行。我本想直接参考引用实现的做法。打开Coinbase的中间件：它是A，工作之后结算。打开Google的A2A x402扩展，期望确认这一点：它是B，先结算后执行。这个领域最大的两个团队阅读相同的规范却得出相反的答案。这时我意识到这不是一个复制粘贴的决定。调和它们的是工作所需的时间。Coinbase的调用者通常是一个受保护的API端点，响应时间在半秒内，因此验证和结算之间的窗口非常小，几乎不会出错，A没问题。我的调用者是一个运行模型的代理，可能还会调用其他代理，因此这个窗口会延长到整个任务的长度，几秒到几分钟。这完全改变了在间隙中可能出错的情况。所以我选择了B。理由很简单：代理工作花费真金白银（token，通常每次调用0.30美元以上），执行缓慢，而且一旦输出产生就存在了。因此，先结算后执行是唯一能让支付失败不会给调用者免费计算资源的顺序。然后我坐下来试图用四种场景来破坏它： * 某人签署有效支付，通过验证，然后在结算到达前耗尽钱包 → 结算回滚，因为我先结算，LLM从未运行，损失0美元。 * 从同一钱包并行发起两个请求，使用不同的nonce，都针对同一余额通过验证 → 一个结算，另一个在链上竞赛中失败，但失败者从未到达模型，所以没有浪费任何东西。 * 某人重放捕获的支付头部 → 在验证运行之前就被nonce检查捕获，返回402。 * 糟糕的情况：中介在10秒超时，但链在25秒后仍确认了交易。付款方被扣款，任务仍然失败。先结算后执行在这里无法拯救你，这是一个需要事后协调的孤儿支付，是链在负载下的属性，不是框架能修复的。 先结算后执行也有其自身的失败，我应该坦诚说明：支付正常完成但工作随后崩溃（提供方500错误，我的bug），现在有一个已付款但没有输出的任务。虽然罕见，但你可以通过持久化nonce/认证元数据和手动退款来处理，而不是假装它不会发生。完整流程图已附上。它是开源的，端到端测试会在笔记本电脑上启动模拟中介和代理，并运行所有四种场景。老实说，我仍然不确定B是否适合所有人，所以如果你能看到它在哪里失效，我很乐意听听。🌻 [github.com/GetBindu/Bindu](http://github.com/GetBindu/Bindu)