Multi-Agent系统实战：如何让多个Agent握手协作
前两天折腾 Multi-Agent，三个 Agent 在那里互踢皮球，一个说"让 B 去处理"，另一个说"这不归我管"，场面一度非常尴尬。
说实话，单 Agent 现在已经挺成熟了，但你一旦想处理复杂任务——比如写一份调研报告还要自动配图表、发给团队、还要跟踪反馈——单 Agent 就捉襟见肘了。这时候就得让多个 Agent 分工配合了。
问题是，多 Agent 确实不好搞。搞了两天才跑通一个像样的流程，记录一下核心的坑和方案。
为什么需要多个Agent？
先说清楚一个基础问题：一个 Agent 不行吗？
还真不行。我用一个简单的例子说明：
假设你要开发一个电商 App 的首页。单 Agent 的做法是：让它写代码、设计 UI、写文案、还要测试。结果呢？代码写一半就开始写文案，改 UI 的时候又去翻代码结构。上下文一长，完全跑偏。
但 Multi-Agent 的做法是：
- 产品 Agent：输出需求文档
- 设计 Agent：根据需求生成 UI 设计稿
- 开发 Agent：按设计稿写代码
- 测试 Agent：检查代码质量
每个 Agent 只关注自己的事，上下文可控，效果反而更好。
我试过同一个任务，单 Agent 折腾了 10 轮对话还在自嗨，多 Agent 5 轮就走完了需求→设计→代码的链路。
Multi-Agent 的三种协作模式
玩了一圈下来，实际用得最多的就三种模式。
1. 顺序流水线
最简单的模式。Agent A 做完传给 Agent B，B 做完给 C。
# 伪代码示意result_a=agent_a.run(task)result_b=agent_b.run(result_a)result_c=agent_c.run(result_b)适用场景：处理流程固定的任务，比如"收集→分析→总结"。
踩坑提醒：输出格式一定要定义清楚。我之前让 Agent A 输出 markdown，Agent B 解析 markdown，结果 Agent A 偶尔飘出一个 HTML 表格，Agent B 直接 parse 失败。解决方案是用 JSON schema 约束中间输出。
2. 路由/编排模式
一个"总管" Agent 负责调度，根据任务类型分发给不同的 Worker Agent。
# Orchestrator 判断任务类型orchestrator=Agent("你是任务分配员，判断任务类型并指派给合适的 Worker")iftask_type=="coding":result=coding_agent.run(task)eliftask_type=="writing":result=writing_agent.run(task)这比第一种灵活得多。但我翻车的地方在：Orchestrator 有时候会"自作聪明"，明明该给 coding agent 的任务，它觉得 writing agent 也能干，结果产出不伦不类。
解决方式：给 Orchestrator 一个白名单——每个 Worker Agent 的能力范围写死，超出范围直接报错而不是自己瞎猜。
3. 辩论/讨论模式
多个 Agent 各持观点，互相讨论，最终达成共识。
这种我最喜欢，也最难实现。比如做代码审查：
- Agent A（严格派）：这段代码性能不好，建议重写
- Agent B（务实派）：能跑就行，不要过度优化
- Agent C（架构派）：这个设计不符合 SOLID 原则
三个 Agent 吵架，最后由一个"裁判" Agent 综合意见给出最终建议。
这个模式的坑是——Agent 容易啰嗦，讨论个没完。我设了一个最大轮数（比如 3 轮），超过就强制输出结论。
让Agent互相"听懂"的关键
多 Agent 最容易被忽略的点：通信协议。
这也是我踩的最大的坑。两个 Agent 对话，就像两个人用不同的语言聊天——你说 JSON，TA 说 YAML，谁也看不懂谁。
定义共享 Schema
所有 Agent 之间传输的数据，必须用同一个 Schema。我通常这么搞：
classMessage:sender:str# 哪个 Agent 发的receiver:str# 发给谁（"all" 表示广播）content:dict# 核心内容，JSON 格式metadata:dict# 元数据：时间戳、版本等这个结构看起来简单，但能解决 90% 的通信问题。
上下文过滤
另一个问题是信息过载。Agent A 发给 B 的消息包含大量上下文，Agent B 根本看不完。
我的做法是：每个 Agent 只接收和自己职责相关的信息。比如用户发了 5000 字的背景说明，产品 Agent 关注需求部分，技术 Agent 只看约束条件，其他信息直接过滤掉。
推荐的工具和框架
试了一圈，这三个最值得用：
1. LangGraph（最灵活）
LangChain 出的多 Agent 框架。最大的优势是可以画 DAG（有向无环图），定义 Agent 之间的依赖关系。
# 核心概念：StateGraphgraph=StateGraph(AgentState)graph.add_node("planner",planner_node)graph.add_node("executor",executor_node)graph.add_edge("planner","executor")适合复杂流程控制。学习曲线略陡，但值得。
2. CrewAI（最简单）
如果你不想写太多代码，CrewAI 是最好的选择。用 YAML 配置 Agent 角色和任务就行。
agents:researcher:role:研究员goal:收集相关资料backstory:专业的信息检索者tasks:research_task:agent:researcherdescription:收集最新的行业动态上手最快，但灵活性差一点。复杂场景下容易失控。
3. AutoGen（微软出品，中规中矩）
微软的 Multi-Agent 框架，支持多轮对话。最大的特点是 Agent 之间可以"闲聊式"交流。
比较适合研究场景，生产环境用得不多。
生产级别需要注意的事
做 Demo 很容易，上线就是另一回事了。
超时和重试
Agent 相互等待、死锁、消息丢失——这些都要处理。我一般给每个 Agent 设 30 秒超时，超时了就重试一次，再超时就报错。
状态跟踪
多 Agent 的调用链很长，出了问题很难排查。建议每一步都写日志：
# 最简单的做法：每一步都记录log.append({"step":3,"from":"orchestrator","to":"coding_agent","input":"请输入...","output":"输出...","timestamp":"2025-02-01T10:00:00"})有了日志，出问题至少能知道哪一步挂了。
幂等性
Agent 重试的时候，会不会重复执行同一件事？比如支付 Agent 重试导致重复扣款——这就严重了。每个 Agent 操作要保证幂等性。
写在最后
Multi-Agent 确实是处理复杂任务的好方案，但别为了用而用。如果单 Agent 能搞定，就别折腾多 Agent。
判断标准很简单：任务是否需要多个独立维度来处理？如果是，那 Multi-Agent 就很合适。如果只是一个简单的 RAG 问答，单 Agent 就够了。
下一步我打算试试 AutoGen 的异步模式，看看能不能让 Agent 在后台并行工作。搞定了再来分享。