让 AI Agent 互相协作：A2A CLI 从发现代理到流式任务实战
当 AI Agent 只会调用本地工具时，能力边界通常就是当前进程和当前代码库。真正复杂的工作往往需要把任务交给另一个专长代理：一个负责检索，一个负责分析，一个负责生成报告。问题是，不同 Agent 之间如何发现能力、发送任务，并可靠地获取进度？
A2A CLI 是 A2A（Agent2Agent）项目提供的命令行客户端。它把发现 Agent、发送消息、流式接收事件和任务管理统一成 a2a 命令，也可以作为 Claude Code、Cursor 或 Codex 的外部工具使用。项目采用 Apache-2.0 许可证，源码以 Go 实现，并基于 A2A Protocol v1.0。
先理解：CLI 解决的是连接问题
A2A 是双向协议：一个 Agent 可以作为客户端，把工作交给另一个兼容 A2A 的 Agent。A2A CLI 并不负责训练模型，也不是新的 Agent 框架；它提供的是一个协议原生的客户端入口：
- 通过 Agent Card 了解远端 Agent 的能力和接口信息；
- 用统一命令发送消息，不必为每个服务写一套 HTTP 客户端；
- 以流式事件观察任务进度；
- 用 JSON 输出和可预测的退出码接入脚本、CI 或更高层的 Agent。
这使它适合做“代理的代理”：本地编码 Agent 负责拆解问题，远端专用 Agent 负责执行某一段工作。
安装与第一次连接
macOS 和 Linux 可以通过 Homebrew 安装：
brew tap a2aproject/a2a-cli https://github.com/a2aproject/a2a-cli brew install a2a
Windows 可以使用 WinGet：
winget install a2aproject.a2acli
也可以直接从源码安装。Go 工具默认生成的二进制文件名是 a2a-cli，需要按文档改名为 a2a：
go install github.com/a2aproject/a2a-cli@latest mv "$(command -v a2a-cli)" "$(dirname "$(command -v a2a-cli)")/a2a"
安装完成后，先读取远端 Agent Card：
a2a card get https://agent.example.com
这一步比直接发送提示词更重要。Agent Card 是能力发现入口，可以先确认服务是否支持你需要的任务类型，再决定后续调用方式。对于生产环境，建议把这一步放进健康检查，而不是等到业务请求失败后才发现端点不可用。
发送消息：同步与流式两种模式
最简单的调用是等待任务完成：
a2a send -a https://agent.example.com "Hello, what can you do?"
如果任务可能运行较久，使用 --stream 实时查看事件：
a2a send -a https://agent.example.com --stream "Summarize this document"
同步模式适合一次性命令或脚本中的短任务；流式模式适合代码审查、长文档分析和需要展示进度的交互式工具。不要把“命令已经返回”误认为“远端 Agent 已完成全部工作”：对长任务，应该根据任务生命周期事件决定是否继续轮询、保存结果或执行下一步。
给编码 Agent 加上一条远程协作通道
A2A CLI 的一个实际用法，是让本地编码 Agent 把不擅长的步骤委托出去。例如，本地 Agent 可以负责读取仓库和修改代码，远端 Agent 负责审查依赖升级带来的兼容性风险。由于 CLI 可以被能调用工具的模型或 harness 驱动，集成方式不必绑定某个模型厂商。
项目还提供了配套 Agent Skill。安装 CLI 后，可以把 skill 加到支持 skills 的编码 Agent：
npx skills add https://github.com/a2aproject/a2a-cli --skill a2a-cli
此时，Agent 可以在需要时直接驱动 a2a，而不是把远端服务硬编码成某一个特定工具。实践中建议为远程委托设置三条边界：明确允许访问的端点；把用户数据和凭据放进环境变量；对远端返回的代码或命令保留人工审批，不要因为它来自另一个 Agent 就自动执行。
JSON 输出与自动化设计
A2A CLI 的价值不只是“在终端发一句话”。它强调协议原生 JSON 输出和可预测退出码，因此可以嵌入流水线：
- 先获取 Agent Card，缓存能力描述；
- 根据任务类型选择目标 Agent；
- 用 JSON 记录请求、任务 ID 和最终状态；
- 失败时依据退出码重试、转移到备用 Agent，或让人工接管。
这种设计比解析人类可读的终端文本稳定得多。脚本应保存原始响应，而不是只提取最后一段文本；排查跨 Agent 问题时，任务状态和事件顺序往往比最终答案更有价值。
不只支持一种传输方式
A2A CLI 原生支持 JSON-RPC、REST 和 gRPC。项目还允许通过放在 PATH 中的 a2a-transport- 二进制增加自定义传输，不需要重新编译 CLI：
a2a transport list a2a send --transport slimrpc --endpoint slim://agents.example/agent "hello"
这类插件机制适合内部网络或遗留系统。不过，传输层扩展不应改变上层任务语义：团队仍应统一 Agent Card、错误处理、超时和审计字段，否则“统一 CLI”只会把差异隐藏到更难排查的地方。
适用边界与结论
A2A CLI 最适合三类场景：给编码助手增加远程委托能力；在终端快速验证 A2A Agent；把多个专用 Agent 编排成可观察的流水线。它不是远程执行沙箱，也不替你解决权限、数据脱敏和信任问题。部署前仍需为端点做身份认证、网络隔离和输出审查。
如果你的系统已经有多个 Agent，却仍靠自定义 curl、私有 SDK 或复制粘贴传递任务，A2A CLI 是一个低门槛的统一入口。先从 card get 建立能力发现，再用 send --stream 验证任务生命周期，最后才把调用接入编码 Agent 或 CI，这条路径比一开始就编写复杂编排器更容易控制风险。