ERC-8183：自主代理商务入门指南

decipherclub 发布于 2026-06-05 阅读 189

ERC-8183 是用于自主AI代理的基于托管的工作协议，定义了客户端、提供者和评估者三个角色，以及Open、Funded、Submitted、Terminal四个状态。客户端锁定ERC-20代币在托管中，提供者提交交付物，评估者决定释放资金或拒绝。通过可选的Hook系统支持信誉门控、SLA等扩展。该标准由以太坊基金会和Virtuals Protocol共同制定，已有多链实现，但评估者信任问题仍是最大挑战。

机器现在可以雇佣其他机器了。

不是通过 API 密钥、订阅，或者人类在支付页面上点击“批准”。而是通过一个以太坊标准——将托管、评估和可执行的服务协议直接嵌入智能合约中。

ERC-8183 是代理型商业协议（Agentic Commerce Protocol）。它定义了 AI 代理如何发布任务、将资金锁定在托管中、接收可交付成果并结算付款——所有这些都在链上完成，完全无需信任，完全不需要人类参与其中。以太坊基金会共同撰写了该协议。Virtuals Protocol 构建了第一个生产实现。 BNB Chain、Arc Network 以及其他越来越多的项目正在采用它。

而几乎没有人——除了代理基础设施圈内的人——在关注它。

让我们直接深入探讨。

用 100 字概括 ERC-8183

ERC-8183 是一个基于托管的自主代理任务协议。

三个角色：客户端发布任务，提供者执行工作，评估者——一个指定的第三方——决定工作是否完成。

四个状态：开放、已资金锁定、已提交、终态。客户端将 ERC-20 代币锁定在托管中。提供者提交可交付成果。评估者要么将资金释放给提供者，要么拒绝任务，将资金返还给客户端。如果在到期前无人操作，任何人都可以触发退款。

可选 Hook（Hooks）通过信誉门槛、SLA 强制执行或自定义逻辑扩展了生命周期。

三个角色

我们来具体化。假设我们有一个 AI 研究代理——称其为代理 R——它需要一份关于 Uniswap V3 池过去 90 天行为的分析报告。代理 R 没有进行该分析所需的工具。但代理 D——一个专门从事链上分析的数据代理——有。

以下是在 ERC-8183 下它们进行交易的方式。

客户端 —— 代理 R。发布任务，指定可交付成果（“90 天 Uniswap V3 池分析报告”），设置付款（100 USDC），指定评估者，并设置到期时间窗口。代理 R 是付款方。

提供者 —— 代理 D。接受任务，执行分析，在链上提交可交付成果（指向报告的哈希或 URI）。代理 D 是工作方。

评估者 —— 在任务创建时指定的第三方代理或合约。不是代理 R，也不是代理 D。评估者是唯一有权释放托管资金或拒绝提交的一方。这个设计决策使 ERC-8183 有别于简单的代币转账——一个中立的第三方持有判断权。

为什么这很重要？

没有评估者角色，代理商业会退化为两种失败模式之一。要么客户端预先支付并希望提供者交付（基于信任，无追索权）。要么提供者先交付并希望客户端支付（基于信任，无保障）。ERC-8183 通过将资金锁定在托管中并将释放决策交给指定的第三方，消除了这两种情况。

四状态生命周期

ERC-8183 中的每个任务都遵循相同的状态机。无一例外。

开放 —— 代理 R 调用 createJob。它指定代理 D 的地址、评估者的地址、到期时间戳、任务描述、支付代币（USDC）、金额（100 USDC），以及一个可选的 Hook 合约。资金尚未锁定。该任务仅以承诺的形式存在，而不是一笔付款。

已资金锁定 —— 代理 R（或任何一方）调用 fundJob。100 USDC 从代理 R 的钱包转移到合约的托管中。资金被锁定。代理 D 现在可以开始工作，知道付款存在且无法被撤回（除非通过评估者或到期）。

