人工智能互操作性中缺失的一层：发现

来源: Agentic AI Foundation (AAIF)
作者: Angie Jones
发布时间: 2026/5/11 23:45:09
原文链接: https://aaif.io/blog/the-missing-layer-in-ai-interoperability-discovery/

---

Angie Jones

VP of Developer Experience, Agentic AI Foundation

随着我们将 AI 集成到更多工作流中，一个常见的问题是：AI 系统如何相互发现并找到相关的工件？AI Catalog 通过提供一个共享的、可信的发现层来解决这个问题，该层为不同类型的 AI 工件提供了一个共同的被发现场所。

假设你正在构建一个代理工作流（agentic workflow）。它需要一个能够对金融任务进行推理的代理（agent）、一个能够访问市场数据工具的 MCP 服务器、你的内部评估数据集，以及一个包含用于分析投资组合表现的技能和提示（prompts）的代理插件。

理论上，所有这些可能已经存在。但实际上，找到它们可能很混乱。

你需要的 MCP 服务器可能列在官方的 MCP 注册表中、第三方 MCP 目录中，或者只是作为 GitHub 上的一个仓库发布。你正在寻找的代理可能存在于 A2A 风格的索引中。技能和提示可能位于技能目录中，或者捆绑在插件市场内。这些表面各自都有其用途。

AI Catalog 并不是要取代它们中的任何一个。它是一个位于现有注册表、市场和目录之上的薄层，使得单个客户端、代理或注册表能够跨所有这些地方找到工件，而无需学习每个地方特有的发现规则。MCP 注册表仍然描述 MCP 服务器。技能目录仍然描述技能。A2A 索引仍然描述代理。AI Catalog 为它们提供了一种共同的方式来被指向、识别和信任。

多样性是好的，但发现是困难的。如果每种工件类型都有自己的发现机制，那么每个客户端、注册表、市场和平台都必须学习所有这些机制。这无法扩展。而且发现只是问题的一半。一旦你能找到某样东西，你还需要决定是否依赖它。

为什么我们需要一个发现标准

与模型能力、代理推理、工具使用或多代理协作相比，发现可能听起来微不足道。

但它并不微不足道。

在客户端调用工具之前，它必须知道该工具存在。在代理委派工作之前，它必须找到正确的对应方。在企业批准 AI 服务之前，它必须知道谁发布了它、它来自哪里以及附带了哪些声明。

如果没有共享的发现基础设施，每个协议、平台和注册表都必须回答相同的问题：

• 元数据应该存放在哪里？
• 客户端应该如何发现它？
• 工件应该如何被标识？
• 版本应该如何表示？
• 发布者信息应该如何附加？
• 信任声明应该如何表达？
• 大型目录应该如何组织？
• 注册表应该如何暴露不同类型的工件？

这些是生态系统问题，而非特定于协议的问题。这就是为什么一个通用的目录层很重要。

AI Catalog 如何工作

一个健康的代理 AI 生态系统不会由单一协议、单一注册表或单一元数据格式构成。AI Catalog 不会取代不同社区已经定义的原生元数据格式。它围绕这些格式提供了一个通用的发现层。

换句话说，AI Catalog 是一张地图。它并不试图成为领土本身。

AI Catalog 的核心是一个用于 AI 工件的类型化 JSON 容器。一个目录条目可以告诉你：

• 这是一个工件
• 这是它的稳定标识符
• 这是它的人类可读名称
• 这是它属于哪种工件类型
• 这是它的原生元数据所在位置
• 这是关于发布者、版本、标签、信任或来源的可选元数据

一个最小的目录可以非常简单：

{
“specVersion”: “1.0”,
“entries”: [
{
“identifier”: “urn:example:skill:code-review”,
“displayName”: “Code Review Assistant”,
“mediaType”: “application/agentskill+zip”,
“url”: “https://skills.example.com/code-review/skill.zip”
},
{
“identifier”: “urn:example:mcp:weather”,
“displayName”: “Weather Service”,
“mediaType”: “application/mcp-server-card+json”,
“url”: “https://api.example.com/.well-known/mcp/server-card.json”
},
{
“identifier”: “urn:example:a2a:research”,
“displayName”: “Research Assistant”,
“mediaType”: “application/a2a-agent-card+json”,
“url”: “https://agents.example.com/researchAssistant”
}
]
}

这里重要的设计选择是 mediaType。

目录消费者不必检索每个工件并检查它来猜测它是什么。目录条目预先声明了工件类型。

例如，如果客户端理解 application/mcp-server-card+json，它就能获取该工件并使用 MCP 特定规则处理 MCP 服务器卡片。如果它理解 application/a2a-agent-card+json，就能使用该格式处理 A2A 代理卡片。

如果客户端不理解某种媒体类型，它可以跳过、显示、索引该内容，或将其传递给另一个能理解的系统。

这使得 AI 目录（AI Catalog）具有可扩展性。新的工件类型可以出现，而无需每个人都重新设计目录格式。

同时，它保持了原生格式的原生性。AI 目录不会重新定义代理卡片，不会重写工具服务器卡片，也不会将元数据压缩到一个通用模式中。

通用模式乍看之下很有吸引力。一种格式适用于所有内容！整洁又美观。但在实践中，这要求每个社区都就每个工件的内部结构达成一致。这很缓慢，而且通常不切实际。

