MCP 之上的一层：十一家公司集体力挺一份并非出自 Anthropic 之手的智能体标准

一场没人宣布开打的标准之争

过去两天最具分量的 AI 新闻不是某个模型发布，而是一个 JSON 文件。

7 月 13 日，The Information 报道称，谷歌、微软、Salesforce、Snowflake 和 ServiceNow 已同意支持一项用于将 AI 智能体连接到企业软件的共享技术标准——各类聚合媒体立刻把这一动作解读为对 Anthropic 的 Model Context Protocol（MCP）的反击。（The Information 的原文在付费墙之后；此处的框架来自二手报道，我无法阅读原始报道。）不过，这项标准是真实且公开的，它有一个名字：Agentic Resource Discovery，简称 ARD。

ARD 并非本周才出现的新事物。它于 2026 年 6 月 17 日以 v0.9 草案形式发布，采用 Apache 2.0 许可，由工程师 Junjie Bu 和 Srinivas Krishnan 在 Google Developers Blog 上宣布。真正新鲜的，是如今堆叠在它背后的政治分量。据 Search Engine Journal 报道，已有十一家组织签署支持：谷歌、微软、GitHub、Hugging Face、思科、Databricks、GoDaddy、NVIDIA、Salesforce、ServiceNow 和 Snowflake。

再看一遍这份名单，注意谁不在上面。OpenAI 不在。写出 MCP 的 Anthropic，也不在。

这份规范究竟做了什么

它的技术构想很窄，而且说实话，相当合理。

今天，一个智能体只能使用别人事先给它接好的工具。你安装一个 MCP 服务器，配置一条连接，工具定义随后被塞进模型的上下文窗口。这在十个工具时行得通，到了一万个就彻底崩溃，因为目录已经装不进提示词了。

ARD 的解法，是把工具选择从上下文窗口挪到一个搜索服务里。它建立在两个基本要素之上。第一，发布方在自己域名下的一个约定路径上托管一份机器可读的清单——通常是 ai-catalog.json——列出该域名提供的能力。第二，注册表爬取这些目录，建立索引，并暴露一个 REST 的 POST /search 端点，返回经过排序的实时结果。智能体用自然语言描述自己想完成什么，注册表告诉它该调用哪个工具。域名所有权验证则用于确认这个工具确实如其所声称。谷歌的博文把整件事描述为回答三个智能体目前无法以标准方式回答的问题："合适的能力在哪里？我究竟该用哪一个能力？以及，我如何验证连接它是安全的？"

Hugging Face 的发布文章把这一转变讲得更直白："从手动安装的静态目录，转向基于意图的搜索。"HF 已经交付了一个参考实现——一个 Discover Tool，通过搜索接口暴露数千个 Skills、ML 应用和 MCP 服务器。

让"反击"叙事变复杂的那部分

问题就出在这里：当天的舆论框架和当天的文件本身彼此矛盾，而这道裂缝值得我们停下来细看。

我读到的每一份一手资料，都把 ARD 描述为架在 MCP 之上的一层，而不是它的替代品。谷歌的公告明确表示该规范与协议无关，MCP 服务器和 A2A 智能体只是你在目录中发布的能力类型示例；发现之后，智能体仍以工具自身的原生协议与之通信。规范甚至定义了一种媒体类型 application/mcp-server-card+json，其全部目的就是让 MCP 服务器能够通过 ARD 搜索被找到。Hugging Face 把 ARD 定位为架在一个三协议栈之上——MCP 负责工具调用，Skills 负责指令，A2A 负责智能体之间的通信——并强调："它不是一款产品，也不是一个市场。它是一项任何公司都可以独立实现的共享标准。"

Snowflake 的博文描述的问题纯粹是管道工程，而非政治："今天，为某一个 AI 客户端配置好 MCP 连接，并不会自动让这些智能体在下一个客户端里可用。"他们的主张是：数据团队发布的一个智能体，将可以在 Snowflake CoWork、Claude、Copilot 或自研应用中被发现，而无需在每一处重新注册。请注意，Claude 就在这份名单里。这不是一份为绕开 Anthropic 而设计的规范；从表面看，它反而让 Anthropic 的协议更容易被找到。

