什么是 ERC-8257？Agent Registry 详解
什么是 ERC-8257？Agent Registry 详解
什么是 ERC-8257？一份关于Ethereum Agent 注册表、工具发现、谓词、agent 以及人工智能基础设施的指南。
在您的应用中实现 USDC 收益自动化Quicknode 的Earn API负责管理金库、资产再平衡和跨链桥接。已在7条链上上线。
阅读公告什么是 ERC-8257？Agent Registry 详解
什么是 ERC-8257？一份关于Ethereum Agent 注册表、工具发现、谓词、agent 以及人工智能基础设施的指南。
通过 SOC 2 II 类认证 · ISO 27001
2026年6月22日 — 阅读时间8分钟
AIagents 生成代码、执行工作流，并与外部服务进行交互。
寻找新工具仍然困难得多。
大多数agents 预先配置好的集成，无论是通过提示、框架、API 还是应用市场实现的。随着agent的服务数量不断增加，这种方法已难以实现规模化。
ERC-8257 提供了一种无需许可的方式，用于发现和验证代理工具及服务。
本文将解释什么是 ERC-8257agent 注册表是如何运作的，它如何融入整体代理基础设施栈，以及该注册表能释放哪些功能。
ERC-8257（Agent 注册表）是一项Ethereum 旨在定义一个面向人工智能agents 工具的无许可链上注册表。该标准规范了关于工具的定义、发布者以及获准调用该工具的对象等信息的最小化、可验证记录。
2026年4月，OpenSea的科迪·西尔斯（Cody Sears）和瑞安·戈兹（Ryan Ghods）提出了该标准，旨在让agents 自主发现、购买使用权限并调用各类工具。
每个已注册的工具或符合 ERC-8257 标准的agent 拥有一个包含 3 个组成部分的链上记录：
创作者地址：出版商，在注册时永久绑定
元数据 URI：指向该工具链下清单的指针
清单哈希值：用于验证描述内容未发生更改
此外，访问谓词中还有一个可选的第四个组成部分，即一个合约地址，用于决定谁可以调用该工具。
这些要素共同构成了工具元数据的统一可信数据源，并提供一项保证：您获取的清单正是创建者从其控制的源地址，使用其签名的地址所提交的那个。
在了解了agent 注册表的用途及其包含的组件之后，让我们来学习它们是如何协同工作的，以及其flow 怎样的。
你知道吗？ERC-8257 Ethereum mainnet Base 上线，截至 2026 年年中Base 76 款工具被收录其中。
ERC-8257 中包含两个工作流，即：
注册Flow：发布者与注册机构之间的交互。
发现与验证Flow：agents、注册表和工具之间的相互作用。
让我们分别来了解一下。
注册flow 工具如何发布以及如何使其可被发现。发布者会注册该工具的创建者地址、元数据 URI 以及清单哈希值（外加一个可选的访问谓词），从而创建一条链上记录，agents 随后agents 解析并验证该记录。
当agent 某个工具或服务时，这一发现和验证过程会建立对agent 读取agent 元数据的信任。
一旦agent 清单、发布者和访问要求与注册记录一致，注册机构的作用即agent 结束。
到目前为止，ERC-8257 看起来像是一个普通的注册表，但正是由于可选的谓词部分，ERC-8257 才不仅仅是一个注册表。
agent 注册表解决了工具的发现和验证问题。但是，并非每个工具都应能被每个agent 调用agent 完全公开。
某些服务可能需要订阅。其他服务则可能仅限于 NFT 持有者、企业客户或符合特定信誉agents 。
ERC-8257 通过一个名为“访问谓词”（access predicate）的可选组件来解决访问问题：这是一个外部合约，用于决定调用者是否可以使用某项工具。
访问谓词是附属于工具注册的一个合约地址。
当一个agent 使用某项工具时，它可以调用谓词合约并提出一个简单的问题：该调用者是否被允许访问此工具？
现在，谓词合约可以验证某个agent 是否agent NFT、持有订阅代币、已支付访问费用、属于白名单，或者是否满足声誉要求。
不同的工具可以在无需修改注册表本身的情况下实施不同的策略。以下是一些示例：
工具类型 | 谓词逻辑 |
|---|---|
公共 API | 始终返回 true |
高级研究工具 | 验证有效订阅 |
企业服务 | 检查白名单成员资格 |
NFT 门槛工具 | 验证 NFT 所有权 |
Agent | 查看付款或信誉要求 |
最重要的是，ERC-8257 并未将上述任何规则硬编码进去，而是将谓词合约设计为可选的附加组件，既保持了标准的轻量级特性，又确保其能够扩展以适应多种用例。
现在我们已经了解了agent 注册表是什么、它是如何注册的、agents 如何agents 它，以及如何控制访问权限。接下来，你可以用它来构建什么呢？
仅就注册表本身而言，并没有什么特别之处。
DNS之所以变得重要，是因为可以通过它发现网站。软件包注册表之所以变得重要，是因为软件可以依赖它们。应用商店之所以变得重要，是因为它们将用户与应用程序连接了起来。
ERC-8257agent工具构建了一个发现层。让我们来探索一下由此所开启的一系列功能：
每款工具都具备可验证的来源、可编程的访问权限以及链上定价提示。仅凭这些，就足以构建一个市场，让用户在无需平台运营商介入的情况下，发现、使用和交易这些工具。
工具提供商可以通过谓词合约定义定价、订阅、代币持有要求、信誉阈值或企业级权限。这种灵活性使得不同的访问模式能够相互竞争，同时在发现层保持互操作性。
借助 ERC-8257，现在可以实现多步骤agent ，其中每个工具均可独立验证并设置验证门槛。
例如，一个交易agent 与一个全天候运行的新闻抓取工具关联，或者一个预测市场agent 与一个 Twitter（X）agent关联。
ERC-8257 提供了一种标准方法来发现和验证这些依赖关系，从而使跨独立提供商组合agent 变得更加容易。
每个平台最终都会面临同样的挑战：维护自己的服务目录。
ERC-8257 将这一责任转移到了共享基础设施上。工具提供商只需发布一次，Agent 、钱包、交易市场和应用程序即可调用相同的记录。
如今，大多数agent 都在单一组织或平台内运行。
ERC-8257 为供应商-客户、客户-市场等跨组织工作流铺平了道路。
例如，研究agent 购买方式获取通过注册工具公开的专有数据源。
现在我们已经了解了 ERC-8257 的工作原理和功能。接下来需要了解的是，为了使agents 发挥作用，所需的更广泛的agent 。
ERC-8257 解决了更广泛的agent 中一个具体问题：能力发现和可验证交互。
但是，agents 在进行交互时，agents 需要身份、执行环境、支付通道以及协调机制。
现在让我们把这个栈组装起来吧。
图层 | 问题 | 议定书 |
|---|---|---|
Agent | 这位agent人是谁？ | ERC-8004 身份或钱包 |
发现 | 有哪些功能？ | ERC-8257 |
访问控制 | 谁可以使用这些功能？ | ERC-8257 谓词 |
付款 | 访问费用如何支付？ | x402，稳定币 |
执行 | 工具是如何调用的？ | MCP、API、agent |
协调 | agents 是如何agents ？ | agent |
从这个lens，ERC-8257与其说是一项人工智能标准，不如说更像是一种基础设施。
已注册的工具可能会暴露 MCP 服务器。
某个谓词可能要求在授予访问权限之前先进行支付。
可以使用agent 标准来证明请求的发起者是谁。
这些责任均不属于 ERC-8257 本身。
该标准的作用是回答一个更简单的问题：“有哪些功能可用，以及在哪里可以找到这些功能？”
目前，架构是稳健的，设计选择也是合理的。尚待解决的问题在于采用情况。
如今，大多数软件都是围绕直接集成构建的。
开发人员选择一项服务，阅读其文档，根据其 API 编写代码，并长期维护这种关系。
ERC-8257 并未推进这一目标，而是将代理基础设施推向了另一个方向。
功能可在运行时被发现。
访问策略变得可编程。
无需人工审批即可使用这些服务。
ERC-8257 是一个常见的发现层。这看起来可能只是基础设施中的一小部分。
DNS 曾是基础设施中的一小部分。软件包注册表曾是基础设施中的一小部分。应用商店最初只是目录。
更艰巨的挑战还在后头。
agents 应如何agents 声誉？市场平台应如何对工具进行排名？自主系统之间的支付、订阅或收入分成应遵循哪些标准？组织应如何在不损害安全性的前提下展示内部能力？
ERC-8257 并未直接解答这些问题。它只是开启了对话，并指明了解决问题的方向。
提供者通过发布创建者地址、元数据 URI、清单哈希值以及可选的访问谓词来注册工具。Agents 该清单，将其与链上记录进行比对验证，评估任何访问要求，然后调用该工具。
清单是对工具的一种机器可读描述。它包含元数据，例如功能、端点、使用要求以及agents 理解该服务并与之交互agents 其他信息。
不。任何机器可访问的服务均可通过 ERC-8257 进行注册。虽然该标准的设计初衷是agents 人工智能agents API、软件服务、自动化系统及其他可编程应用程序均可采用相同的发现模型。
MCP 规范了工具的暴露和调用方式。ERC-8257 规范了工具的发现和验证方式。这两者相辅相成，可在agent 协同使用。
开发人员可以在共享注册表标准的基础上，构建agent 、可编程访问系统、跨组织agent 、服务发现层以及agent 。
是的。ToolRegistry 合约部署在 0x265BB2DBFC0A8165C9A1941Eb1372F349baD2cf1 在Ethereum mainnet Base。截至2026年年中，已有76种工具被收录。该EIP仍处于草案状态，这意味着在最终确定之前，该接口仍可能发生变化。
不。该注册表存储的是元数据的引用，而非元数据本身。工具描述仍保存在链下，而存储在链上的哈希值则agents 其完整性。
Quicknode 成立于 2017 年，Quicknode 为开发者和企业Quicknode 机构级区块链基础设施。凭借 99.99% 的运行时间以及对 80 多条区块链的支持，各团队能够毫无妥协地构建和扩展链上应用。
将最新的工程见解、产品更新和 Web3 资讯直接发送至您的收件箱。