如何发布和发现 A2A 兼容的智能体？

1. 发布 Agent Card 到 well-known URL

A2A 协议采用去中心化的发现机制，智能体通过在其服务域名的 /.well-known/agent.json 路径下发布 Agent Card JSON 文档来宣告自身能力。该路径遵循 RFC 8615 定义的 well-known URI 规范，使任何其它智能体能够通过构造标准 URL 来发现并获取该智能体的能力描述。Agent Card 文档应包含完整的身份信息、服务端点、支持的功能、技能列表和认证要求，使客户端智能体能够全面了解该智能体的能力并决定是否需要与之交互。

2. 客户端获取并解析 Agent Card

客户端智能体通过向目标智能体的 /.well-known/agent.json 端点发送 HTTP GET 请求来获取其 Agent Card。获取到 Agent Card JSON 文档后，客户端解析其中的各个字段：检查 capabilities 字段了解该智能体支持的功能（如是否支持流式传输、推送通知）；检查 skills 数组了解该智能体提供哪些具体技能；检查 authentication 字段了解需要使用的认证方案。基于这些信息，客户端构造符合要求的 A2A 请求。

3. 企业内部的智能体目录服务

在企业内部，可以构建私有的智能体目录服务来管理企业内部所有 A2A 兼容智能体的 Agent Card。该目录服务定期爬取企业内部各智能体服务的 /.well-known/agent.json 端点，或将智能体注册接口与企业 CI/CD 流程集成，实现智能体上线时自动注册。企业内部开发者可以通过查询该目录服务来发现可供使用的智能体，而无需事先知道每个智能体的具体部署地址。

4. 版本协商与兼容性管理

A2A 协议支持版本协商机制，使客户端智能体能够与服务端智能体协商双方都支持的最高版本协议。Agent Card 中的 version 字段声明该智能体实现的 A2A 协议版本；客户端在发送请求时，在请求头中声明自己支持的协议版本。当协议发生不兼容变更时，版本协商机制使旧版客户端能够与旧版服务端继续通信，同时允许新版客户端充分利用新版协议的功能。这确保了 A2A 生态系统在协议演进过程中的平滑过渡。