多 Agent 协作工具越来越便宜，启动一个 Agent 只需要一句话。但 Addy Osmani 在 Google I/O 的一场小组讨论上指出了一个被忽视的悖论：跑更多 Agent，不代表你有更多的产出；你的认知带宽根本不能并行化。
这篇文章是他在 Google I/O 后对"编排税"（Orchestration Tax）这个概念的完整展开。
被忽视的不对称
启动 Agent 的成本极低——一个按键或一句话就够了。但关闭循环的成本一点都不低：总要有人检查返回的结果是否正确，把不同 Agent 改动的部分合并起来。这个人就是你自己，而你只有一个人。
Osmani 把这个现实比作 Python 的 GIL（全局解释器锁）：你可以 spawn 任意多个线程，但同一时刻只有一个能执行 Python 字节码，因为必须先抢到锁。在 Agent 工作流里，你就是那把锁。所有 Agent 可以同时跑，但当任何一项工作需要真正理解架构或解决合并冲突时，必须过你这关。
这直接引出了 Amdahl 定律在 Agent 场景的应用：并行化带来的加速比，受制于无法并行的串行部分。如果 pipeline 里有一大块工作没法并行化，不管扔多少核心上去都会有一个硬上限。对于 Agent 开发来说，这个串行部分就是判断力（judgment）。Spawn 8 个 Agent 并不会加速你的判断时间，只是让排队等判断的队列变得更深。
一个反直觉的性能事实
优化非瓶颈部分不会提升吞吐量，只会增加堆积在瓶颈前面的未完成工作量。这条古老的性能工程定律在 Agent 开发场景里被大多数人忽视了。
Osmani 的洞察是：大家都在用 Agent 优化那个从来没成为约束的步骤——代码生成本身。真正的约束是 review 步骤，而系统的吞吐量等于 review 步骤的吞吐量。编排税，就是 Agent 产出和你能实际合并的东西之间的结构性缺口。
这也解释了为什么很多人有这种感觉：工具效率高了，但人反而更累了。原因是——你的大脑这个串行处理器正在以 100% 的负荷跑着，没有任何弹性。
上下文切换的代价
每次你离开一个 Agent 去做别的事情，再回来时都要付出上下文切换成本：大脑从冷存储里重新加载一个完全不同的上下文。CPU 做这件事用微秒级时间，工程师们为此想尽办法避免。而人类做这件事要花几分钟，而且永远没法完美恢复。
Osmani 的估算：5 个 Agent 不等于 1 倍的工作量做 5 次，而是 5 次冷加载，加上一个一直在后台运行的脑内进程——不断担心"现在该检查哪个 Agent"。
真正有效的方法
Osmani 在实践中验证过的几条原则：
按审查速率扩展 Agent 数量，而不是按 UI 便利。好的并发系统会使用背压（backpressure），让生产者的速度匹配消费者的处理速度。你的 Agent 数量是生产者，审查速率是消费者。并行 Agent 的正确数量，是你能真正做好代码审查的数量。对大多数人来说这是个位数。
把任务分成两堆：一堆是可以委托给后台云 Agent 的隔离性工作，这些可以异步跑，只在最终关卡需要你；另一堆是判断力本身就是工作的复杂任务，比如奇怪的 bug 或架构设计。第二堆任务绝对不能并行化——同时做多个复杂任务不会提升产出，只会磨损那把锁。
批量审查。上下文切换的代价极高。一次性坐在那审查 4 个 Agent，比检查一个、离开做别的事、再冷加载回来要便宜得多。给 Agent 留足自由度，让工作先堆积一点，然后集中处理一批。
结论很简单：你得把自己的注意力当作它真正的样子——稀缺的串行资源。就像设计分布式系统时会认真考虑瓶颈在哪里一样，也给你的大脑同样的尊重。
原文为 Addy Osmani 在 Google I/O 小组讨论后的完整长文，中文翻译为编者根据原文结构重新组织。