第8节 反面教材什么时候不该用多智能体一句话总结Anthropic最简单方案原则的多智能体版——单循环好验证器经常打败多智能体花活三个真实反例成本翻倍/责任稀释/调试地狱多智能体的准入检查清单。本文导航一、多智能体不是万能药二、三个真实反例三、成本核算器把反例1算成一笔账四、准入检查清单与自动评估器五、Anthropic最简单方案原则六、下台阶的三个信号小结一、多智能体不是万能药第10章走到这里工具箱已经塞满了spawn、worktree、Supervisor、五种编排模式、官方Teams机制。最后这一节我要亲手把这些工具按回箱子里一部分——因为最容易犯的错不是不会用多智能体而是到处用多智能体。常见误区 任务很复杂 → 用多智能体 真相 任务很复杂 → 先用单循环好验证器 单循环搞不定 → 才考虑多智能体这个误区有个心理学根源多智能体架构看起来高级。简历上写设计了多Agent协作系统比写了一个带验证器的循环唬人得多。但工程不为简历服务为结果服务。回顾一下第1节的账单同样10个模块的审计单循环总token 151K子智能体方案176K——多智能体天然多近两成起步的固定开销每个工人的独立系统提示、任务描述、结构化返回。这个开销什么时候值回票价当注意力挤压真实存在决策占比被稀释到15%以下、当并行收益真实兑现任务天然独立、当独立验证真实提质交叉视角有意义。三个条件缺一个那两成就是纯亏。还有第6节的编排税没算进去每个并行产出的diff都要吃你的审查带宽。单循环一次交付一个可控的整体多智能体交付N份需要分别审查的diff。复杂度不会消失只会转移——从模型的上下文转移到你的审查队列从运行时的token转移到调试时的深夜。本节的三个反例全都是复杂度转移后在人这一侧爆雷的形态成本翻倍是转移到账单责任稀释是转移到协作语义调试地狱是转移到排查工作。判别式只有一个转移过去的那一侧你接得住吗账单有预算、协作有签字、排查有日志——三个接得住都成立多智能体才是好工具任何一个接不住它就是定时炸弹。二、三个真实反例反例1成本翻倍任务修复3个bug 多智能体方案 Supervisor 3个Worker Checker 5个Agent × 5轮 × 5K tokens 125K tokens 单循环方案 1个Agent 验证器 1个Agent × 8轮 × 5K tokens 40K tokens 多智能体成本3倍质量提升仅10%细看这笔账的结构。3个bug是什么类型的都是小修小补——改一个边界条件、补一个空值检查、修一个正则。这种任务单循环串行修第1个bug的修复经验还能帮第2个同仓库的代码风格、测试跑法都熟了。拆成3个独立Worker后每个Worker都要从零装载仓库上下文Supervisor还要付费做分解和汇总Checker再付一遍审查费。多Agent的固定开销对小任务是常数级税负任务越小税负率越高。125K vs 40K3倍成本买10%质量提升——这10%还是乐观估计实际那3个bug单循环全修对了多智能体方案反而因为一个Worker理解偏了任务返工一轮。什么时候这个账能反过来算bug从3个变30个、每个都要啃几百行上下文、彼此独立——那时固定开销被摊薄并行的墙钟收益和隔离的注意力收益开始占上风。规模是多智能体的第一道门槛。反例2责任稀释多智能体出错了谁负责 Supervisor我只负责派发 Worker-1我只是执行命令 Worker-2我只管自己的任务 Checker我只是审查 结果没人负责问题难以定位这不是段子是我亲历的一次事故复盘。一个三Agent系统产出的方案有个数据口径错误复盘会上四个角色含Checker各自都按流程做了但错误就是穿过了所有环节Supervisor分解时没写明口径Worker按自己的理解填了数Checker查的是格式不是口径三方都无辜错误全责。单循环没这个问题错误在哪个环节日志一条线拉到底责任无可推诿。多智能体把责任链拉长了每一段都有我只是局部的辩护空间。治本的方案不是退回单循环而是把隐式责任显式化每个Agent的结构化笔记里强制带我负责判断的部分/我无法判断依赖上游的部分两个字段第2节StructuredNote的变体交接处声明假设。责任稀释的根因不是Agent多是交接处没人签字。反例3调试地狱单循环出错 1个循环 → 看日志 → 定位问题 多智能体出错 5个Agent → 5份日志 → 谁的问题 跨Agent通信出错 任务分解不对 还是工人执行出错调试复杂度的增长是超线性的。单循环的日志是一条时间线二分查找半小时能锁定问题段。五Agent系统是五条时间线加一堆交接点错误可能出生在Worker-2潜伏在交接序列化爆发在Supervisor的汇总——你在爆发点看到的现场离病因隔了两次上下文搬运。我那次的排查路径先看汇总日志症状→ 怀疑Worker-3背锅→ 翻Worker-3完整日志发现它拿到的任务描述就错了 → 追到Supervisor的分解输出 → 发现分解提示词里一个模糊措辞。三小时翻越四份日志。同样的错误在单循环里就是一次顺序排查。第2节的全字段日志和提示词落盘在这次排查里救了我——没有落盘的原始提示词病因那一步根本无从对证。多智能体系统的可调试性不是天然属性是日志工程买来的每个Agent独立日志文件、每次交接的完整输入输出落盘、全局trace_id串联。没有这三样调试地狱不是风险是必然。三、成本核算器把反例1算成一笔账反例1的账我写了个核算器让该不该上多智能体变成一道算术题而不是风格题。# src/ai_loop_course/multiagent_cost.py单循环 vs 多智能体的成本核算器固定开销模型 工程规范pydantic建模、logging双输出按月分割保留12个月 importloggingfromlogging.handlersimportTimedRotatingFileHandlerfrompydanticimportBaseModel,Field loggerlogging.getLogger(cost_calc)logger.setLevel(logging.INFO)_fmtlogging.Formatter(%(asctime)s %(levelname)s %(message)s,%Y-%m-%d %H:%M:%S)forhin(logging.StreamHandler(),TimedRotatingFileHandler(logs/cost_calc.log,whenMIDNIGHT,interval31,backupCount12,encodingutf-8)):h.setFormatter(_fmt)logger.addHandler(h)classTaskProfile(BaseModel):任务画像三个参数决定两套方案的成本n_subtasks:intField(ge1,description可拆分的子任务数)context_per_task:intField(gt0,description每任务需装载的上下文token)rounds:intField(gt0,description每任务平均循环轮数)classCostModel(BaseModel):成本模型固定开销取自第1节实测口径per_agent_system:int2000# 每个Agent独立系统提示任务描述orchestration:int500# Supervisor分解汇总开销每任务摊note_overhead:int300# 每次结构化返回的折叠开销quality_gain:float0.10# 多智能体质量增益乐观估计defsingle_loop_cost(p:TaskProfile)-int:单循环任务串行但上下文跨任务复用第2个任务起上下文增量小reuse0.4# 相邻任务上下文重合度同仓库任务典型值total0foriinrange(p.n_subtasks):ctxp.context_per_taskifi0elseint(p.context_per_task*(1-reuse))totalctx*p.roundsreturntotaldefmultiagent_cost(p:TaskProfile,m:CostModel)-int:多智能体每工人独立装载全量上下文 编排固定开销workersp.n_subtasks*(p.context_per_taskm.per_agent_system)*p.rounds overheadp.n_subtasks*(m.orchestrationm.note_overhead)m.per_agent_systemreturnworkersoverheadif__name____main__:mCostModel()fornin(3,10,30):pTaskProfile(n_subtasksn,context_per_task5000,rounds5)s,multisingle_loop_cost(p),multiagent_cost(p,m)verdict多智能体更省ifmultiselse单循环更省logger.info(子任务%2d 单循环%7d 多智能体%7d 倍率%.2f → %s,n,s,multi,multi/s,verdict)真实控制台输出2026-03-21 15:44:02 INFO 子任务 3 单循环 55000 多智能体 109400 倍率1.99 → 单循环更省 2026-03-21 15:44:02 INFO 子任务10 单循环 160000 多智能体 360000 倍率2.25 → 单循环更省 2026-03-21 15:44:02 INFO 子任务30 单循环 460000 多智能体1076000 倍率2.34 → 单循环更省结果可能反直觉在上下文可复用的前提下单循环在这个模型里永远更省——因为同仓库任务的上下文重合度40%单循环第2个任务起只需装增量的60%而多智能体每个工人都全价重装。倍率在2倍上下且随子任务数缓慢爬升1.99→2.34比第1节的实测约两成凶得多——原因是核算器里每个工人要跑满5轮、每轮全价带着上下文第1节的演示工人第一轮就交了笔记轮数越多、上下文越大重装的浪费滚得越大。那多智能体什么时候赢改两个参数就知道context_per_task涨到50K每任务要啃大块独立文档reuse趋近0任务跨仓库毫不相干——单循环的上下文越滚越大撞上注意力挤压第1节的测量仪报警质量开始掉这时代价换质量才成交。成本核算器告诉你的不是答案是你为多智能体付费的前提条件是否成立。踩坑提示核算器的quality_gain字段我建了模型但没让它在verdict里说话——因为质量增益没有可靠的事前估计方法。别在决策里用拍脑袋的质量百分比给自己找理由先把能算的算清楚质量项留给单循环试跑后实测。四、准入检查清单与自动评估器## 多智能体准入检查 在决定用多智能体前确认以下全部满足 - [ ] 单循环 验证器已经尝试过确实不够 - [ ] 任务可以清晰分解为独立子任务 - [ ] 子任务之间低耦合不需要频繁通信 - [ ] 有足够的审查带宽并行度 审查能力 - [ ] 有明确的验收标准每个子任务可验证 - [ ] 有预算多智能体成本更高 - [ ] 有调试能力能追踪多Agent日志 如果任何一项不满足 → 用单循环清单七条第一条压秤单循环试过没有。没试过就上多智能体等于没量血压就开降压药。清单可以背也可以跑。我把它写成了自动评估器——输入任务画像输出准入结论# src/ai_loop_course/admission_check.py多智能体准入自动评估器七条清单的代码化importmathfrompydanticimportBaseModelfrommultiagent_costimportTaskProfile,CostModel,single_loop_cost,multiagent_costclassAdmissionInput(BaseModel):准入评估输入把七条清单压成可测量的字段tried_single:boolFalse# 清单1试过单循环吗n_subtasks:int1coupling:strlow# low/medium/high 子任务耦合度review_capacity:int5# 每天可审diff数per_agent_output:float2.0# 单Agent日产diff数has_acceptance:boolTrue# 每子任务有验收标准budget_multiplier:float2.5# 预算容忍倍率核算器实测同仓库任务倍率约2has_tracing:boolFalse# 有多Agent日志追踪defcheck(x:AdmissionInput)-tuple[bool,list[str]]:逐条评估返回是否准入, 未过关项清单fails[]ifnotx.tried_single:fails.append(未先尝试单循环验证器清单第1条一票否决)ifx.coupling!low:fails.append(f子任务耦合度{x.coupling}高耦合下交接成本吃掉并行收益)max_parallelmath.ceil(x.review_capacity/x.per_agent_output)ifx.n_subtasksmax_parallel:fails.append(f并行度超审查带宽{x.n_subtasks}{max_parallel}第6节公式)pTaskProfile(n_subtasksx.n_subtasks,context_per_task5000,rounds5)ratiomultiagent_cost(p,CostModel())/single_loop_cost(p)ifratiox.budget_multiplier:fails.append(f成本倍率{ratio:.2f}超预算容忍{x.budget_multiplier})ifnotx.has_acceptance:fails.append(子任务缺验收标准无法验证的并行是灾难)ifnotx.has_tracing:fails.append(缺多Agent日志追踪出问题进调试地狱)return(notfails),failsif__name____main__:forcasein[AdmissionInput(tried_singleTrue,n_subtasks3,has_tracingTrue),AdmissionInput(tried_singleTrue,n_subtasks3,couplinghigh,has_tracingTrue),AdmissionInput(tried_singleFalse,n_subtasks3,has_tracingTrue),]:ok,failscheck(case)print(f准入{ok}未过关{failsiffailselse无})真实控制台输出准入True 未过关无 准入False 未过关[子任务耦合度high高耦合下交接成本吃掉并行收益] 准入False 未过关[未先尝试单循环验证器清单第1条一票否决]三个案例三种结局全绿放行高耦合被拦交接成本会吃掉并行收益没试过单循环直接一票否决。评估器把感觉该用多智能体变成了七项硬检查每一次放行都有据可查。五、Anthropic最简单方案原则复杂度阶梯 单提示词 → 循环验证器 → 单Agent工具 → 多Agent编排 每上一级确认下一级确实不够用。 不要为了先进而复杂化。不够不够不够单提示词循环验证器单Agent工具多Agent编排这四级阶梯是整个课程的骨架回放第23章单提示词第46章循环验证器Agentic Loop第7~9章单Agent工具权限压缩第10章多Agent编排。每一级的不够都有可观测的症状单提示词不够输出不可靠循环不够任务超出单轮能力单Agent不够注意力挤压第1节测量仪报警只有这些症状逐级出现爬梯子才是合理的。阶梯上被标绿的是第二级——循环验证器。这是性价比之王实现成本最低一个while循环加一个判定函数覆盖面最广本课程大部分实战案例停在这级就解决了也是最常被跳过的一级。很多人从单提示词直接跳到多Agent编排把本该花在验证器上的功夫花在了编排拓扑上结果验证缺口被N个Agent放大N倍。下台阶的姿势也要正确多智能体跑了一阵发现过度设计砍掉编排时不要一步到位退回单提示词——退到单循环验证器检查症状是否消失。复杂度应该停在症状消失的那一级而不是降到最低的那一级。六、下台阶的三个信号反着说也成立已经在跑多智能体的系统出现哪三个信号说明该降级了我自己的判据信号一工人的任务描述越写越长。健康的多智能体系统里每个工人的任务描述一页纸以内当你的任务描述膨胀到三页各种约束、例外、上下文补丁说明这个任务根本不可分解——它在用提示词长度抗议被强行拆开。不可分解的任务硬拆交接面的信息损耗就得靠任务描述补补到后来单循环直接做完都够了。信号二工人之间开始频繁传话。worker-1的产出要喂给worker-2当输入worker-2的疑问又要绕回worker-1确认——链式依赖越串越长并行度名存实亡。低耦合是多智能体的准入条件清单第3条耦合度爬升就是准入条件在失效。传话超过两轮的合并成一个Agent反而快。信号三编排层代码比业务代码还多。Supervisor的分解提示词改了八版、状态机加了一堆特判、日志对账逻辑缠成一团——基础设施的复杂度淹没了任务本身。这时候退回单循环你失去的是先进换回的是可维护性。三个信号共用一个底层逻辑多智能体的收益隔离并行独立验证必须持续大于它的固定开销。收益萎缩或开销膨胀到临界点信号就会从最疼的地方冒出来。每月拿这三个信号过一遍系统比事后大重构便宜得多。三个信号各自的应对也列成表方便对照执行信号判断标准应对动作任务描述膨胀单个工人提示词超一页合并相邻子任务减少Agent数工人频繁传话跨Agent往返超过两轮把传话链合并进一个Agent编排代码超业务代码Supervisor特判逻辑多于工人提示词降级单循环验证器注意三行的应对动作全都是减法——没有一条是优化编排。这是本节的隐藏立场多智能体系统出问题时第一反应不该是修编排是怀疑编排本身。工具箱里最顺手的锤子往往就是该先放下的那把。给正在犹豫的读者一个决策流程把本节内容压缩成一个可执行的判断序列任务预计几轮能完成预估≤10轮 → 单循环结束判断跑一遍单循环验证器 → 达标就停别升级不达标跑第1节的压力测量仪 → 决策占比没跌破15% → 修提示词别升级跌破了跑本节准入评估器 → 全绿才上多智能体上了之后每月巡检三个下台阶信号。五步走完用不用多智能体从风格之争变成流程产出。这也是整个第10章的落点编排是工具箱里的一件工具拿起来要有流程放回去要有信号——工具指挥人人就废了。小结反例问题教训成本翻倍5个Agent比1个贵3倍先用单循环责任稀释出错没人负责明确职责边界调试地狱5份日志难定位保留调试能力核心结论多智能体不是万能药。单循环好验证器经常打败多智能体花活。准入清单单循环确实不够、任务可清晰分解、子任务低耦合、有审查带宽、有预算、有调试能力——全部满足才上多智能体。三个补充判断规模是第一道门槛任务太少固定开销税负率高上下文可复用的同仓库任务单循环天然更省成本核算器倍率约2~2.3责任稀释的根因是交接处没人签字治本靠结构化笔记里显式声明我判断的/我依赖上游的。第10章八章走完把这一章和全书的关系摆正子智能体与并行编排是循环工程的高级形态不是终极形态——它解决的是单循环注意力不够和串行太慢代价是三税和三反例。工具箱到这里齐了下一章开始解决另一个维度的问题系统怎么在没人盯着的时候安全地跑。下节预告第10章子智能体与并行编排到此收官。下一章进入自动化与无人值守第11章第1节《Headless模式CLI化的循环与管道集成》——把Agent循环变成管道里的一道命令无人值守跑批、cron调度、CI集成让前面十章搭的系统在没人盯着的时候也能安全运转。如果觉得本文对你有帮助欢迎点赞、收藏、关注三连本系列持续更新中关注不迷路~文章编号第10章第8节 | 总进度75/120 | 预计阅读时间13分钟 第10章子智能体与并行编排全部完成8/8篇累计75/120篇62.5%