ARD协议详解：AI智能体如何自主发现和调用工具

当企业内部的AI智能体越来越多，一个尴尬的问题浮出水面：它们彼此之间根本不知道对方的存在。销售部门做了一个客户数据分析智能体，市场部的AI助手却完全不知情——除非有人手动告知并配置连接。这就是AI世界的「信息孤岛」问题。

事实上，企业内部的「信息孤岛」问题由来已久，早在传统IT时代，不同部门使用不同的ERP、CRM、OA系统就已经造成了数据割裂。进入AI智能体时代后，这个问题被进一步放大——因为智能体不仅需要访问数据，还需要发现和调用其他智能体的能力。据Gartner预测，到2028年企业内部部署的AI智能体数量将超过传统软件应用，这意味着如果没有统一的发现机制，智能体之间的协作成本将呈指数级增长。

2026年6月，Google、Microsoft、NVIDIA、Salesforce、GitHub等11家科技巨头联合发布了一个开放规范——ARD（Agentic Resource Discovery），专门解决这个问题。ARD就像是为AI智能体打造的搜索引擎，让智能体能够自主发现、定位并调用所需的工具和服务。

MCP的局限：有了接口，却找不到设备

要理解ARD协议的价值，我们需要先回顾2024年Anthropic推出的MCP（模型上下文协议）。MCP相当于给智能体世界提供了一个「USB-C接口」——它统一了AI系统与各种数据源、工具之间的连接方式，开发者只要按照协议开发，智能体就能直接调用这些工具。

从技术层面来看，MCP（Model Context Protocol）由Anthropic于2024年11月正式发布，其核心设计理念是为大语言模型提供一个标准化的上下文注入接口。在MCP出现之前，每个AI应用要接入外部工具（如数据库查询、API调用、文件读取等），都需要开发者编写定制化的集成代码。MCP通过定义统一的消息格式和交互流程，将这一过程标准化。它支持三种核心原语：Resources（资源，如文件和数据）、Tools（工具，如函数调用）和Prompts（提示模板）。MCP迅速获得了行业认可，OpenAI、Google、Microsoft等公司相继宣布支持，使其成为事实上的智能体通信标准。

MCP的局限性

但MCP有一个致命前提：你必须事先知道有这个工具，然后手动把它接到你的智能体上。 这就好比你的手机支持USB-C，但你根本不知道哪里能买到U盘或键盘——接口再好也没用。

随着企业和开发者发布的AI工具呈爆发式增长，手动配置的方式显然无法扩展。AI智能体迫切需要一个自己的「发现机制」，就像我们用搜索引擎一样，让它能自主找到并调用所需资源。

ARD的架构设计：借鉴DNS的分层去中心化模型

ARD的架构设计参考了互联网的域名系统（DNS），采用分层和去中心化的模型，主要由两大核心组件构成：目录（Catalog） 和 注册表（Registry）。

这里有必要深入理解DNS的架构精髓。DNS（Domain Name System，域名系统）是互联网最核心的基础设施之一，它将人类可读的域名（如google.com）转换为机器可识别的IP地址。DNS采用树状分层结构：根服务器位于顶层，下面依次是顶级域名服务器（.com、.org等）、权威域名服务器和本地缓存服务器。这种分层设计使得DNS既能支撑全球数十亿设备的域名解析需求，又不依赖任何单一中心节点——即使某个服务器宕机，其他节点仍可正常工作。ARD借鉴了这一架构思想：目录（Catalog）类似于权威DNS记录，由资源所有者自行维护；注册表（Registry）类似于DNS递归解析器，负责汇聚和检索这些分散的记录。

目录：AI工具的「产品说明书」

目录本质上是一个能力清单。任何组织或开发者想把自己的AI服务公开出来，只需在自己的域名下固定路径 /.well-known/aicatalog.json 放置一个标准清单文件。这个文件会详细说明工具的功能、能处理的任务类型以及调用方式。

值得一提的是，/.well-known/ 是由IETF在RFC 5785中定义的一个标准化URI路径前缀，专门用于在Web服务器上放置站点级别的元数据文件。这个机制已经被广泛应用于多种互联网协议中：例如Let's Encrypt使用 /.well-known/acme-challenge/ 来验证域名所有权以签发SSL证书，OAuth协议使用 /.well-known/openid-configuration 来发布认证服务器的配置信息。ARD选择 /.well-known/aicatalog.json 作为标准路径，意味着任何拥有域名和Web服务器的组织都可以零门槛地发布自己的AI能力清单，无需额外的注册流程或第三方平台。

域名所有权担保信任

清单的可信度由域名所有权来担保。就像你访问 microsoft.com 就知道这是微软的官方网站一样，清单放在谁的域名下，就由谁的信誉背书。这是一种简洁而有效的信任机制。

注册表：AI智能体的「搜索引擎」

注册表会主动爬取这些公开的目录，为它们建立索引。当智能体需要完成某个任务时，可以直接用自然语言查询，比如「我需要一个能分析销售数据的工具」，注册表就会返回按相关度排序的工具列表，包含功能描述、提供方和连接方式。

一次完整的发现与执行流程

在ARD体系下，一个AI智能体找到并使用工具的完整过程可以分为四步：

