多 Agent 系统的设计哲学：不是群聊，而是一套协作操作系统

📝

万字拆解多 Agent 系统设计：六层架构、四个拆分天花板、五种角色、三种协作模式、四种通信机制、七个工程落地难点、五个实践与五个反模式。核心：角色清晰 × 信息通畅 × 边界明确。

原文链接：https://mp.weixin.qq.com/s/FNkwMRHKxKEpIUyUEPrsPw（架构精进之路）

当多个 AI 智能体协同工作时，1+1 远大于 2。但真正决定一个多 Agent 系统好不好用的，从来不是 Agent 的数量，而是任务怎么拆、角色怎么分、信息怎么传、边界怎么控。

01 先纠偏：Multi-Agent 不是”群聊”，而是”协作操作系统”

很多人的体验：你说一句，AI 写一段；再提要求，它改一下；来回十几轮，不如自己写得快。于是有人说”AI 单打独斗还行，干不了复杂活”。

但问题真出在 AI 不够聪明吗？不一定——更可能的原因是你让一个人干了一支团队的活。

主流 Multi-Agent 框架（LangGraph、AutoGen、CrewAI）的核心设计目标从来不是”聊天”，而是围绕复杂任务建立一套可控的协作系统。单 Agent 像自由职业者，灵活但上限低；多 Agent 系统像一家公司，有分工、有流程、有审批，能搞定个人搞不定的事。

一个成熟的多 Agent 框架，通常包含六层架构：

分层	主要职责	关键设计问题
任务层	接收用户目标，形成可执行任务	任务能不能拆？验收标准清不清楚？
编排层	决定谁做什么、何时做、如何合并	串行、并行、图编排还是动态调度？
Agent 层	执行具体推理、工具调用和局部决策	角色边界在哪？上下文多大？用什么模型？
工具层	连接代码、搜索、数据库、API 等	权限怎么控？失败了怎么重试？
记忆层	保存任务状态、历史事实、长期偏好	记什么？什么时候召回？怎么过期？
评估层	检查结果质量、事实一致性	怎么自动验证？什么时候需要人介入？

Agent 只是系统中的一个节点。 真正决定系统稳定性的，是编排、状态和边界控制——就像一支军队的战斗力，从来不取决于单个士兵有多能打，而取决于指挥体系有多清晰。

02 为什么要拆分 Agent？

模型越来越强（GPT-5、Claude 4），一个强大的模型自己干不行吗？答案是：单 Agent 存在四个天然的天花板，模型再强也绕不过去。

天花板一：上下文容量有限——几十万 token 窗口”装得下”不等于”用得好”。让一个 Agent 同时理解需求、搜索代码、写实现、写测试、做审查，注意力被稀释，每个环节都做到 60 分，没有一个能做到 90 分。

天花板二：角色冲突——写代码的人给自己的代码打分，天然倾向打高分。同一个 Agent 既生成代码又审查代码，”自我审查”基本等于没审查。有研究对比：自我审查发现缺陷的概率，比独立审查低 60% 以上。写代码时你在”建”，审查时你应该在”拆”，同一个大脑切换不过来。

天花板三：缺乏对抗验证——单 Agent 推理路径是线性的，从 A 推到 B 再推到 C。如果 A 这个假设本身就错了，错误会一直延续到执行结束才暴露，修正成本等于全部重来。另一个 Agent 从不同角度挑战假设，很多问题在早期就能被揪出来。

天花板四：无法并行——搜索代码库、分析架构、研究技术方案明明可以同时进行，单 Agent 只能一件一件来，用户等待时间等于所有步骤耗时之和。

一个人干五个人的活 ≠ 五个人分工协作。决策、执行、评判分离，才能形成真正的质量闭环。

03 角色设计：给 AI 团队分配”专业岗位”

多建几个 Agent 就行？还真不行。稳定的多 Agent 系统，每个 Agent 必须有明确的角色和边界——就像足球队，你不能让十一个人都当前锋。

最常见的五种角色：

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

黄金法则：一个人的代码，另一个人审查，第三个人测试。 执行者 ≠ 审查者 ≠ 验证者——三个角色必须是三个独立的 Agent 实例，不能是同一个 Agent 换个 Prompt 就上场。因为”自己查自己的 bug”这件事，不管是人还是 AI，都不靠谱。

同一个模型，不同的”人格”：角色的差异不是靠”这个 Agent 更聪明”，而是靠不同的 System Prompt 约束出不同的行为模式：

