企业官网建设流程全解析

第6节 编排税：你的审查带宽才是并行度上限

一句话总结：Osmani的orchestration tax——worktree消除机械冲突但审查吞吐限流；并行N=ceil(审查能力/产出速度)的估算公式；审查排队、批量diff、抽查策略。

本文导航

• 一、什么是编排税：一次真实限流事故
• 二、并行度估算公式
• 三、排队模拟：把审查瓶颈跑给你看
• 四、应对策略：四种降税手段
• 五、审查带宽的自我测量
• 六、编排税的隐性形态：交接成本
• 七、把并行度写进配置，而不是写进野心
• 小结

一、什么是编排税：一次真实限流事故

第3节的worktree解决了一类冲突：机械冲突——两个Agent改同一个文件、同一个分支互相覆盖。这类冲突有工程解，git替我们管好了。

但还有一类冲突没有工程解：认知冲突——5个Agent并行产出的5份diff，最终都要过你这双眼睛。你看diff的速度不会因为Agent跑得快而变快。

编排税 = 多Agent并行带来的额外审查负担 worktree解决了"机械冲突" 但没解决"审查瓶颈" 5个Agent并行产出 → 你还是要一个个Review 你的审查带宽 = 并行度上限

这张图就是本节的核心：左边的产出可以无限扩，右边的审查带宽是刚性的。中间的队列会无限堆积。这个概念Addy Osmani叫orchestration tax（编排税）——你为编排付出的隐性成本，不在token账单上，在你的注意力账户里。

为什么说它是"税"而不是"成本"？因为它随并行度线性增长且无法豁免：每开一个并行Agent，就多一份必须被人审查的diff。你可以在token上省钱（用便宜模型跑工人），可以在时间上省钱（并行），但审查这一步要么你付，要么质量付——没有第三条路。跳过审查的多智能体系统等于无人看守的无人车间，产出越快，废品越多。

排队论里有个经典公式可以佐证这个直觉：利特尔法则（L = λ × W），系统里的平均积压量等于到达速率乘以平均等待时间。套进我们的场景：diff到达速率（Agent产出）一旦超过服务速率（你的审查吞吐），等待时间W趋于无穷，积压L跟着爆炸。第二节的推演表格和第三节的模拟器，本质都是这个法则的数值化——数学早就把结论写好了，我们只是用Agent的语境重演了一遍。

我的一次真实限流事故

讲个真事，比公式有说服力。

上季度我给自己的仓库审计任务开了8个并行Agent（worktree隔离，一切正常）。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个/天）：

第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 logger=logging.getLogger("review_sim")logger.setLevel(logging.INFO)_fmt=logging.Formatter("%(asctime)s %(levelname)s %(message)s","%Y-%m-%d %H:%M:%S")forhin(logging.StreamHandler(),TimedRotatingFileHandler("logs/review_sim.log",when="MIDNIGHT",interval=31,backupCount=12,encoding="utf-8")):h.setFormatter(_fmt)logger.addHandler(h)random.seed(42)# 固定随机种子，结果可复现classSimConfig(BaseModel):n_agents:int# 并行Agent数produce_per_hour:float=0.25# 单Agent小时产出（2个/8小时工时）review_per_hour:float=1.25# 审查吞吐（10个/8小时工时）hours:int=40# 模拟时长（一周工时）classSimResult(BaseModel):n_agents:intproduced:intreviewed:intfinal_queue:intmax_wait_hours:floatdefsimulate(cfg:SimConfig)->SimResult:"""逐小时离散模拟：产出进队、审查出队，记最长等待"""queue:list[float]=[]# 元素=入队时刻produced=reviewed=0# 记账在事件发生处累加（别在期末快照）max_wait=0.0forhourinrange(cfg.hours):arrivals=sum(1for_inrange(cfg.n_agents)ifrandom.random()<cfg.produce_per_hour)queue.extend([float(hour)]*arrivals)produced+=arrivals# 吞吐1.25个/小时 = 每小时保底审1个，另有25%概率多审1个served=1+(1ifrandom.random()<cfg.review_per_hour-1else0)whilequeueandservedandqueue[0]<=hour-0.5:max_wait=max(max_wait,hour-queue.pop(0))reviewed+=1served-=1returnSimResult(n_agents=cfg.n_agents,produced=produced,reviewed=reviewed,final_queue=len(queue),max_wait_hours=max_wait)if__name__=="__main__":fornin(3,5,8,12):r=simulate(SimConfig(n_agents=n))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小时

数字会说话：

1. 过载后已审数被焊死：8个和12个Agent的已审数都停在45、46——到达速率一旦超过服务速率，系统吞吐就被审查端钉死在1.25个/小时，多开的Agent纯粹在给队列增产；而3个、5个Agent时已审数跟着产出走（31、46），说明审查带宽还有余量，瓶颈在产出端；
2. 队列在临界点后线性膨胀：1→4→40→67，从5个Agent到8个Agent跨过临界点，期末队列翻十倍——过载区里每多开一个Agent，一周多积压约7个diff；
3. 最长等待从3小时涨到20小时：8个Agent时一个diff要在队列里躺20个小时才被审到——到那时代码早改样了，审它等于考古。

