如何让多个 Agent“分工、互评、协作”并最终完成复杂任务？

过去一年，Multi-Agent 已经从一个“炫技概念”变成许多 AI 产品的核心能力：

• AutoGPT 用多个 Agent 互相讨论、模拟人类团队
• Devin 里包含 Planner、Coder、Executor 等
• Claude Artifacts 支持协作编辑
• ReAct / Debate / Critic 模式都属于多 Agent 范畴

很多人以为 Multi-Agent = 多开几个模型，但其实远不止如此。

真正的工程级 Multi-Agent，是“一个组织结构系统”：

• 有角色
• 有职责
• 有边界
• 有上下游
• 有监督
• 有沟通协议
• 有失败恢复机制

今天这篇，我会用最实战的方式，告诉你“可落地”的多智能体协作怎么做。

1.为什么需要多智能体？（单 Agent 的天然瓶颈）

单个 Agent 有几个致命缺陷：

① 容易“思维泡沫”

单一模型容易越做越偏，越写越乱，越改越糟。

（特别是长任务、需要长期推理时。）

② 难以兼顾多个能力维度

• Planner 专长拆任务，但不擅长写代码
• Analyzer 专长总结，但无法执行
• Critic 擅长评估，但不擅长创作

让一个模型做全部，必然不稳定。

③ 大任务容易出现执行偏移

写代码、写业务流程、做方案设计时，模型会逐渐偏离目标。

Multi-Agent 的价值：让“能力解耦”，职责分明，系统更稳定。

2.Multi-Agent 的 4 种工程结构

模式 1：双智能体“创作 - 评审”结构（2-Agent Critic）

最简单且最好用：

• 一个产出
• 一个审核
• 最后综合意见执行

Producer → Critic → Producer（修正） → 输出

为什么有效？

• Producer 负责创造
• Critic 负责找问题（模型天生擅长）
• 能在不增加太多成本的情况下显著提高质量

工业界典型用法：

• 文案生成（Critic 检查逻辑、风格、事实）
• 代码生成（Critic 校验 bug 和不一致）
• 文章写作（Critic 评估结构是否清晰）

最常用 Prompt：

Producer Prompt

你负责“创作”，按照要求输出内容。不要自我审查，不要进行多余解释。

Critic Prompt

你负责“评审”，请对输出内容进行：

• 结构问题
• 逻辑问题
• 事实错误
• 风格偏差
• 未满足要求的部分 并给出可执行的修改建议，不要自己改写。

这个结构可以把所有内容质量提升 20%–40%。

模式 2：Planner - Worker（主流企业级）

这种结构是最实战、最落地、也是最值得你打造成“自媒体系列”的。

结构：

Planner（规划） → Worker（执行） → Planner（验收）

职责分离：

• Planner：拆任务、定义步骤、设定成功标准
• Worker：根据步骤逐项执行
• Planner：检查 Worker 的结果是否满足要求

适用任务：

• 写一篇大纲 + 段落的长文
• 做一个自动化脚本
• 生成视频脚本
• 执行包含多个子任务的复杂流程

为什么比 2-Agent 更强？

因为 Planner 能让任务“结构化”，减少 Worker 自己瞎跑。

模式 3：CEO – Manager – Worker（3 层组织）

对于复杂系统（如 Devin、AutoGPT），通常用 3 层：

CEO：确定目标、范围、优先级  
Manager：拆任务、组织步骤、检查进度  
Worker：执行具体子任务

典型场景：

• 构建产品原型
• 写一整套教学文档
• 做大规模数据处理
• 做智能助手（例如个人工作助理）

优势：

• CEO 保持全局正确性
• Manager 确保结构
• Worker 执行效率最高

这其实就是“模拟一个小公司”。

模式 4：多角色协作（Expert Team）

适用于“专业分工”的情况，比如：

分析专家（Analyst）
研究专家（Research）
规划专家（Planner）
执行专家（Executor）
审校专家（Reviewer）
风格优化（Stylist）

然后采用 Round Table（圆桌讨论） 或 Pipeline（流水线） 执行。

适用场景：

• 写书
• 做复杂行业报告
• AI 产品设计
• 商业战略制定
• 生成大型代码项目

这类系统的关键是：每个 expert 的 prompt 需要非常明确否则会互相干扰，导致讨论乱跑。

3. 不同 Agent 如何沟通？

这是 Multi-Agent 的核心。你只需要记住一句话：

沟通必须结构化，而不是自然聊天。

推荐使用 JSON 作为统一协议：

示例：

{
  "role": "planner",
  "task_list": [
    "分析需求",
    "拆解任务",
    "生成步骤",
    "制定成功标准"
  ],
  "notes": "注意避免编造信息"
}

或者：

{
  "critique": [
    "结构逻辑不够清晰",
    "引用部分未提供来源",
    "风格偏离要求"
  ],
  "suggestions": [
    "补充背景信息",
    "重构段落顺序"
  ]
}

结构化沟通的好处：

• 不会把长文本传来传去
• 不会把消息搞混
• 不会因为上下文变化导致模型跑偏

4. 如何让多智能体协作“稳定”而非“乱成一团”？

5个工程级关键点。

① 每个 Agent 必须有明确“边界”

示例边界：

• Planner 不做执行
• Worker 不做规划
• Critic 不自己改写

边界模糊 = 100% 乱。

② 所有 Agent 都要有“目标函数”

让每个 Agent 都知道成功是什么。

例如：

Worker 的成功标准： “输出必须符合 steps 中定义的步骤，不得跳步，也不得额外发挥。”

③ 一个 Agent 不能拥有整个上下文

要让它“只看到自己需要的内容”。

避免：

• 污染上下文
• 反复引用不相关内容
• 逻辑链条混乱

④ 用“有限轮次”机制限制发散

例如：

工作循环最多 3 轮  
如仍未达成，交给 Planner 重写步骤

否则模型会进入无限优化（特别常见）。

⑤ 失败要能“重试”，而不是继续跑偏

必须引入一个错误检查机制：

Worker → 验收失败 → Planner → 重写步骤 → 重新执行

这就是 Devin 的核心稳定机制之一。

5.最终可执行示例

多智能体协作的最小可用结构

Agent 1：Planner

负责拆任务 不执行 不创作

Prompt：

请根据用户目标，拆解成 3–7 个可执行步骤，并给出成功标准。 用 JSON 输出，不要额外解释。

Agent 2：Worker

逐步执行 不做全局规划

Prompt：

根据步骤依次执行任务。 每一步执行后用 JSON 返回结果，不要跳步。

Agent 3：Critic

负责审查 不负责改写

Prompt：

对 Worker 的结果做结构检查。 返回：错误列表 + 修改建议。

6.总结：Multi-Agent 是“组织设计学”，不是炫技

你现在学习到的是：

• 4种主流多智能体架构
• 每种适用场景
• 如何用结构化协议让 Agent 不乱
• 如何设置边界 / 成功标准
• 如何让系统稳定运行
• 如何工程化落地