8.0
热点
AI SCORE
编程提效2026-08-06 09:37
用A2A打通多智能体协作流程
dev.to · AI#A2A#Agent#MCP
Editor brief · 编辑速览
文章解释A2A协议如何解决智能体之间的发现、通信与任务交接，并区分MCP、A2A和AG-UI各自连接的对象。重点讨论从单智能体工具调用转向可替换、多智能体工作流所需的协议基础。
痛点：你的 Agent 能收取邮件、计算费率、撰写报告——但它只能单打独斗。一套完整流程，比如“查询费率 → 询问客户 → 更新报价 → 发送邮件”，就会让它反复兜圈子，每次任务交接都可能中断。
你将学到：A2A（Agent-to-Agent）协议——2026 年三大 Agent 互联协议之一——以及多 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 包办所有事情。一旦面对完整的业务流程，它就会频繁中断：
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-to-Agent）由 Google 主导并开源，它定义了一套标准，用来规范 Agent 如何发现彼此、启动任务、传递结果以及报告状态。
打个比方：A2A 就像 Agent 世界里的“HTTP + REST”——只要定义统一的请求和响应格式，任何实现了 A2A 的 Agent 都能与其他 Agent 协作。
Scheduler 拆解任务 → 分发给专业 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。
与 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 和数字化转型。提供重实践、可动手操作的教程——跟着做，就能跑起来。
如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。