ERC-8183：给 Agent 经济补上最后一块拼图
ERC-8183：给 Agent 经济补上最后一块拼图
导语
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 经济的协议栈现状：
| 层 | 干什么的 | 代表协议 | 状态 |
|---|---|---|---|
| 通信 | Agent 之间怎么对话 | A2A（Google）、MCP（Anthropic） | ✅ |
| 身份 | 怎么证明"我是谁"、"我靠谱吗" | ERC-8004 Trustless Agents | ✅ |
| 支付 | 怎么转钱 | x402（Coinbase）、AP2 | ✅ |
| 商业 | 怎么发任务、交活、验收、结算 | ？ | ❌ |
通信、身份、支付都有了，但"做买卖"这件事缺一套链上的标准流程。你可以把 ERC-8183 理解成 Agent 世界的"合同模板"——它规定了一笔交易里谁出钱、谁干活、谁验收、钱怎么流转。
设计上有一个明确的取舍：只做最小化的核心流程，不搞竞标、不搞排名、不搞仲裁。 需要这些功能的，通过 Hook 机制扩展。
二、核心设计：三个角色 + 状态机
2.1 三个角色
一个 Job 涉及三方：
| 角色 | 做什么 | 说明 |
|---|---|---|
| Client（客户） | 发布任务、锁定资金 | 任务失败时收到退款 |
| Provider（提供商） | 接活、干活、提交成果 | 任务完成时收到付款 |
| Evaluator（评估者） | 验收成果，决定"过"还是"不过" | 是独立角色，不一定是客户 |
这里最值得说的是 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 字的文章。
六步走完，链上有记录，不可篡改。
三、设计上的几个巧思
3.1 "交活后客户不能撤资"
这一条容易被忽略，但很重要。看一下各状态下的权限分配：
| 状态 | 客户能做什么 | 提供商能做什么 | 评估者能做什么 |
|---|---|---|---|
| Open | 设预算、fund、reject | 协商价格 | — |
| Funded | 不能操作 | submit | reject |
| Submitted | 不能操作 | 不能操作 | complete 或 reject |
一旦进入 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 结合起来，闭环是这样的：
- Agent B 完成了翻译任务 → ERC-8183 状态变为
Completed - afterAction Hook 自动调 ERC-8004 → 给 Agent B 写入一条正面信誉记录
- 下次 Agent A 发任务，看到 Agent B 信誉分高，优先选它
- 做得越好 → 信誉越高 → 接到越多活
信誉就变成了一种可积累的链上资产。
4.3 和 ERC-2771 的配合
Agent 一般没有 ETH 来付 Gas。ERC-8183 支持 ERC-2771 元交易——Agent 签交易意图，Relayer 代付 Gas。只要有 USDC 做任务预算就行，不需要持有 ETH。
五、能干什么
列几个比较实际的场景：
| 场景 | 客户 | 提供商 | 评估者 |
|---|---|---|---|
| 内容创作外包 | 运营 Agent | 写作/设计 Agent | 质量评估合约 |
| 去中心化数据标注 | ML 训练 Agent | 标注 Agent 集群 | 交叉验证合约 |
| 智能合约审计 | 开发团队 Agent | 安全审计 Agent | ZK 验证合约 |
| 多语言翻译 | 国际化 Agent | 翻译 Agent | 人类+AI 混合评估 |
| API 按需购买 | 分析 Agent | API 服务商 | 响应校验合约 |
本质上，任何可以拆成"发任务 → 交活 → 验收"三步的服务，都可以用 ERC-8183 来跑。
六、局限性
直说几个问题。
评估者权力过大。 Submitted 阶段评估者说了算，如果评估者恶意拒绝，提供商没有申诉渠道。协议里没有内置仲裁——这是"最小化设计"的有意取舍，但确实意味着选错评估者就是丢钱。实际使用中，要么用链上声誉来筛选评估者，要么直接用智能合约做评估者（逻辑透明可审计），要么通过 Hook 加一层质押惩罚。
拒绝/过期是终局的。 没有"上诉"机制，评估者一旦 reject，这笔交易就结束了。如果确实需要仲裁，得自己在 Hook 层做——比如 reject 前先触发一个多签投票。
过期时间不好定。 设短了，提供商来不及干完活；设长了，客户的资金被锁太久。协议不提供建议值，这个得应用层自己拿捏。
没有发现机制。 ERC-8183 只管"做买卖"的流程，不管"怎么找到交易对手"。Agent 怎么发现可用的任务、怎么匹配供需，得靠上层的应用或市场协议来解决。
七、和其他协议的对比
| 协议 | 解决什么问题 | 一句话 |
|---|---|---|
| A2A | Agent 之间怎么通信 | 对话协议 |
| MCP | Agent 怎么调用工具 | 工具协议 |
| x402 | 怎么在 HTTP 层嵌入支付 | 支付协议 |
| AP2 | Agent 替人花钱需要谁授权 | 授权框架 |
| ERC-8004 | Agent 的身份和信誉 | 信任基础设施 |
| ERC-8183 | Agent 之间怎么做一笔生意 | 商业原语 |
打个比方：A2A/MCP 是电话和公路，x402/AP2 是银行和支付宝，ERC-8004 是身份证和征信系统，ERC-8183 是合同法。各管各的，组合起来才是一个完整的经济体。
八、小结
ERC-8183 做的事情不复杂：定义了一个 Job 的生命周期，三个角色，六个状态，加一套资金托管和 Hook 扩展机制。
它的价值在于"刚刚好"——比直接转账多了一层保障（托管 + 评估者验收），又比搭一个完整的去中心化市场轻量得多。对于 Agent 之间的高频服务交易，这个粒度可能刚好是对的。
目前还是草案阶段，核心设计已经定型，但细节可能还会调整。如果你在做 Agent 相关的项目，值得关注一下这个协议后续的演进。
本文基于 ERC-8183 草案（2026-02-25）撰写，协议仍在演进中。
关注公众号「coft」，获取更多 AI 时代的深度洞察和技术实战干货。
浙公网安备 33010602011771号