• Developer 的 Prompt：”你是专业的代码实现者，只负责写代码。不要审查自己的代码——那是 Reviewer 的工作。”
• Reviewer 的 Prompt：”你是严格的代码审查者，默认态度是不信任。逐条检查正确性、安全性、性能、可维护性。只提修改意见，不要动手改代码。”
• Tester 的 Prompt：”你是测试工程师，目标是找出代码的缺陷。假设代码里一定有 Bug，你的任务就是证明它。”

同一个演员演不同角色靠的是剧本，Agent 的”剧本”就是它的 System Prompt。Prompt 写得越精准，角色边界越清晰，协作效率越高。

04 三种经典协作模式

模式一：Manager-Worker（中心化调度）——一个 Manager 在上面，下面管着好几个 Worker。Manager 拆任务、分配、汇总、把关，Worker 具体执行。

• 适合：软件功能开发、Bug 修复、项目重构等复杂任务的一次性交付
• 优点：责任清晰，Manager 对最终结果负责；质量可控
• 缺点：Manager 容易成为信息瓶颈；Manager 的能力决定了整个系统的上限（老板强则团队强）

模式二：Pipeline（流水线接力）——每个 Agent 负责一个环节，做完传给下一个，像工厂流水线。

• 适合：数据处理流水线、CI/CD 检查链、内容生产流水线
• 优点：环节高度专注，数据流清晰；问题容易定位，卡在哪个环节一目了然
• 缺点：串行等待，总时间等于所有环节之和；上游错误被下游放大（第一道工序出错，后面全白干）

模式三：Peer-to-Peer（对等协商）——每个 Agent 地位平等，各自独立形成判断，然后对比、辩论、达成共识。

• 适合：架构设计评审、技术选型讨论、风险评估
• 优点：多视角覆盖盲区；对抗性验证
• 缺点：协调成本高，可能陷入”辩论死锁”；没有明确最终决策者，容易议而不决

真实系统：三种模式混搭。一个代码重构任务可能这样运转：第一层专业分工（Manager 拆解：搜索交给 Explorer、编码交给 Developer、审查交给 Reviewer）；第二层并行处理（32 个文件按模块拆成 4 组，4 个 Developer 并行干活）；第三层流水线接力（Developer 写完 → Reviewer 审查 → 通过后 Tester 测试）。最终总时间约是 4 个阶段的耗时，而不是 32 个文件逐个串行的耗时。

05 Agent 之间如何通信？

Agent 之间不会自动”知道”彼此在做什么，需要显式设计通信机制。

方式一：结构化输出传递——通过结构化数据（JSON Schema）传递信息，而不是自由文本。自由文本（”我在 src/auth/login.ts 里找到了登录逻辑，用了 JWT，token 存在 localStorage，好像还有个 refresh token 的机制但不太确定……”）下游解析易遗漏误解；结构化输出（{"files_found": [...], "auth_method": "JWT", "token_storage": "localStorage", "concerns": [...]}）下游直接读字段，零歧义。就像公司里的”表单”和”聊天记录”的区别。

方式二：Manager 中转——Worker 之间通常不直接通信，所有信息由 Manager 汇总后再分发。Manager 的职责不只是”传话筒”，更重要的是”翻译和精简”：Explorer 返回 5000 tokens 的分析报告，Manager 提取出 500 tokens 的关键上下文传给 Developer。减少下游上下文噪音 + 节省 Token 成本。

方式三：共享上下文文件——Agent 之间通过读写中间文件传递信息，类似微服务架构中的消息队列。Manager 创建 task.md（任务描述/子任务分配/当前状态）→ Worker A 完成写入 result_a.json → Worker B 启动读取 task.md 和 result_a.json → 全部完成后 Manager 汇总。好处：解耦（不依赖同时在线）、可追溯（中间产物都在文件里）、可恢复（任务中断可以从中间文件继续，不用从头再来）。

方式四：环境变量注入——通过环境变量或 Metadata 注入小而固定的配置信息（项目根目录路径、当前分支名称、目标部署环境、关键约束条件），不需要每个 Agent 去”问”。

好的通信机制，不是让 Agent 们”畅聊”，而是让信息精准、高效地流动。

06 从 Demo 到生产：工程落地的七个真正难点

