一句话理解
如果 MCP / A2A / OpenAPI 解决“怎么连接和调用”，ARD 解决的是“在还不知道要调用什么之前，如何可靠地找到候选能力”。
- 它让开发者把能力发布到自有域名的
ai-catalog.json。 - 它让 Registry 像搜索引擎一样抓取、索引、排序这些能力。
- 它让 Agent 在运行时按意图搜索，而不是预先装满所有工具。
01 · 核心判断
ARD 要补的不是“工具调用”，而是“能力发现”的基础设施缺口。
Google 博客把它称为 agentic web 的缺失层；规范本身更精确地说：它是面向 agentic resources 的联邦发现与搜索规范。
为什么现在出现
- A预装模式到达上限。 当资源从几十个变成成千上万个，硬编码 MCP URL、插件清单或私有 catalog 无法覆盖长尾需求。
- B上下文窗口不是注册表。 把所有工具说明塞给 LLM 既昂贵又粗糙，还无法充分利用发布者身份、合规证明、代表性查询等检索信号。
- C企业需要治理，而不是无边界连接。 ARD 把发现、验证、策略过滤和运行时授权拆开，使企业可以用自己的 Registry 控制答案集合。
发布
发布方在域名下放置 /.well-known/ai-catalog.json，列出 MCP、A2A、Skills、API、嵌套 catalog 或 Registry。
抓取
Registry 通过 well-known、robots 指令、HTML link 或 DNS 线索发现 catalog，并持续索引。
搜索
Agent 用自然语言意图和结构化过滤条件发起 POST /search，获取排序后的候选能力。
验证
客户端或企业网关检查 URN 域名、trustManifest 身份、证明材料、来源链与签名。
直连
通过资源原生协议执行调用。此时 ARD 退场，MCP、A2A 或 API 接手。
02 · 重绘架构图
从发布者域名到运行时调用：ARD 是一条“发现—验证—交接”的控制链。
下面的架构图把博客中的流程重新组织为四层：发布层、发现层、治理与验证层、执行层。重点不是“新增一个中央市场”，而是让多个 Registry 通过同一数据模型和 REST 搜索接口联邦协作。
ARD Concept Architecture · Publish → Crawl → Search → Verify → Connect
横向滚动可查看完整图
Catalog 是发布面它像网页的 HTML：让资源第一次有了可抓取的结构化表面。
Registry 是搜索面它负责语义检索、过滤、分页、联邦，并可返回 referrals。
Trust 是连接前门槛URN、trustManifest 与企业策略共同决定是否允许连接。
Execution 不被替代ARD 不定义工具怎么跑，只把正确的入口交给原生协议。
03 · 数据模型
一个轻量 catalog，把能力变成可搜索、可排序、可验证的“资源条目”。
规范的中心是 ai-catalog.json。它不是把资源复制到一个平台，而是提供一个统一 envelope：资源仍在原地，发现信息变得机器可读。
稳定逻辑身份
urn:ai:<publisher>:<namespace>:<agent-name> 把资源绑定到可验证域名。它是搜索与联邦合并时的稳定主键，不随部署地址变化。
媒体类型驱动
条目用 IANA 风格 media type 表达资源形态，例如 A2A agent card、MCP server card、AI skill、嵌套 catalog 或 registry。
值或引用，二选一
url 指向远端 artifact，data 内嵌完整 artifact。规范强调二者互斥，避免解析歧义与企业环境中的不确定行为。
给语义搜索可训练信号
资源描述常常太泛。代表性自然语言查询可以帮助 Registry 建向量索引，让“我要转写音频”匹配到相关 MCP 或 skill。
信任元数据的挂钩
包含 cryptographic identity、attestations、provenance 与 signature。它不让资源自动可信，而是让验证流程有结构化证据可检查。
通用 Registry 接口
查询模型由 text 与 filter 组成：语义意图负责相关性，结构化过滤负责类型、标签、发布者、证明材料与企业策略约束。
ARD 负责什么
发布把资源能力、入口和信任信息写进 catalog。
发现通过 Registry 抓取、索引、语义排序和过滤。
联邦让私有、公共、供应商 Registry 以 auto、referrals 或 none 模式协作。
连接前验证把 trustManifest 和 publisher 域名交给客户端或企业网关检查。
ARD 不负责什么
执行协议不替代 MCP、A2A、OpenAPI、workflow runtime。
授权决策不决定用户是否有权调用资源；授权仍由身份系统和业务策略完成。
安全沙箱不保证运行时无害；仍需要隔离、审计、限权和人工确认。
单一市场不是一个中心化 app store；不同 Registry 可以服务不同组织与领域。
04 · 信任机制
ARD 最有价值的地方不是“搜到”，而是搜到之后能不能建立可解释的信任链。
Google 博客把验证放在四阶段流程的第三步。这个位置很关键：Agent 即将代表用户行动，发现不可信会把风险规模化。
可信连接的最小公式：
域名锚定 URN + trustManifest + 企业策略 = 连接前许可。
URN 中的 publisher 提供命名空间和组织锚点；trustManifest 提供可验证身份、合规证明、来源链与签名；企业策略决定在当前用户、任务、数据边界和风险等级下是否允许调用。三者缺一，都会让“发现”停留在候选列表，而不是安全连接。
Evidence
规范要求 catalog entry 使用域名锚定 URN，并把物理入口放在 url 或 data。
Implication
身份与位置被拆开。 企业迁移网关或更换云环境时，资源逻辑身份可以保持稳定，Registry 索引和客户端策略不必全部改写。
Evidence
Search response 中的 score 被规范定义为语义相关性信息，明确不能被当作安全或合规评级。
Implication
排序和信任必须分层。 最相关的资源不一定可用、合规或可信；企业网关需要在排序之后继续做策略裁剪。
Evidence
trustManifest 可以携带 SPIFFE、DID、HTTPS FQDN、SOC2、GDPR、HIPAA 等证明材料位置或摘要。
Implication
合规从文档变成可检索元数据。 Agent 平台可以先过滤“有 SOC2 证明的供应商能力”，再让人工或策略引擎复核。
Evidence
ARD 把身份验证委托给 artifact 协议和底层身份体系，不在发现层实现完整授权。
Implication
发现只是前门。 运行时仍需要 OAuth、mTLS、secret 管理、工具权限和审计日志。把 ARD 当作“安全全包”会低估风险。
05 · 战略含义
ARD 可能把 agent 能力分发，从“安装插件”推进到“意图搜索”。
这不是简单的开发者便利功能。它会改变工具生态、企业治理、平台竞争和“agentic SEO”的激励结构。
能力开始需要“可发现性工程”
未来发布 MCP server、Skill 或 Agent，不只是写 README。你还要写好 catalog、代表性查询、标签、合规证明和可验证身份，让 Registry 能正确理解并排序。
谁掌握 Registry，谁影响能力分发
GitHub、Hugging Face、Google Cloud 等参考实现说明，平台会把既有生态包装成 ARD 入口。开放规范降低接入门槛，但分发入口仍可能集中到高质量 Registry。
工具治理从静态清单升级为策略化检索
企业可以维护一个内部 Registry，把内部资源、经批准的供应商资源、公共 referrals 统一成一个受控答案集合，同时保留对 egress、pinning 和审计的控制。
上下文窗口减负，按需注入工具
Agent 不需要长期携带所有工具描述。它可以先搜索，再把少数候选能力注入运行时，从而减少 token 成本和工具选择噪声。
发现攻击面也会被产业化
当“被 agent 搜到”有商业价值，虚假 catalog、关键词堆砌、低质证明、相似名称抢注都会出现。Registry 质量和信任验证会成为竞争点。
开放联邦优先于单一目录
ARD 的价值在于让多种资源协议共享发现表面，而不是把所有协议合并。它更像 DNS + search 的控制模型，而不是一个统一 runtime。
06 · 企业落地路线
对企业来说，正确起点不是“开放所有工具”，而是先建立可控的发现域。
如果把 ARD 直接接到公共网络，风险会先于价值放大。更稳妥的做法是用内部 Registry 作为政策边界，把公共资源作为受控 referrals。
资源盘点与最小 catalog
- 列出内部 MCP、A2A、API、Skill、工作流资源。
- 定义 URN 命名规则和 owner 责任人。
- 为高频资源补齐 description、capabilities 与 representativeQueries。
- 使用 conformance 工具验证首批
ai-catalog.json。
私有 Registry 与策略过滤
- 部署内部
POST /search服务。 - 按用户角色、数据敏感度和资源类型配置过滤策略。
- 接入 trustManifest 检查与 allowlist。
- 记录搜索、候选选择、连接许可与实际调用日志。
联邦与生产治理
- 评估供应商 Registry 与公共 Registry referrals。
- 建立 egress policy、tool pinning、版本冻结和回滚机制。
- 为高风险工具加入人工审批或 step-up auth。
- 把发现质量纳入 eval：召回率、误选率、拒绝率、合规命中率。
07 · 风险与观察指标
ARD 会让能力连接更开放，也会让“发现层安全”成为新的战场。
深度解读必须保留边界：ARD 是必要条件，不是充分条件。它让资源更容易被找到，但不会自动保证资源安全、合规或适合当前用户。
草案演进风险
规范当前为 v0.9 草案，media type 和 schema 仍在调整。例如最新 ADR 与 conformance 材料使用 application/mcp-server-card+json，强调这是发现卡片而非运行时协议流。
发现投毒与“agentic SEO”
代表性查询、标签和描述会影响排序。Registry 需要反垃圾、信誉、签名、人工审核和行为反馈，否则长尾资源可能被关键词堆砌污染。
查询泄露意图
Agent 搜索请求本身可能暴露企业正在处理的任务、客户、系统或事件。生产环境需要私有 Registry、脱敏、查询日志治理和边界隔离。
验证不等于行为可信
trustManifest 可以证明“谁发布、有哪些证明、元数据是否完整”，但不能证明工具在每次运行时都不会越权、泄露数据或返回误导结果。
接下来值得观察的五个信号
- 主流 agent 客户端是否把 ARD 搜索结果作为工具按需注入机制，而非仅做目录浏览。
- 企业 Registry 是否提供策略模拟、审批流、审计回放和工具版本 pinning。
- 公共 Registry 是否出现信誉体系、publisher verification badge 与反垃圾排序。
- MCP、A2A、Skill、OpenAPI 社区是否统一发现卡片的 media type 与元数据映射。
- 开发者是否开始把 catalog 质量视为分发能力：代表性查询、合规证明、文档与运行可用性一起优化。
08 · Source Index
来源、边界与可验证材料。
本报告基于公开博客、规范仓库和参考实现文章整理。因为 ARD 仍为草案，报告中涉及 media type 与实现生态的判断应随规范更新复核。
Google Developers Blog
Announcing the Agentic Resource Discovery specification提供发布背景、两大原语 catalogs / registries、四阶段运行演示和 Gemini Enterprise Agent Platform 的企业治理视角。
ARD Specification Repository
ards-project/ard-spec规范单一信源，包含 v0.9 草案、schema、OpenAPI、URN naming guide、ADR 与 conformance 工具。
Hugging Face Blog
Agentic Resource Discovery: Let agents search解释 ARD 位于 MCP、Skills、A2A 前方，并展示 Hugging Face Discover Tool 如何把 Spaces、Skills、MCP server 暴露为 ARD 条目。
Microsoft Command Line Blog
Introducing the Agentic Resource Discovery specification强调 ARD 更接近 DNS + search 的控制模型：不同发现服务可以服务公共、供应商或企业私有答案集合。