A2A 代理间互操作工作流

当智能体需要跨团队协作时

实际系统里，智能体很少活在单个进程里。订单智能体在 Java 服务里，数据分析智能体跑在 Python notebook 中，客服智能体则托管在另一家厂商的平台上。它们各自能完成任务，但一旦需要协作——比如工单需要先查订单、再做分析、最后交给人工——开发者就要手写一堆胶水代码：统一消息格式、处理鉴权差异、追踪跨系统的任务状态。每个对接都是一次性的，换一拨智能体就得重写一遍。

这个技能基于 Agent2Agent（A2A）协议解决的就是这类问题：让相互独立的智能体运行时能够互相发现能力、交接任务，而不必共享代码库或运行环境。

核心思路与关键步骤

A2A 协议把「一个智能体调用另一个智能体」标准化为三件事：

• 能力暴露：每个智能体通过协议描述自己能处理什么任务、需要什么输入、返回什么产物，其他智能体据此做路由决策。
• 任务路由：发起方把任务发给 A2A 服务器，由它转交给目标智能体的运行时，中间无需双方认识彼此的内部结构。
• 状态与产物回传：任务的进度、中间产物和最终结果沿原路返回，发起方可以轮询或接收推送。

配套的 Python SDK（a2a-sdk）和官方文档提供了协议规范、教程和参考实现。典型接入路径是：先阅读协议规范与文档站点，理解消息与任务模型；再用 SDK 在自己的运行时上暴露能力，或作为客户端调用其他智能体；最后把任务路由逻辑嵌进现有工作流。

适用边界

• 协议解决的是「互操作」层，不替代智能体内部的规划与工具调用逻辑；单个智能体本身的智能水平仍取决于各自的实现。
• 需要至少一个 A2A SDK 和可暴露或可连接的运行时，纯黑盒 API 无法直接接入。
• 鉴权、网络策略与任务超时等运维细节仍需各团队自行处理，协议只规定了通信语义。
• 适合少量跨系统的关键协作链路，不建议一开始就把所有智能体全部网状互联。