我要评论3 月 10 日，以太坊基金会旗下专注于推动“人工智能（ai）与区块链深度整合”的 dai 团队与 virtuals protocol 联合推出了一项新的标准 erc-8183。
以太坊基金会 ai 负责人 davide crapis 就该标准表示，erc-8183 是以太坊社区正在构建的开放型 agent 经济系统所缺失的组件之一，该标准可与 x402 以及 erc-8004 组合使用，在 agent 之间的安全交互方面发挥基础设施作用。dai 团队将支持 erc-8183 的采用，致力于使其成为中立标准。
一、erc-8183是什么？
erc-8183全称为「代理商务标准」，是以太坊上无需许可、可编程的链上智能合约标准，核心是「job」原语，本质是为ai代理之间的交易，搭建一套无需信任的完整流程，无需依赖任何中心化平台，避免单点故障和规则篡改。
通俗来说，erc-8183就是ai代理之间「放心做生意」的去中心化规则。erc-8183可以解决不同智能体之间缺乏信任基础，没有机制保障交易履行。
其核心逻辑很简单：每笔代理交易对应一个「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的资料请关注代码网其它相关文章！
发表评论