Multi-Agent协同设计：如何给AI团队分配合适的角色？

你让一个 Agent 写代码、审查、测试、部署全包了，结果代码质量差、审查走形式、测试覆盖率低——这不是 Agent 能力不行，是角色设计出了问题。就像一个全栈工程师既写前端又写后端还做运维，不是不能干，而是精力分散后每样都干不精。多 Agent 协同的本质不是"多找几个人干活"，而是 通过角色分离，让每个 Agent 只聚焦一件事，再通过结构化的协调机制让它们合力产出高质量结果。

一、为什么要拆分Agent？——单Agent的四个天花板

1.1 单Agent的天然局限

问题一：上下文容量有限

• 单个 Agent 的上下文窗口有上限（200K 甚至 1M tokens）
• 当你让它同时理解需求、搜索代码、写实现、写测试、做审查
• → 上下文被各种信息塞满
• → 模型注意力分散，关键信息被"挤出"
• → 结果是每个环节都做到 60 分，没有一个做到 90 分

问题二：角色冲突

• 写代码的人给自己的代码打分 → 天然倾向高分
• 同一个 Agent 既生成代码又审查代码 → "自我审查"等于没审查
• 研究发现：自我审查发现缺陷的概率比独立审查低 60%+

问题三：缺乏对抗验证

• 单 Agent 的推理路径是线性的
• 没有另一个视角来挑战它的假设
• → 错误假设一直延续到执行结束才暴露
• → 修正成本 = 全部重来

问题四：无法并行

• 搜索代码 + 分析架构 + 研究方案，明明可以并行
• 单 Agent 只能串行执行
• → 用户等待时间 = 所有步骤耗时之和

💡 关键洞察：单 Agent 的瓶颈不是"模型不够聪明"，是认知资源被稀释。就像一个医生同时看内科、外科、儿科——不是医术不行，是注意力分散导致每个科室都达不到专科医生的水平。

1.2 拆分带来的三个质变

质变一：专业深度

• 每个 Agent 的 System Prompt 高度专一
• 写代码的 Agent → Prompt 全是代码规范
• 做审查的 Agent → Prompt 全是检查清单
• 写测试的 Agent → Prompt 全是覆盖率要求
• → 同一个模型，不同的 System Prompt 产生不同的"专业人格"

质变二：独立视角

• 执行者 + 审查者 + 验证者 = 三个独立视角
• 审查者不被执行者的思路"带偏"
• 验证者可以挑战审查者的结论
• → 对抗性验证，而非自我确认

质变三：并行加速

• 三个独立子任务同时启动
• 用户等待时间 = 最慢的那个子任务的时间
• → 墙钟时间从"累加"变成"取最大值"

二、角色设计：最常见的五种Agent角色

2.1 角色全景图

• Manager（编排者）：理解任务 → 拆分子任务 → 分配角色 → 汇总结果 → 质量把关
• Explorer（探索者）：搜索代码、分析架构、收集信息
• Developer（执行者）：写代码、改配置、实现功能
• Reviewer（审查者）：审查代码质量、安全漏洞、规范遵守
• Tester（验证者）：生成测试、运行回归、检查覆盖率

2.2 五种角色的详细设计

角色	核心职责	关键要求	不可做的事
Manager（编排者）	理解任务→拆分子任务→分配角色→汇总结果→质量把关	全局视野、判断力、不亲自执行	不写代码、不搜索文件
Explorer（探索者）	搜索代码、分析架构、收集信息	只读权限、广撒网	不修改文件、不产出方案
Developer（执行者）	写代码、改配置、实现功能	在 worktree 隔离环境中操作	不审查自己的代码
Reviewer（审查者）	审查代码质量、安全漏洞、规范遵守	独立性、批判性思维	不改代码、只提意见
Tester（验证者）	生成测试、运行回归、检查覆盖率	不信任实现代码	不修改被测代码

2.3 角色的System Prompt设计差异

同一个底层模型，不同的 System Prompt 会产生完全不同的"人格"：

