机器经济真正缺少什么？从 Agent 支付、可信验收到可执行任务契约

AI 正在降低决策和协作成本，但它能否催生真正的机器经济，取决于我们能否把陌生主体之间的承诺转化为可验收、可执行、可结算的任务契约。

一、AI 与 Crypto 真正的交点不是支付，而是交易制度

过去十年，人们反复尝试寻找人工智能与区块链的结合点。很多方案停留在“给 Agent 配一个钱包”，或为原本不需要代币的软件服务引入链上结算。但一个更值得研究的问题是：当 Agent 能独立发现资源、采购服务、完成工作，乃至与其他 Agent 协商条款时，市场本身将发生什么变化？

传统 API 经济出售的是调用权：人类注册账户，预付或订阅，持续使用一组能力。未来的 Agent 经济则可能更频繁地交易按需、短时、定制化的成果。一个电商研究 Agent 可能在几分钟内购买搜索数据、调用模型、聘请另一个 Agent 编写分析程序，再购买第三方复核。每笔交易的价格可能很低，参与者却未必有既存的商业关系。

Nick Szabo 关于智能合约的原始构想，是把约定条款嵌入可自动执行的机制，降低履约和违约的摩擦。它提供了理解这一问题的起点：支付解决资金如何移动，托管解决先付款的风险，市场发现解决找谁交易；但交付结果能否被可靠验收，决定交易能否重复发生。

二、协议栈正在形成，但“已有合约”不等于“已有可信市场”

机器经济并非从零开始。x402 试图把机器支付接入 HTTP 交互；ERC-8004 设计了 Agent 身份、声誉与验证注册表；ERC-8183 提出了以 Job 为单位的资金托管、成果提交和验收者决定放款的流程；AP2 聚焦支付授权和用户意图的绑定；MCP 与 A2A 则侧重能力调用和 Agent 间通信。

这些机制解决不同问题，不应混为一谈。尤其要注意，ERC-8004 与 ERC-8183 的官方文档截至本文撰写时仍标记为 Draft。ERC-8004 的链上身份无法直接证明服务真实可用，也承认开放声誉信号面临 Sybil 风险。ERC-8183 则将验收权交给指定 Evaluator，但基础机制并不自动保证验收者诚实或提供完整仲裁。

2026 年 10 月发表的研究综述 SoK: Decentralized Agent Economic Infrastructure 提出了一个更本质的标准：guarantee closure（保证闭合）。一个工作流即使每个局部协议都按规则运行，最终仍可能出现错误支付。例如，验收者签名本身有效，却没有充分证明交付物满足约定；托管合约因此放款，在技术上合法，在经济上却可能错误。

因此，重要的问题不是“有没有验证”或“有没有签名”，而是：本次交易所依赖的证据，是否与本次任务、交付版本、验收规则和最终付款条件严格绑定？

三、托管并不等于信任：真正的瓶颈在验证

买方把十美元锁进托管合约，并不意味着卖方有十美元的作恶成本。对卖方而言，任务失败可能只是拿不到报酬；如果它已经窃取数据、消耗对手时间或破坏系统，托管并不能挽回损失。

因此至少要区分三种制度：Escrow（买方预留交易款）、Performance Bond（卖方履约保证金）和 Slashing（在符合已约定条件且经有效裁决时扣罚保证金）。但保证金只有在违规能被检测并执行处罚时才有意义。

一个简化的激励模型能够说明这一点。设任务报酬为 P，保证金为 S，诚实履约成本为 cH，作弊成本为 cD，作弊被正确裁定并处罚的概率为 q，诚实方被误判的概率为 f，作弊带来的额外预期收益为 g。在风险中性、一次性交易且违规时拒付并扣罚保证金的假设下，诚实履约优于作弊的条件为：

(q − f)(P + S) ≥ (cH − cD) + g

这不是通用的定价公式，而是说明：当 q 很低、f 较高时，要求参与者锁定大量资本也未必能产生可靠激励。相反，提高验证的区分能力，可能大幅降低所需保证金。更重要的是，误罚诚实卖方的风险也不能被忽略。

而验证本身又存在悖论：谁验证验证者？若买方控制验收，卖方可能被恶意拒付；若第三方控制验收，买卖双方又需要防止第三方失职、串通或失联。于是问题从“可信支付”发展成了“可信判定与申诉”。

