原文作者：KarenZ，Foresight News
这一次，OpenSea 的叙事重心没有落在 NFT 交易上。它盯上了另一种入口：当 AI Agent 开始自主发现工具、获得权限并支付费用，谁来组织这些工具，谁就可能占据下一轮链上分发的起点。
OpenSea 借用了一个人人都熟悉的比喻：App Store 让开发者发布应用、用户发现应用并完成付费；Agent 工具也需要类似入口。区别在于，这一次逛商店、判断权限、准备付款和调用服务的主体，可能是一只持有钱包的 Agent。
OpenSea 看中的，是 NFT 从资产变成权限
5 月 26 日晚，OpenSea 发布「 ERC-8257 ：代理工具注册中心」。在 OpenSea 展示的场景里，一个 AI Agent 正尝试为 NFT 估值。它调用专业定价工具时遭到拒绝，随后发现：持有指定 NFT 的地址可以使用折扣接口。于是 Agent 在链上买入该 NFT，再次发起请求，将单次调用费用从 0.05 美元降至 0.01 美元。
这个例子点出了 OpenSea 的新算盘。在 ERC-8257 的设想里，NFT 还可以成为机器能够读取并立即使用的访问凭证。
研究数据源、定价工具、交易信号、合作伙伴 API，都可以设置链上门槛。例如，持有某个 NFT 才能访问折扣接口，持有订阅型 NFT 才能调用高级服务，或者通过白名单、质押余额、零知识证明决定谁能进入。
对 OpenSea 而言，变化非常具体。一枚 NFT 的用途可以从头像、收藏品和社群身份，延伸为 Agent 调用服务时的折扣卡、会员证或限量席位。市场里能够交易的对象，也随之扩展为可被软件直接执行的访问权。
OpenSea CTO Chris Maddern Chris Maddern 随后将这一方向概括为一条更完整的链上路径：稳定币用于 Agent 支付，NFT 用于身份与订阅，Agent Tool Registry 则推动这套构想靠近实际运行。
ERC-8257 做的事很窄：登记工具，验证资格
ERC-8257 于 2026 年 4 月 17 日创建，目前在 ethereum/ERCs 仓库中标注为 Draft。它的标题是 Agent Tool Registry，目标是提供一个无需许可的链上工具注册表，而非建设一家拥有审核、排行和退款机制的完整应用商店。
ERC-8257 的技术设计并不复杂。开发者注册工具时，链上记录几个关键元素：工具创建者地址、指向工具说明文件的 metadataURI、证明说明文件未被篡改的 manifestHash，以及决定谁可以访问工具的 accessPredicate。
用白话来说，链上注册表像一本可验证的工具目录：工具能做什么、怎样调用、价格提示是什么，放在链下的 manifest 文件里；该文件的哈希被写入链上，Agent 拉取文件后可以校验内容是否一致；至于某个钱包有没有资格调用工具，则交给独立的 predicate 合约判断。
如果 accessPredicate 为空地址，工具面向所有调用者开放；如果指定了合约，它就可以验证 NFT 持仓、订阅状态、白名单、质押门槛、DAO 投票结果或零知识证明等条件。
需要注意的是，ERC-8257 不接管资金。提案明确将定价信息放入 manifest，将实际支付交给 x402 或其他支付协议。注册表负责发现与权限，结算留给外部系统。这样的拆分让标准保持轻量，也意味着 OpenSea 推出的更像一层分发和准入基础设施，而非新的支付协议。
这也是为何 ERC-8257 作者将 ERC-8257 称为「the 403 to x402『s 402」。HTTP 语境中，402 指向付款要求；403 指向权限不足。x402 回答「这次调用如何付款」，ERC-8257 想处理「这个地址是否有资格进入」。
严格而言，403 是便于理解产品定位的类比。ERC-8257 草案规定的是注册与权限判断机制，并未要求所有工具都必须通过某种固定的 HTTP 403 流程回应 Agent。
所谓 Agent App Store，争的是分发起点
「App Store」这个说法很容易让人联想到由平台审核、排序并掌控入口的封闭市场。但 ERC-8257 的核心设计偏向开放：任何开发者都可以登记工具，Agent 可以读取链上注册信息，访问条件也可以通过外部合约扩展。
OpenSea 真正想争取的，是开放协议之上的工具发现与资产交易场景。过去，Agent 寻找工具往往依靠文档、GitHub 仓库、中心化目录或人工配置；ERC-8257 试图提供一层可核验的链上入口，让 Agent 找到估值 API、研究订阅、交易信号或数据服务，读取使用条件，再根据自己的钱包状态购买权限或完成付款。
在 Ethereum Magicians 讨论区，提案方称参考实现已部署至 Base 主网，并通过 CLI、SDK 及 ERC-721、ERC-1155、订阅和复合 predicate 示例进行验证。
这给 OpenSea 留出一条比争夺 NFT 聚合交易更宽的路径。只要 Agent 经济需要链上会员、可交易席位或 token-gated API，OpenSea 就能继续扮演资产发现和购买场所。平台撮合的对象可以从文化资产，逐步扩展到机器执行任务时需要的访问资格。
如果把 Agent 调用一项链上付费工具拆开看，目前浮现出的协议分工大致如下：
MCP 负责工具与 AI 应用之间的通信方式。服务器可以暴露 tools、resources 与 prompts，客户端发现已连接服务的能力后发起调用。它处理的是能力描述与调用接口，并不天然提供公开、链上、可验证的全球工具目录。
ERC-8004 关注 Agent 的身份、信誉与验证记录，让不同主体能够识别某个 Agent 以及它过往的行为线索。
x402 面向支付，让人或 Agent 能够通过稳定币为 API 与数字内容进行程序化付款。
ERC-8257 则试图补上工具发现与准入这一层：Agent 如何找到工具，如何确认 manifest 未被篡改，如何判断自己的钱包是否满足使用条件。
有哪些挑战？
ERC-8257 给了 Agent 一张工具目录和一套门禁规则，却没有自动解决服务质量与安全问题。
链上的 manifest 哈希只能证明 Agent 读取到的说明文件与登记时一致，无法证明工具输出可靠、接口不会泄露数据，也无法保证开发者长期提供服务。predicate 合约同样可能配置错误、失效或引入复杂风险。一个 Agent 能够自动买到门票，并不等于它走进的房间一定安全。
Ethereum Magicians 上讨论区里已经出现数个待继续打磨的问题：跨链钱包状态如何证明；ENS 是否适合作为额外发现入口；付费协议命名是否需要统一约定；ERC-8257 与另一项 ERC-8239: Agent Skill Registry 的范围是否存在重叠。提案作者也在讨论中确认，工具定义、价格提示与不同 registry 思路之间仍有整合空间。
因此，ERC-8257 的意义还不在于它已经成为 Agent 工具市场的统一答案。它更像 OpenSea 提前摆下的一张桌子：Agent 来寻找工具，开发者来登记能力，NFT 来承担权限，支付协议负责结算，而 OpenSea 希望坐在最靠近交易发生的位置。
NFT 市场曾经最关心的问题，是谁愿意为一张链上资产出价。ERC-8257 打开的新问题是：当一段软件需要权限才能继续工作，它会买下什么，又会从哪里买？
