好久没更新了先跟大家说声抱歉。前段时间手上的项目比较忙精力都放在了交付上分享就停了下来让一直在等的朋友久等了。现在项目告一段落这周会连着更新两章后面也会恢复正常节奏还是认真写、免费分享。谢谢大家的耐心。引子第五轮聊分工前四轮拷问记忆、工具、规划、安全之后第五次见面。这回面试官拿着我上一版的架构图开的场“你这个方案把一个任务拆给了 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内部可能自己是一条 pipelinedebate 的那个裁判可能自己是个小 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 是主从架构 / MapReducepipeline 是 Unix 管道 / 数据流水线通信失真是序列化与部分失败上下文隔离是微服务的边界上下文与进程隔离责任收敛到单一节点是分布式共识里的 leader 选举。另一门是组织行为学debate 是集成决策协调成本是阿姆达尔定律串行的协调部分限制了并行的加速上限叠加布鲁克斯定律加人不总是加速而该不该拆、怎么分工不内耗根本就是一道管理题。多 Agent 系统是把这两门几十年的老学问缝在了一起——怎么让多个不可靠的节点协作怎么让多个独立的个体分工而不内耗。再回收题眼加 Agent和加人是一回事。你不是在给系统充值智商你是在组建一个会内耗的团队。所以多 Agent 设计的真功夫从来不在把单个 Agent 调得多强而在协调设计得多好——什么时候拆、用什么阵型编排、怎么交接、共享多少上下文、谁对结果负最终责任。单个 Agent 的能力决定下限协调设计决定上限。但一个更尖锐的问题此刻已经躲不过去了你搭了这么复杂一套协作系统凭什么说它比一个单 Agent 强它跑起来热热闹闹、五个 Agent 你来我往可这到底是高效协作还是在昂贵地空转真出了错你怎么在一棵 Agent 调用树里精确定位是哪个节点、哪一步、哪一次交接出的问题——这些问题的答案只有一个前提你得能看见它。下一篇就聊这件把所有前几篇都兜住的事评估体系与可观测性——一个 Agent 到底好不好用怎么量化。这个系列会持续更新也欢迎把你被问住的问题丢过来说不定就是下一篇的选题。本文是《AI Agent 核心机制》系列第五篇。前四篇分别讲怎么记得住事记忆与 RAG、“怎么操作外部世界”工具调用、“怎么想清楚该干嘛”规划与 ReAct、“怎么不被带坏”安全护栏想从头搞懂大模型本身怎么思考请看《别再把 AI 当黑盒万字拆解大语言模型的底层暴力美学》与《自注意力中的 QKV 详解》系列。