那么，究竟是哪一种——一场伏击，还是一件配件？

为什么"互补"和"战略"并不矛盾

诚实的答案是：两种解读可以同时成立，而这份张力本身就是故事。

MCP 赢下了调用层。据关于 The Information 报道的转述，在过去大约十八个月里，它悄然成为事实上的默认标准——而它所依托的基础，掌握在一个竞争对手手里。对微软、谷歌和 Salesforce 来说，这是个别扭的位置，再多的 Apache 2.0 许可也无法让它变得舒服。发现层位于调用层之上——它决定了一个智能体究竟会把哪些工具纳入考虑范围。谁运营注册表，谁就塑造了智能体所能看到的世界，正如搜索引擎塑造了人类所能看到的世界。从历史上看，拥有索引的价值，一向高于拥有管道。

再看看是谁签了字。正如 Crypto Briefing 所指出的，这个联盟掌管着企业数据真正栖身的那些系统——Salesforce 管客户，Snowflake 管数据，ServiceNow 管工作流，再加上两大最大的云厂商，以及 NVIDIA 和 GitHub。如果他们发布 ai-catalog.json，而 OpenAI 和 Anthropic 不去适配，那么这些模型公司就将沦为一张由软件巨头所拥有的发现图谱中的租客。对 MCP 而言是互补，对 Anthropic 而言则是战略上的贴身。两者皆是。

还有一处细节不利于阴谋论式的解读：底层的 AI Catalog 数据模型由一个 Linux 基金会工作组维护，而据报道，OpenAI 和 Anthropic 都是更广泛的 Linux 基金会智能体标准项目的成员。这是一场几乎完全在同一个房间里进行的角力。

炒作与真实

真实的部分：规范确实存在，是公开的，有版本号，也有可运行的代码。据报道，GitHub 的 Copilot 智能体查找器已支持跨 MCP 服务的发现。Hugging Face 的注册表已经上线。十一家拥有真实分发能力的公司把名字签在了上面。

尚不真实的部分：采纳。这是一份 v0.9 草案。它的价值完全取决于一个注册表生态是否真的会成形，而 Search Engine Journal 指出，该生态仍处于早期阶段。一个没有爬虫、没有目录的发现标准，只是一份 schema，不是一套基础设施。互联网上有一整片墓地，埋着那些设计精良却无人发布的清单文件——谷歌自家的 John Mueller 就曾公开表示，LLM 系统无法有意义地区分那些提供了 llms.txt 之类机器可读文件的网站。一位谷歌员工对这一类构想说出这样的话，意味颇为深长。

同样未经证实的还有：Anthropic 或 OpenAI 关于 ARD 的任何表态。他们不在支持者名单上，这是事实。但这种缺席意味着什么——是拒绝、是漠不关心，还是一场仍在进行中的对话——现有资料无法确立，我也不打算假装知道。

总结

对标题式的叙事保持怀疑，对底层的动作保持敬意。所谓十一家公司联手扼杀 MCP 的说法，一碰到规范本身就站不住脚——因为这份规范的构造目的，恰恰是让 MCP 服务器更容易被找到。但所谓这仅仅是一项技术便利的说法，一碰到那份来宾名单，同样站不住脚。

值得关注的模式，不是 ARD 会不会"打败"MCP，而是发现层会不会成为智能体 AI 中真正积累筹码的那一层——如果会，那么拥有企业数据版图的那些公司，是否最终也将拥有那个索引：每一个智能体，包括 Claude 和 ChatGPT，都必须查询它才能找到方向。那不会是 MCP 的失败，而是一次降级：从人人在其之上构建的标准，降为别人目录里的一种载荷格式。

六个月后再问一次：世界上究竟存在多少个 ai-catalog.json 文件。那个数字，而不是本周的新闻报道，才是全部的故事。