如何轻松掌握新一代金融科技（FinTech）行业正在发生的市场热点、技术动向、生态进展、治理态势…？ 外捕研究（Web3Caff Research）推出的「市场脉搏分析」栏目将深入一线探寻并筛选当前发生的热点事件，并进行价值解读、点评与原理分析。透过现象看本质，即刻跟随我们快速捕获一线市场风向。
作者：ShirleyLi，外捕研究（Web3Caff Research）研究员
封面：Typography by 外捕研究（Web3Caff Research）
字数：全文共计 2600+ 字
相较人类用户，AI Agent最大的优势在于，其在理想情况下，具备更强的自主执行能力：它可以自己完成任务、自行执行操作，并在没有持续人工干预的情况下主动调用外部工具。然而，在 AI Agent 调用工具（例如交易平台 API、数据分析工具、预言机）的实际过程中，还是会面临一些问题。
首先，这些工具的访问入口分散在 GitHub、官方网站、中心化 API 平台等各处，缺乏统一的发现渠道。AI Agent 在无人工干预的情况下，很难自主定位并接入所需的工具，而且不同平台的具体付费方式也各有差异，缺乏标准化的流程。这就会给 AI Agent 调用工具的过程带来一些困扰。
其次，在传统互联网中，调用 API 通常需要开发者注册账号、获取 API Key，并按照特定规则进行权限验证。这一流程原本是为人类参与者制定的，但对于 AI Agent 而言，要想自动完成注册、获取凭证并调用工具，目前依然缺乏公开且标准化的实现方案。
虽然目前x402 协议已经能够支持 AI Agent 自动完成支付，但它主要适用于 “付费即用” 的开放式接口，难以应对更复杂的权限场景，例如，只有订阅的用户才能访问服务，或者持有某种凭证的用户才能享受到优惠折扣等。
为填补这一空白，OpenSea 于近日尝试推出了ERC-8257 标准草案，致力于为 AI Agent 建立一个开放、无需许可的链上工具目录，让 AI Agent 能够自主发现工具、理解访问规则，并在满足条件后自动完成调用与支付。
简单来说，ERC-8257 的核心是一套链上工具注册表。该注册表本质上是一个智能合约，工具开发者可以将其工具的相关信息及访问权限注册上链，并向全网公开。
不过，由于将数据全部直接上链的成本较高，因此，ERC-8257 允许开发者将更详细的工具信息存放在自己维护的服务器或域名下，以 JSON 格式文件（Manifest）的形式呈现，而链上注册表仅记录指向该文件的链接。该链下文件通常会包括：工具名称、功能描述、API 接口、调用方式、定价信息、支付协议、访问规则，等等。而链上注册表则需要记录链下文件的地址、文件哈希值以及工具开发者信息等关键数据。这种设计旨在防止开发者后续私自篡改工具内容。当 AI Agent 在调用工具时，可以通过校验文件哈希值来验证链下内容是否与链上登记的信息一致。
在 ERC-8257 中，还有一个很关键的设计：访问权限并非固定格式，而是通过独立的智能合约来定义。工具开发者可以自由定义该合约，以规定谁有资格调用其工具。例如，开发者可以检查 AI Agent 是否持有某种NFT、是否持有某种Token、是否进行了订阅、是否在某个白名单内，等等。
来看一个例子，某链上分析工具规定：普通用户调用普通 API 的费用为 0.05 美元/次，而持有某种 NFT 的用户仅需支付 0.01 美元/次。同时，如果用户订阅了其服务（通过指定 Token 或者支付协议持续付费），还可以获得高级分析接口的访问权限。
在这一场景中，“持有某种 NFT”、“订阅服务” 就是两种特殊的访问凭证。如果 AI Agent 当前不具备相应权限，它可以在链上或者去市场中获取这些条件（例如购买 NFT 或完成订阅），然后再重新申请调用。
但需要注意的是，当访问权限以 NFT 或 Token 等资产形式存在时，它们本身就可能进入市场流通体系，从而受到供需关系影响，出现较高的价值波动或者投机行为。
因此，ERC-8257 并不将权限系统限制为单一资产模型，而是选择保持开放性。工具或者服务开发者可以根据具体需求选择不同的访问机制，例如，引入不可转让的SoulboundNFT（灵魂绑定NFT）来避免交易行为引起的价值波动，或者引入声誉评分这类非资产化的机制，降低投机行为带来的影响。
在支付层面，ERC-8257 也并不负责定义具体支付逻辑，而是只要求开发者在 JSON 文件中声明支持哪种支付协议，例如 x402、链上ERC-20支付，或者其它机器支付协议，真正的支付执行将由对应协议来完成。
从整体流程来看，ERC-8257 的工作方式大致如下：
- 工具开发者部署工具服务，并编写对应的访问权限，然后再将相关信息提交到链上注册表中；
- 当 AI Agent 需要调用某种工具或者服务时，可以扫描链上注册表，发现符合其需求的工具或者服务时，可以进一步阅读详细的描述文件，以理解调用规则；
- 如果 AI Agent 不满足访问条件，可以尝试获取对应权限后，再次发起调用；
- 最终，AI Agent 可以在无需人工参与的情况下，自主完成工具发现、权限验证、支付与调用的整个流程。
图源：The App Store for Agent Tools: ERC-8257
总体而言，ERC-8257 试图解决的，并不仅仅只是如何让 API 上链的问题，而是 AI Agent 如何能够像人类用户一样，自动发现工具、理解访问规则、获取访问权限，并以标准化的方式调用这些工具。从设计目标来看，ERC-8257 将与 x402 协议一起，形成一种互补关系：
- ERC-8257 有望使 AI Agent 在全局范围内发现工具，并且根据规则判断自身是否具有访问权限；
- x402 协议负责调用工具过程中的支付与结算。在工具被允许调用后，支持 AI Agent 按次或按调用频率付费。
然而，除了前文提到的，如果访问权限以 NFT 或 Token 等资产形式存在时，可能会引入价值波动与投机风险外，ERC-8257 标准在实际落地过程中还会面临一些潜在的风险挑战。
例如，尽管 ERC-8257 提供了标准化的工具注册与访问框架，但不同开发者在设定访问条件时仍然存在差异。虽然 AI Agent 在发现工具层面可以依赖统一的链上索引路径，但在实际调用过程中，依然需要兼容不同的权限判断逻辑，这就会带来一定的技术复杂性。
此外，在信任机制方面，目前 AI Agent 会通过对比链上记录的哈希值和链下工具描述文件，来校验文件在传输过程中是否被篡改。然而，这一机制仅能解决数据是否一致的问题，无法进一步保证工具运行逻辑是否正确、其接口是否可信，以及数据处理过程中是否存在潜在的信息泄露等风险。同时，由于工具服务通常部署在链下基础设施上，其长期可用性与稳定性仍依赖于开发者的运营能力，这就意味着，AI Agent 还需要通过外部声誉机制来进行甄别。
由此可见，在 ERC-8257 标准被实际应用之前，其在工具可信度、权限规则一致性等方面仍有待进一步验证和完善。
要点结构图：
