Quicknode

2026年6月22日 — 阅读时间8分钟

AI 代理可以生成代码、执行工作流，并与外部服务进行交互。

寻找新工具仍然困难得多。

大多数代理依赖于预先配置好的集成，无论是通过提示、框架、API 还是应用市场实现的。随着代理可访问的服务数量不断增加，这种方法在扩展方面变得越来越困难。

ERC-8257 提供了一种无需许可的方式，用于发现和验证具有代理功能的工具和服务。

本文将解释什么是 ERC-8257，代理工具注册表是如何运作的，它如何融入整体代理基础设施栈，以及该注册表能释放哪些功能。

什么是 ERC-8257

ERC-8257（代理工具注册表）是一项以太坊标准草案，旨在定义一个面向人工智能代理和工具的无许可链上注册表。该标准规范了关于工具的定义、发布者以及获准调用该工具的对象等信息的最小化、可验证记录。

2026年4月，OpenSea的科迪·西尔斯（Cody Sears）和瑞安·戈兹（Ryan Ghods）提出了这一标准，旨在让人工智能代理能够自主发现、购买使用权限并调用各类工具。

ERC-8257 的工作原理

每个已注册的工具或符合 ERC-8257 标准的代理都将拥有一个包含 3 个组成部分的链上记录：

1. 创作者地址：出版商，在注册时永久绑定

2. 元数据 URI：指向该工具链下清单的指针

3. 清单哈希：用于验证描述是否未发生更改

此外，访问谓词中还有一个可选的第四个组成部分，即一个合约地址，用于决定谁可以调用该工具。

这些要素共同构成了工具元数据的统一可信来源，并提供一项保证：您获取的清单正是创建者从其控制的源地址，使用其签名的地址所提交的那个。

在了解了代理工具注册表的用途及其包含的组件之后，让我们来学习它们是如何协同工作的，以及其工作流程是怎样的。

ERC-8257 中包含两个工作流，即：

1. 注册流程：发布者与注册机构之间的交互。

2. 发现与验证流程：代理、注册表和工具之间的相互作用。

让我们分别来了解一下。

ERC-8257：注册流程如何运作

注册流程规定了工具如何发布并使其可被发现。发布者会注册该工具的创建者地址、元数据 URI 以及清单哈希值（外加一个可选的访问谓词），从而创建一条链上记录，代理程序随后可以解析并验证该记录。

ERC-8257：发现与验证的运作机制

当代理发现某个工具或服务时，这一发现和验证过程会建立对代理所读取的元数据的信任。

一旦代理确认清单、发布者和访问要求与注册记录一致，注册机构的作用即告结束。

到目前为止，ERC-8257 看起来像是一个普通的注册表，但正是由于可选的谓词部分，ERC-8257 才不仅仅是一个注册表。

ERC-8257 访问控制：谓词模式详解

代理工具注册表解决了工具的发现和验证问题。但是，并非每个工具都应能被每个代理调用，也不应完全公开。

某些服务可能需要订阅。其他服务则可能仅限于 NFT 持有者、企业客户或符合特定信誉要求的代理商使用。

ERC-8257 通过一个名为“访问谓词”（access predicate）的可选组件解决了访问问题：这是一个外部合约，用于决定调用者是否可以使用某项工具。

什么是谓词基于访问控制

访问谓词是附属于工具注册的合约地址。

当一个代理试图使用某项工具时，它可以调用谓词合约并提出一个简单的问题：该调用者是否被允许访问此工具？

现在，谓词合约可以验证某个代理是否拥有 NFT、持有订阅代币、已支付访问费用、属于白名单，或者满足声誉要求。

不同的工具可以实施不同的策略，而无需更改注册表本身。以下是一些示例：

最重要的是，ERC-8257 并未将这些规则硬编码进去，而是将谓词合约设计为可选的附加组件，既保持了标准的轻量级特性，又确保其能够扩展以适应多种用例。

现在我们已经了解了代理工具注册表是什么、它是如何注册的、代理如何发现它，以及访问是如何被控制的。接下来，你可以用它来构建什么呢？

ERC-8257 带来了什么

仅就注册表本身而言，并没有什么特别之处。

DNS之所以变得重要，是因为可以通过它发现网站。软件包注册表之所以变得重要，是因为软件可以依赖它们。应用商店之所以变得重要，是因为它们将用户与应用程序连接了起来。

ERC-8257 为代理可访问的工具构建了一个发现层。让我们来探索一下由此所开启的一系列功能：

1. 代理型市场

每款工具都具备可验证的来源、可编程的访问权限以及链上定价提示。仅凭这些，就足以构建一个市场，让用户在无需平台运营商介入的情况下，发现、使用和交易这些工具。

2. 可编程接入市场

