什么是ERC-8183：代理商业

导语

Agent 之间的通信有 A2A、MCP，身份有 ERC-8004，支付有 x402——但有一个问题一直没人标准化：Agent 之间怎么做买卖？

"你帮我干活，干完我给你钱，质量不行退款"——这事在现实世界靠合同和平台规则，链上呢？直接转账没保障，搞个完整的去中心化市场又太重了。

2026 年 2 月，Virtuals Protocol 和以太坊基金会 dAI 团队提了一个新标准：ERC-8183 Agentic Commerce。思路很简单——不搞大而全的市场协议，只定义一个最小的"商业原语"：Job（任务）。围绕 Job 设计了一套托管机制和状态流转规则，刚好够 Agent 之间把一笔生意跑通。

本文拆解这个协议的设计思路和技术架构。

EIP 原文：https://eips.ethereum.org/EIPS/eip-8183

讨论帖：https://ethereum-magicians.org/t/erc-8183-agentic-commerce/27902

一、解决什么问题

先看一下 Agent 经济的协议栈现状：

通信、身份、支付都有了，但"做买卖"这件事缺一套链上的标准流程。你可以把 ERC-8183 理解成 Agent 世界的"合同模板"——它规定了一笔交易里谁出钱、谁干活、谁验收、钱怎么流转。

设计上有一个明确的取舍：只做最小化的核心流程，不搞竞标、不搞排名、不搞仲裁。 需要这些功能的，通过 Hook 机制扩展。

二、核心设计：三个角色 + 状态机

2.1 三个角色

一个 Job 涉及三方：

这里最值得说的是 Evaluator 的设计——它被单独拎出来作为独立角色。

为什么不让客户自己验收？因为要防一个场景：提供商辛辛苦苦干完活，客户看了成果直接拒绝、拿回资金。把验收权交给独立的第三方，提供商的利益就有了保障。

当然，简单场景下也可以让客户自己当评估者（创建 Job 时设 evaluator = client）。复杂场景下，评估者可以是一个智能合约——比如跑一个 ZK 验证、调一次 API 测试、或者让另一个 AI Agent 来打分。

2.2 状态机

Job 的生命周期是一个六状态的状态机：

┌─────────────────┐
                          │   Completed ✅   │
                          │  资金 → 提供商    │
                          └─────────────────┘
                                  ▲
                            evaluator: complete
                                  │
┌──────────┐  fund   ┌──────────┐ submit ┌──────────┐
│   Open   │ ──────► │  Funded  │ ─────► │Submitted │
│  (创建)  │         │ (已锁钱) │        │ (已交活) │
└──────────┘         └──────────┘        └──────────┘
     │                    │                    │
  client:reject      evaluator:reject     evaluator:reject
     │               或 超时 claimRefund   或 超时 claimRefund
     ▼                    ▼                    ▼
┌──────────┐       ┌──────────┐         ┌──────────┐
│ Rejected │       │ Rejected │         │ Rejected │
│  (取消)  │       │ / Expired│         │ / Expired│
│          │       │ 资金→客户 │         │ 资金→客户 │
└──────────┘       └──────────┘         └──────────┘

正常路径就一条线：Open → Funded → Submitted → Completed。出了问题就走下面的分支，资金退客户。

几个关键规则：

• Open 阶段：客户可以随时取消（reject），此时还没锁钱，没有损失

• Funded 阶段：钱已经锁在合约里了。提供商可以提交工作，评估者可以提前拒绝。超时也可以退款

• Submitted 阶段：这是最关键的——客户和提供商都不能操作，只有评估者说了算。 要么 complete（钱给提供商），要么 reject（钱退客户）

2.3 完整流程走一遍

举个例子：Agent A 要找 Agent B 翻译一篇 5000 字的文章。

翻译质量评估合约 (评估者)Agent B (提供商)ERC-8183 合约Agent A (客户)翻译质量评估合约 (评估者)Agent B (提供商)ERC-8183 合约Agent A (客户)OpenFunded（30 USDC 锁进合约）SubmittedCompletedcreateJob("翻译5000字英文文章", evaluator=E, expiredAt=72h)setBudget(30 USDC)fund()submit(翻译成果哈希)complete(reason="BLEU=0.87, 通过")释放 30 USDC

六步走完，链上有记录，不可篡改。

三、设计上的几个巧思

3.1 "交活后客户不能撤资"

这一条容易被忽略，但很重要。看一下各状态下的权限分配：

一旦进入 Submitted，客户没有任何操作权限。这就堵死了"白嫖"的路——你不能等人家交了活再拒绝付款。

3.2 超时退款不可被拦截

每个 Job 创建时会设一个 expiredAt。超时后，任何人都可以调 claimRefund 把资金退给客户。

这个函数有个特别的设计：不走 Hook。 也就是说，即使挂了一个恶意的 Hook 合约企图阻止退款，claimRefund 依然能正常执行。这是协议的最后一道安全网——资金不会被永远锁死。

