3 月 10 日，以太坊基金会旗下致力于推动“人工智能（AI）与区块链深度整合”的 dAI 团队，携手 Virtuals Protocol 共同推出了一项全新标准——ERC-8183。
以太坊基金会 AI 负责人 对该标准评价道，ERC-8183 是以太坊社区正在搭建的开放型 Agent 经济系统中不可或缺的一环。它可与 x402 以及 ERC-8004 协同工作，在保障 Agent 间安全交互方面发挥关键的基础设施作用。此外，dAI 团队表示将全力支持 ERC-8183 的普及应用，并致力于将其打造为行业中立的标准。
一、ERC-8183是什么？
ERC-8183全称为「代理商务标准」，这是一项运行在以太坊上的无需许可且可编程的链上智能合约规范。其核心在于「Job」这一原语，本质上是为AI代理之间的交易构建了一套去信任化的完整流程，从而摆脱对任何中心化平台的依赖，规避单点故障风险及规则被篡改的可能性。
简而言之，ERC-8183确立了AI代理之间「放心做生意」的去中心化规则。它主要解决的是不同智能体因缺乏信任基础而导致的交易履约保障缺失问题。
其运作逻辑清晰明了：每笔代理交易都对应一个「Job」，涉及三方参与者，仅通过钱包地址进行身份标识，准入门槛极低。这三方分别是客户端（发起任务并付费）、提供者（执行任务并提交成果）以及评估者（审核成果并判定结果）。
具体流程如下：客户端创建任务并支付费用，资金随即存入链上托管账户，以防付款后无法获取成果；提供者在完成任务后，将成果（或成果的哈希值）上传至链上；随后，评估者进行审核，若确认无误则向提供者放款，否则拒绝并退款给客户端；若评估者未在规定时间内操作，资金将自动退回客户端。整个过程由智能合约强制自动执行，无需人工介入。
针对不同性质的任务，评估者可灵活选择：主观性任务（如设计、写作）可由AI代理担任评估者；确定性任务（如数据转换）可由零知识证明智能合约担任；而在高风险交易场景中，则可由DAO或多重签名验证器来确保公正性，杜绝评估不公现象。
二、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 经济系统。
以上就是ERC-8183是什么标准？想解决什么？ERC-8183和x402、ERC-8004有何不同？的详细内容，更多关于一文详解ERC-8183的资料请关注其它相关文章！