相反，AI 目录让每个工件保持其原生格式，同时提供一种共享的方式来标识和发现它。

关注点分离原则依然不败。

AI 目录的类型

AI 目录的设计考虑了渐进式复杂度。

一个小型开源项目可能只需要一个静态 JSON 文件，列出少量工件。而一个大型组织可能需要主机身份、合规证明、签名以及与企业管理注册中心基础设施的集成。

该规范通过简单目录、可发现目录、可信目录和嵌套目录来支持这些需求。

最小目录

最小目录只是一个条目列表。每个条目包含标识符、显示名称、媒体类型，以及 URL 或内联数据。

这对于简单的发现来说已经足够。例如，一个开源项目可以发布一个小型目录，指向其代理卡片、工具服务器卡片和评估数据集。

可发现目录

可发现目录增加了主机信息，并且可以发布在可预测的位置（例如知名 URI），或通过链接关系进行通告。

无需让每个客户端都知道一个自定义 URL，目录可以放在某个可预测的位置，以便客户端、爬虫、代理和注册中心能够自动找到它。

嵌套目录

AI 目录还支持嵌套目录，这意味着一个目录条目可以指向另一个目录。

例如，企业可以按部门、团队、产品线或区域组织目录：

企业目录
├── 财务目录
├── 工程目录
└── 研究目录

发布者还可以将相关工件打包在一起：

财务工作流包
├── 代理卡片
├── 工具服务器卡片
└── 评估数据集

一个有用的代理工作流可能依赖于代理、工具、数据集、策略、文档和部署元数据的组合。嵌套目录为发布者提供了一种描述这些集合的方式，而无需为每个用例发明一个独立的打包概念。

设计保持简单：一个目录可以包含条目，而一个条目本身也可以是另一个目录。

从简单发现到可信发现

找到工件只是问题的一部分。随着 AI 系统变得更加可组合，客户端还需要知道它们是否应该依赖所找到的内容。

客户端可能需要知道：

• 谁发布了这个工件？
• 发布者的身份是否可验证？
• 这个工件是否已被签名？
• 它是由什么源代码或构建过程产生的？
• 是否有合规证明？
• 自审查以来，工件是否发生了变化？
• 工件是否可以追溯到注册中心、源代码仓库或出处声明？

这就是发现变得不仅仅是：

> 这里有一份列表。

而是：

> 这里有一份列表，外加帮助你评估它们来自何处以及是否应该依赖它们的信息。

AI 目录引入了一个可选的信任清单（Trust Manifest）来携带这些信息。

信任清单与工件并列存在。它不会包装或修改工件的原生格式。这使得信任信息可以在目录层演进，而无需强制每个协议特定的模式都吸收相同的信任字段。

工具服务器卡片可以专注于描述工具服务器。代理卡片可以专注于描述代理。数据集描述符可以专注于描述数据集。

目录可以在所有这些内容周围携带通用的发现和信任元数据。

这种区别很重要，因为缺乏信任的发现只会帮助不安全的系统更快传播。

为什么 AI 注册中心和 AI 市场需要发现层

注册中心和市场（例如专门针对 MCP 服务器、技能、插件或代理的市场）是发现问题尤为突出的地方。

一个只支持一种工件类型的注册中心可以定义一种元数据模型和一种交互模式。然而，代理式 AI 基础设施不太可能保持如此狭窄。

开发者可能希望跨多种工件类型进行搜索：

• “显示所有与金融相关的代理。”
• “查找此组织发布的工具服务器。”
• “列出带有来源元数据的工件。”
• “查找同时包含代理和支持工具的包。”
• “显示此域为 AI 客户端发布的所有内容。”
• “筛选支持特定协议的工件。”
• “查找此能力的最新版本。”

通用的目录格式为注册中心构建者提供了这些用例的共享基础。

它并不强制每个注册中心拥有相同的用户界面、排名模型、治理流程或审批工作流。这些选择仍然可以各不相同。但它确实提供了通用的原语：

• 标识符
• 媒体类型
• URL
• 版本
• 发布者
• 元数据
• 信任清单
• 嵌套目录

这就是那种让生态系统更易于构建的“无聊”基础设施。而无聊的基础设施往往是最重要的一种。

开放生态系统的共享层

代理式 AI 生态系统仍处于早期阶段。不同的社区探索不同的通信、工具使用、代理交互、打包、身份和部署方法，这是健康的。

但随着生态系统的成熟，某些层应该成为共享层。

发现是其中一层。信任是另一层。

如果我们希望代理、工具和服务在开放生态系统中协同工作，我们需要的不仅仅是交互协议。

我们需要地图。而这些地图必须是可发现、可信赖且共享的。

目录化使这个多样化的生态系统变得可导航。它为开发者、注册中心、平台和企业提供了一种通用的方式来查找和评估 AI 工件，同时允许这些工件保留在其所属的社区和规范中。

这正是开放基金会应该支持的工作：中立、协作的基础设施，无需任何单一供应商拥有，每个参与者都可以帮助塑造。

AI Catalog 仍处于早期阶段，工作正在公开进行。下一步是实施经验：真实的目录、真实的工件、真实的注册中心实验，以及来自构建、保护、发布和消费这些系统的人员的反馈。

通过 GitHub issues、PRs 和讨论 参与 AI Catalog 项目，或加入 AI Catalog 工作组，该工作组由来自各种 AI 协议（MCP、A2A 等）的成员组成。