发布：资源提供方在自己的域名下创建并发布 aicatalog.json 清单，将工具信息公开
索引：注册表服务持续爬取这些清单，将它们全部索引起来
查询：当AI客户端需要某个工具时，直接向注册表发起查询
调用：客户端从搜索结果中选择合适的工具，通过工具的原生协议（如MCP或REST API）直接调用

ARD与MCP的协作关系

这里有一个关键的设计理念：注册表只负责发现，不参与实际调用。 这带来了几个显著优势：

轻量灵活：不关心具体执行方式，可兼容任何通信协议
去中心化：没有中央控制节点，任何人都可以运行自己的注册表
易于整合：企业可以方便地将内部工具和外部公开工具整合，并自主决定哪些资源可被发现

ARD与MCP：互补而非替代

ARD和MCP的关系是互补的，而非竞争。MCP解决的是「怎么连」——智能体和工具之间如何通信；ARD解决的是「找谁连」——智能体去哪里找到这些工具。

可以这样理解：ARD处于MCP的上游，先帮智能体找到合适的工具，再由MCP负责实际的连接和调用。一个解决发现问题，一个解决通信问题，两者结合才让AI智能体形成了完整的自主能力闭环。

生态现状与首批产品落地

ARD规范草案于2026年6月17日正式发布，采用Apache 2.0开源许可，数据模型由Linux基金会下属的AI Catalog工作组维护。

Apache 2.0是目前最受企业欢迎的开源许可证之一，它允许任何人自由使用、修改和分发代码（包括商业用途），同时提供了明确的专利授权条款，这对企业采用开源技术至关重要——它消除了潜在的专利诉讼风险。而Linux基金会是全球最大的开源技术组织，旗下托管了Linux内核、Kubernetes、CNCF等众多关键项目，其中立的非营利性质确保了ARD不会被任何单一商业公司控制。这种「厂商中立」的治理模式是ARD能够吸引11家竞争对手同时参与的关键因素。

首批支持者阵容豪华，包括Google、Microsoft、Cisco、NVIDIA、Salesforce、ServiceNow、Databricks、Snowflake、GitHub、Hugging Face、GoDaddy等11家公司。

多家公司的产品落地

发布当天就有多家公司推出了基于ARD的产品：

GitHub 上线了 Agent Finder，让Copilot可以自动发现和调用MCP服务器及各种技能工具
Hugging Face 发布了 Discover Tool，可搜索上千个技能和MCP服务器
Cisco 将ARD集成到了 AGNTCY Agent Directory
Google 在Gemini企业智能体平台中加入了ARD支持
DataRobot 宣布兼容ARD并发布了AI目录

你可能没注意到，OpenAI和Anthropic目前尚未出现在初始支持者名单中，这两家在AI领域举足轻重的公司是否会加入，将对ARD的生态推广产生重要影响。

从深层来看，Anthropic是MCP协议的创建者，在智能体基础设施层面有自己的战略布局，加入一个由Google主导推动的发现层协议可能涉及生态主导权的博弈。OpenAI则一直倾向于构建自己的封闭生态——从GPT Store到Plugins再到最新的Responses API，其策略更偏向平台化而非开放互操作。不过值得注意的是，在MCP的推广过程中，OpenAI最初也未参与，但最终在2025年3月宣布支持。历史经验表明，当一个开放标准获得足够的行业动量后，即使是最强势的玩家也难以长期置身事外。

安全挑战不容忽视

ARD的开放架构在带来便利的同时，也引入了新的安全隐患。由于信任模型依赖域名所有权，一旦域名被劫持、DNS被污染或服务器被入侵，攻击者就可以上传恶意的 aicatalog.json 文件，诱使AI智能体连接到危险工具。

这些安全威胁并非理论上的假设。DNS劫持（DNS Hijacking）是指攻击者通过篡改DNS记录将域名指向恶意服务器，2019年的Sea Turtle攻击事件就曾影响了40多个组织。DNS缓存污染（DNS Cache Poisoning）则是通过向DNS解析器注入伪造的响应来实现中间人攻击。此外，供应链攻击也是重大威胁——如果工具提供方的服务器被入侵，攻击者可以在合法域名下替换 aicatalog.json 文件，而智能体会因为信任该域名而毫无防备地连接恶意工具。这种攻击在AI场景下尤其危险，因为智能体可能拥有执行代码、访问敏感数据甚至操作生产系统的权限。

Google也坦承，ARD本身并不是一个安全解决方案。在实际部署时，需要配合以下安全措施：

强身份验证与授权机制
资源白名单与治理策略
代码签名验证
运行时监控与策略执行

这意味着企业在拥抱ARD的同时，必须建立配套的安全体系，不能简单地「开箱即用」。

总结与展望

ARD协议的出现，让AI智能体从需要手动连接的孤立系统，进化为可以自主探索和利用各种能力的互联生态。它补上了MCP之后的关键拼图——发现层，解决了在AI能力爆发式增长背景下，智能体如何高效且安全地发现和使用工具的核心问题。

当然，ARD在生态推广（尤其是争取OpenAI和Anthropic的加入）和安全实践方面仍面临不少挑战。但作为推动AI互操作性的重要一步，它标志着AI智能体生态正在从「手动配置」走向「自主发现」的新阶段，值得每一位AI从业者持续关注。