Developer 的 System Prompt 要点：
 "你是专业的代码实现者，只负责写代码"
 "遵循项目的编码规范和设计模式"
 "不要审查自己的代码——那是 Reviewer 的工作"
 "不要在写代码的同时做安全性检查——专注实现"

Reviewer 的 System Prompt 要点：
 "你是严格的代码审查者，默认态度是'不信任'"
 "逐条检查：正确性、安全性、性能、可维护性"
 "你只提修改意见，不要动手改代码"
 "不要因为代码'看起来不错'就放松标准"

Tester 的 System Prompt 要点：
 "你是测试工程师，目标是找出代码的缺陷"
 "对边界条件、异常路径、并发场景做重点测试"
 "假设代码有 Bug，你的任务是证明它"
 "不要因为 Developer 写的代码而降低测试强度"

💡 关键洞察：角色的差异不是靠"这个 Agent 更聪明"来实现的，而是靠不同的 System Prompt 约束出不同的行为模式。就像同一个演员演不同角色靠的是剧本——Agent 的"剧本"就是它的 System Prompt。

三、协作模式：三种经典的分工结构

3.1 模式一：Manager-Worker（中心化调度）

最适合复杂任务的一次性交付。Manager 负责拆解和汇总，Worker 负责执行。

结构：
 Manager
 / | \
 Worker Worker Worker

适用场景：
 - 软件功能开发："帮我实现用户登录功能"
 - Bug 修复："排查并修复这个内存泄漏"
 - 项目重构："把这个模块从 JS 迁移到 TS"

优点：
 责任清晰：Manager 对最终结果负责
 质量可控：Manager 做最终把关
 容易理解：像传统的团队管理结构

缺点：
 Manager 成为瓶颈：所有信息必经 Manager
 Manager 的能力决定整体上限
 Worker 之间无法直接协作

3.2 模式二：Pipeline（流水线接力）

最适合流程固定、环节明确的任务。每个 Agent 完成一个环节，传递给下一个。

结构：
 Agent A → Agent B → Agent C → Agent D

适用场景：
 - 数据处理流水线：采集→清洗→分析→可视化
 - CI/CD 检查链：编译→单元测试→集成测试→部署检查
 - 内容生产流水线：选题→撰写→编辑→发布

优点：
 每个环节高度专注
 上一步的输出是下一步的输入，数据流清晰
 容易监控：卡在哪个环节一目了然

缺点：
 串行等待：总时间 = 所有环节求和
 下游必须等上游完成
 一个环节失败，后续全部重来
 上游的错误会被下游放大

Pipeline 模式实战——AI 日报生成：

Agent A（数据采集）: 从飞书、Linear、GitHub 拉取原始数据
 → 输出: 结构化 JSON [{来源, 内容, 时间}, ...]

Agent B（信息筛选）: 过滤噪音，提取高价值信息
 → 输出: 精简后的关键事件列表

Agent C（日报撰写）: 按模板生成自然语言日报
 → 输出: Markdown 日报初稿

Agent D（质量检查）: 检查格式、数据准确性、语言流畅度
 → 输出: 最终可发布的日报

3.3 模式三：Peer-to-Peer（对等协商）

最适合需要多视角碰撞的任务。Agent 之间平等协商，各自提出方案，互相挑战。

结构：
 Agent A ⇄ Agent B ⇄ Agent C
 每个 Agent 独立形成判断，然后对比、辩论、达成共识

适用场景：
 - 架构设计评审："这个微服务拆分方案有什么问题？"
 - 技术选型讨论："React vs Vue，哪个更适合这个项目？"
 - 风险评估："这个数据库迁移方案的潜在风险有哪些？"

优点：
 多视角覆盖盲区
 对抗性验证：好的方案经得起挑战
 不容易被单一 Agent 的偏见带偏

缺点：
 协调成本高：需要多轮交互
 可能陷入"辩论死锁"——谁也说服不了谁
 没有明确的最终决策者

Peer-to-Peer 实战——架构方案评审：

