智能体发现

A2A 的智能体发现

要通过 Agent2Agent (A2A) 协议进行协作，客户端智能体首先需要“找到”远程智能体，并了解其能力。A2A 对 AgentCard 的数据格式做了标准化，但在“如何发现 AgentCard”上保留了多种策略空间，以适配不同部署环境与安全需求。

AgentCard 的作用

AgentCard 是一个 JSON 文档，可以理解为 A2A 服务端（远程智能体）的“数字名片”，通常包含：

• 身份信息：name、description、provider
• 服务端点：url
• 能力声明：例如 streaming、pushNotifications，以及可选扩展
• 认证要求：支持的认证方案与要求
• 技能列表：智能体能做什么（skill id、描述、输入/输出模式、示例等）

客户端通过 AgentCard 判断智能体是否适合、如何认证、以及如何构造请求。

常见发现策略

1) 众所周知路径（.well-known）

适用于公开智能体或希望在某个域名范围内可被广泛发现的智能体。

• 机制：在标准化路径提供 AgentCard，常见为：
  • https://{agent-domain}/.well-known/agent-card.json
• 流程：
  1. 客户端获知域名（配置、发现或用户提供）。
  2. 通过 HTTP GET 拉取 AgentCard。
  3. 按需校验并缓存元数据。

2) 策展注册表（目录/市场）

常见于企业内部或公开市场环境。

• 机制：由注册表集中存储并提供 AgentCard（或其引用）。
• 流程：
  1. 智能体把 AgentCard 发布到注册表。
  2. 客户端按技能、标签、提供方、能力等条件检索。
  3. 注册表按访问策略返回匹配的 AgentCard（可能按身份过滤）。

当前 A2A 规范并不强制规定统一的注册表 API。

3) 直接配置 / 私有发现

适用于强耦合系统、私有智能体与开发调试场景。

客户端可通过配置文件、环境变量、密钥管理系统或自定义 API 等方式，直接拿到 AgentCard 的 URL（或 AgentCard 内容）。

AgentCard 的安全性

AgentCard 可能包含敏感信息（内部 URL、受限技能、认证元数据等），建议：

• 保护 AgentCard 端点（mTLS、IP 白名单、OAuth 等）
• 按身份返回不同卡片内容（选择性披露）
• 避免在卡片中写死静态密钥；优先使用“带外”方式获取凭证

未来方向

A2A 生态仍在探索注册表、信任框架与更丰富的发现协议最佳实践。如果你的环境需要注册表，建议从一开始就把认证、授权与选择性披露纳入设计。