已提交 —— 代理 D 完成分析报告。它通过一个可交付成果引用（指向报告的 IPFS 哈希、URI 或链上数据）调用 submitJob。任务进入已提交状态。现在评估者做出决定。

终态 —— 以下三种结果之一：

评估者调用 completeJob。100 USDC 从托管释放给代理 D。任务完成。

评估者调用 rejectJob。100 USDC 返还给代理 R。代理 D 交付了，但工作未达到标准。

在到期时间戳之前无人操作。任何人都可以调用 claimRefund。100 USDC 返还给代理 R。系统默认保护客户端的资金。

那么这在实践中意味着什么？

这意味着代理 R 可以在无需信任代理 D 的情况下雇佣它。托管保证了资金的存在。评估者保证了只有在工作得到验证时资金才会移动。到期保证了资金永远不会被永久卡住——即使评估者消失。

一个合约。三个角色。四个状态。这就是整个原语。

Hook 系统——为什么极简主义有效

ERC-8183 故意设计得非常精简。基础规范处理了托管和状态转换。其他一切——信誉、SLA、自定义支付逻辑——通过 Hook 插入。

Hook 是附加到任务上的可选智能合约，在每个状态转换之前或之后执行额外的逻辑。该规范定义了 IACPHook 接口。开发者实现它。

目前存在三个生产级 Hook。

ReputationHook —— 在每个任务解决后自动将任务结果（已完成或已拒绝）写入 ERC-8004 的 ReputationRegistry。每个完成的任务都会提高提供者的链上信誉。每个拒绝都会损害它。

ReputationGateHook —— 在允许 fundJob 执行之前，通过检查提供者的 ERC-8004 信誉评分来限制提供者的资金锁定。信誉低于阈值的提供者无法接收已资金锁定的任务。此 Hook 在 Base 主网上线，合约已验证。

SLAHook —— 在资金锁定后强制执行提交截止日期。如果提供者未在 SLA 窗口内提交，任务可以提前到期。除了全局到期之外，还增加了基于时间的约束。

现在，以下设计决策揭示了规范作者的优先级。

claimRefund 被故意排除在 Hook 系统之外。如果 Hook 可以阻止退款请求，那么恶意 Hook 合约可以通过每次 claimRefund 尝试时回退来永久锁定托管资金。通过使退款无法被 Hook 拦截，ERC-8183 保证过期的任务总是将资金返还给客户端——无论附加了什么 Hook 逻辑。

安全优先于灵活性。这就是权衡，而且它是正确的。

谁构建了它

四位共同作者在 EIP 上。

Davide Crapis —— 以太坊基金会 AI 负责人，dAI（去中心化 AI）计划负责人。EF 在 AI 代理基础设施方面的关键人物。

Bryan Lim、Tay Weixiong 和 Chooi Zuhwa —— Virtuals Protocol 团队。其中三位作者。

起源故事很重要。Virtuals Protocol 一直在运行一个名为 Agent Commerce Protocol 的内部系统——一个专有的基于托管的任务系统，用于其 18,000+ 代理生态系统。ACP 在 ERC 标准出现之前就已经在运行。当 Virtuals 团队联系以太坊基金会的 Crapis 时，目的是将 ACP 的内部合约逻辑转换为一个开放、中立的 ERC 标准——任何开发者或平台都可以采用，而无需供应商锁定。

ERC-8183 于 2026 年 2 月 25 日提交。3 月 10 日公开宣布。八天后，即 3 月 18 日，BNB Chain 推出了 BNBAgent SDK 作为“第一个实时实现”。Arc Network 随后在 4 月发布了教程和黑客松。

截至 2026 年 5 月，该 EIP 仍处于草案状态。尚未进入审查或最终状态。

谁在使用它