Round 1: 独立提案
 Agent A（激进派）: "用微服务架构，15 个服务，全异步通信"
 Agent B（保守派）: "用模块化单体，3 个模块，同步调用"
 Agent C（务实派）: "混合方案：核心单体 + 高频场景独立服务"

Round 2: 互相评审
 Agent A → 评审 B 的方案: "单体在流量高峰会崩，拆分是必要的"
 Agent B → 评审 A 的方案: "15 个服务运维成本太高，小团队扛不住"
 Agent C → 评审 A+B: "A 过度设计，B 扩展性不足"

Round 3: 收敛决策
 Manager 读三个方案 + 互评意见 → 选择 C 的混合方案
 或者让三个 Agent 投票，多数方案胜出

3.4 三种模式对比

维度	Manager-Worker	Pipeline	Peer-to-Peer
控制结构	中心化	链式	去中心化
决策者	Manager 独断	无（按流程走）	协商/投票
并行能力	Worker 之间可并行	不可并行	Agent 之间可并行
容错性	Manager 重试 Worker	上游失败，下游阻塞	冗余设计自然容错
适合任务	复杂但目标明确	流程固定步骤清晰	方案未定需要碰撞
协调成本	中（Manager 调度）	低（按序传递）	高（需要多轮交互）

四、Agent之间如何通信？——上下文传递的四种方式

多 Agent 协同最容易被忽视的问题：Agent 之间不会自动"知道"彼此在做什么。你需要显式设计通信机制。

4.1 方式一：Structured Output（结构化输出传递）

Agent 之间通过结构化数据（JSON Schema）传递信息，而非自由文本。

为什么需要结构化输出？

自由文本的问题：Agent A 输出 "我在 src/auth/login.ts 里找到了登录逻辑，用了 JWT，token 存在 localStorage..."，Agent B 要解析这段文字才能提取关键信息 → 容易遗漏或误解。

结构化输出的优势：

{
 "files_found": ["src/auth/login.ts", "src/auth/token.ts"],
 "auth_method": "JWT",
 "token_storage": "localStorage",
 "concerns": ["token 未加密存储", "缺少 refresh 机制"]
}

Agent B 直接读取字段 → 零歧义。

实现方式	适用场景	优点	缺点
JSON Schema 强制约束	Worker → Manager 汇报	零歧义，可验证	需要预先定义 Schema
Markdown 表格	对比分析结果	人类可读	不够机器友好
YAML 结构化	配置和中间产物	可读性好 + 结构清晰	嵌套层级多时解析复杂
自由文本 + 摘要	探索性结果	灵活度高	下游 Agent 可能误解

4.2 方式二：Manager 中转

在 Manager-Worker 模式中，Worker 之间不直接通信——所有信息由 Manager 汇总后再分发。

信息流：
 Explorer ──→ Manager ──→ Developer
 Developer ──→ Manager ──→ Reviewer
 Reviewer ──→ Manager ──→ Developer

Manager 的职责不仅是"传递"，更是"翻译和精简"：
 Explorer 返回 5000 tokens 的详细分析
 Manager 提取 500 tokens 的关键上下文
 只把这 500 tokens 传给 Developer
 → 减少下游 Agent 的上下文噪音
 → 同时也减少 Token 成本

4.3 方式三：Shared Context File（共享上下文文件）

Agent 之间通过读写中间文件来传递信息，类似微服务中的消息队列。

实现方式：
 1. Manager 创建一个任务文件 task.md，包含：
 - 任务描述
 - 子任务分配
 - 当前状态
 2. Worker Agent A 完成任务后，写入自己的输出文件：
 result_a.json → 包含结构化结果
 3. Worker Agent B 启动时，读取 result_a.json 和 task.md
 → 了解上下文后开始自己的任务
 4. 所有 Worker 完成后，Manager 读取所有 result_*.json
 → 汇总生成最终交付物

优点：
 解耦：Agent 之间不依赖同时在线
 可追溯：中间产物保留，方便排查
 可恢复：任务中断后可以从中间文件继续