四、先把任务定义成商品，再讨论机器市场

不是所有 Agent 工作都具有同样的可验证性。确定性的数据转换，可以通过重算、校验和和单元测试验证；批量分类可能需要预定抽样和误差规则；市场研究、品牌策略等开放式成果，往往只能验证材料来源、研究过程或约定的交付范围，很难自动证明最终商业价值。

这决定了市场需要不同的任务契约，而不是一个统一的“AI 验收分数”。大体可以分为：

• 确定性任务：冻结输入、环境和验收程序，自动测试交付物。
• 统计性任务：预先约定抽样方法、可接受误差、复核和返工制度。
• 主观性任务：区分过程交付、专家审阅与长期效果，预设争议裁决路径。

如果 AI 同时编写需求、生成测试、实现任务、评价结果，那么它完全可能准确通过自己误解需求后生成的测试。需求解释是否正确，不能由执行是否符合错误规则来证明。因此，验收规则可以由 AI 起草，但必须在交易前确认并冻结；执行者不得自行修改正式验收条件。

拍卖和资源池也应该建立在商品标准化之后。一个只承诺给出答案的 Agent 报价五美元，另一个提供可追溯来源、复现记录与独立复核的 Agent 也报价五美元，这两个报价其实不可直接比较。没有质量定义的市场，容易演化为削减验收成本的劣币竞争。

五、从“身份”转向“责任主体—配置—本次履约”

Agent 身份可以低成本大量创建，因此单纯靠可重置的账户信誉，很难建立持久约束。但这不意味着声誉无用，而是需要区分三层身份：

1. 经营责任主体：谁授权接单、控制资金、承担长期经营收益和合同责任。
2. 执行配置：所用模型、工具、权限、工作流与版本；能力表现应绑定任务类型和配置。
3. 单次履约：该笔交易使用了哪些输入、由哪个环境执行、产出了什么版本、由谁按什么规则验收。

据此，声誉适合做供应商筛选及风险限额，技术验证适合决定本次交付是否符合约定，保证金适合约束可裁决的违规。三者互补而不是替代。

同一经营者控制多个 Agent 账户时，平台还必须计算共同的资金风险敞口。不能允许一笔保证金在多个并发任务中被重复作为充分担保。

六、一个可落地的工程模型：Evidence-Carrying Work

真正值得建设的基础能力，可以称为 Evidence-Carrying Work（携带验收证据的工作成果）。它强调成果附带与本次契约相匹配的证据，而不是宣称每种工作都可以获得完整数学证明。

我们可以将交易划分为四种核心对象：

• Task Contract：交付定义、输入快照、验收规则版本、预算、权限、截止时间、争议规则。
• Execution Manifest：供应商、执行实例、模型和工具配置、环境、输入与成果摘要。
• Evidence Bundle：交付物、必要日志、测试报告、验证程序版本、来源与完整性记录。
• Acceptance Receipt：任务标识、成果版本、验收规则摘要、验收者身份、PASS/FAIL/INCONCLUSIVE 结论、签名和唯一结算标识。

这里可以借鉴 SLSA Provenance 对软件产物来源的描述方式，但必须承认“来源可追溯”不等于“业务要求已满足”。

放款规则应由确定性控制层负责：资金已预留、权限有效、证据匹配本次任务与成果、验收者符合约定、交易尚未结算，才允许进入支付流程。执行 Agent 自己写出的“我已经完成”，不能是唯一证据；执行环境也不应持有付款密钥。

不能判断（INCONCLUSIVE）尤其重要。验证环境出错、依赖缺失、证据不完整，不应被包装为通过，也不能直接视为供应商恶意违约。

七、必须同时保护买卖双方，才可能形成重复交易

多数托管设计首先关心不合格成果不得收款，这是必要但不充分的。另一侧同样重要：如果供应商已经合格交付，验收者却失联，简单地到期退款可能使诚实卖方遭受损失。

因此，我们至少需要两类可检验的制度性质：

付款安全性：不符合约定条件的成果，不得凭无效、错配或重放的证据获得付款。

履约可兑现性：在约定的时间、证据和基础设施可用性假设下，合格成果应有可执行的验收和收款路径。

