好久没更新了，先跟大家说声抱歉。前段时间手上的项目比较忙，精力都放在了交付上，分享就停了下来，让一直在等的朋友久等了。现在项目告一段落，这周会连着更新两章，后面也会恢复正常节奏，还是认真写、免费分享。谢谢大家的耐心。
引子：第五轮，聊"分工"
前四轮拷问（记忆、工具、规划、安全）之后，第五次见面。这回面试官拿着我上一版的架构图开的场：
“你这个方案，把一个任务拆给了 5 个 Agent 协作。我想聊聊这张图。”
我心里还挺得意：“对，一个主 Agent 负责编排，下面几个子 Agent 分别管检索、分析、写作，分工明确、各司其职。”
对方盯着图看了两秒：“‘分工明确、各司其职’——这话听着，像一个管理者会说的。那我就问你一个管理者的问题：加 Agent，和加人，是一回事吗？”
我一愣，没料到他往这个方向拐。他接着说：“你有没有想过，你画这张图的时候，以为自己在让系统变得更聪明。可你真正做的，是组建了一个团队——而团队，是会内耗的。”
这一下把我问住了。因为我确实从没算过那笔账：我加的每一个 Agent，带来的是产能，还是又一张需要开会对齐的嘴。第五次连环追问，就从这里开始：
“什么时候是真需要多个 Agent，什么时候只是自找麻烦？”
“为什么不让一个更聪明的大 Agent 自己把活全干了？”
“真要拆，几个 Agent 之间怎么编排？”
“Agent 之间怎么传话，怎么防止越传越走样？”
“每个子 Agent，该让它看到多少全局信息？”
“一堆 Agent 跑起来，怎么防止它们集体失控、烧光预算？”
“上了线，多 Agent 这套踩过什么坑？”
还是七问。而"加 Agent 等于加人"这个视角——多 Agent 系统首先是一个组织，其次才是一个技术架构——是这一整篇的题眼。照旧，把七问补完，就是全文的路线图。
第一章：先破个迷信——多 Agent 不等于更智能
面试官：什么时候是真需要多个 Agent，什么时候只是自找麻烦？
先泼一盆冷水，因为这盆水能省下很多人半年的弯路：“多 Agent = 更高级 = 更智能”，是这个领域流传最广的一个迷信。
架构图上画满一堆 Agent、连着复杂的编排箭头，看着确实先进、唬人。但每多接一个 Agent，你就多背一份协调成本——上下文要在它们之间传递、结果要对齐、错误会跨 Agent 传播、失败点又多了一个。这些成本不是抽象的，是实打实的 token、延迟和线上事故。
这里有一条软件工程界的老定律，几乎可以原样搬过来——布鲁克斯定律（《人月神话》）：“往一个已经延期的项目里加人，只会让它更晚。”因为新人带来的产能，被新增的沟通协调开销吃掉了还倒亏。多 Agent 是一模一样的道理：分工带来的收益，必须大于协调付出的成本，拆才划算。而在很多任务里，这笔账是负的。
所以正确的默认姿势是：能一个 Agent 解决的，就别拆。一个带工具、带循环、带良好上下文管理的单 Agent（前四篇讲的全部内容），能覆盖的场景远比大多数人以为的多。做 Devin 的 Cognition 团队专门写过一篇文章，标题直白得近乎劝退——《Don’t Build Multi-Agents》（别搭多 Agent），核心论点就是：轻率拆成多 Agent，最大的风险是上下文碎片化导致的决策不一致，几个 Agent 各基于半张信息各干各的，最后拼不到一起。
那什么信号才真的该拆？先给结论，下一章展开：任务能干净地分解成互相独立的子任务、子任务需要不同的专业化配置、需要并行来压缩时间、或者单个上下文已经装不下。四条里没中任何一条，就别拆。
💡 开发者视角：识别"为了多 Agent 而多 Agent"的反模式，有个一句话的照妖镜——把这几个 Agent 的角色提示词合并成一个 Agent 的系统提示 + 一组工具，会明显更差吗？如果不会，那你的多 Agent 架构只是把复杂度从"一段提示词"搬到了"一张编排图"里，账面上热闹，净收益为零，还白白多出了协调开销和调试难度。先证明单 Agent 不行，再谈拆。
第二章：拆的真正理由——不是一个不够聪明，是一个上下文装不下
面试官：为什么不让一个更聪明的大 Agent 自己把活全干了？
这一问，直击很多人拆 Agent 的错误理由。如果你心里的答案是"因为一个 Agent 不够聪明"，那换个更强的模型就该解决问题——但现实是，换了更强的模型，该拆的任务还是得拆。为什么？因为拆分解决的从来不是"智力"问题，而是"上下文"问题。
拆 Agent 的真正理由有四个，没有一个和"智商"有关：
一，上下文隔离（最本质的理由）。一个 Agent 单打独斗时，会把检索来的原始资料、中间推理、工具调用日志，全堆在同一个上下文里，越堆越乱。第一篇讲的"中间信息丢失"、第三篇讲的"目标漂移"，在一个塞满了杂物的上下文里会加倍发作。拆开之后，每个子 Agent 只面对自己那一小摊事，上下文干净、注意力集中；干完活，它交回的是一份提炼过的结论，而不是把自己一路产生的垃圾全倒进主上下文。多 Agent 本质上是一种上下文管理手段——这是它最容易被忽略、却最重要的价值。
二，关注点分离与专业化。不同子任务需要不同的系统提示、不同的工具集，甚至不同档位的模型（便宜模型干粗活、贵模型做难判断）。第二篇讲过，一个 Agent 挂几十个工具会选择困难；拆开后，每个 Agent 的工具箱都小而精，选择准、上下文省。
三，并行。互相独立的子任务——比如同时调研三个候选技术方案——可以并行跑，直接压缩墙钟时间。这是多 Agent 相对单 Agent 的独有优势：单 Agent 的循环本质是串行的，一步接一步；而多个子 Agent 可以真正同时开工。
四，容错边界。一个子 Agent 失败了、或者被注入劫持了（第四篇的噩梦），影响面被限制在它自己的边界内，不会直接搞崩全局——前提是你的通信和上下文设计做对了（第四、五章的主题）。
把这四条合起来，是一个需要重新校准的认知：
多 Agent 首先是一种上下文架构，其次才是一种"智能架构"。你拆的不是智能，是上下文和关注点。
一个真实的参照系是深度研究类任务。Anthropic 分享过他们的多 Agent 研究系统：一个主 Agent 把研究问题分解，派发多个子 Agent 并行去检索不同的子领域，每个子 Agent 把自己领域内浩如烟海的原始资料，在自己的上下文里消化成一份简报，只把简报交回主 Agent 汇总。它为什么有效？因为"检索三个独立子领域"天然可并行，而且每个子领域的海量原文如果全塞进一个上下文早就爆了——子 Agent 在边界内把原文嚼碎、只吐结论，主上下文因此始终清爽。代价也很诚实：这类系统的 token 消耗，是单 Agent 对话的十几倍（多个 Agent 各自的上下文加上通信开销）。所以它值不值，纯看任务的价值撑不撑得起这份开销。
图 1：换个更强的模型，替代不了拆分——拆分解决的不是"智力"问题，是"上下文"问题。左边什么都堆进一个上下文，右边每个子 Agent 只背自己那一摊、把提炼过的结论交回。
💡 开发者视角：判断该不该拆，有个非常操作性的问题：这些子任务，能不能各自独立完成、再把结果拼起来？能（调研三个独立子领域、从不同维度审同一份代码）——拆分收益大；不能，子任务环环相扣、每一步都得看到前一步的完整细节（写一篇逻辑连贯的长文，后一段紧咬前一段的语气和论证）——强行拆开，第四章要讲的"传话失真"会毁掉连贯性，远不如让一个 Agent 一气呵成。可独立分解性，是多 Agent 的先决条件，不是可选项。
第三章：编排模式——把 Agent 组织起来的三种阵型
面试官：真要拆，几个 Agent 之间怎么编排？
生产里的编排模式，万变不离三种主力阵型：
一，Orchestrator-Worker（主管-工人，中心化编排）。一个主 Agent 负责分解任务、把子任务派发给工人 Agent、再汇总它们的结果。主 Agent 是唯一的"大脑"，工人是"手"。这是最常用、最好控制的模式，适合能分解成子任务、又需要一个统一汇总视角的活。上一章的 Anthropic 研究系统就是它。它的软肋是：主 Agent 是单点瓶颈，也是单点故障。
二，Pipeline（流水线，顺序移交）。Agent A 的输出是 Agent B 的输入，链式往下传，像工厂流水线：需求分析 → 方案设计 → 编码 → 测试，一段一个 Agent。适合阶段清晰、每一阶段需要不同专业化的任务。它的风险是第三篇讲过的误差复利——上游一个失真，会一路传到下游被放大；而且它是串行的，并不省时间。很多框架里的 "handoff（移交）"模式就是这一类。
三，Debate/Review（辩论-评审，去中心化）。多个 Agent 平行给出方案、或者互相挑刺，最后由一个裁判或一轮投票收敛。适合开放性、高风险、值得多视角交叉验证的决策——这正是第三篇"换个检查者来审"、第四篇"红队自问"的多 Agent 化身。它的收益是多样性能纠正单点偏见（集成学习的思想），代价是最贵：同一个问题要算好几遍。
这三种不是互斥的，可以嵌套：orchestrator 派发的每个 worker，内部可能自己是一条 pipeline；debate 的那个裁判，可能自己是个小 orchestrator。别追求纯粹，按任务拼。
一条选择原则收束本章：中心化好控制，去中心化多样性强，流水线适合阶段化——绝大多数生产系统，从 orchestrator-worker 起步就足够了。辩论式虽然诱人，但请留给那些真正高风险、值得多花几倍成本去交叉验证的决策，别拿它当默认。
图 2：三种编排阵型——中心化的主管-工人、阶段化的流水线、多视角的辩论评审。绝大多数生产系统从主管-工人起步就够，辩论式留给值得多花几倍成本的高风险决策。
💡 开发者视角：无论用哪种阵型，都必须有一个明确的"谁做最终决定"。多 Agent 最容易出的乱子有两种：一种是"三个 Agent 都以为别人会兜底，结果没人兜底"；另一种是"两个 Agent 各执一词，系统卡在那里收敛不了"。责任必须收敛到单一节点——要么一个 orchestrator，要么一个裁判，要么一条写死的投票规则。记住：去中心化的可以是执行，但不能是责任。
第四章：通信与传话失真——子 Agent 交回的是"报告"，不是"过程"
面试官：Agent 之间怎么传话，怎么防止越传越走样？
先看这个问题的两个极端答案，你就明白它难在哪：
- 传全部原始上下文：对齐是好了，但爆炸——每个 Agent 都背着全量历史，token 翻几倍，还把彼此的噪音互相传染。
- 只传一句结论：干净是干净了，但可能把下游真正需要的关键细节一起丢了。
真实的病症叫传话失真（传声筒游戏）：信息每经过一个 Agent 转述，就损耗一次。子 Agent 把一手资料压缩成简报（丢一次），主 Agent 把好几份简报再压成一个结论（再丢一次）。层层摘要，和第一篇讲的上下文压缩丢信息是同一个病根，只不过这次发生在 Agent之间。
工程上治它，靠四件事：
一，结构化交接，而不是自由文本。子 Agent 返回一个结构化对象——带明确字段：结论、置信度、依据、未解决项——而不是甩一段散文。结构化能防止"关键信息藏在一句闲话里，被下游整个忽略"。
二，传引用，而不是传全文。大产物（检索到的长文档）落盘，Agent 之间只传路径/ID + 摘要，需要细节的 Agent 自己按需去取。这是第二篇"落盘 + 引用"、第一篇"记忆外置"在 Agent 通信层的原样复用。
三，保留可追溯的出处。子 Agent 的结论要能追回它基于哪些原始材料——否则主 Agent 根本没法判断这个结论该信几分。这份可追溯性，也正是第六篇可观测性的原料。
四，把交接契约当接口写死。每个 Agent 的输入/输出格式，是一份"接口契约"——这就是第二篇讲的 Schema 思想，只是这次读者从模型换成了另一个 Agent。契约清晰，传话失真才可控。
由此得到一个反直觉、但极其重要的结论：
多 Agent 系统的质量上限，往往不取决于单个 Agent 有多强，而取决于它们之间的接口设计有多干净。
就像一家公司：员工个个能力超群，但如果交接全靠口头、没有文档、信息每过一手就衰减一层，整体产出照样稀烂。Agent 团队一模一样。
💡 开发者视角：调试多 Agent 系统，第一个该看的不是单个 Agent，而是"交接点"。最常见的失真根本不是某个 Agent 突然变笨了，而是 A 的输出格式和 B 期待的输入对不上，B 只能连蒙带猜。把每一个交接点的契约像定义 API 那样显式写下来，比你反复去调单个 Agent 的提示词，有效一个数量级。
第五章：上下文——共享还是隔离，这是本篇最核心的架构决策
面试官：每个子 Agent，该让它看到多少全局信息？
这是多 Agent 设计里最核心的权衡，而且它没有唯一答案——它是一条光谱，你要做的是在光谱上选一个点。
光谱的一端：全共享（所有 Agent 都看到全部历史）。
- 好处：全局对齐，不会各干各的、决策打架。前面提到的 Cognition《Don’t Build Multi-Agents》强烈站这一侧——他们认为上下文碎片化是多 Agent 失败的头号原因，主张尽量共享，甚至干脆别拆。
- 坏处：贵（每个 Agent 都背全量）、慢、互相干扰（一个 Agent 的推理噪音污染另一个），以及一个致命的安全问题——注入扩散：这正是第四篇结尾埋的钩子。一个子 Agent 读到的一句恶意指令，若全量共享，就直接传染了整个团队。
光谱的另一端：全隔离（每个 Agent 只看自己那一小片任务）。
- 好处：干净、省、专注，而且故障隔离——注入被困在单个 Agent 内出不来。
- 坏处：可能丢全局，子 Agent 因为看不到大图，做出"局部合理、全局错误"的决策（第三篇的局部贪心）；还容易出现"两个子 Agent 基于不同假设各干一半，最后拼不到一起"。
实用的落点，几乎总在中间，而且有个好记的原则：共享目标，隔离过程。每个子 Agent 都必须看到：最终目标 + 验收标准 + 与它相关的约束（共享这些，防跑偏）；但不需要看到：其他 Agent 的完整推理过程和原始资料（隔离这些，防污染、防爆炸）。一句话——共享 what，隔离 how。这和第三篇"计划锚定要什么、执行自由留给怎么拿"是同一条哲学。
再叠一层安全维度（接第四篇）：共享上下文是注入的高速公路。如果某个子 Agent 会读取不可信的外部内容（网页、用户上传的文件），就更要把它隔离——把"接触外部世界"的 Agent，和"掌握全局、能动手"的 Agent 分开，让脏数据止步于隔离边界，别让它顺着共享上下文一路流进那个能转账的 Agent。这是第四篇纵深防御在多 Agent 架构上的自然延伸。
图 3：共享 what、隔离 how——每个子 Agent 都看到最终目标与验收标准，但看不到别人的完整过程与原始资料。接触外部数据的 Agent 与能动手的 Agent 之间，要有一条隔离带。
💡 开发者视角：给一个能直接用的默认值——默认隔离，按需共享。从"每个 Agent 只给它完成任务所需的最小信息"起步（这正是第四篇最小权限原则在信息维度的翻版），然后观察：发现某个 Agent 因为缺全局而反复犯错，再把它缺的那一块显式补给它。反过来做（默认全共享，再逐个删）几乎必然失败——你永远不敢删，最后拖着一坨谁都不敢碰的巨型上下文上线。
第六章：不失控——成本、错误传播与协调开销
面试官：一堆 Agent 跑起来，怎么防止它们集体失控、烧光预算？
多 Agent 把第三篇讲的单 Agent 失控问题，先乘了个 N，再加了几样新花样：
成本爆炸（树状放大）。一个 orchestrator 派 5 个 worker，每个 worker 自己又是一个多轮循环，可能还再派子-子 Agent。token 消耗是树状展开的，一不留神就冲到单 Agent 的几十倍。对策：给整棵调用树设总预算，并在 Agent 间分配——orchestrator 拿到总预算，再切成子预算发给 worker（第三篇说过，预算是产品决策，这里它变成了一个需要层层分账的产品决策）。
错误与失真传播。上游一个错误结论，被下游当成可信前提继续往上搭，一路放大（pipeline 阵型尤其致命）。对策：在交接处做校验（第三篇"完成要过验证步"的多 Agent 版），并让下游对上游的结果保持"参考、而非圣旨"的态度。
协调死锁与踢皮球。Agent A 等 B、B 等 A；或者都以为对方负责，任务就那么悬着。对策：明确责任节点（第三章），并给每一个等待设超时。
循环升级。第三篇的复读机、钟摆，在多 Agent 里升级成"两个 Agent 把球无限踢来踢去"的死循环对话。对策：第三篇那三道防线（硬预算、无进展检测、干预升级）在编排层原样再实现一遍——只不过这次监控的对象，从单个 Agent 的动作，变成了 Agent 之间的消息流。
一条总原则收口：
编排层必须有一个"上帝视角"的外层控制器，掌握全局预算、全局步数、全局超时，能一键叫停整棵树。
别把终止判断分散到各个 Agent 自己手里。第三篇立过"控制权归代码"，到了这一篇要再强调一层：控制权归编排层，不归任何单个 Agent——因为一个被注入或跑飞的子 Agent，是没有能力、也没有立场喊停整个系统的。
图 4：一个 orchestrator 能派生出一整棵调用树，token 树状放大。终止与预算的控制权，归编排层这个"上帝视角"，不归树上任何单个节点。
💡 开发者视角：多 Agent 的可观测性是刚需，不是奢侈品——这也直接把话题交给了下一篇。单 Agent 出问题，你看一条轨迹就行；多 Agent 出问题，你得在一棵 Agent 调用树里，定位到底是哪个节点、哪一次交接出的错。所以上线前就得把"每个 Agent 的输入 / 输出 / 耗时 / 成本"结构化地记录下来，否则线上一出事，你就是在一团乱麻里徒手找线头。
第七章：上线踩坑清单——多 Agent 的坑，都在"协调"里
面试官：上了线，多 Agent 这套踩过什么坑？
照例，最后一章交坑。六条，条条来自"协调"这个多 Agent 独有的战场。
为了多 Agent 而多 Agent。最常见、也最贵的坑。把一个单 Agent 能干的活拆成五个，协调成本吃光分工收益，还平白多出五倍的失败点。上线前做一次减法：对每个 Agent 都问一句"它能不能被合并进别人？"（回收第一章的照妖镜。）
交接契约没定义，全靠自由文本。A 吐一段散文，B 连蒙带猜，传话失真从这里就开始了。把 Agent 之间的接口当正经 API来设计：有 schema、有版本、有校验。（回收第四章。）
上下文全量共享，又贵又是注入高速路。默认隔离、共享目标不共享过程；尤其要在"接触外部数据的 Agent"和"能动手的 Agent"之间，砌一道隔离带。（回收第五章 + 第四篇。）
没有全局预算，树状烧钱。只给单个 Agent 设了步数上限，却忘了给整棵调用树设总预算——一个贪心的 orchestrator，能悄无声息地派生出成百上千次调用，账单第二天才吓你一跳。预算必须设在编排层。（回收第六章。）
多样性是假的。用同一个模型、同一套提示词，起三个"角色不同"的 Agent 去辩论、去投票，你以为有了交叉验证——其实它们会犯一模一样的错，多数投票只是把同一个偏见投了三票。要真多样性，就得让它们真的不同：不同的提示词视角、不同的工具、甚至不同的模型。（集成学习的前提，是基学习器之间不相关。）
主 Agent 成了单点故障。orchestrator 一旦挂掉、被注入、或上下文爆掉，整个系统跟着全崩。关键系统里，主 Agent 的输入——尤其是那些来自子 Agent、可能已被污染的结果——也要校验，别默认子 Agent 交回来的东西一定干净。（回收第四篇：连自己的队友也不能无条件信任。）
结语：多 Agent 不是玄学，是分布式系统碰上了组织行为学
回头看这七问，照系列惯例把玄学拆成老熟人——只不过这一篇的老熟人，来自两门学问。
一门是分布式系统：orchestrator-worker 是主从架构 / MapReduce；pipeline 是 Unix 管道 / 数据流水线；通信失真是序列化与部分失败；上下文隔离是微服务的边界上下文与进程隔离；责任收敛到单一节点，是分布式共识里的 leader 选举。另一门是组织行为学：debate 是集成决策；协调成本是阿姆达尔定律（串行的协调部分，限制了并行的加速上限）叠加布鲁克斯定律（加人不总是加速）；而"该不该拆、怎么分工不内耗"，根本就是一道管理题。多 Agent 系统，是把这两门几十年的老学问缝在了一起——怎么让多个不可靠的节点协作，怎么让多个独立的个体分工而不内耗。
再回收题眼：加 Agent，和加人，是一回事。你不是在给系统充值智商，你是在组建一个会内耗的团队。所以多 Agent 设计的真功夫，从来不在把单个 Agent 调得多强，而在协调设计得多好——什么时候拆、用什么阵型编排、怎么交接、共享多少上下文、谁对结果负最终责任。单个 Agent 的能力决定下限，协调设计决定上限。
但一个更尖锐的问题，此刻已经躲不过去了：你搭了这么复杂一套协作系统，凭什么说它比一个单 Agent 强？它跑起来热热闹闹、五个 Agent 你来我往，可这到底是高效协作，还是在昂贵地空转？真出了错，你怎么在一棵 Agent 调用树里，精确定位是哪个节点、哪一步、哪一次交接出的问题？——这些问题的答案只有一个前提：你得能看见它。下一篇，就聊这件把所有前几篇都兜住的事：评估体系与可观测性——一个 Agent 到底好不好用，怎么量化。
这个系列会持续更新，也欢迎把你被问住的问题丢过来，说不定就是下一篇的选题。
本文是《AI Agent 核心机制》系列第五篇。前四篇分别讲"怎么记得住事"（记忆与 RAG）、“怎么操作外部世界”（工具调用）、“怎么想清楚该干嘛”（规划与 ReAct）、“怎么不被带坏”（安全护栏）；想从头搞懂大模型本身怎么"思考"，请看《别再把 AI 当黑盒：万字拆解大语言模型的底层"暴力美学"》与《自注意力中的 QKV 详解》系列。
