A2A中的Agent发现¶

为了使AI智能体能够使用Agent2Agent（A2A）协议进行协作，它们首先需要找到彼此并了解其他智能体提供的能力。A2A通过Agent Card标准化了智能体的自我描述格式。然而，发现这些Agent Card的方法可能会根据环境和需求的不同而有所变化。

Agent Card的角色¶

Agent Card 是一个 JSON 文档，作为 A2A Server（远程 Agent）的数字化"名片"。它对于发现和启动交互至关重要。Agent Card 通常包含以下关键信息：

• 身份信息：name、description、provider提供商信息
• 服务端点：可访问 A2A 服务的 URL
• A2A 能力：支持的协议特性，如streaming或pushNotifications
• 认证：与 Agent 交互所需的认证方案（例如，"Bearer"、"OAuth2"）
• 技能：Agent 可以执行的特定任务或功能列表（AgentSkill 对象），包括其 id、name, description, inputModes, outputModes 以及examples

客户端 Agent 通过解析 Agent Card 来确定远程 Agent 是否适合特定任务、如何构建对其技能的请求，以及如何安全地与之通信。

发现策略¶

1. Well-Known URI¶

这是一种推荐的方法，适用于公共 Agent 或在特定领域内需要广泛可发现性的 Agent。

• 机制：A2A Server 在其域名的标准化"well-known"路径上托管其 Agent Card。
• 标准路径：https://{agent-server-domain}/.well-known/agent.json（遵循 RFC 8615 关于 well-known URI 的原则）。
• 流程：
  • a、客户端 Agent 知道或以编程方式发现潜在 A2A Server 的域名（例如，smart-thermostat.example.com）。
  • b、客户端向 https://smart-thermostat.example.com/.well-known/agent.json 发送 HTTP GET 请求。
  • c、如果 Agent Card 存在且可访问，服务器将其作为 JSON 响应返回。
• 优势：简单、标准化，使爬虫或能够解析域名的系统能够自动发现。有效地将发现问题简化为"找到 Agent 的域名"。
• 注意事项：最适合用于开放发现或在控制域名的组织内进行发现。如果 Agent Card 包含敏感信息，提供 Agent Card 的端点本身可能需要认证。

2. 精细化的注册表（基于目录的发现机制）¶

对于企业环境、市场或专业生态系统，Agent Card 可以通过注册中心和目录进行发布和发现。

• 机制：中间服务（注册表）维护 Agent Card 的集合。客户端根据各种标准（例如，提供的技能、标签、提供商名称、所需能力）查询此注册表以查找 Agent。
• 流程：
  • a、A2A Server（或其管理员）向注册表服务注册其 Agent Card。这种注册机制超出了 A2A 协议本身的范围。
  • b、客户端 Agent 查询注册表的 API（例如，"查找具有'图像生成'技能且支持流式传输的 Agent"）。
  • c、注册表返回匹配的 Agent Card 列表或对它们的引用。
• 优势：
  • 集中管理、策划和管理可用 Agent。
  • 基于功能能力而不仅仅是域名进行发现。
  • 可以在注册表级别实现访问控制、策略和信任机制。
  • 支持公司特定或团队特定的 Agent 目录，或符合 A2A 的公共 Agent 市场等场景。
• 注意事项：需要额外的注册表服务。A2A 协议目前没有定义此类注册表的标准 API，这也是未来可能探索和社区标准化的领域。

3. 直接配置 / 私有发现¶

在许多场景中，特别是在紧密耦合的系统内、私有 Agent 或开发和测试期间，客户端可能会直接配置 Agent Card 信息或获取它的 URL。

• 机制：客户端应用程序具有硬编码的 Agent Card 详细信息，从本地配置文件读取，通过环境变量接收，或从客户端已知的私有专有 API 端点获取。
• 流程：这高度依赖于应用程序的部署和配置策略。
• 优势：对于已知的、静态的 Agent 关系或不需要动态发现的场景，简单且有效。
• 注意事项：在动态发现新的或更新的 Agent 方面灵活性较低。远程 Agent 的 card 变更可能需要重新配置客户端。基于专有 API 的发现没有通过 A2A 标准化。

Agent Card安全¶

Agent Card 有时可能包含需要保护的信息，例如：

• 仅供内部使用或限制访问的 Agent 的 URL
• 如果用于特定方案的非机密信息（例如，OAuth token URL），则 authentication.credentials 字段中的详细信息。强烈建议不要在 Agent Card 中存储实际的明文密钥。
• 敏感或内部技能的描述

保护机制：¶

• 端点访问控制：如果 Agent Card 不打算用于公共、未认证的访问，则提供 Agent Card 的 HTTP 端点（无论是 /.well-known/agent.json 路径、注册表 API 还是自定义 URL）都应使用标准 Web 实践进行保护。
  • mTLS：如果适合信任模型，要求使用相互 TLS 进行客户端认证。
  • 网络限制：限制对特定 IP 范围、VPC 或私有网络的访问。
  • 认证：要求标准 HTTP 认证（例如，OAuth 2.0 Bearer token、API Key）来访问 Agent Card 本身。
• 注册表的选择性公开：Agent 注册表可以实现逻辑，根据认证客户端的身份和权限返回不同的 Agent Card 或不同级别的详细信息。例如，公共查询可能返回有限的 card，而认证的合作伙伴查询可能收到包含更多详细信息的 card。

重要的是要记住，如果 Agent Card 包含敏感数据（再次强调，不建议用于密钥），则必须确保在没有强认证和授权的情况下永远无法访问该 card。A2A 协议鼓励客户端通过带外方式获取动态凭证的认证方案，而不是依赖嵌入在 Agent Card 中的静态密钥。

未来考虑¶

A2A 社区可能会在未来探索标准化注册表交互或更高级的语义发现协议。欢迎在这一领域提供反馈和贡献，以增强 A2A Agent 的可发现性和互操作性。