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")
if task_type == "coding":
    result = coding_agent.run(task)
elif task_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。我通常这么搞：

class Message:
    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 之间的依赖关系。

# 核心概念：StateGraph
graph = 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: researcher
    description: 收集最新的行业动态

上手最快，但灵活性差一点。复杂场景下容易失控。

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 在后台并行工作。搞定了再来分享。