Virtuals Protocol —— 主要的生产部署。在 Base 和 Arbitrum 上运行。更广泛的 Virtuals 生态系统包括 18,000+ 个代币化代理。Virtuals 于 2026 年 2 月推出了一个收入网络，每月通过 ACP 向出售服务的代理分发最高 100 万美元。ACP v2 包含了统一的任务接口、自定义任务提供定义、持久化链上账户（代理间关系历史）以及完成后跟进的提醒备忘录。

关于数字的一个注意事项。Virtuals 声称有 200 万+ 笔 ACP 交易。我们无法独立验证这一点——该数字来自一个单一的二手来源，且 ERC-8183 托管交易与更广泛的 ACP 系统活动之间的细分并未公开。其发展势头是真实的。精确规模无法验证。

BNBAgent SDK —— BNB Chain 的实现，于 2026 年 3 月在测试网上线。主网待定（无确认日期）。值得注意的补充：BNBAgent 通过 UMA 的数据验证机制处理争端，代币持有者投票决定结果。这增加了一个争端解决层，而基础 ERC-8183 规范故意排除了这一层。

Arc Network —— 一个专注于 USDC 计价代理商业的稳定币原生 L1。发布了“创建你的第一个 ERC-8183 任务”教程，并于 2026 年 4 月举办了“Arc 上的代理型经济”黑客松。

AgentHire —— Avalanche Fuji 测试网上的一个开源市场，实现了完整的雇佣-竞价-评估-结算流程，包括 EIP-712 签名竞价和信誉门槛。

模式很清晰。多个链，多个实现，都收敛于同一个规范。这就是标准应该做到的。

ERC-8183 在堆栈中的位置

三个互补的标准正在形成链上代理商业的基础设施。理解它们之间的关系是重要的心智模型。

ERC-8004 回答：这个代理是谁，我们能信任它吗？身份注册和链上信誉。

ERC-8183 回答：代理如何雇佣、交付、评估和结算？商业层——托管、任务生命周期、评估。

x402 回答：资金如何在每次 HTTP 请求中移动？每次调用的微支付，无托管，无评估。

三者并非竞争对手。它们是不同层次。

ERC-8183 的 ReputationGateHook 消耗 ERC-8004 的信誉评分——提供者必须有最低信誉才能接收已资金锁定的任务。ERC-8183 的 ReputationHook 写回 ERC-8004——每个已完成或已拒绝的任务自动更新提供者的信誉。这两个标准相互促进。

那么什么时候使用哪一个？

一个需要一次性数据查询的代理——单次 API 调用，支付 0.002 美元，获得响应——使用 x402。不需要托管，不需要评估。支付即走。

一个需要另一个代理执行多步骤任务的代理——研究一个主题，生成一份报告，提交审核——使用 ERC-8183。托管锁定资金。评估者验证可交付成果。只有工作通过时提供者才能获得报酬。

它们不可互换。它们服务于不同的交易模式。

ERC-8183 没有解决的问题

该规范诚实地说明了其边界。它故意遗漏了三件事。

没有争端解决。 拒绝或到期是最终的。评估者的决定不能在基础标准内上诉。BNBAgent SDK 通过将争端提交给 UMA 的 DVM 来解决这个问题。但规范本身并未规定仲裁。每个实现必须独立解决对评估者的信任问题。

仅限单链。 没有本地机制让在以太坊上创建的任务在 Base 上托管资金或在 Arbitrum 上提交可交付成果。跨链任务编排需要桥接集成或一个更高级别的协议来协调跨链的 ERC-8183 实例。

评估者信任问题。 这是一个大问题。评估者拥有单方面批准或拒绝的权力。恶意评估者可以批准糟糕的工作（窃取客户端的资金）。恶意评估者可以拒绝好的工作（折磨提供者）。该规范定义了该角色，但没有指定如何选择可信任的评估者。

信誉 Hook 有所帮助——它们限制提供者的进入。但它们不能防止评估者的不当行为。评估者是整个 ERC-8183 经济的关键。并且这仍然是一个开放的设计空间。

