想象一个场景：你的公司有上百个AI Agent同时在运行。有的在写代码，有的在处理客服，有的在审核合同，有的在分析市场数据。它们分布在AWS、Google Cloud、Azure和本地机房，使用MCP、A2A、OpenAPI等不同协议。现在，一个新来的开发需要找一个能处理“数据库异常自动修复”的Agent。他去问隔壁组同事，同事说“好像有，但不知道在哪”。他去问运维，运维说“你得自己找”。他翻了三个控制台、问了五个人，最终放弃了，自己写了一个——重复造了一个已经存在的轮子。
这是2026年每一家正在规模化AI Agent的企业每天都在上演的场景。
Agent的发现困境：当螺丝钉比工具箱还多
AI Agent的爆发式增长正在制造一个严峻的治理问题：企业部署的Agent越多，就越难找到它们。
2026年4月，云安全联盟（CSA）发布的一项调查显示：82%的企业环境中有未被登记的AI Agent在运行，65%的企业在过去12个月中经历过AI Agent相关的安全事故，其中61%导致数据泄露，43%导致业务中断，35%造成直接经济损失。调查基于418名IT和安全专业人士的反馈。数据背后是一个残酷的事实：大多数企业的Agent管理能力远远落后于部署速度。
问题出在根上。今天Agent生态中的每个环节都有各自的协议栈。MCP定义了工具如何被调用，A2A定义了Agent之间如何通信，OpenAPI定义了API的格式——但这些协议都解决的是“连接”问题，而非“发现”。当一个Agent不知道某个工具的存在时，再好的调用协议也毫无意义。
这就像互联网早期阶段：每个网站都有自己的IP地址，但没有DNS。用户只能用一本不断过期的手册查找网站IP。Agent生态现在就处在那本“手册时代”。
4月9日，AWS在Amazon Bedrock AgentCore中推出了Agent Registry预览版，试图在自己的围墙内解决这个问题。Agent Registry是一个集中式、可搜索的目录，支持语义搜索和关键词搜索——开发者可以用自然语言描述需求来查找Agent。它提供了审批工作流、AWS CloudTrail审计、URN命名空间管理、Agentic Egress Policies（出站策略）和工具固定等企业级功能。目前已在美国西部（俄勒冈）、亚太（东京）、亚太（悉尼）、欧洲（爱尔兰）和美国东部（弗吉尼亚北部）五个区域可用。
但AWS自己很清楚：当Agent跨云、跨环境、跨组织运行时，一个单独的AWS内部目录远远不够。
ARD：Agent世界的DNS
6月17日，Google联合微软、Hugging Face、思科、Databricks、GitHub、GoDaddy、英伟达、Salesforce、ServiceNow、Snowflake等十余家行业伙伴，共同发布了Agentic Resource Discovery（ARD）开放规范。规范以Apache License 2.0授权，在agenticresourcediscovery.org和GitHub上公开。
AWS虽然没有出现在联合发布方名单中，但AWS官方博客明确表示对这一规范“提供了反馈意见”，并在8月20日以一篇详细工程博客阐述了AWS Agent Registry如何与ARD互补。
这个阵容值得细看。Google牵头，微软站台，英伟达和Hugging Face护航，亚马逊在侧翼呼应——基本覆盖了从云基础设施到AI开发者社区再到企业应用的完整生态。这可能是AI Agent领域迄今为止参与方最广泛的开放标准联盟。
Google Cloud杰出工程师Srinivas Krishnan在公告中解释了ARD的初衷：
问题说起来简单，但在企业环境中解决起来很难。企业的答案不能只是“找个能用的东西”，它必须有治理，安全和身份必须内建其中，而不是事后补上。
ARD的核心设计极为简洁。它引入两个基本构件：Catalog（目录）和Registry（注册表）。
Catalog是一个ai-catalog.json文件，由组织托管在自己的域名下，描述该组织可供调用的Agent能力。因为文件放在自有域名下，域名所有权本身就是密码学信任基础——你能控制这个域名，你就是这个能力的合法发布者。这就是ARD的“域名即身份”设计哲学。
Registry则是Catalog的搜索引擎。它可以爬取各域名下的Catalog、建立索引、对外提供搜索接口。当客户端Agent提出自然语言查询时，Registry返回匹配结果，附带信任验证元数据。
值得强调的是：ARD只做“发现”，不做“执行”。它帮你找到正确的资源，然后由资源的原生协议（MCP、A2A、OpenAPI等）去执行调用。ARD官网说得非常清楚：“ARD sits entirely before invocation.” 它像黄页帮你找到一家餐厅的电话，但不负责帮你做饭。
官方将其类比为DNS之于互联网。DNS让每个网站不需要和每个访问者签订双边协议就能被访问；ARD让每个Registry不需要和其他Registry维护专有连接器就能实现联合索引。这个类比在技术圈引起了广泛共鸣——DNS是互联网最成功的去中心化基础设施之一，用同样模式解决Agent发现问题，逻辑自洽且经过了时间验证。
谷歌云与亚马逊的算盘：两套策略，一个终点
表面上AWS和Google对ARD都表态“支持开放标准”。但仔细看两家各自的落地策略，差异比共识更值得关注。
Google Cloud是ARD名义上的发起方。6月17日在Google Developers Blog上正式宣布ARD的同时，Google推出了Google Cloud Agent Registry作为企业级产品落地。Google Agent Registry提供完全托管的搜索、发现和托管服务，包括全局唯一命名空间URN、Agentic Egress Policies、工具固定，以及基于Agent Identity的信任清单验证——后者可满足HIPAA等企业合规标准。
AWS则选择了更务实的路径。AWS没有在6月17日一起站台，而是花了两个月消化规范、调整产品路线，再以一篇工程博客详细阐述“AWS Agent Registry + ARD”的技术对接方案。AWS推出的Agent Registry同样具备URN命名空间、审批工作流、CloudTrail审计、语义搜索等能力，且可以通过AWS CLI、SDK、Console以及MCP Server四种方式访问。
两家的路径差异很说明问题：Google选择“同步发布标准+产品”，强攻舆论制高点；AWS选择“先做产品，再说标准”，稳扎稳打。但终点是一致的——用ARD开放标准，让自己的Registry能跨过生态边界索引Agent资源，从而让企业客户在自己的Console中获得完整的Agent管理视图。
更深一层看，AWS在ARD标准制定中的角色有更深的伏笔。AWS参与ARD推进的关键人物之一是Jeffrey Damick——AWS Route 53的首席软件工程师。Route 53是AWS的DNS服务，Damick的研究方向正是“DNS与AI的交汇点，探索互联网基础协议如何支持AI Agent的发现和通信”。ARD规范中已明确使用域名作为身份锚点，这意味着Route 53团队的深度参与不只是友好的姿态——AWS在底层协议层面占据了有利的技术位置。
微软的第三条路：用开发者生态开路
三家核心云厂商中，微软的站位最为特殊。微软既是ARD的重要贡献者，又手握独特的开发者生态。
微软技术院士（Technical Fellow）Ramanathan Guha在其官方博客中写道：
ARD是一个开放规范，为AI能力的发布、索引和发现建立了安全的通用层。这使AI客户端能够自动发现并接入新的能力。
微软最现实的牌是GitHub Copilot中的Agent Finder已经基于ARD实现了运行时能力发现。这意味着数以千万计的开发者，每天在代码编辑器里感受的“AI帮你找工具”体验，底层基础设施就是ARD。这种“从开发者工具渗透企业”的路径，恰好是微软最擅长的打法。
InfoQ的报道中引用了微软AI首席工程师Jennifer Marsman的补充观点，她强调ARD解决的问题是“简单但难解的”——企业需要的不是一个“找到能用的东西”的方案，而是一个“有治理、有安全、有身份内建”的方案。
三家的共同点也很明显：每家都推出了自己的Agent Registry产品，每家都在用ARD标准服务于自己的产品矩阵。开放标准并没有消除竞争，它只是让竞争从“无法互通的竖井”升级为“底层互通但上层搏杀”的新阶段。
Agent Registry：云厂商的下一个规则制定权之争
为什么Google、微软、AWS对Agent发现的治理权如此上心？因为这个市场的规模正在快速显现。
根据Gartner的预测，到2028年，33%的企业软件应用将包含Agentic AI（2024年这个比例不到1%），至少15%的日常工作决策将由Agentic AI自主完成。企业从“管理几个Agent”到“管理几百个Agent”的跨越，可能只需要两三年时间。
每个Agent都需要注册、被发现、被连接、被审计、被管理。Agent Registry不是锦上添花的工具——它是AI时代的IT基础设施层。当一个企业内部有数千个Agent每天调用数万个工具时，决定谁能调用谁、谁可以被谁发现、调用是否合规——这些问题的答案直接等于企业AI能力的上限。而掌握Registry产品标准和数据流量的云厂商，负责制定这些问题的答案。
这才是ARD之争的真正焦点。开放标准讨论的是技术兼容，但每个云厂商推出的Registry产品，恰恰是商业竞争的兵家必争之地。Agent Registry不仅是目录，更是政策引擎——谁用你的Registry，谁就可能用你的审批流程、你的审计规则、你的URN体系、你的出站策略。这些可都不是开放的。
开放式标准的未解之题
ARD规范虽已发布，但走向大规模落地仍面临多重挑战。
信任模型的实现复杂度是第一个难关。ARD的“域名即身份”看起来简洁，但企业环境中域名所有权验证、证书管理、密钥分发在Agent间的自动化场景下远比人类浏览器中的HTTPS复杂。Agent没有智商来判断一个证书是否可信——它只能根据预设策略执行。策略过松，影子Agent问题根治不了；策略过紧，Agent间协作效率大幅下降。
Registry的商业化路径同样悬而未决。如果Agent Registry像搜索引擎一样靠爬虫抓取Catalog，谁来维护Registry的运营？谁来决定搜索结果排序？会不会出现竞价排名式的Agent推广？目前规范中没有答案。
跨企业Agent发现还带来了全新的安全边界。当一个企业的Agent可以搜索到另一个企业的Agent能力描述时，信息泄露的边界在哪里？ARD目前的方案是让Catalog发布者决定什么信息对外公开、什么只在内部Registry可见，但企业间的信任传递仍是未解难题。
标准碎片化风险也并未消除。ARD和现有MCP、A2A、OpenAI GPT Actions、Anthropic Tool Use之间的关系，官方表述是“互补”而非“替代”。但多一层标准就多一层兼容性负担。企业最终可能需要为同一套能力维护多份描述文件——这恰恰是ARD试图解决的问题的反面。
这些问题并不意味着ARD没有价值。任何改变行业格局的底层基础设施，在早期必然经历兼容性、安全性和商业模式的博弈。DNS从1983年发展至今才成为互联网的骨架，ARD的路还很长。
但方向已经明确。当Google、微软、AWS——三家云巨头——同时在一个开放标准上押注，这不是一时的技术热点，而是行业共识正在形成的信号。Agent生态缺的不是更好的模型，而是一套所有人都在用的“门牌号系统”。ARD给了它第一版。后面的事——谁来画地图、谁来管交通、谁来收过路费——才是真正决定谁能赢得下一代AI基础设施治理权的关键牌局。
三巨头都已入局。这场牌局才刚刚开始。
快报