当 Agent 的数量从几十个激增至上百万个甚至更多，大模型该如何知道调用哪一个呢？过去两年，MCP 解决了 Agent 如何被调用的问题，A2A 解决了 Agent 之间如何对话的问题，但面对“海量 Agent 怎么找”这一核心问题，业界始终缺乏标准答案。2026 年 5 月，由 Google、Microsoft 和 Hugging Face 牵头，联合多家巨头厂商推出了 ARD（Agentic Resource Discovery）协议。目的是为 Agent 生态构建一个搜索引擎。
解决三大核心痛点ARD 的诞生直击当前 Agent 落地过程中的实际痛点。首先是安装负担，当前的“App Store 范式”要求手动配置和注册 Agent，这在 Agent 数量达到百万级时是不可持续的。其次是上下文窗口耗尽，将成百上千个工具的描述塞进上下文让模型挑选，极易耗尽推理 token。ARD 将“发现”环节移出 LLM，交由专门的搜索服务处理，仅将最相关的候选结果返回。最后是描述同质化，大量 Agent 的描述千篇一律，难以进行语义召回。ARD 引入了 representativeQueries（典型用户提问）字段，将 Agent 的语义指纹标准化。
从 App Store 到搜索引擎综合来看，ARD 实现了清晰的范式跃迁。旧范式依赖手动安装注册，LLM 在上下文内盲选，扩展性受限；而 ARD 范式将调用前提变为动态搜索发现，选择机制交由专业引擎进行召回和排序。Agent 只需发布 manifest 即可被发现，理论上扩展性无上限。在数据模型上，ARD 的核心是 Capability Manifest（托管于 /.well-known/ai-catalog.json），用 IANA 媒体类型作为“信封”，不绑定具体协议，具备极强的通用性。在发现机制上，ARD 采用了静态（类似网页的 sitemap/robots.txt）加动态（Agent Registry 爬虫抓取与索引）的双层架构。
联邦搜索与去中心化信任为了支撑庞大的生态，Agent Registry 暴露了标准的 HTTP REST 接口，提供 search（语义搜索）、explore（聚合探索）、list（确定性浏览）三件套 API。同时，Registry 之间支持联邦搜索，通过 auto、referrals或 none 三种模式互相转发查询，实现 Agent 调用层与发现层的正交。
在信任与身份方面，ARD 采用了域名锚定的 URN 标识符，将“逻辑身份”与“物理位置”分离。利用 DNS 的全球唯一性换取 URN 的唯一性，并通过密码学凭据交叉验证，有效防止攻击者冒用他人命名空间，构建了去中心化的信任锚。
行业洞察与未来展望ARD 的推出释放了几个关键信号。首先，押注的是“Agent 数量会爆炸式增长”这一前提，如果 Agent 像 90 年代的网页般爆发，ARD 就是必要的基础设施。其次，“search-first”将对 LLM 架构产生真实影响，Agent 框架需新增“先搜索、再调用”的发现阶段，先适配者将吃到红利。
然而，真正的难题并不在协议，而在治理。公网 registry 的运营、排名规则、防垃圾与恶意 Agent 过滤，这些搜索引擎时代的老问题，需要行业共同解决。此外，目前中国厂商在贡献者名单中缺席，国内生态若需接入，必须尽早布局自己的 registry 与治理规则。
目前草案版本为 v0.9，核心架构已基本定型，正是切入生态建设的最佳窗口期。ARD 并非一项新技术，而是用 Web 思路解决 Agent 发现问题的工程决策集合。
Agent 的搜索引擎时代，可能比想象中来得更快。