对于客观任务——交易是否执行？数据是否匹配模式？——自动化评估者有效。对于主观任务——这个报告好吗？这个创意工作可以接受吗？——评估需要判断力，而当前的链上机制无法可靠提供。

现在，当你读到此时，可能会产生一个反对意见。

“但这不就是一个花哨的托管合约吗？智能合约托管自 2017 年以来就存在了。”

是的——托管模式并不新鲜。两方锁定加释放条件是 Solidity 中最古老的原语之一。

但 ERC-8183 不是托管。托管是骨架。

新的东西是三个角色的分离——客户端、提供者和一个中立的评估者（既不是客户端也不是提供者）——加上一个可 Hook 化的生命周期。信誉门槛、SLA 强制执行和自定义结算逻辑都可以插入状态机，而无需任何人修改基础合约。旧的托管说“当 X 发生时释放”。ERC-8183 说“当评估者决定时释放，并让信誉、截止日期和策略在同一任务上随行”。

托管是骨架。Hook 系统是神经系统。

代理商业中最难的问题

支付层已解决。x402 处理每次请求的微支付。ERC-8183 处理基于托管的任务支付。资金流动。

身份层已解决。ERC-8004 为代理提供可验证的链上身份和信誉。我们知道它们是谁。

商业生命周期已解决。ERC-8183 定义了任务状态——创建、资金锁定、提交、评估、结算。工作流存在。

但判断层——谁来决定工作是否好？——尚未解决。ERC-8183 没有解决，任何标准也没有解决。

而判断层决定了代理商业是成为一个真正的经济体，还是停留在系列玩具演示的水平上。

那些解决评估问题——可靠、无需信任、可扩展的代理输出质量评估——的建设者将控制代理经济中最重要的基础设施。规范作者知道这一点。他们故意将评估者留作开放的设计空间。不是因为他们无法定义它，而是因为过早地对判断进行标准化比完全没有标准化更糟糕。

代理商业中最难的问题不是支付、不是身份、不是托管。而是判断。

延伸阅读

致谢 Decipher 团队

无信任代理失败之处，以及我为何构建无信任代理 Plus\ 无信任代理失败之处，以及我为何构建无信任代理 Plus \ \ ERC-8004 给了代理一个身份。它忘记了它们生活在不止一条链上。\ \ 发布三个月后，该标准在 23+ 条链上拥有约 200,000 个注册代理。这个数字看起来像是被采用了。仔细看，它看起来像是一个问题。\ \ 这些代理中的每一个都在一个……那么，“无信任代理”到底在做什么？\ 那么，“无信任代理”到底在做什么？ \ \ ERC-8004 不是你想的那样。\ \ 大多数人听到“无信任代理”时，会认为该标准开箱即用就提供了无信任性。事实并非如此。它提供的是更温和的——说实话——在当前阶段更有用的东西：一个协调原语，为 AI 代理提供链上……TAP 在幕后实际如何工作\ TAP 在幕后实际如何工作 \ \ 关于我如何为链上 AI 代理制作 TAP 项目的详细概述。\ \ 上周我介绍了 TAP —— 为碎片化的 ERC-8004 代理提供规范身份和聚合信誉。\ \ 本周更深入。\ \ 我分解了每个组件：TAPRegistry 如何从单个钱包派生确定性的代理 ID，如何……无信任代理 Plus - 深度解析\ 无信任代理 Plus - 深度解析 \ \ AI 代理面临多链身份危机。\ \ 一个危机：同一个代理在三条不同的链上作为三个不同的实体存在，而没有任何链上机制能证明它们是同一个。\ \ ERC-8004 为 AI 代理提供了链上身份。\ \ 现在已有超过 200,000 个代理在 23+ 条链上注册，高于……

  • 原文链接： decipherclub.com/erc-818...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
微信扫码分享

相关文章

0 条评论

登录后发表评论