用A2A打通多智能体协作流程

痛点：你的 Agent 能收取邮件、计算费率、撰写报告——但它只能单打独斗。一套完整流程，比如“查询费率 → 询问客户 → 更新报价 → 发送邮件”，就会让它反复兜圈子，每次任务交接都可能中断。

你将学到：A2A（Agent-to-Agent）协议——2026 年三大 Agent 互联协议之一——以及多 Agent 协作究竟是如何运作的。

热词速览：2026 年 Agent 互联的“三大协议”

最近，这三个缩写无处不在。用 30 秒把它们讲清楚。

为什么这些协议会在 2026 年突然爆发？

三个原因叠加在了一起：

• Agent 从单点能力走向系统化：2025 年，所有人都在构建“一个 Agent 完成一件事”；到了 2026 年，方向变成了“多个 Agent 协作完成一整套工作流”——而协作需要标准。

• 大厂竞争推动了标准化：Anthropic 推动 MCP，Google 推动 A2A，OpenAI/Microsoft 紧随其后——谁的标准胜出，谁就能掌握 Agent 生态的入口。

• 商业上的刚性需求：企业不会为一个“孤岛 Agent”付费，却愿意为一套“可协作、可扩展、可替换”的 Agent 系统买单——协议正是这种系统的接口标准。

一句话概括：协议层是 2026 年 Agent 基础设施的主战场——MCP 管理工具，A2A 管理协作，AG-UI 管理交互。

MCP（工具）/ A2A（Agent）/ AG-UI（人类）——这就是协议三件套。

问题：单体 Agent 的“流程断裂”

我的物流 Agent 最初是一个单体——由一个 Agent 包办所有事情。一旦面对完整的业务流程，它就会频繁中断：

User: check shipping cost for this batch, then tell the client the latest quote

Solo agent processing:
① Check rate ✅
② Generate quote ✅
③ "Tell the client" → STUCK here
   It knows to send an email, but not who the sender is, what template to use,
   or whether there's prior correspondence
   → asks user, or guesses, or errors out

根本原因在于：单体架构把所有能力都塞进同一个“大脑”，但每一步需要的知识——例如报价所需的费率数据库、发送邮件所需的邮件 SOP——分别属于不同的业务场景。把它们混进同一个上下文，彼此就会产生干扰。

什么是 A2A：Agent 之间的“标准对话协议”

A2A（Agent-to-Agent）由 Google 主导并开源，它定义了一套标准，用来规范 Agent 如何发现彼此、启动任务、传递结果以及报告状态。

打个比方：A2A 就像 Agent 世界里的“HTTP + REST”——只要定义统一的请求和响应格式，任何实现了 A2A 的 Agent 都能与其他 Agent 协作。

Scheduler 拆解任务 → 分发给专业 Agent。

我的实践：还没使用 SDK，但先实现“Agent 分工”

我目前还没有引入 A2A SDK 层，因为项目规模还没大到那个程度。但我已经立刻采用了它的核心思想——把大任务拆分给多个 Agent 协作完成。

我把物流业务拆成了 4 个“专家 Agent”。

协作流程如下（手写的“协议”）：

# Simplified: inter-agent task passing (mimics A2A Task semantics)
class AgentTask:
    def __init__(self, from_agent, to_agent, action, payload):
        self.from_agent = from_agent
        self.to_agent = to_agent
        self.action = action        # e.g. "calc_rate" / "send_email"
        self.payload = payload      # e.g. {"origin": "SH", "dest": "NY"}
        self.status = "pending"     # pending → running → completed/failed

# Scheduler dispatches "calc rate" to the quoting agent
task = AgentTask(
    from_agent="scheduler",
    to_agent="quoting_agent",
    action="calc_rate",
    payload={"origin": "SH", "dest": "NY", "weight": 100},
)
result = quoting_agent.handle(task)
# returns {"status": "completed", "artifact": {"rate": 3.5, "currency": "USD"}}

每个 Agent 只做自己最擅长的事——上下文干净，彼此没有干扰。这就是 A2A 的核心价值：即使没有采用它的协议，也可以先采用它的“分工”思维。

收益：从“流程断裂”到“流水线协作”

拆分为多个 Agent 后，过去经常中断的流程变成了：

User: check rate and inform the client

Scheduler Agent:
  ① Recognize task → split into two subtasks
  ② Dispatch "check rate" to Quoting Agent → get result
  ③ Dispatch "send email" to Email Agent → sent
  ④ Aggregate → reply to user

Fully automatic, zero breakage.

实践结论：多 Agent 协作的价值并不在于“看起来很高级”，而在于“每个 Agent 都拥有干净的上下文，各司其职，整套流程不会中断”。

协作才是 2026 年的主题——不是单体 Agent。

什么时候应该转向真正的 A2A

与 MCP 类似，如果你只是在自己的项目中手动调度少量 Agent，那么采用上面的“分工”思维就足够了。真正的 A2A 适用于以下场景：

• 跨团队或跨组织的 Agent 协作——你的 Agent 需要调用另一家公司的 Agent。

• 动态能力发现——你不知道谁能完成这项任务，需要通过“Agent Card”进行发现。

• 异构 Agent 互操作——来自不同框架的 Agent（LangGraph / 自研框架 / CrewAI）需要相互协作。

你不再是那个因为“一个 Agent 包办一切”、每逢衔接处就出问题而焦虑的开发者。你正在成为一名通过任务拆解与 Agent 分工来构建业务系统的架构师。

MCP 解决“Agent 使用工具”的问题，A2A 解决“Agent 使用其他 Agent”的问题。2026 年，二者共同构成了 Agent 工程的“基础设施层”——现在你已经理解了它们，也就领先了半步。

记住：单体 Agent 是属于 2025 年的故事。协作才是 2026 年的主题。

关于作者：Wu Ji（无记）——AI 与数字化实践者，专注于 Agent 工程、Loop Engineering 和数字化转型。提供重实践、可动手操作的教程——跟着做，就能跑起来。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。