模拟还偏乐观了：真实审查吞吐不是恒定的（人下午会累、会被会议打断），真实diff复杂度也不均匀。但方向性结论稳固：过载并行买到的是积压，不是速度。

踩坑提示：写这类离散模拟时我犯过一个错——把produced记成期末队列长度（期末快照），跑出来的"产出"忽大忽小差点让我怀疑人生。离散模拟的计数器一定要在事件发生处累加（produced += arrivals），期末快照只能拿到存量拿不到流量，存量加流量才是产出。这是写一切模拟和监控的通用教训：流量在事件点计数，存量在时点快照。

四、应对策略：四种降税手段

审查带宽刚性，不等于只能躺平。四条策略按性价比排序：

自动验证前置是四条里最值钱的，因为它把审查的筛选工作交给了机器：每个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合并前强制跑pytest+mypy+ruff，红灯自动打回——这一步直接砍掉我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_output=sum(w.diffs_per_dayforwinworkers)/len(workers)n=math.ceil(review_capacity/avg_output)returnnif__name__=="__main__":# 日志统计出的各worker日产（示例：5个worker各跑了一周）workers=[WorkerStat(name=f"worker-{i}",diffs_per_day=2.1)foriinrange(5)]my_capacity=4.6# 自我测量：一天认真审4.6个n=optimal_parallelism(my_capacity,workers)print(f"审查能力={my_capacity}/天 平均产出=2.1/天 → 最优并行度 N={n}")

真实控制台输出

审查能力=4.6/天 平均产出=2.1/天 → 最优并行度 N=3

注意这个结果和第一节那次事故的对照：我的实测带宽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模式在表格里"协调风险"标了高：无主管的网状结构里，每个节点都可能要和其他所有节点对齐。

心智成本：你维护的不是一套系统而是N+1套（N个工人加1个编排层）。每个工人的提示词版本、工具白名单、失败模式都在你的认知负载里。第8节讲的"调试地狱"就是这项成本集中爆发的时候。

三税合算的推论：并行度的甜点区通常比直觉小。直觉觉得"8个Agent总比4个强"，三税合算下，第5个Agent开始就在为负贡献打工。这也是第3节并发预算和本节公式给出一致答案（4~5个）的原因——两套推导殊途同归时，这个数就值得钉在配置文件里。

七、把并行度写进配置，而不是写进野心

最后一个实践建议：最优并行度不该是每次开跑前的临场发挥，而该是配置文件里一个有出处的数字。

# config.py 里的一段REVIEW_CAPACITY_PER_DAY=4.6# 2026-03自测：一个月认真审的PR数/工作日AGENT_OUTPUT_PER_DAY=2.1# 2026-03日志统计：worker平均日产diffMAX_PARALLEL=3# ceil(4.6/2.1)，三税合算后的保守值

三个数字三个注释：数字可复算、出处可追溯、变化可审计。下季度你觉得审得快了，重测一次改第一个数；换了更快的模型，从日志重算第二个数——第三个数永远是被推导出来的，而不是被感觉出来的。

配置化还有个组织意义：团队新人看到这行配置和注释，五分钟理解并行度为什么是3而不是30。编排税的知识不进配置，就会在每个新成员身上重缴一遍。

再补一句季度复审的节奏：三个数字每季度重测一次（审查能力和产出速度都会漂移——人熟练了、模型升级了、任务类型变了），重测后同步更新配置和注释里的日期。配置不是刻在石头上的戒律，是带时间戳的快照——数字会过时，但"数字+出处+日期"的组合永远可审计。

踩坑提示：并行度配置要配护栏，光写注释不够。我的编排器入口处有一行硬校验：assert n_workers <= MAX_PARALLEL，超了直接拒绝启动。没有护栏的配置只是建议，赶工期的时候谁都想"这次特殊，开8个"——特殊两次，事故一次。

小结

核心要点：

1. 编排税：worktree解决机械冲突，审查带宽限流——每开一个Agent就多一份必须被人审的diff，税随并行度线性增长不可豁免；
2. 公式：N = ceil(审查能力/产出速度)，超发并行度买到的是积压不是速度，超载还会系统性压低单份审查质量；
3. 排队模拟实证：过载后吞吐被审查端焊死（8、12个Agent已审都停在45~46），期末队列从4膨胀到67，最长等待从3小时涨到20小时；
4. 四种降税手段：自动验证前置（最值钱，验证器是人力杠杆）、分层审查（风险导向预算）、批量diff（同质任务）、抽查+回炉（兜底威慑）。

下节预告

自己写编排要踩这么多坑，官方有没有现成方案？下一节横向对比：第10章第7节《Agent Teams官方机制对比》——Claude Code和Codex的多智能体配置方式、交接玩法，以及"用官方还是自己写"的判定线。

如果觉得本文对你有帮助，欢迎点赞、收藏、关注三连！
本系列持续更新中，关注不迷路~

文章编号：第10章第6节 | 总进度：73/120 | 预计阅读时间：12分钟