就是第一个，你给大家讲讲，结合一点上下文

回复 joye：好，我按第一篇 Addy Osmani 的《The Orchestration Tax》讲，并接上前面我们聊的「主 agent 收敛入口、降低用户面对的 agent 数量」这条线。我刚把原文抓下来看过，下面以原文为准。 先说这篇文章的起点。Osmani 在 Google I/O 的一个圆桌上被问到，开发者应该带走什么、改变什么，他的回答是「感觉很忙不等于很有产出」。他说你可以同时跑 20 个 agent，然后感觉自己非常忙，但这并不等于 20 个 agent 的产出。圆桌上 Richard Seroter 给这个问题起了名字，叫 orchestration tax，也就是编排税。Osmani 的判断是：这不是纪律问题，是架构问题。 他的核心论点是一个不对称。启动一个 agent 很便宜，就是敲一句 prompt。但闭环很贵：要有人检查结果是否正确，还要和其他 agent 改过的东西对齐，最后合进代码库。这个「有人」只能是你，而你只有一个。他把这件事类比成并发系统：你就是那个串行资源，好比 Python 的 GIL。几个 agent 可以同时跑，但只要碰到真正需要理解架构、解决 merge 冲突的判断，就得抢同一把锁，而锁只有一把，在你手上。 他还引用了 Amdahl 定律来说明上限。并行加速能到多少，取决于串行部分占多少。在 agent 开发里，串行部分就是判断。开 8 个 agent 并不会让你的判断变快，只会让等着你判断的队列更长。这是一个老的性能工程常识：优化的如果不是瓶颈，吞吐量不会提高，只会堆出更多排在瓶颈前面的未完成工作。agent 的产出再多，系统吞吐也只等于 review 这一步的吞吐。 关于累，他也讲得很具体。每次切回去看某个 agent，都要付一次上下文切换的成本，相当于把脑子里的东西清空，再从冷启动重新加载。5 个 agent 不是同一个工作量做五遍，而是 5 次冷加载，加上后台一个一直在担心该去看哪个 agent 的进程。他说，靠咬牙硬扛改不了结构性限制，税会照样被收，只是会以别的形式出现：review 越来越浅，或者出现他说的「认知投降」，因为自己形成判断太费注意力，干脆直接接受 agent 的代码。所以要么主动付这个税，要么让它悄悄毁掉你对自己系统的理解。 他给的应对办法有五条。第一，按 review 速度而不是 UI 允许的数量决定并行数，把 agent 数量当成生产者，把你的 review 速率当成消费者，加上背压。对大多数人来说，这个数字是个位数的低位。第二，把任务分两堆：一堆是可以独立委派、最后只需要你把关的隔离工作；另一堆是判断本身就是工作的复杂任务，比如诡异的 bug 或架构设计。最大的错误是把第二堆也并行化，那只会让锁抖动，结果更糟。第三，批量 review，一次看 4 个 agent 的产出，比每看一个就切走、回来再冷启动便宜得多。第四，只把锁花在判断上，让机器自己验证能验证的部分，比如写通过的测试、生成截图，人只看剩下那 20%。第五，保护串行时间，关键判断要用最好的时段，不要用 agent 之间的零碎空档。有时候最高杠杆的动作，是合上满屏 agent 的电脑，把一个问题完整想清楚。 放回我们前面聊的上下文，这篇文章和我们的讨论其实是同一个问题的两面。前面说的主 agent 收敛入口、用文件交接、登记簿、验收闸门，目标是让用户少面对 agent 数量，这在 Osmani 的框架里是把「编排」这部分的 overhead 尽量从人身上拿走。但文章也提醒了一个容易忽略的地方：主 agent 做的是拆分、派发、汇总，它能替你省掉的是盯进度和整理结果的工作，省不掉的是判断。验收闸门如果由主 agent 自己打勾，那闸门就变成了机器给机器放行，Osmani 说的「只把锁花在判断上」就落空了。所以更稳的做法是：机器负责把能验证的部分先验证掉，比如测试、lint、截图对比；人只在两处出手，一是拆任务的时候判断哪些是第一堆、哪些是第二堆，二是对验收标准里真正需要判断的那部分做最终把关。 另外我前面说「主 agent 变成单点」，这一点和 Osmani 的串行资源论其实是一回事。主 agent 的拆分判断错了，后面所有执行都白干，这就是把整个系统的吞吐绑在一个串行节点上。区别在于，Osmani 讲的是人的带宽，而我们讲的是主 agent 的判断质量，两者都要靠背压和分堆来限制。 如果要给群里讲一句话版本：agent 的启动成本趋近于零，闭环成本没有，而闭环上只有你一个人。所以设计 agent 工作流，本质上是在设计你自己的注意力怎么被调度。原文在这里：https://addyosmani.com/blog/orchestration-tax/