你让一个 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 角色全景图
![]()
2.2 五种角色的详细设计
| 角色 | 核心职责 | 关键要求 | 不可做的事 |
|---|
| Manager（编排者） | 理解任务→拆分子任务→分配角色→汇总结果→质量把关 | 全局视野、判断力、不亲自执行 | ❌ 不写代码、不搜索文件 |
| Explorer（探索者） | 搜索代码、分析架构、收集信息 | 只读权限、广撒网 | ❌ 不修改文件、不产出方案 |
| Developer（执行者） | 写代码、改配置、实现功能 | 在 worktree 隔离环境中操作 | ❌ 不审查自己的代码 |
| Reviewer（审查者） | 审查代码质量、安全漏洞、规范遵守 | 独立性、批判性思维 | ❌ 不改代码、只提意见 |
| Tester（验证者） | 生成测试、运行回归、检查覆盖率 | 不信任实现代码 | ❌ 不修改被测代码 |
角色的黄金法则：
一个人的代码，另一个人审查，第三个人测试。
执行者 ≠ 审查者 ≠ 验证者
三个角色必须是三个独立的 Agent 实例。
角色的黄金法则： 一个人的代码，另一个人审查，第三个人测试。 执行者 ≠ 审查者 ≠ 验证者 三个角色必须是三个独立的 Agent 实例。
|
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 要解析这段文字才能提取关键信息 → 容易遗漏或误解 结构化输出的优势： Agent A 输出: { "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 通信方式选择决策树
![]()
五、并行处理 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 的职责只有三个： 1. 拆解任务（拆得对不对） 2. 分发和汇总（信息是否完整） 3. 质量把关（最终交付物是否合格） 一旦 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，不要盲目拆分
☐ 避免常见反模式（过度拆分、角色交叉、全串行）
参考文献：
Multi-Agent协同设计