工具提供商可以通过谓词合约定义定价、订阅、代币持有要求、信誉阈值或企业级权限。这种灵活性使得不同的访问模式能够相互竞争，同时在发现层保持互操作性。

3. 可组合的代理工作流

借助 ERC-8257，现在可以实现多步骤智能合约管道，其中每个工具均可独立验证并设置验证门槛。

例如，一个交易代理可以与一个全天候运行的新闻抓取工具关联，或者一个预测市场代理可以与一个 Twitter（X）代理关联。

ERC-8257 提供了一种标准方法来发现和验证这些依赖关系，从而使跨独立提供商构建多代理工作流变得更加容易。

4. 开放式代理生态系统

每个平台最终都会面临同样的挑战：维护自己的服务目录。

ERC-8257 将这一责任转移到了共享基础设施上。工具提供商只需发布一次，代理框架、钱包、交易市场和应用程序即可调用相同的记录。

5. 跨组织代理工作流

如今，大多数代理工作流都在单一组织或平台内运行。

ERC-8257 为供应商与客户、客户与市场等跨组织工作流铺平了道路。

例如，研究人员可以通过购买方式获取通过注册工具公开的专有数据源。

现在我们已经了解了 ERC-8257 的工作原理和功能。接下来需要了解的是，为了使智能合约真正发挥作用，所需的更广泛的智能合约技术栈。

ERC-8257 在 Agentic 基础设施堆栈中的位置

ERC-8257 解决了更广泛的代理栈中一个具体问题：能力发现和可验证交互。

但是，代理之间仍需具备身份识别、执行环境、支付通道以及协调机制才能进行交互。

现在让我们把这个栈组装起来吧。

从这个角度来看，ERC-8257与其说是一项人工智能标准，不如说更像是一种基础设施。

• 已注册的工具可能会暴露 MCP 服务器。

• 某个谓词可能要求在授予访问权限之前先进行支付。

• 可以使用代理身份标准来证明请求的发起者是谁。

这些责任均不属于 ERC-8257 本身。

该标准的作用是回答一个更简单的问题：“有哪些功能可用，以及在哪里可以找到这些功能？”

目前，架构是稳健的，设计选择也是合理的。尚待解决的问题在于采用情况。

ERC-8257 的下一步发展

如今，大多数软件都是围绕直接集成构建的。

开发人员选择一项服务，阅读其文档，根据其 API 编写代码，并长期维护这种关系。

ERC-8257 并未推进这一目标，而是将代理基础设施推向了另一个方向。

• 功能可在运行时被发现。

• 访问策略变得可编程。

• 无需人工审批即可使用这些服务。

ERC-8257 是一个常见的发现层。这看起来可能只是基础设施中的一小部分。

DNS 曾是基础设施中的一小部分。软件包注册表曾是基础设施中的一小部分。应用商店最初只是目录。

更艰巨的挑战还在后头。

代理应如何评估声誉？市场平台应如何对工具进行排名？自主系统之间的支付、订阅或收益分成应遵循哪些标准？组织应如何在不损害安全性的前提下展示内部能力？

ERC-8257 并未直接解答这些问题。它只是开启了对话，并指明了解决问题的方向。

常见问题解答（FAQ）

1. ERC-8257 是如何运作的？

提供者通过发布创建者地址、元数据 URI、清单哈希值以及可选的访问谓词来注册工具。代理会检索该清单，将其与链上记录进行比对验证，评估任何访问要求，然后调用该工具。

2. 什么是 ERC-8257 清单？

清单是对工具的机器可读描述。它包含元数据，例如功能、端点、使用要求以及代理程序理解该服务并与之交互所需的其他信息。

3. ERC-8257 仅适用于 AI 代理吗？

不。任何机器可访问的服务都可以通过 ERC-8257 进行注册。虽然该标准的设计初衷是针对人工智能代理，但 API、软件服务、自动化系统及其他可编程应用程序均可采用相同的发现模型。

4. ERC-8257 与 MCP 有什么区别？

MCP 规范了工具的暴露和调用方式。ERC-8257 规范了工具的发现和验证方式。这两者相辅相成，可在同一代理架构内协同使用。

5. 开发者可以利用 ERC-8257 构建什么？

开发人员可以在共享注册表标准的基础上，构建代理市场、可编程访问系统、跨组织代理工作流、服务发现层以及多代理生态系统。

6. ERC-8257 是否已在主网上线？

是的。ToolRegistry 合约部署在 0x265BB2DBFC0A8165C9A1941Eb1372F349baD2cf1 在以太坊主网和Base上。截至2026年年中，已有76种工具被收录。该EIP仍处于草案阶段，这意味着在最终确定之前，该接口仍可能发生变化。

7. ERC-8257 是否将工具元数据存储在链上？

不。该注册表存储的是元数据的引用，而非元数据本身。工具描述仍保存在链下，而存储在链上的哈希值则允许代理验证其完整性。