AWS 再推 ARD：MCP Server、Agent 和 Skills 能被统一发现吗

AWS 再推 ARD：MCP Server、Agent 和 Skills 能被统一发现吗

AWS 在 8 月 31 日的技术回顾里再次提到 Agentic Resource Discovery（ARD），把它概括成“面向 Agent 的 DNS”。这个比喻抓住了重点：三五个 MCP Server 尚可依靠配置文件和内部文档；当 Agent、Skills、A2A Agent Card、API 与工作流散落在多个云、SaaS 和本地环境里，客户端首先要知道到哪里找到可用能力。

[AWS 的 ARD 说明](https://aws.amazon.com/blogs/machine-learning/agentic-resource-discovery-ard-an-open-specification-for-agent-discovery/)发布于 8 月 24 日，本周又被官方回顾带回开发者视野。它强调 ARD 是开放规范，并非 AWS Agent Registry 的专属接口。当前 [ARD 官方仓库](https://github.com/ards-project/ard-spec)标注的版本为 v0.91，仍在演进。讨论它时既不应当成概念演示，也不宜写成已经稳定普及的互联网基础设施。

ARD 管“在哪里”，MCP 与 DASP 管另外两件事

ARD 的核心是让发布者以统一格式描述资源，再让注册表抓取、索引和联邦搜索。资源可以是 MCP Server、Agent、Skill、API 或工作流，目录由发布者自己的域名锚定。一个典型入口是 /.well-known/ai-catalog.json：组织在可控域名下发布目录，注册表读取元数据，客户端根据任务搜索合适能力。资源不必搬进同一个平台，原环境仍然掌握上下架和访问控制。

这层分工很容易与 MCP 混在一起。MCP 描述客户端怎样查看并调用工具，ARD 解决这些工具如何进入可发现目录；A2A 更关注 Agent 之间的发现、委派和任务协作；DASP 管持久会话、事件历史与断线恢复。一个 Agent 通过 ARD 找到报表工具，通过 MCP 调用，再把长任务放进 DASP 会话，三层可以同时存在。可参考 [A2A、MCP 与 DASP 的协议分工](/articles/a2a-agent-protocol-aaif-mcp-dasp)，避免把所有能力都塞进同一份工具协议。

统一目录还缓解上下文浪费。客户端无需在每次请求前把几百个工具定义全部交给模型，可以先查询注册表，取得少量候选后再加载具体 schema。不过，搜索结果排序、自然语言描述质量和版本兼容会直接影响模型选错工具的概率。目录字段需要可测试、可弃用并标明环境，不能只堆营销介绍。

能被发现，不等于已经可信或有权调用

域名锚定能说明目录从哪里发布，却不能自动证明其中的安全认证、数据范围和服务质量都真实。企业注册表仍需审批、签名校验、所有者、风险等级、版本、依赖、数据分类与退出机制。运行时授权也必须留在资源端：Agent 找到一个财务查询 MCP Server 后，还要经过身份认证、Token 受众检查和细粒度权限，不能把目录可见性当成调用许可。

联邦搜索会带来新的供应链入口。上游目录被接管、描述被篡改、同名资源抢占和过期 endpoint 都可能把 Agent 引向错误服务。落地初期适合只索引明确允许的域名，在测试环境验证 schema、鉴权和副作用；生产目录保留人工批准与快速下架。对于会写数据、发消息或执行代码的工具，调用前确认与审计仍然必要。

现阶段更实际的做法，是先建立企业内部 Agent 资产清单，再把稳定资源映射成 ARD 目录。已有 [MCP Inspector 测试流程](/articles/open-source-mcp-inspector-testing-debugging)可以继续验证具体服务器，ARD 只补发现层。AnyAIS 的模型网关与 DASP 会话能力分别承接模型接入和运行状态；若后续接入 ARD，目录信息也应与模型、工具权限和会话审计分开治理。