MCP解决了Agent工具调用，但没解决规模问题

Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.

Follow TNS on your favorite social media networks.

Become a TNS follower on LinkedIn.

Check out the latest featured and trending stories while you wait for your first TNS newsletter.

将 AI Agent 连接到某个工具相对直接。但一旦组织拥有散布在不同云端和平台的数百乃至数千个资源，事情就变得复杂了。Agentic Resource Discovery（代理资源发现），简称 ARD，正是为了帮助 Agent 在这片混乱中找到方向。

AWS 在 8 月 31 日的 Weekly Roundup 中重点介绍这一开放规范，此前一周已做了深入技术解读，将其描述为"DNS，但为 Agent 服务"。ARD 无需提前告知 Agent 去哪里找所有东西，而是让它在不同注册中心之间搜索所需。

尽管 AWS 重点介绍这个项目，ARD 并非 AWS 技术。它由 Google 的 Junjie Bu、Microsoft 的 R.V. Guha 和 Hugging Face 的 Shaun Smith 共同撰写，以 Apache 2.0 许可证发布。来自 Cisco、Databricks、GitHub、GoDaddy、Nvidia、Salesforce、ServiceNow 和 Snowflake 等多家公司的工程师也参与塑造了这个项目。

AWS 目前的角色至少是，为该规范提供反馈，并探索它如何与自身的 Agent Registry 配合工作。目标是让现有的各个注册中心协同运作。

无需提前告知 Agent 去哪里找所有东西，ARD 允许它在不同注册中心之间搜索所需。

MCP 跳过了发现这一步

Model Context Protocol 已成为 AI 应用连接外部工具和数据的常见方式，但它假设客户端已经知道要使用哪个服务器。随着企业将基础设施散布在云端、SaaS 平台和内部系统上，这就成了问题。

ARD 帮助 Agent 在尝试使用资源之前先找到它。该规范使用"agentic resource"（代理资源）一词来指代 AI 客户端可以连接的任何事物，从 MCP 服务器到其他外部能力。ARD 兼容的服务会追踪可用资源，而无需开发者提前设置每个连接。

Model Context Protocol 已成为 AI 应用连接外部工具和数据的常见方式，但它假设客户端已经知道要使用哪个服务器。

无需强制迁移的联邦制

企业可以保留自己的目录和策略，同时将搜索路由到其他 ARD 兼容的服务。例如，一家企业可以将内部资源保持私有，同时在需要时搜索已批准的外部目录。AWS 将此称为"describe once, discover everywhere"（一次描述，随处发现）。

当前 v0.91 提案（日期为 8 月 26 日）使用 JSON-LD 和 REST 接口。其必需的 POST /search 端点按任务搜索，而可选端点允许客户端浏览可用资源。

每个发现服务都可以设置自己的规则，决定返回什么以及信任哪些来源。这也正是 AWS 的 DNS 类比不足的地方。域名指向一个特定位置，而 ARD 搜索可能返回多个看起来都能完成任务的选项。

Route 53 工程师塑造了 ARD

DNS 类比有其历史渊源。AWS 8 月 24 日 ARD 文章的三位作者中有两位与 Route 53 密切合作。Principal Software Engineer Jeffrey Damick 专注于 DNS 和网络技术，而 Bhargav Talluri 负责 Route 53 的产品管理，同时兼管 AWS Agent Registry 中的 Agent 身份和发现产品。

Agent Registry 已为 AWS 客户提供了资源的集中视图。添加 ARD 可以将运行在其他地方的资源纳入这个视图，而无需企业向 AWS 注册所有内容。

添加 ARD 可以将运行在其他地方的资源纳入这个视图，而无需企业向 AWS 注册所有内容。

ARD 的治理仍在制定中，董事会任期和成员资格等细节尚未确定。该小组还讨论过最终将项目转移到一个中立组织，如 W3C 或某个 AI 基金会。

使用工具之前的发现

AWS 已经在探索如何连接 Agent Registry 并在其自身目录之外寻找资源。

可能没有太多时间来 settle 在一个通用方案上，因为一旦企业建立了自己的发现系统，连接所有这些目录只会变得更难。