Google 与多家行业合作伙伴发布了 Agentic Resource Discovery（ARD）规范，试图解决 AI Agent 生态中的一个基础问题：当工具、API 和其他 Agent 持续变化时，Agent 如何动态找到可用能力，并判断这些能力是否可信、兼容且适合当前任务。
ARD 的定位不是替代 MCP、OpenAPI 等执行协议，而是在它们之上增加发现层。目录负责发布资源，注册中心帮助检索资源，现有协议继续负责描述参数和执行调用。这种分层让 Agent 不必把所有工具绑定在代码或系统提示词中。
发现与执行需要分开
当前不少 Agent 应用在启动时加载一组固定工具：开发者编写函数定义，将 OpenAPI 文档转换成工具，或者配置若干 MCP Server。工具数量较少时，这种方式足够直接；当组织内部出现数百个 API、多个版本和不同信任等级时，静态配置会暴露几个问题：
- Agent 的上下文无法容纳全部工具定义。
- 工具升级、下线后，静态清单容易失效。
- 同名能力可能由多个团队或供应商提供。
- 找到一个接口，并不代表该接口已经通过身份、来源和完整性验证。
ARD 所描述的目录和注册中心可以承担检索入口。Agent 先根据任务查找候选资源，再读取资源指向的 MCP、OpenAPI 或其他执行描述，最后按照本地安全策略决定是否调用。
可以把这套流程理解为：
用户任务
↓
能力查询，例如“发送审批邮件”
↓
ARD 目录或注册中心
↓
候选工具、API 或 Agent + 来源与验证信息
↓
读取 MCP/OpenAPI 执行描述
↓
策略检查、授权与实际调用
这里最重要的边界是：发现结果只是候选项，不应自动等同于执行许可。
Catalog、Registry 与信任信息各自做什么
从来源摘要可以确定，ARD 强调基于 catalog 和 registry 的发现机制，并关注验证、互操作性与信任。实际落地时，可以把几个角色分开处理：
- 资源发布者声明能力、版本、执行协议和描述文档的位置。
- Catalog保存资源元数据，让能力能够被索引和查询。
- Registry提供跨团队或跨目录的发现入口。
- 执行协议继续使用 MCP、OpenAPI 等既有机制。
- 策略执行方根据签名、发布者、环境和权限决定是否放行。
这种设计的价值在于，发现层不必重新定义每个 API 参数，也不必发明另一套工具调用格式。例如，目录记录可以说明某项能力使用 OpenAPI，并指向对应文档；Agent 在选中该资源后，再解析 OpenAPI operation 并执行请求。
信任同样不能只靠一个 verified: true 字段。生产系统至少要追问：谁完成了验证、验证的对象是哪一个版本、元数据是否被篡改、签名是否过期，以及发布者是否仍在允许名单中。
可以这样实践：搭建一个最小发现目录
下面是一个演示性伪项目，用于说明如何把“发现”和“执行描述”连接起来。字段名称仅为实践假设，并不代表 ARD 正式规范中的真实 Schema；接入正式实现时，应替换为规范定义的字段和验证流程。
创建 catalog.yaml：
resources:
- id: com.example.ticket-search
name: Ticket Search API
description: Search support tickets by keyword and status
version: 1.2.0
capabilities:
- search_support_tickets
execution:
protocol: openapi
descriptor: https://tools.example.com/tickets/openapi.json
publisher:
id: com.example.platform
verification:
status: verified
digest: sha256:replace-with-real-descriptor-digest
- id: com.example.docs-agent
name: Internal Documentation Agent
description: Answers questions using approved internal documentation
version: 2.0.1
capabilities:
- answer_internal_docs
execution:
protocol: mcp
descriptor: https://agents.example.com/docs/mcp.json
publisher:
id: com.example.knowledge
verification:
status: verified
digest: sha256:replace-with-real-descriptor-digest
再创建一个可运行的 discover.py。运行前需要安装 PyYAML，并将查询词作为命令行参数传入：
#!/usr/bin/env python3
import sys
from pathlib import Path
import yaml
def discover(catalog: dict, query: str) -> list[dict]:
words = {word.lower() for word in query.split()}
matches = []
for resource in catalog.get("resources", []):
searchable = " ".join([
resource.get("name", ""),
resource.get("description", ""),
*resource.get("capabilities", []),
]).lower()
score = sum(word in searchable for word in words)
verified = resource.get("verification", {}).get("status") == "verified"
if score and verified:
matches.append((score, resource))
matches.sort(key=lambda item: (-item[0], item[1]["id"]))
return [resource for _, resource in matches]
def main() -> None:
query = " ".join(sys.argv[1:]) or "search support tickets"
catalog = yaml.safe_load(Path("catalog.yaml").read_text(encoding="utf-8"))
for resource in discover(catalog, query):
execution = resource["execution"]
print(f'{resource["id"]} {resource["version"]}')
print(f' protocol: {execution["protocol"]}')
print(f' descriptor: {execution["descriptor"]}')
if __name__ == "__main__":
main()
执行：
python -m venv .venv
. .venv/bin/activate
python -m pip install PyYAML
python discover.py "search support tickets"
这个示例只完成本地检索和最低限度的状态过滤。生产实现还需要下载 descriptor、校验摘要或数字签名、限制允许的发布者，并在调用工具前进行用户授权。
接入时不要省略这些控制
ARD 降低了发现能力的成本，但动态发现也扩大了攻击面。恶意发布者可能伪装成常用工具，合法工具的描述文档也可能在发布后被替换。采用这类机制时，建议建立以下检查项：
- 将资源身份绑定到可验证的发布者，而不是只相信显示名称。
- 对目录记录和执行描述做签名或内容摘要校验。
- 固定生产环境允许使用的协议、域名和发布者范围。
- 把“可被发现”与“允许执行”设为两个独立权限。
- 记录 Agent 选择了哪个资源版本、选择原因及实际调用结果。
- 为失效、撤销和版本升级设计缓存刷新机制。
- 对高风险操作保留人工确认、最小权限凭证和调用限额。
ARD 值得关注的地方，不是又增加了一种调用协议，而是尝试为分散的 Agent 能力建立统一入口。团队可以先从内部只读目录开始，复用现有 OpenAPI 或 MCP 资产，并逐步加入发布者验证、版本治理和策略控制。只有当发现结果能够被独立验证，而且执行仍受明确授权约束时，动态工具发现才适合进入生产环境。