工程上必须准备备用验收者、超时后的补证或申诉机制，以及资金状态与工作状态分离。代码已验收通过但支付系统超时，不应重新执行任务；付款结果未知，也不能简单重复支付。任务提交期限、验收期限与最终结算期限必须独立定义。

主观任务可以保留人工仲裁，但必须诚实标注它是一个信任主体，而不是把“链上记录了人工决定”误称为完全去中心化。

八、真正的经济约束首先来自最小损失边界

即使拥有足够好的验收与保证金，Agent 也可能造成资金无法覆盖的不可逆损失：生产数据泄露、供应链破坏、权限滥用等。因此风险控制顺序应该是：

先限制能够造成的损失，再提高验证质量，最后计算必要的担保与结算机制。

具体来说，应该有任务级预算、权限最小化、数据隔离、执行沙箱、供应商并发风险额度、可撤销授权和异常熔断。经济惩罚是最后一层约束，不应替代工程安全。

微交易的商业可行性也不由链上手续费单独决定。真实的单位交易成本包括需求规格化、执行、验证、结算、争议和资金占用。任务记录、质量验收、资金结算可以采用不同频率，例如逐笔保留使用证据，对部分交易进行抽样或挑战复核，再批量资金结算。关键是总成本是否下降，而不是某笔转账是否足够便宜。

九、产品路线：先做任务契约内核，不急于做开放交易所

对已有任务编排、Agent Harness 与 Worker 基础设施的团队而言，最现实的创业方向不是重建区块链，更不是先发行代币，而是为现有任务系统增加一套可组合的 Agent Work Contract Engine：

1. 把自然语言委托转化为确认后的结构化任务契约。
2. 在隔离环境中执行任务，并生成不可任意替换的产物与证据。
3. 按约定规则独立验收，记录通过、失败、无法判定与复核结果。
4. 控制付款、退款、返工、申诉和可能的履约保证金。
5. 把历史履约结果反馈给能力评估和后续任务路由。

第一个试点场景建议选择受限的 AI 编程修复任务：固定基准提交、明确故障复现、执行环境隔离、提交候选补丁、自动测试并交由维护者复核。交易标的应是“符合约定检查、可供维护者审阅的候选补丁”，而不是承诺代码绝对正确或上线后必然创造价值。

第一阶段在企业内部使用数据库账本和模拟结算，验证契约—成果—证据—验收—结算闭环；第二阶段引入真正独立的供应商，测试跨信任边界的合作；第三阶段只有当多方共用结算基础设施确有收益时，再对接 x402、ERC-8183 等机制。

核心指标应是误付款率、误拒付率、合格交付按时收款率、每个最终采用成果的全成本、维护者实际审阅时间，以及独立买家的重复购买率。普通任务队列加 CI、人工审批和数据库账本，必须作为对照组；否则无法区分自动化收益和链上机制的增量价值。

十、结论：机器经济的单位，不是 Token，而是可验收的承诺

AI 能降低想法、决策和协作的成本；Crypto 能提供跨主体可编程的支付和部分承诺执行能力。但两者之间缺少的不是又一种代币，而是一种对任务结果建立证据、明确责任、约束误判，并将验收结果可靠连接到经济后果的机制。

因此，真正的路径应当是：先把工作定义成可验收的商品，再把验收做成可复用的证据，最后让证据支持陌生主体之间的交易。

可信的机器经济未必全部在链上，也未必完全没有人工。它真正要实现的是：即使参与者互不相识、执行主体可以更换、任务交易非常短暂，双方仍能知道“买的是什么、怎么证明交付、出问题谁负责，以及怎样获得应得的款项”。

---

参考资料与进一步阅读

1. Nick Szabo, Smart Contracts: Building Blocks for Digital Markets（1996）。
2. ERC-8004: Trustless Agents，以太坊改进提案。
3. ERC-8183: Agentic Commerce，以太坊改进提案。
4. SoK: Decentralized Agent Economic Infrastructure（2026）。
5. Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem（2026）。
6. Agent Payments Protocol (AP2), Specification。
7. x402 Documentation。
8. SLSA Build Provenance。
9. METR: Research Update on Agent Performance and Real-World Tasks。

研究日期：2026 年 10 月 22 日。本文区分已发布协议、研究观察和作者提出的工程设计假说。文中公式为简化激励模型，不构成投资或法律建议。