缺点：
 文件管理复杂度随 Agent 数量增长
 并发写入可能冲突（需要文件锁或命名约定）

4.4 方式四：环境变量 / Metadata 注入

轻量级的上下文传递，适合小而固定的配置信息。

适用场景：
 - 项目根目录路径
 - 当前分支名称
 - 目标部署环境（staging / production）
 - 关键约束条件（"不要修改 src/legacy/ 下的代码"）

实现：
 Manager 在创建 SubAgent 时，将这些信息写入 Agent 的 prompt 或 metadata
 每个 SubAgent 一启动就知道这些"全局变量"
 不需要在每次通信中重复传递

4.5 通信方式选择决策树

1. 信息需要精确传递且格式固定？→ Structured Output
2. Worker 之间需要间接通信？→ Manager 中转
3. 需要持久化中间产物、支持断点续做？→ Shared Context File
4. 只传递小而固定的全局配置？→ 环境变量注入

五、并行处理 vs 专业分工：不是二选一，而是怎么搭

5.1 两种策略的本质差异

这是多 Agent 设计中最容易混淆的概念：

并行处理（Horizontal Split）：

• 定义：同一个任务，拆成 N 份，N 个 Agent 同时做
• 核心问题："怎么把一个大事切成多块一起跑？"
• 示例：
• 扫描 100 个文件的安全漏洞
• → Agent 1 负责文件 1-25
• → Agent 2 负责文件 26-50
• → Agent 3 负责文件 51-75
• → Agent 4 负责文件 76-100
• → 4 个 Agent 并行，时间缩短到 1/4

专业分工（Vertical Split）：

• 定义：不同性质的任务，由不同专业角色的 Agent 分别完成
• 核心问题："怎么让每个环节由最擅长的人做？"
• 示例：
• 实现一个新功能
• → Explorer Agent：分析现有代码
• → Developer Agent：写实现代码
• → Reviewer Agent：代码审查
• → Tester Agent：测试验证
• → 每个环节串行，但每个环节由专业 Agent 负责

5.2 真实场景：两者叠加

真实的多 Agent 系统几乎都是两层叠加：

第一层：专业分工（确定"谁做什么类型的活"）
 Manager → 拆解出不同类型的子任务
 - 搜索类任务 → 给 Explorer
 - 编码类任务 → 给 Developer
 - 审查类任务 → 给 Reviewer
 - 测试类任务 → 给 Tester

第二层：并行处理（对同类任务做水平拆分）
 当某个类型的工作量太大时，再做并行拆分

 示例：
 Developer 发现需要改 3 个独立的文件
 → 创建 3 个 Developer SubAgent，每个负责一个文件
 → 3 个并行执行，完成后 Manager 汇总

 Reviewer 需要审查 500 行代码变更
 → 创建 2 个 Reviewer SubAgent，各审 250 行
 → 2 个并行审查，发现不同类型的问题

实战案例：重构一个微服务

第一层（专业分工）：
 Manager → 分析重构范围
 Explorer → 扫描所有受影响文件，输出清单
 （Explorer 返回：32 个文件需要修改）

第二层（并行处理）：
 32 个文件按模块拆成 4 组
 → Developer A：用户模块（8 个文件）
 → Developer B：订单模块（8 个文件）
 → Developer C：支付模块（8 个文件）
 → Developer D：通知模块（8 个文件）
 4 个 Developer 并行修改

第三层（专业分工）：
 4 个 Developer 完成后
 → Reviewer：审查所有变更
 → Tester：运行全量测试

总时间 = Explorer(1x) + Developer(1x，并行) + Reviewer(1x) + Tester(1x)
 ≈ 4 个阶段，而非 32 个文件逐个串行

5.3 并行 vs 分工的选择判断

判断维度	适合并行处理	适合专业分工
任务性质	同质化（都是同一类操作）	异质化（需要不同能力）
耦合度	低耦合（任务之间独立）	有依赖（B 需要 A 的输出）
专业要求	通用技能即可	需要不同领域的专业知识
质量风险	统一标准，容易检查	每个环节不同标准，需要多层把关
典型场景	批量文件处理、大规模搜索	软件开发全流程、内容生产

