详解ERC-8183：以太坊攻坚AI Agent互信难题的答案 | 加密百科深度分析
加密百科独家解读
这件事，简单说，就是以太坊给AI“打工人”们制定了一套“支付宝”规则。
想象一下，未来网络上有很多AI程序（Agent），它们可以自己接活、自己干活。比如一个负责写文案的AI，想找一个会画图的AI帮忙做海报。问题来了：两个AI互不认识，怎么保证交易靠谱？画图的怕干了活拿不到钱，写文案的怕先付了钱对方糊弄事。
过去，这种问题靠淘宝、滴滴这样的“平台”解决。平台作为中间人，保管钱、判断活干没干好、最后打款。现在，以太坊基金会想用区块链和智能合约，做一个“去信任”的、自动运行的平台，这就是ERC-8183标准。
它的核心机制很像一个“智能合约托管系统”：
1. 发布任务：客户AI（Client）把任务要求和佣金，锁进一个智能合约。
2. 接单干活：服务商AI（Provider）看到任务，完成工作后，把“作业证明”提交上链。
3. 关键裁决：这时，一个叫“评估者”（Evaluator）的角色出场。它可以是另一个AI、一个自动验证程序，甚至是一个DAO组织。它的唯一任务就是判断：活干得合格吗？
4. 自动结算：评估者说“合格”，智能合约自动把钱打给服务商AI；说“不合格”，钱就退回给客户AI。
这个设计的巧妙之处在于，它把最难的“主观判断”问题，抽象成了一个地址的“是或否”信号。协议不关心评估者是人、是AI还是代码，只认它发出的指令。这为各种复杂的AI服务交易提供了可能性。
另外，它和之前以太坊社区的其他标准是“组合拳”关系：
x402：相当于给AI装了个“支付二维码”，让它能随时扫码付款。
ERC-8004：相当于给AI发了个“身份证+大众点评”，记录它的历史和信誉。
ERC-8183：则是制定了完整的“雇佣-验收-发薪”工作流程。
三者合在一起，目标就是搭建一个基础设施，让AI们能在以太坊上形成一个去中心化的“劳务市场”，自己赚钱、自己花钱、自己合作，不再需要人类公司或中心化平台在中间当老板和裁判。这是在为未来高度自动化的AI经济体铺设铁轨。
背景资料 (原快讯)
原创 | Odaily （@OdailyChina）
作者｜Azuma（@azuma_eth）
3 月 10 日，以太坊基金会旗下专注于推动“人工智能（AI）与区块链深度整合”的 dAI 团队与 Virtuals Protocol 联合推出了一项新的标准 ERC-8183。
以太坊基金会 AI 负责人 Davide Crapis 就该标准表示，ERC-8183 是以太坊社区正在构建的开放型 Agent 经济系统所缺失的组件之一，该标准可与 x402 以及 ERC-8004 组合使用，在 Agent 之间的安全交互方面发挥基础设施作用。dAI 团队将支持 ERC-8183 的采用，致力于使其成为中立标准。
ERC-8183 想解决什么？
根据 Virtuals Protocol 方面所发布的介绍文章，ERC-8183 专为 AI Agent 之间的商业交易而设计，该标准定义了一套链上规则，使两个互不信任的 Agent 能够完成“雇佣-交付-结算”这样的商业流程，而不需要依赖中心化平台。
ERC-8183 试图解决的核心问题是，当 Agent 彼此雇佣和合作时，如何在没有平台、没有法律、没有人工仲裁的情况下完成交易？
举个例子，假如某个偏市场推广方向的 Agent A 希望雇佣另一个偏图像生成的 Agent B 来为其制作一批营销海报，这里就存在一个商业互信问题 —— 双方互不认识，也没有信任基础，到底该什么时候付款？假如 A 先付款，B 可能罢工或者返还不合格的工作结果；假如 B 先干活，A 也有可能拒付报酬……
在传统的互联网世界，用户与商家也会面临类似的商业互信，而平台则在其中承担了关键的中介作用 —— 平台会负责托管 A 的资金，会负责判断 B 的服务完成与否，也会负责最后的放款。我们熟悉的淘宝、京东、美团、滴滴，本质上都是这种平台型中介。
而以太坊基金会和 Virtuals Protocol 想要做的，便是通过 ERC-8183 将平台的职能抽象为链上协议，使其由智能合约执行，从而在 Agent 经济中承担起一种去中心化的中介角色。
ERC-8183 工作方案拆解
ERC-8183 的运行机制并不复杂，该标准引入了一个名为 Job（你可以理解为“任务”）的新概念。每一个 Job 都可以视作一笔完整的商业交易，其中会包含三个不同的角色：
- Client：“客户”，简单来说就是发布各类任务的 Agent；
- Provider：“服务商”，就是负责完成任务的 Agent；
- Evaluator：“评估者”，最为特殊的角色，负责判断任务是否完成。
这里需要需要着重解释下 Evaluator，该角色的引入是 ERC-8183 最核心的设计。在该标准中，Evaluator 仅被定义为一个链上地址（address），但从更广义的角度来看，该地址背后可以对应多种不同的执行形态。
- 对于诸如写作、设计或分析这类具有主观性的任务，Evaluator 可以是一个 AI Agent，它会读取所提交的结果，将其与最初的任务要求进行对比，然后作出判断；
- 而对于计算、证明生成或数据转换等确定性任务，Evaluator 则可以是一个封装了零知识验证器（ZK verifier）的智能合约。Provider 提交证明，Evaluator 在链上进行验证，并自动调用「complete」或「reject」来完成或拒绝该任务；
- 在高价值或高风险的任务场景中，Evaluator 还可以是一个多签账户、DAO、或是由质押机制支撑的验证集群。
ERC-8183 并不会区分这些不同形态。协议层只关心一点 —— 某个地址是调用「complete」还是「reject」，至于这个地址背后运行的是一个由 LLM 驱动的 AI Agent，还是一个 ZK 电路，都不属于协议需要关心的范围。
继续说回 Job，每一个 Job 的生命周期都会有以下四种状态，这也对应着 ERC-8183 运转时的不同流程。
- Open：Client 会在此周期创建 Job，发布任务并明确要求；
- Funded：Client 会把佣金转去一个智能合约托管地址，而非直接交给 Provider；
- Submitted：Provider 完成工作并提交证明；
- Terminal（Completed / Rejected / Expired）：Evaluator 负责审核任务，并根据审核结果判断任务是否完成（Completed 或 Rejected）并将资金分别转给 Client 或 Provider；若在时间要求内没有 Provider 响应或完成任务，资金会退还给 Client。
除去上述标准流程外，ERC-8183 还可通过模块化的扩展功能 Hooks 来实现更多衍生功能，以对应现实世界的复杂商业用例。Hooks 是 Job 创建时附加的可选智能合约，可在 Job 各个生命周期的前后执行自定义逻辑，比如信誉门槛、竞价机制、费用分配，或是其他特殊要求。
ERC-8183 和 x402、ERC-8004 有何不同？
从 x402 到 ERC-8004，再到如今的 ERC-8183，不太熟悉的读者可能会一头雾水，纳闷为什么隔一阵子就要做一个新的东西。但其实，这三者分别处在 AI Agent 经济系统的三个不同环节，想要解决的问题也各不相同。
x402 是一个 HTTP 支付协议，它想要解决的问题是让 AI Agent 能够像调用 API 一样直接付款；ERC-8004 是 AI Agent 身份与声誉标准，它解决的问题是如何判断一个 Agent 是否可靠；ERC-8183 则面向了商业交易环节，想攻破如何让两个不信任的 Agent 完成交易的难题。
如果用一句话概括就是，x402 负责解决“怎么付钱”；ERC-8004 负责知道“对方是谁、靠不靠谱”；ERC-8183 负责处理“怎么放心地去交易”。
三者并非竞争关系，而是互补关系，它们共同指向着同一个目标 —— 构建一个去中心化、能够自主运转的 AI Agent 经济系统。
注：以上背景资料自公开行业资讯，加密百科网仅作科普解读。