多 Agent 框架在 Demo 里总是显得很强大，但进入真实工程系统，真正的难点通常不是模型能力，而是可控性——知道系统在做什么、为什么这么做、出了问题怎么定位、怎么恢复、怎么控制成本。

能力	为什么重要	设计建议
可观测性	需要知道哪个 Agent 做了什么、为什么	记录任务、消息、工具调用、状态变化
可恢复性	长任务可能中断或失败	保存任务状态，支持从节点恢复
权限最小化	多 Agent 会增加误操作面	按角色配置工具权限，不该给的不给
成本控制	多 Agent 会放大 Token 和工具成本	设置预算、轮次上限和停止条件
冲突处理	多个 Agent 可能给出不同结论	引入主 Agent 或 reducer 做最终决策
人工介入	高风险决策不能全自动	审批节点、暂停点、回滚方案
结果验证	LLM 输出不能天然可信	测试、静态检查、事实引用、审查器

特别强调权限设计——一个 Agent 能执行 Shell 命令，另一个能访问生产数据库，第三个能调用外部 API……如果权限不做隔离，一个 Agent 出了问题，整个系统都可能遭殃。工具权限按角色分级：

工具类型	风险等级	推荐权限策略
只读代码搜索	低	多数 Agent 可用
文件编辑	中	只给 Executor 或主 Agent
Shell 命令	中到高	限制命令白名单或沙箱执行
外部 API 写入	高	需要审批或专用 Agent
凭据访问	极高	默认禁止，必要时最小授权

工具越多，能力越强，风险也越高。权限边界比工具数量更重要——就像财务章不能谁都能拿，服务器密码不能人人都知道。

07 五个关键实践 + 五个常见反模式

✅ 五个关键实践：

1. 先 Scout 再 Split：不要上来就创建一堆 Agent。先用一个 Agent 快速 scout（只读 + 低成本），摸清任务实际规模和结构，再决定拆多少个、用什么模式。打仗之前先派侦察兵。
2. 设定 Agent 数量上限：轻量任务 1-3 个，中量 3-5 个，重量 5-8 个；超过 8 个先想想是不是该拆成多个独立任务。协调成本随 Agent 数量指数级增长，太多会吃掉所有并行收益。
3. 为每个 Agent 设定”Stop 条件”：不是”做完再停”，而是”满足条件就停”（Scanner 搜索覆盖 90% 就停止；Analyzer 发现 Top 10 问题且交叉验证通过就停止）。没有停止条件的 Agent 会一直跑——浪费 Token 或陷入死循环。
4. Manager 不做具体工作：职责只有拆解任务、分发汇总、质量把关。Manager 一旦亲自写代码、搜文件，角色就混淆了，整体效率反而下降。
5. Parallel + Pipeline 混搭：独立子任务用 parallel，有依赖的用 pipeline，需要多视角碰撞用 peer-to-peer。一个复杂任务里三种模式通常同时存在，不要强求只用一种。

❌ 五个常见反模式：

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

作者自述：这五个反模式几乎在每个做多 Agent 的团队身上都看到过，包括自己——刚开始也犯过”过度拆分”的错，以为 Agent 越多越厉害，结果协调成本高得离谱。

写在最后：Multi-Agent 的本质是”协作操作系统”

判断一个多 Agent 框架好不好，不是看支持多少种 Agent、API 多优雅、Star 数量，而是看七个问题：

1. 它如何拆任务和调度 Agent？
2. 它如何隔离和共享上下文？
3. 它如何管理工具权限和审批？
4. 它如何保存中间状态和长期记忆？
5. 它如何合并多个 Agent 的冲突结论？
6. 它如何验证结果是否真的完成？
7. 它如何控制成本、轮次和停止条件？

框架的 API 会不断变化，新模型会不断出现，但这些设计问题是相对稳定的。真正有价值的多 Agent 框架，不是让 Agent 数量变多，而是让复杂任务的协作过程变得可分解、可观察、可验证、可恢复。

多 Agent 协同不是”人多力量大”，而是角色清晰 × 信息通畅 × 边界明确。三个要素缺一不可。

好的多 Agent 设计，每个 Agent 都像一颗棋子——单看很简单，组合起来却能解决极其复杂的问题。而不好的设计呢？每个 Agent 都觉得自己很厉害，凑在一起却像一盘散沙。

说到底，多 Agent 系统的设计哲学，和人类团队的管理哲学是相通的——毕竟，AI 再强，也是人设计的。