AI智能体循环工程-第10章第6节-子智能体与并行编排-编排税你的审查带宽才是并行度上限

第6节 编排税你的审查带宽才是并行度上限一句话总结Osmani的orchestration tax——worktree消除机械冲突但审查吞吐限流并行Nceil(审查能力/产出速度)的估算公式审查排队、批量diff、抽查策略。本文导航一、什么是编排税一次真实限流事故二、并行度估算公式三、排队模拟把审查瓶颈跑给你看四、应对策略四种降税手段五、审查带宽的自我测量六、编排税的隐性形态交接成本七、把并行度写进配置而不是写进野心小结一、什么是编排税一次真实限流事故第3节的worktree解决了一类冲突机械冲突——两个Agent改同一个文件、同一个分支互相覆盖。这类冲突有工程解git替我们管好了。但还有一类冲突没有工程解认知冲突——5个Agent并行产出的5份diff最终都要过你这双眼睛。你看diff的速度不会因为Agent跑得快而变快。编排税 多Agent并行带来的额外审查负担 worktree解决了机械冲突 但没解决审查瓶颈 5个Agent并行产出 → 你还是要一个个Review 你的审查带宽 并行度上限限流Agent-1产出你的审查队列Agent-2产出Agent-3产出Agent-4产出Agent-5产出你的审查带宽3个/小时这张图就是本节的核心左边的产出可以无限扩右边的审查带宽是刚性的。中间的队列会无限堆积。这个概念Addy Osmani叫orchestration tax编排税——你为编排付出的隐性成本不在token账单上在你的注意力账户里。为什么说它是税而不是成本因为它随并行度线性增长且无法豁免每开一个并行Agent就多一份必须被人审查的diff。你可以在token上省钱用便宜模型跑工人可以在时间上省钱并行但审查这一步要么你付要么质量付——没有第三条路。跳过审查的多智能体系统等于无人看守的无人车间产出越快废品越多。排队论里有个经典公式可以佐证这个直觉利特尔法则L λ × W系统里的平均积压量等于到达速率乘以平均等待时间。套进我们的场景diff到达速率Agent产出一旦超过服务速率你的审查吞吐等待时间W趋于无穷积压L跟着爆炸。第二节的推演表格和第三节的模拟器本质都是这个法则的数值化——数学早就把结论写好了我们只是用Agent的语境重演了一遍。我的一次真实限流事故讲个真事比公式有说服力。上季度我给自己的仓库审计任务开了8个并行Agentworktree隔离一切正常。Agent们确实快两小时全部跑完交回8个分支的diff。然后呢我审第一个分支花了25分钟第二个30分钟到第四个分支的时候我已经开始跳着看了第六个直接看起来没问题就合了。第二天第六个分支里的一个边界条件错误炸了测试。复盘时算了一笔账我的有效审查能力是每天认真审5个diff我派了8个超载60%超载部分的审查质量断崖式下跌——不是我不想认真审是注意力这个资源不可超发。这次事故让我明白并行度的分母从来不是Agent数量是审查吞吐。从那以后我开工前先算一笔账下一节的公式算完再决定开几个Agent。顺便说一个更隐蔽的心理效应diff一多人会不自觉地降低单份审查标准来清空队列“今天必须把这些看完”。所以超载不只是延后是系统性降低质量——这是编排税最恶劣的征收方式。二、并行度估算公式最优并行数 N ceil(审查能力 / 产出速度) 示例 审查能力10个PR/天 单Agent产出2个PR/天 → N ceil(10/2) 5个Agent 超过5个 → 审查队列堆积 → 瓶颈公式的直觉单个Agent每天产2个diff你每天能消化10个那么5个Agent的产出恰好贴着你的消化上限。第6个Agent不会让系统更快——它产出的diff会在队列里排队等你系统的实际吞吐还是每天10个。用表格推演一下不同并行度下的系统行为假设审查能力10个/天单Agent产出2个/天并行Agent数日产出日审查能力队列日增量一周后队列系统状态3610-4清空审查带宽闲置5101000恰好饱和最优81610642队列线性堆积1224101498灾难审查名存实亡第4行那个98的队列意味着什么一周后你有近百个diff积压每个diff对应的是几小时前的代码状态——等你审到它时代码已经又改了好几轮diff过期审查等于考古。堆积的审查比不审查更浪费。还要注意公式里两个参数都是可测量的审查能力可以从你的历史PR记录算每天认真review的个数产出速度可以从Agent日志算第2节的全字段日志里就有每个worker的完成时间。两个数一代入最优并行度就是一行代码的事。三、排队模拟把审查瓶颈跑给你看光看表格不过瘾我写了个离散排队模拟器把3个Agent闲、5个Agent恰好、8个Agent过载、12个Agent灾难四种情况各跑一遍。参数照公式节单Agent日产2个diff按8小时工时折算0.25个/小时审查能力10个/天1.25个/小时模拟40小时一周工时。# src/ai_loop_course/review_queue_sim.py审查队列离散模拟不同并行度下队列深度与最长等待时间 工程规范pydantic建模、logging双输出按月分割保留12个月 importloggingimportrandomfromlogging.handlersimportTimedRotatingFileHandlerfrompydanticimportBaseModel,Field loggerlogging.getLogger(review_sim)logger.setLevel(logging.INFO)_fmtlogging.Formatter(%(asctime)s %(levelname)s %(message)s,%Y-%m-%d %H:%M:%S)forhin(logging.StreamHandler(),TimedRotatingFileHandler(logs/review_sim.log,whenMIDNIGHT,interval31,backupCount12,encodingutf-8)):h.setFormatter(_fmt)logger.addHandler(h)random.seed(42)# 固定随机种子结果可复现classSimConfig(BaseModel):n_agents:int# 并行Agent数produce_per_hour:float0.25# 单Agent小时产出2个/8小时工时review_per_hour:float1.25# 审查吞吐10个/8小时工时hours:int40# 模拟时长一周工时classSimResult(BaseModel):n_agents:intproduced:intreviewed:intfinal_queue:intmax_wait_hours:floatdefsimulate(cfg:SimConfig)-SimResult:逐小时离散模拟产出进队、审查出队记最长等待queue:list[float][]# 元素入队时刻producedreviewed0# 记账在事件发生处累加别在期末快照max_wait0.0forhourinrange(cfg.hours):arrivalssum(1for_inrange(cfg.n_agents)ifrandom.random()cfg.produce_per_hour)queue.extend([float(hour)]*arrivals)producedarrivals# 吞吐1.25个/小时 每小时保底审1个另有25%概率多审1个served1(1ifrandom.random()cfg.review_per_hour-1else0)whilequeueandservedandqueue[0]hour-0.5:max_waitmax(max_wait,hour-queue.pop(0))reviewed1served-1returnSimResult(n_agentscfg.n_agents,producedproduced,reviewedreviewed,final_queuelen(queue),max_wait_hoursmax_wait)if__name____main__:fornin(3,5,8,12):rsimulate(SimConfig(n_agentsn))logger.info(Agent数%2d 产出%3d 已审%3d 期末队列%3d 最长等待%.1f小时,r.n_agents,r.produced,r.reviewed,r.final_queue,r.max_wait_hours)真实控制台输出2026-03-19 16:22:08 INFO Agent数 3 产出 32 已审 31 期末队列 1 最长等待3.0小时 2026-03-19 16:22:08 INFO Agent数 5 产出 50 已审 46 期末队列 4 最长等待7.0小时 2026-03-19 16:22:08 INFO Agent数 8 产出 85 已审 45 期末队列 40 最长等待20.0小时 2026-03-19 16:22:08 INFO Agent数12 产出113 已审 46 期末队列 67 最长等待20.0小时数字会说话过载后已审数被焊死8个和12个Agent的已审数都停在45、46——到达速率一旦超过服务速率系统吞吐就被审查端钉死在1.25个/小时多开的Agent纯粹在给队列增产而3个、5个Agent时已审数跟着产出走31、46说明审查带宽还有余量瓶颈在产出端队列在临界点后线性膨胀1→4→40→67从5个Agent到8个Agent跨过临界点期末队列翻十倍——过载区里每多开一个Agent一周多积压约7个diff最长等待从3小时涨到20小时8个Agent时一个diff要在队列里躺20个小时才被审到——到那时代码早改样了审它等于考古。模拟还偏乐观了真实审查吞吐不是恒定的人下午会累、会被会议打断真实diff复杂度也不均匀。但方向性结论稳固过载并行买到的是积压不是速度。踩坑提示写这类离散模拟时我犯过一个错——把produced记成期末队列长度期末快照跑出来的产出忽大忽小差点让我怀疑人生。离散模拟的计数器一定要在事件发生处累加produced arrivals期末快照只能拿到存量拿不到流量存量加流量才是产出。这是写一切模拟和监控的通用教训流量在事件点计数存量在时点快照。四、应对策略四种降税手段审查带宽刚性不等于只能躺平。四条策略按性价比排序策略做法效果批量diff合并同类型改动一起Review减少Review次数抽查策略低风险任务抽查20%审查量-80%自动验证前置测试全过的才进入人工Review过滤80%问题分层审查低风险自动过高风险人工释放审查带宽自动验证前置是四条里最值钱的因为它把审查的筛选工作交给了机器每个diff先跑完整测试套件lint类型检查全绿才有资格进人工队列。人工注意力只花在机器判断不了的部分——架构合理性、边界语义、安全隐患。这其实就是第5章验证器思想的复用验证器是人力的杠杆自动化程度每上一格审查带宽就放大一截。分层审查是风险导向的预算分配改文档的diff自动合入改测试的抽查改核心逻辑的必审双人审。把80%的审查预算押在20%的高风险diff上比雨露均沾强得多。分层的判据可以从diff元数据自动推断改动文件路径src/core/ vs docs/、改动行数、涉及模块的测试覆盖率。批量diff适合同质任务8个Agent各改一个模块的同类问题把8个diff按依赖顺序串起来一次审——上下文只装载一次审8个的成本约等于审3个。代价是diff之间会互相干扰视线只适合改动确实同构的场景。抽查策略是最后的兜底低风险任务池随机抽20%人工过配合抽查发现问题全池回炉的规则威慑力比覆盖率重要。纯抽查没有回炉规则等于放水。四种手段叠加后的效果可以量化假设自动验证过滤60%、分层再分流20%、剩余部分批量抽查压缩50%你的有效审查带宽从10个/天放大到约30个/天——最优并行度从5涨到15。降税的本质是给审查带宽装杠杆而不是硬扛。讲一个我应用这四条的真实改造。起点8个并行Agent我每天审8个diff周五必然积压第一节那次限流事故就发生在这个阶段。改造分三步走第一步上自动验证前置每个diff合并前强制跑pytestmypyruff红灯自动打回——这一步直接砍掉我60%的审查量大部分低级问题机器比我看得准第二步分层改动只涉及docs/和tests/的diff走抽查通道src/core/的走必审通道——又分流两成第三步把剩余的同质diff比如同一批补充类型标注任务批量串审。三步之后我的实际人审量从每天8个降到2.5个审查质量回升到事故前水平第八节那张准入清单里的审查带宽一栏从勉强及格变成富余。回头看这次改造没有增加任何审查人力改变的是审查的时序和分层——把人的注意力从第一道闸后撤到最后一道闸让机器挡在前面。第5章讲验证器时说过验证器是循环的脊椎在编排层面这句话的对应版本是自动验证是并行度的扩容器。五、审查带宽的自我测量公式里的审查能力不能拍脑袋得测。两种测量路径一个测人、一个测Agent。测人从自己的PR历史回溯。翻最近一个月你认真review过的PR数认真看了超过10分钟或留了实质意见除以工作日。数据在自己身上不用猜。我第一次测的时候以为自己一天能审8个实测4.6个——自评永远高估因为人会记住状态好的那天遗忘状态差的一周。测Agent从运行日志统计产出速度。第2节的全字段日志这时候派上用场——每个worker的开始结束时间戳都在里面统计一段周期内单个Agent的diff产出节奏就是产出速度。把测量写成代码# src/ai_loop_course/bandwidth_meter.py从worker日志反推产出速度代入公式算最优并行度importmathfrompydanticimportBaseModelclassWorkerStat(BaseModel):单个worker一段周期内的产出统计name:strdiffs_per_day:floatdefoptimal_parallelism(review_capacity:float,workers:list[WorkerStat])-int:N ceil(审查能力 / 平均产出速度)avg_outputsum(w.diffs_per_dayforwinworkers)/len(workers)nmath.ceil(review_capacity/avg_output)returnnif__name____main__:# 日志统计出的各worker日产示例5个worker各跑了一周workers[WorkerStat(namefworker-{i},diffs_per_day2.1)foriinrange(5)]my_capacity4.6# 自我测量一天认真审4.6个noptimal_parallelism(my_capacity,workers)print(f审查能力{my_capacity}/天 平均产出2.1/天 → 最优并行度 N{n})真实控制台输出审查能力4.6/天 平均产出2.1/天 → 最优并行度 N3注意这个结果和第一节那次事故的对照我的实测带宽4.6个/天2.1个/天的Agent产出速度最优并行度是3——而我当时开了8个。公式回看超载近3倍难怪审查质量崩了。两个参数的测量都要注意口径审查能力用认真审的定义走过场的合并不算数产出速度用被审通过的diff被打回重做的算0.5个。口径松一档结论错一截。测量还有个常见陷阱用高峰期的数据外推。状态最好的那个下午审了6个diff不代表日均能力是6——用一周总量除以天数才是真实吞吐。我在自测时第一版就拿周三的数字当了日均算出来的并行度虚高了一倍差点重演超载事故。测量要用长周期抹平波动和股票不该用单日涨幅估值是同一个道理。六、编排税的隐性形态交接成本审查队列是编排税最显性的形态还有两个隐性的加在一起才是全貌。交接成本N个Agent的产出要拼成一个整体拼接处的对齐工作接口一致、风格统一、命名冲突随N增长。3个工人的交接面是3条两两之间5个工人是10条8个工人28条——交接面按N(N-1)/2增长比线性快得多。这就是为什么Swarm模式在表格里协调风险标了高无主管的网状结构里每个节点都可能要和其他所有节点对齐。心智成本你维护的不是一套系统而是N1套N个工人加1个编排层。每个工人的提示词版本、工具白名单、失败模式都在你的认知负载里。第8节讲的调试地狱就是这项成本集中爆发的时候。税种形态增长规律主要杠杆审查税人工Review队列随N线性自动验证前置/分层交接税拼接对齐工作随N×(N-1)/2任务边界切干净心智税系统认知负载随N近似线性标准化worker配置三税合算的推论并行度的甜点区通常比直觉小。直觉觉得8个Agent总比4个强三税合算下第5个Agent开始就在为负贡献打工。这也是第3节并发预算和本节公式给出一致答案4~5个的原因——两套推导殊途同归时这个数就值得钉在配置文件里。七、把并行度写进配置而不是写进野心最后一个实践建议最优并行度不该是每次开跑前的临场发挥而该是配置文件里一个有出处的数字。# config.py 里的一段REVIEW_CAPACITY_PER_DAY4.6# 2026-03自测一个月认真审的PR数/工作日AGENT_OUTPUT_PER_DAY2.1# 2026-03日志统计worker平均日产diffMAX_PARALLEL3# ceil(4.6/2.1)三税合算后的保守值三个数字三个注释数字可复算、出处可追溯、变化可审计。下季度你觉得审得快了重测一次改第一个数换了更快的模型从日志重算第二个数——第三个数永远是被推导出来的而不是被感觉出来的。配置化还有个组织意义团队新人看到这行配置和注释五分钟理解并行度为什么是3而不是30。编排税的知识不进配置就会在每个新成员身上重缴一遍。再补一句季度复审的节奏三个数字每季度重测一次审查能力和产出速度都会漂移——人熟练了、模型升级了、任务类型变了重测后同步更新配置和注释里的日期。配置不是刻在石头上的戒律是带时间戳的快照——数字会过时但数字出处日期的组合永远可审计。踩坑提示并行度配置要配护栏光写注释不够。我的编排器入口处有一行硬校验assert n_workers MAX_PARALLEL超了直接拒绝启动。没有护栏的配置只是建议赶工期的时候谁都想这次特殊开8个——特殊两次事故一次。小结核心要点编排税worktree解决机械冲突审查带宽限流——每开一个Agent就多一份必须被人审的diff税随并行度线性增长不可豁免公式N ceil(审查能力/产出速度)超发并行度买到的是积压不是速度超载还会系统性压低单份审查质量排队模拟实证过载后吞吐被审查端焊死8、12个Agent已审都停在45~46期末队列从4膨胀到67最长等待从3小时涨到20小时四种降税手段自动验证前置最值钱验证器是人力杠杆、分层审查风险导向预算、批量diff同质任务、抽查回炉兜底威慑。下节预告自己写编排要踩这么多坑官方有没有现成方案下一节横向对比第10章第7节《Agent Teams官方机制对比》——Claude Code和Codex的多智能体配置方式、交接玩法以及用官方还是自己写的判定线。如果觉得本文对你有帮助欢迎点赞、收藏、关注三连本系列持续更新中关注不迷路~文章编号第10章第6节 | 总进度73/120 | 预计阅读时间12分钟