在做 Go Agent 框架 Covonaut 的过程中，我实现了 Google 提出的 A2A（Agent-to-Agent）协议。这套协议的作用的让不同框架、不同厂商构建的 Agent 能够互相发现、互相调用，真正实现跨平台的协作。
Covonaut 已经完整支持了 A2A 的双向能力，既能将自身的 Agent 暴露为标准 A2A 服务供他人调用，也能作为客户端去调用其他支持了 A2A 的 Agent。
Agent Card，Agent 的自我介绍一个 Agent 要想被外部调用，首先得让别人知道“我是谁、我能干什么”。A2A 通过 Agent Card 解决了这个问题。每个 A2A Server 都会在 /.well-known/agent.json 路径下暴露一份自描述卡片，包含名称、简介、技能列表、能力声明（如是否支持流式、推送通知）以及认证方式等。
这种设计让发现 Agent 这件事变得标准化，调用方只需拉取这张卡片，就能清晰地了解对方的能力和接入要求，完全无需依赖私有约定。
Task 模型，把交互变成可追踪的状态机A2A 没有采用请求-响应模式，而是将一次交互建模为一个有状态的 Task。一个 Task 拥有完整的生命周期，从 submitted 到 working，最终走向 completed、failed 或 canceled。
特别值得一提的是 input-required 状态，当 Agent 需要补充信息才能继续时，会主动暂停并等待外部输入。这种显式的状态建模，让长程、可恢复的复杂交互变得可控且透明。
不止于调用，取消、回溯与多轮会话Task 只是起点，真正的协作还需要精细的控制力和上下文连续性：
中途取消：任务启动后，调用方可随时发送 tasks/cancel 终止执行，避免无效等待。状态回溯：Task 的完整历史和实时状态均可查询；即使流式连接中断，也能重新订阅并补全缺失的更新。多轮会话：多个 Task 可以关联到同一个 Session 下，共享上下文。这意味着 Agent 间的协作是连续的对话，而非孤立的一问一答。三种传输模式适配不同场景A2A 提供了三种传输方式，背后共用同一套 Task 模型，调用方可按需选择：
同步请求响应：适合秒级返回的短任务。SSE 流式：适合耗时较长的任务，实时推送进度和中间结果。WebSocket 长连接：适合需要持续双向通信的场景，内置心跳保活与鉴权机制。消息原生支持多模态A2A 的消息体由多个 Part 组成，支持文本、文件（Base64 内嵌或 URI 引用）和结构化数据三类，让 Agent 之间不仅能“对话”，还能传递文件、JSON 结果等真实业务载荷，实用性大大增强。
推送通知，告别低效轮询对于耗时任务，调用方无需反复询问“好了没”。A2A 支持配置 Webhook 回调地址（可选 Token 和自定义 Header 鉴权），Task 状态一旦变更，服务端会主动推送更新，大幅降低系统开销。
与本地 Handoff 无缝打通Covonaut 本身具备多 Agent Handoff 能力，将远端 A2A Agent 也接入了这套机制。注册远端 Agent 后，模型可以通过类似 transfer_to_xxx 的工具直接移交任务。对上层而言，调用本地子 Agent 和远端 A2A Agent 的体验完全一致，真正实现了混合编排。
工程兜底，按来源限流对外暴露服务时，安全性是底线。Covonaut 的 A2A Server 内置了基于 IP 的令牌桶限流，防止单个调用方耗尽资源，保障服务稳定性。
一点思考A2A 解决的是 “Agent 之间如何对话” 这一基础设施层的问题。在 Covonaut 中完整落地 A2A 后，一个 Agent 既可以独立运行，也能作为更大协作网络中的一个节点灵活接入。
Covonaut 框架 GitHub 地址：https://github.com/covoyage/covonaut