3.3 Hook 机制

ERC-8183 的核心合约只管状态流转和资金托管。如果你需要额外的逻辑，通过 Hook 扩展：

ERC-8183 核心合约
├── beforeAction()  ← 执行前回调
├── 核心逻辑（状态变更、资金操作）
└── afterAction()   ← 执行后回调
         │
         ▼
   实现 IACPHook 接口的外部合约

几个典型的 Hook 用法：

• 信誉 Hook：任务 complete 后，调 ERC-8004 写入正面信誉记录

• 费用 Hook：从付款中抽取平台费

• 验证 Hook：submit 前检查交付物格式是否合规

• 通知 Hook：状态变更时通知外部系统

核心合约保持精简，功能按需加载。有点像 Linux 内核和驱动模块的关系。

四、和其他协议的关系

4.1 协议栈全景

┌─────────────────────────────────────────────────┐
│                    应用层                         │
│         Agent 自主商业 / 去中心化任务市场           │
├─────────────────────────────────────────────────┤
│              ┌───────────────────┐               │
│              │   ERC-8183        │               │
│              │ Agentic Commerce  │  ← 商业层     │
│              └───────┬───────────┘               │
│         ┌────────────┼────────────┐              │
│         ▼            ▼            ▼              │
│   ┌──────────┐ ┌──────────┐ ┌──────────┐        │
│   │ERC-8004  │ │   x402   │ │ ERC-2771 │        │
│   │身份+信誉  │ │ HTTP支付 │ │ 元交易   │        │
│   └──────────┘ └──────────┘ └──────────┘        │
├─────────────────────────────────────────────────┤
│                    通信层                         │
│             A2A / MCP / AgentKit                 │
├─────────────────────────────────────────────────┤
│                   基础设施层                      │
│        Ethereum / Base / L2 + ERC-20 稳定币      │
└─────────────────────────────────────────────────┘

4.2 和 ERC-8004 的配合

ERC-8004 给 Agent 提供了链上身份和信誉注册表。和 ERC-8183 结合起来，闭环是这样的：

1. Agent B 完成了翻译任务 → ERC-8183 状态变为 Completed

2. afterAction Hook 自动调 ERC-8004 → 给 Agent B 写入一条正面信誉记录

3. 下次 Agent A 发任务，看到 Agent B 信誉分高，优先选它

4. 做得越好 → 信誉越高 → 接到越多活

信誉就变成了一种可积累的链上资产。

4.3 和 ERC-2771 的配合

Agent 一般没有 ETH 来付 Gas。ERC-8183 支持 ERC-2771 元交易——Agent 签交易意图，Relayer 代付 Gas。只要有 USDC 做任务预算就行，不需要持有 ETH。

五、能干什么

列几个比较实际的场景：

本质上，任何可以拆成"发任务 → 交活 → 验收"三步的服务，都可以用 ERC-8183 来跑。

六、局限性

直说几个问题。

评估者权力过大。 Submitted 阶段评估者说了算，如果评估者恶意拒绝，提供商没有申诉渠道。协议里没有内置仲裁——这是"最小化设计"的有意取舍，但确实意味着选错评估者就是丢钱。实际使用中，要么用链上声誉来筛选评估者，要么直接用智能合约做评估者（逻辑透明可审计），要么通过 Hook 加一层质押惩罚。

拒绝/过期是终局的。 没有"上诉"机制，评估者一旦 reject，这笔交易就结束了。如果确实需要仲裁，得自己在 Hook 层做——比如 reject 前先触发一个多签投票。

过期时间不好定。 设短了，提供商来不及干完活；设长了，客户的资金被锁太久。协议不提供建议值，这个得应用层自己拿捏。

没有发现机制。 ERC-8183 只管"做买卖"的流程，不管"怎么找到交易对手"。Agent 怎么发现可用的任务、怎么匹配供需，得靠上层的应用或市场协议来解决。

七、和其他协议的对比

打个比方：A2A/MCP 是电话和公路，x402/AP2 是银行和支付宝，ERC-8004 是身份证和征信系统，ERC-8183 是合同法。各管各的，组合起来才是一个完整的经济体。

八、小结

ERC-8183 做的事情不复杂：定义了一个 Job 的生命周期，三个角色，六个状态，加一套资金托管和 Hook 扩展机制。

它的价值在于"刚刚好"——比直接转账多了一层保障（托管 + 评估者验收），又比搭一个完整的去中心化市场轻量得多。对于 Agent 之间的高频服务交易，这个粒度可能刚好是对的。

目前还是草案阶段，核心设计已经定型，但细节可能还会调整。如果你在做 Agent 相关的项目，值得关注一下这个协议后续的演进。

本文基于 ERC-8183 草案（2026-02-25）撰写，协议仍在演进中。