💡 关键洞察：并行处理解决的是速度问题，专业分工解决的是质量问题。真正高效的多 Agent 系统，是先用专业分工保证每个环节的质量下限，再用并行处理在这些环节中加速。质量优先，速度次之——因为并行出错的修复成本远高于串行精做。

六、实战设计：一个完整的多Agent协作方案

6.1 场景：用户要求"分析项目代码质量并生成改进报告"

任务拆解分析：这个任务天然包含三类不同性质的子任务：

• a) 搜索型任务：扫描项目、收集代码指标
• b) 分析型任务：基于数据做判断、找问题
• c) 生成型任务：写报告、提建议

如果让一个 Agent 全包：上下文塞满扫描结果 → 分析不深入；分析和写作混在一起 → 逻辑不清晰；自己扫描、自己分析、自己打分 → 缺乏客观性。

6.2 多Agent方案设计

角色分配（专业分工层）：

Manager（1 个）:
 职责：接收任务 → 拆解 → 分配 → 汇总报告
 工具：Agent 创建、文件读写
 不亲自扫描、不亲自分析、不亲自写报告

Scanner（3 个，并行处理层）:
 职责：扫描代码，收集量化指标
 分工：
 Scanner A：扫描 src/ 下的代码指标（行数、圈复杂度、嵌套深度）
 Scanner B：扫描依赖和配置（package.json、tsconfig、eslint）
 Scanner C：扫描测试覆盖率和文档完整性
 工具：只读——search_file、read_file、grep
 输出：结构化 JSON

Analyzer（2 个，Peer-to-Peer）:
 职责：基于 Scanner 的数据，独立分析，然后交叉验证
 Analyzer A：从"安全性 + 性能"角度分析问题
 Analyzer B：从"可维护性 + 规范性"角度分析问题
 两者独立分析 → 交换结果 → 找出共识和分歧
 工具：只看数据，不访问代码
 输出：问题清单 + 严重程度 + 改进建议

Writer（1 个）:
 职责：将 Analyzer 的结论组织成可读的报告
 工具：文件写入
 输出：Markdown 格式的代码质量报告

6.3 这个设计为什么好？

① 为什么 Scanner 要 3 个而不是 1 个？

• 三个扫描维度互不依赖（并行处理加速）
• 如果只用 1 个 Scanner，扫描时间 = 三个维度之和
• 拆成 3 个，用户等待时间 = 最慢的那个

② 为什么 Analyzer 要 2 个而不是 1 个？

• 避免单一视角的盲区（专业分工 + Peer-to-Peer）
• 安全专家和可维护性专家看同一段代码，关注点不同
• 交叉验证：两个人独立得出相同结论 → 高置信度
• 两人结论冲突 → Manager 裁决，或标注为"需要人工判断"

③ 为什么 Writer 只有 1 个？

• 报告写作需要"一致的逻辑和文风"
• 多人分写再拼接 → 风格割裂，逻辑断层
• 写作不是瓶颈（前面步骤已经决定了报告质量）
• 如果报告特别长（50 页+），可以考虑按章节并行写 + 1 个统稿

④ 为什么 Scanner 不能兼任 Analyzer？

• Scanner 看的是"数据"，Analyzer 做的是"判断"
• 扫描者看到 1000 行代码，"哦，圈复杂度 15"
• 分析者看到 1000 行代码，"这个函数的 if-else 可以提取策略模式"
• 两个角色的思维模式完全不同，混在一起会降低深度

七、协作效率的五个关键实践

7.1 实践清单

实践一：先 Scout 再 Split

• 不要上来就创建一堆 Agent
• 看到任务就拆 → 拆错了 → 大量上下文浪费
• 先用一个 Agent 快速 scout（只读 + 低成本）
• → 搞清楚任务的实际规模和结构
• → 再决定拆多少个 Agent、用什么模式

