A2A 中的代理发现¶
要使用 Agent2Agent (A2A) 协议进行协作,AI 代理需要首先相互发现并了解其功能。A2A 通过 代理卡 标准化代理自描述。然而,这些代理卡的发现方法因环境和要求而异。代理卡定义了代理提供什么。客户端代理有多种策略来发现这些卡。策略的选择取决于部署环境和安全要求。
代理卡的作用¶
代理卡是一个 JSON 文档,作为 A2A 服务器(远程代理)的数字“名片”。它对于代理发现和交互至关重要。代理卡中包含的关键信息如下:
- 身份:包括
name、description和provider信息。 - 服务终点:指定 A2A 服务的
url。 - A2A 功能:列出支持的功能,例如
streaming或pushNotifications。 - 身份验证:详细说明所需的
schemes(例如,“Bearer”、“OAuth2”)。 - 技能:使用
AgentSkill对象描述代理的任务,包括id、name、description、inputModes、outputModes和examples。
客户端代理使用代理卡来确定代理的适用性、构建请求并确保安全通信。
发现策略¶
以下各节详细介绍了客户端代理发现远程代理卡的常用策略:
1. 知名 URI¶
此方法推荐用于公共代理或旨在在特定领域内广泛发现的代理。
-
机制:A2A 服务器通过在其域上的标准化、
well-knownURI 托管其代理卡,使其可被发现。标准路径是https://{agent-server-domain}/.well-known/agent-card.json,遵循 RFC 8615 的原则。 -
流程
- 客户端代理知道或通过编程发现潜在 A2A 服务器的域(例如,
smart-thermostat.example.com)。 - 客户端对
https://smart-thermostat.example.com/.well-known/agent-card.json执行 HTTP GET 请求。 - 如果代理卡存在且可访问,服务器将其作为 JSON 响应返回。
- 客户端代理知道或通过编程发现潜在 A2A 服务器的域(例如,
-
优点
- 易于实施
- 符合标准
- 促进自动化发现
-
考量
- 最适合开放或域控制的发现场景。
- 如果代理卡包含敏感详细信息,则需要对提供代理卡的终点进行身份验证。
2. 精选注册表(基于目录的发现)¶
此方法用于企业环境或公共市场,其中代理卡通常由中央注册表管理。精选注册表充当中央存储库,允许客户端根据“技能”或“标签”等条件查询和发现代理。
-
机制:中介服务(注册表)维护代理卡集合。客户端查询此注册表以根据各种条件(例如,提供的技能、标签、提供者名称、功能)查找代理。
-
流程
- A2A 服务器将其代理卡发布到注册表。
- 客户端代理查询注册表的 API,并按“特定技能”等条件进行搜索。
- 注册表返回匹配的代理卡或引用。
-
优点
- 集中管理和治理。
- 基于功能的发现(例如,按技能)。
- 支持访问控制和信任框架。
- 适用于私有和公共市场。
- 考量
- 需要部署和维护注册表服务。
- 当前的 A2A 规范未规定精选注册表的标准 API。
3. 直接配置/私有发现¶
此方法用于紧密耦合的系统、私有代理或开发目的,其中客户端直接配置代理卡信息或 URL。
- 机制:客户端应用程序利用硬编码的详细信息、配置文件、环境变量或专有 API 进行发现。
- 流程:流程特定于应用程序的部署和配置策略。
- 优点:此方法对于在已知、静态关系中建立连接非常简单。
- 考量
- 对于动态发现场景不灵活。
- 代理卡信息更改需要客户端重新配置。
- 基于专有 API 的发现也缺乏标准化。
保护代理卡¶
代理卡包含敏感信息,例如:
- 内部或受限代理的 URL。
- 敏感技能的描述。
保护机制¶
为降低风险,应考虑以下保护机制:
- 已验证代理卡:我们建议使用已验证的扩展代理卡,用于敏感信息或提供卡的更详细版本。
-
安全终点:在提供代理卡(例如,
/.well-known/agent-card.json或注册表 API)的 HTTP 终点上实施访问控制。方法包括:- 相互 TLS (mTLS)
- 网络限制(例如,IP 范围)
- HTTP 身份验证(例如,OAuth 2.0)
-
注册表选择性披露:注册表根据客户端的身份和权限返回不同的代理卡。
任何包含敏感数据的代理卡都必须通过身份验证和授权机制进行保护。A2A 规范强烈建议使用带外动态凭证,而不是在代理卡中嵌入静态密钥。
未来考量¶
A2A 社区正在探索标准化注册表交互或高级发现协议。