A2A 智能体发现
使用 A2A 协议协作之前，智能体需要先找到彼此并了解对方的能力。A2A 通过 Agent Card 标准化智能体的自我描述；至于客户端如何发现这些 Agent Card，则因环境和需求而异。Agent Card 定义智能体提供什么，发现策略的选择取决于部署环境和安全要求。
Agent Card 的作用
Agent Card 是一份 JSON 文档，相当于 A2A 服务器（远程智能体）的数字名片，对发现与交互至关重要。它包含的关键信息有：
- 身份：
name、description以及provider信息； - 服务接口：
supportedInterfaces列出服务端支持的接口，每个接口包含url、protocolBinding（如JSONRPC、GRPC、HTTP+JSON）、protocolVersion，以及可选的tenant； - A2A 能力：
capabilities声明支持的特性，如streaming、pushNotifications、extensions，以及是否提供认证后的扩展 Agent Card（extendedAgentCard）； - 认证：
securitySchemes与securityRequirements声明认证方案和要求； - 技能：用
AgentSkill对象描述智能体能完成的任务，包含id、name、description、tags、inputModes、outputModes、examples； - 默认输入/输出模式：
defaultInputModes与defaultOutputModes。
客户端智能体借助 Agent Card 判断智能体是否适用、构造请求并确保安全通信。完整字段定义见协议规范：智能体发现 。
发现策略
1. Well-Known URI
适用于公开智能体，或在特定域名内需要广泛被发现的智能体。
- 机制：A2A 服务器把 Agent Card 托管在自己域名下标准化的
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 请求； - 如果 Agent Card 存在且可访问，服务器以 JSON 响应返回。
- 客户端智能体已知或通过程序发现某个潜在 A2A 服务器的域名（例如
- 优点：实现简单、遵循标准、便于自动化发现。
- 注意事项：最适合开放或域名可控的发现场景；如果 Agent Card 含有敏感信息，提供它的端点需要认证。
2. 精选注册中心（基于目录的发现）
适用于企业环境或公共市场，Agent Card 通常由中心化的注册中心管理。注册中心充当集中式仓库，允许客户端按"技能"、“标签"等条件查询和发现智能体。
- 机制：中介服务（注册中心）维护一组 Agent Card，客户端按各类条件（提供的技能、标签、提供方名称、能力等）查询。
- 流程：
- A2A 服务器把 Agent Card 发布到注册中心；
- 客户端智能体查询注册中心 API，按"特定技能"等条件搜索；
- 注册中心返回匹配的 Agent Card 或引用。
- 优点：集中管理与治理；支持按能力（如技能）发现；支持访问控制与信任框架；同时适用于私有和公共市场。
- 注意事项：需要部署和维护注册中心服务；当前 A2A 规范没有规定注册中心的标准 API。
3. 直接配置 / 私有发现
适用于紧耦合系统、私有智能体或开发场景，客户端直接配置 Agent Card 信息或 URL。
- 机制：客户端应用使用硬编码信息、配置文件、环境变量或私有 API 来发现。
- 流程：取决于应用自身的部署与配置策略。
- 优点：在已知、静态的关系中建立连接很直接。
- 注意事项：不适合动态发现场景；Agent Card 信息变化需要重新配置客户端；基于私有 API 的发现同样缺乏标准化。
保护 Agent Card
Agent Card 可能包含敏感信息，例如内部或受限智能体的 URL、敏感技能的描述。
防护机制
- 认证后的扩展 Agent Card：对于敏感信息或需要提供更详细版本的 Agent Card，建议使用需要认证才能获取的扩展 Agent Card（
GetExtendedAgentCard，服务端通过capabilities.extendedAgentCard声明支持）。 - 保护端点：对提供 Agent Card 的 HTTP 端点（如
/.well-known/agent-card.json或注册中心 API）实施访问控制，方式包括双向 TLS（mTLS）、网络限制（如 IP 范围）、HTTP 认证（如 OAuth 2.0）。 - 注册中心选择性披露：注册中心根据客户端的身份和权限返回不同的 Agent Card。
任何包含敏感数据的 Agent Card 都必须用认证和授权机制保护。A2A 规范强烈建议使用带外的动态凭据，而不要在 Agent Card 中嵌入静态密钥。
Agent Card 签名
Agent Card 可以使用 JSON Web Signature（JWS，RFC 7515
）进行数字签名，让客户端验证 Agent Card 未被篡改，并确实来自声称的提供方。签名前需要按 JSON Canonicalization Scheme（JCS，RFC 8785
）对 Agent Card 内容做规范化，且 signatures 字段本身不参与签名。签名的格式与验证流程详见协议规范
。
缓存
Agent Card 描述智能体的能力，通常变化不频繁，例如新增技能或更新认证要求时才会变化。对 Agent Card 端点应用标准的 HTTP 缓存实践，可以减少不必要的网络请求，同时保证客户端最终能获得更新后的信息。
服务端建议：托管 Agent Card 端点的服务器应在响应中包含 HTTP 缓存头。带有合适 max-age 指令的 Cache-Control 头允许客户端和中间节点在指定时间内缓存 Agent Card；再包含一个由 Agent Card 的 version 字段或内容哈希生成的 ETag 头，客户端就可以发起条件请求，避免重复下载未变化的 Agent Card。
客户端建议：获取 Agent Card 的客户端应遵循标准的 HTTP 缓存语义。缓存过期后，应使用条件请求（例如携带已存储 ETag 的 If-None-Match，或 If-Modified-Since），而不是无条件地重新获取完整的 Agent Card。服务器没有提供缓存头时，客户端可以采用合理的默认缓存时长。对于扩展 Agent Card，客户端还应遵循规范中会话范围的缓存指引。
规范性要求见协议规范中智能体发现一节的缓存部分。
未来展望
A2A 社区正在探索标准化注册中心交互或更高级的发现协议。