实践二：设定 Agent 的数量上限

• 不是 Agent 越多越好
• 10 个 Agent 扫描 10 个文件 → 协调成本 > 并行收益
• 经验值：
• 轻量任务：1-3 个 Agent
• 中量任务：3-5 个 Agent
• 重量任务：5-8 个 Agent
• 超过 8 个 → 考虑是否应该拆成多个独立任务

实践三：为每个 Agent 设定"Stop 条件"

• 不是"做完再停"，而是"满足条件就停"
• Scanner：搜索覆盖面达到 90% 以上 → 停止搜索
• Analyzer：发现 Top 10 问题 + 交叉验证通过 → 停止分析
• 设定步数上限 → Agent 无法推进时降级

实践四：Manager 不做具体工作

• 这是效率最高的设计原则
• Manager 的职责只有三个：
• 拆解任务（拆得对不对）
• 分发和汇总（信息是否完整）
• 质量把关（最终交付物是否合格）
• 一旦 Manager 开始亲自写代码、搜文件 → 它就不是 Manager 了
• → 角色混淆 → 整体效率下降

实践五：Parallel + Pipeline 混搭

• 不是所有环节都适合同一种模式
• 独立子任务 → parallel（扫描、搜索）
• 有依赖的子任务 → pipeline（审查 → 修改 → 再审查）
• 需要多视角碰撞 → peer-to-peer（分析、评审）
• 一个复杂任务里，三种模式通常同时存在

7.2 常见反模式

反模式	表现	后果	修正
过度拆分	5 个文件的改动用了 5 个 Developer	协调成本吃掉并行收益	合并：同类任务少于 3 个不打散
角色交叉	Developer 同时充当 Reviewer	自我审查 = 没审查	强制分离：不同的 Agent 实例
全串行	Pipeline 用了 6 步，实际有 3 步可以并行	用户等太久	识别独立子任务，改 serial 为 parallel
无结构输出	Agent 之间传自由文本	下游可能误解上游结果	关键节点用 JSON Schema 约束输出格式
Manager 亲自动手	Manager 看到 Developer 写得不好就自己改	职责混乱，Worker 闲置	Manager 应该让 Developer 重做，而非代替

八、总结：多Agent协同设计检查清单

设计多 Agent 系统时，逐项确认：

第一步：任务分析

• 这个任务有哪些不同性质的子任务？（搜索？实现？审查？测试？）
• 哪些子任务可以并行？哪些有依赖必须串行？
• 有没有需要"第二视角"来对抗验证的环节？

第二步：角色设计

• 每个 Agent 有且只有一个明确的职责
• 执行者 ≠ 审查者 ≠ 验证者（三个不同 Agent 实例）
• 每个角色的 System Prompt 有明确的"该做什么"和"不能做什么"
• Manager 不亲自执行具体工作

第三步：协作模式选择

• 目标明确有依赖 → Manager-Worker
• 流程固定步骤清晰 → Pipeline
• 方案未定需要碰撞 → Peer-to-Peer
• 复杂任务通常是三种模式的混合

第四步：通信设计

• 关键节点输出用结构化格式（JSON Schema）
• 中间产物需要持久化 → 共享上下文文件
• 全局常量环境变量 → prompt 注入
• Manager 做信息中转和精简，而非全量转发

第五步：效率与边界

• Agent 数量是否在合理范围内（3-8 个）
• 每个 Agent 有明确的 Stop 条件
• 先 Scout 再 Split，不要盲目拆分
• 避免常见反模式（过度拆分、角色交叉、全串行）

💡 核心理念总结：多 Agent 协同不是"人多力量大"，而是角色清晰 × 信息通畅 × 边界明确。三个要素缺一不可。角色不清晰 → Agent 不知道该做什么；信息不通畅 → Agent 做重复劳动或漏掉关键上下文；边界不明确 → Agent 可能越界操作或陷入死循环。好的多 Agent 设计，每个 Agent 都像一颗棋子——单看很简单，组合起来能解决复杂问题。