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 → 评审 AB: A 过度设计B 扩展性不足 Round 3: 收敛决策 Manager 读三个方案 互评意见 → 选择 C 的混合方案 或者让三个 Agent 投票多数方案胜出3.4 三种模式对比维度Manager-WorkerPipelinePeer-to-Peer控制结构中心化链式去中心化决策者Manager 独断无按流程走协商/投票并行能力Worker 之间可并行不可并行Agent 之间可并行容错性Manager 重试 Worker上游失败下游阻塞冗余设计自然容错适合任务复杂但目标明确流程固定步骤清晰方案未定需要碰撞协调成本中Manager 调度低按序传递高需要多轮交互四、Agent之间如何通信——上下文传递的四种方式多 Agent 协同最容易被忽视的问题Agent 之间不会自动知道彼此在做什么。你需要显式设计通信机制。4.1 方式一Structured Output结构化输出传递Agent 之间通过结构化数据JSON Schema传递信息而非自由文本。为什么需要结构化输出自由文本的问题Agent A 输出 我在 src/auth/login.ts 里找到了登录逻辑用了 JWTtoken 存在 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 汇报零歧义可验证需要预先定义 SchemaMarkdown 表格对比分析结果人类可读不够机器友好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 通信方式选择决策树信息需要精确传递且格式固定→Structured OutputWorker 之间需要间接通信→Manager 中转需要持久化中间产物、支持断点续做→Shared Context File只传递小而固定的全局配置→环境变量注入五、并行处理 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方案设计角色分配专业分工层 Manager1 个: 职责接收任务 → 拆解 → 分配 → 汇总报告 工具Agent 创建、文件读写 不亲自扫描、不亲自分析、不亲自写报告 Scanner3 个并行处理层: 职责扫描代码收集量化指标 分工 Scanner A扫描 src/ 下的代码指标行数、圈复杂度、嵌套深度 Scanner B扫描依赖和配置package.json、tsconfig、eslint Scanner C扫描测试覆盖率和文档完整性 工具只读——search_file、read_file、grep 输出结构化 JSON Analyzer2 个Peer-to-Peer: 职责基于 Scanner 的数据独立分析然后交叉验证 Analyzer A从安全性 性能角度分析问题 Analyzer B从可维护性 规范性角度分析问题 两者独立分析 → 交换结果 → 找出共识和分歧 工具只看数据不访问代码 输出问题清单 严重程度 改进建议 Writer1 个: 职责将 Analyzer 的结论组织成可读的报告 工具文件写入 输出Markdown 格式的代码质量报告6.3 这个设计为什么好① 为什么 Scanner 要 3 个而不是 1 个三个扫描维度互不依赖并行处理加速如果只用 1 个 Scanner扫描时间 三个维度之和拆成 3 个用户等待时间 最慢的那个② 为什么 Analyzer 要 2 个而不是 1 个避免单一视角的盲区专业分工 Peer-to-Peer安全专家和可维护性专家看同一段代码关注点不同交叉验证两个人独立得出相同结论 → 高置信度两人结论冲突 → Manager 裁决或标注为需要人工判断③ 为什么 Writer 只有 1 个报告写作需要一致的逻辑和文风多人分写再拼接 → 风格割裂逻辑断层写作不是瓶颈前面步骤已经决定了报告质量如果报告特别长50 页可以考虑按章节并行写 1 个统稿④ 为什么 Scanner 不能兼任 AnalyzerScanner 看的是数据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 都像一颗棋子——单看很简单组合起来能解决复杂问题。