ARD（智能体资源发现规范）
| 分类 | 🔗 技术协议 |
| 阅读时间 | ⏱️ 16 分钟 |
| 更新时间 | 📅 2026-11-09 |
| 条目编号 | ENC-PROTOCOL-23-ard |
关键要点 ✦
- 发布主体与定位：据 Cisco Outshift 官方博客（页面标注 2026-06-17 发布、2026-10-05 更新），Cisco 联合 Databricks、GoDaddy、GitHub、Google、Hugging Face、Microsoft、NVIDIA、Salesforce、ServiceNow、Snowflake 等共同公布 ARD 规范，规范站点为 agenticresourcediscovery.org，代码组织在 GitHub 的 ards-project；其目标是把智能体发现从「手工安装、静态目录」转向「运行时按意图检索」。
- 治理与实现分工：据该博客，ARD 建立在 Linux 基金会下的 AI Catalog 工作组之上；AGNTCY Agent Directory（dir.agntcy.org）是同一 Linux 基金会体系下的开源参考实现，二者与 AI Catalog 一起构成「规范—目录—实现」三层，而不是同一个东西。
- 三类 AI Cards：据 Cisco 官方说明，Agent Directory 把资源表示为 AI Cards，并支持 MCP AI Cards（服务器与工具）、A2A AI Cards（智能体通信端点）、AgentSkills AI Cards（可复用能力）三类，使其能作为与具体运行时、框架无关的通用发现层。
- 联邦检索机制：据该博客 FAQ，目录用分布式哈希表（DHT）与点对点同步把多个目录实例聚成统一发现平面；查询分两步——先在 DHT 中按 OASF 核心属性定位相关摘要及其宿主节点，再由本地节点触发 OCI（Open Container Initiative）数据同步拉取记录，之后在本地按约束、成本与评测分数做完整检索。
- 信任与身份：据该 FAQ，目录使用密码学签名且可验证的 AI Cards 保证真实性及来源，并接入 SPIFFE、SPIRE 等工作负载身份框架做跨域信任；各组织在联邦内保留自己的策略与数据共享边界。
- 成熟度需如实标注：据第三方技术审计站 llm4agents 2026 年对 dir 与 oasf 仓库的逐项核查，OASF v1.1.0（2026-07-10 发布）的记录对象只有 11 个字段且不含价格字段，而 IETF 草案 draft-mp-agntcy-ads-02 的前言承诺可按成本、延迟与资源需求评估能力，规范文本与实现之间存在落差；该审计还指出每次查询必须带至少一个技能条件、纯领域或纯模块查询不被支持。另有标准观察站 Agent Surface 把 AGNTCY/OASF 列为「可贡献、宜观察」而非可承载生产依赖的方向。以上第三方口径未经独立复核，本站仅作现状参考。
为什么静态目录撑不住多智能体
单个智能体接工具时，工具清单可以写死在配置里；但当系统里出现几十上百个由不同团队、不同框架、不同云环境各自部署的智能体与工具时，人工维护的清单会立刻变成瓶颈。据 Cisco Outshift 官方博客描述，现实中的大企业往往是「一片拼凑的实验场」：智能体散落在业务单元、区域数据中心、云环境和运营域里，能力被锁在厂商与框架的孤岛中，某个团队做好的能力对另一个团队既不可见也不可信。
ARD 把这种局面重述成一个检索问题：不是在部署时把已知清单写进配置，而是在运行时按当前意图去查询「现在有哪些能力能帮我做这件事」。规范站 agenticresourcediscovery.org 与 GitHub 上的 ards-project 承载规范文本；按该博客的说法，这一转变能带来网络效应——更多能力被发布、被发现、被复用，而不是每两个系统之间都写一遍专用适配层。
规范、目录与实现的三层分工
容易混淆的是三个名字的关系。据 Cisco 官方说明，ARD 是规范本身，建立在 Linux 基金会下的 AI Catalog 工作组之上，标准化智能体如何查询和使用跨注册表的能力；AI Catalog 是承载该规范的工作组与目录语境；AGNTCY Agent Directory 则是开源参考实现，提供规范的消费 API，开发者可以先在本地跑一个目录实例做开发与发现，再把同一批卡片提升到集群化、联邦化的生产环境。三者不是同义词，也不是同一个组织的产品线。
AGNTCY 本身的历史更长：据 Cisco Outshift 的项目页，它由 Outshift 于 2025 年 3 月联合 LangChain、Galileo 发起，2025 年 7 月捐给 Linux 基金会以取得中立治理，核心组件包括发现、身份、消息与可观测性；该页称 2026 年生态已接近 150 个成员、6 个活跃工作组，其组件与建设者还进入了 AAIF、A2A 协议以及 ARD 规范等更广泛的社区。理解这条时间线很重要：ARD 是后来在既有 OASF、目录、身份工作之上收敛出来的规范层，而非凭空出现的新协议。
AI Cards 与联邦查询怎么工作
据 Cisco 官方 FAQ，Agent Directory 把各类资源统一表示为 AI Cards，并同时支持 MCP AI Cards（服务器与工具）、A2A AI Cards（智能体通信端点）与 AgentSkills AI Cards（可复用能力）。这一设计使目录不绑定特定运行时或框架：一个 MCP 服务器、一个 A2A 端点、一份技能包，都可以作为可检索、可验证的记录出现在同一张发现平面上。这也解释了 ARD 与相邻协议的关系——MCP 管「智能体怎么接工具」，A2A 管「智能体之间怎么委派任务」，而 ARD 管「怎么知道有哪些工具和智能体存在」；本站的 A2A、Agent Card 与 MCP 市场词条分别覆盖了后两层中的其他切面。
联邦是它区别于普通应用商店的关键。据同一 FAQ，目录实例通过 DHT 与点对点同步聚成统一发现平面，查询分两步：先在 DHT 中按核心 OASF 属性找出相关摘要及其宿主节点，再由本地节点触发 OCI 数据同步拉取完整记录，随后在本地按约束、成本与评测分数做细粒度检索。各组织保留自己的策略与共享边界，因此这是跨组织边界的发现而非把数据交出去。安全上，目录采用密码学签名、可验证的 AI Cards 保证真实性与来源，并接入 SPIFFE、SPIRE 一类工作负载身份框架，让「找到某个能力」与「确认这个能力确实由声称的一方发布」成为两个可分别验证的步骤。
现状、落差与采用建议
需要克制地看待成熟度。据第三方审计站 llm4agents 对 IETF 独立草案 draft-mp-agntcy-ads-02 与 dir、oasf 两个仓库的逐项核查，OASF 记录被打包为 OCI 制品、用 Kademlia DHT 做两级映射（技能到内容标识、内容标识到节点）、用 Sigstore 做来源、用 SPIFFE 做联邦身份，工程密度较高；但该记录对象只有 11 个字段，不含任何价格或计费字段，而草案前言却承诺可按成本、延迟与资源需求评估能力——规范承诺与实现之间有可见落差。该审计还指出，因技能是 DHT 的主键，每次查询必须带至少一个技能条件，纯领域或纯模块查询不被支持，技能分类法因此成为整个系统的承重墙，而分类法本身会漂移。上述均为第三方审计口径，本站未独立复核。
另据标准观察站 Agent Surface 的追踪，OASF v1.1.0 于 2026-07-10 发布，Schema 尚未收敛到稳定版本，周边检索索引与目录运营工具仍偏早期；AGNTCY Dir 在 2026 年 8 月至 10 月间陆续加入 HTTP 搜索接口、稳定性修复与可验证身份声明、内容策略、运行时工作负载过滤等能力，其建议是可参与、可观察，但不宜把生产依赖直接压在上面。对工程团队而言，较务实的路径是先在本地目录实例里把能力描述与技能分类法整理清楚，再评估联邦化；同时把「能力发现」与「能力授权」分开设计，前者可以相对开放，后者仍应走非人类身份治理与最小权限的既有链路。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
🎯 应用场景
✅ 最佳实践
- 区分规范、工作组与参考实现：ARD 是规范，AI Catalog 是 Linux 基金会工作组，AGNTCY Directory 是开源实现，选型与评估时不要混为一谈。
- 先治理技能分类法再谈联邦检索：技能是 DHT 查询的主键，分类法漂移会直接削弱发现召回。
- 把「发现」与「授权」分层：可发现不等于可调用，能力调用仍需接入工作负载身份与最小权限校验。
- 用签名与可验证来源约束卡片真实性，尤其当目录跨组织边界联邦时，别把目录返回内容当作可信输入。
- 对成本、延迟、评测分数一类字段，先核实当前实现是否真的提供，不要直接按规范前言的承诺做容量或计费设计。
- 从本地目录实例起步做能力描述与检索质量验证，联邦化作为后续扩展，并持续跟踪 Schema 版本稳定性。
🔮 未来展望
随着 MCP、A2A 等协议在同一基金会体系内收敛，能力发现很可能从各框架自带的私有注册表，逐步让位于中立的联邦发现层；AI Cards 若与可验证身份、评测分数、成本信号进一步打通，目录有望从「找得到」升级为「可比较、可问责」的能力市场底座。但这条路径的前提是 Schema 稳定、分类法治理成熟、规范承诺与实现差距收敛，短期内更现实的定位仍是可观察的基础设施而非可直接依赖的生产组件。本站将持续跟踪 AGNTCY Dir 版本迭代与 ARD 规范在 IETF 等标准组织的推进情况。