原文标题：The Orchestration Tax

原文作者：Addy Osmani

编译：Peggy

编者按：当 AI Agent 变得越来越便宜、越来越容易调用，软件开发正在进入一个新的阶段：问题不再是能不能启动更多 Agent，而是人类是否还有足够的注意力去管理、判断和合并它们的产出。

这篇文章提出了一个很有启发性的概念——「编排税」。启动 Agent 的成本很低，只需要一句 Prompt 或一次点击；但真正昂贵的是后续环节：检查结果是否正确、理解它对系统架构的影响、处理不同 Agent 之间的冲突，并最终决定哪些代码可以进入主分支。这些工作无法被简单并行化，仍然要回到同一个串行资源：人的判断力。

作者将开发者比作 AI Agent 系统里的「GIL」，即那个限制并发系统最终吞吐量的单线程锁。多个 Agent 可以同时运行，但只要进入架构判断、代码审查和冲突合并阶段，就必须重新经过开发者的大脑。于是，Agent 越多，不一定意味着产出越高，也可能只是让待审查的任务队列更长，让开发者陷入更频繁的上下文切换和认知疲劳。

这也是当前 AI 编程工具热潮中容易被忽视的一点：效率感和真实生产力并不总是一回事。一个满屏运行的 Agent 仪表盘，会制造出「高产」的错觉；但如果开发者没有真正理解、审查和整合这些改动，系统最终积累的可能不是生产力，而是技术债和认知债。

因此，本文真正讨论的不是「如何使用更多 Agent」，而是「如何围绕人的注意力重新设计工作流」。在 Agent 时代，关键能力不只是会提问、会分派任务，而是知道哪些任务可以交给机器并行处理，哪些任务必须保留给人类判断；什么时候应该批量 review，什么时候应该停止编排，重新专注于一个核心问题。

AI 正在扩大软件生产的并发能力，但人的注意力仍然是系统中最稀缺、最不可复制的资源。真正成熟的 Agent 工作流，不是把所有任务都扔给机器，而是像设计生产系统一样，认真设计自己的注意力架构。

以下为原文：

现在，启动更多 AI Agent 已经变得很容易。但更多 Agent 同时运行，并不意味着「你」也变多了。你的认知带宽无法并行化。所有真正用于引导它们、判断结果、合并修改的判断力，最终仍然必须经过同一个串行处理器——也就是你自己。

所谓「编排税」，本质上就是你忘记这一点后所付出的代价。而唯一真正的解法，是像设计任何并发系统一样，开始设计你自己的注意力。

我之前在 Google I/O 上参加了一场圆桌讨论，和 Richard Seroter、Aja Hammerly、Ciera Jaspan 一起聊软件工程现在的样子，以及它接下来可能如何演化。接近尾声时，Richard 问我们：开发者听完之后，最应该带走并改变的一件事是什么？

我说出了这几个月一直在反复思考的一点：感觉自己很忙，绝不等于真的有产出。你可以同时运行 20 个 Agent，并且感觉自己忙得不可开交。但这并不等于你交付了 20 个 Agent 对应的工作量。

在那场对话早些时候，Richard 给这个问题起了一个名字。他说：「你刚才讲到的，其实就是编排税。你不可能在自己的脑子里成功管理 20 个 Agent。」

他说得完全正确。我想把这个概念更完整地拆开讲，因为这并不是一个自律问题，而是一个架构问题。

那场圆桌里有一句我几乎是随口说出的话，后来一直萦绕在我脑海里：运行多个 Agent，并不意味着世界上多了一个你。

人们没有计入的非对称性

Agent 工作流里存在一种隐藏的非对称性。

启动一个 Agent 非常便宜。你只需要敲一下键盘，或者写一句 Prompt。但完成 Agent 的闭环一点也不便宜。总得有人检查它返回的结果是否正确，并把它和其他 Agent 改动过的内容重新协调起来。

这个人就是你。而你只有一个。

上个月，我在《你的并行 Agent 上限》里写过这个问题的一部分，主要讨论的是那种环境式焦虑：你不知道哪条并行线程正在悄悄失败。这篇文章想谈的是这种成本背后的结构。

当你开始把 Agent 开发看作一个并发系统时，你会意识到，人类本身只是这个系统里的一个组件。一个很慢的串行组件。

你就是那个单线程资源

如果你写过并发代码，你其实已经具备理解这个问题的直觉。只是你过去把这种直觉用错了地方。

Python 有全局解释器锁，也就是 GIL。你可以创建任意多线程，但同一时间只有一个线程能执行 Python 字节码，因为它们都必须先拿到这把锁。

你就是你的 AI Agent 的 GIL。

它们都可以同时运行。但只要它们的工作需要真正理解系统架构，或者需要解决合并冲突，就必须先拿到这把锁。而这把锁只有一把，由你持有。

阿姆达尔定律把这件事说得非常精确：并行化带来的加速上限，取决于工作中仍然必须串行完成的那一部分。如果你的流程里有很大一块无法并行化，那么无论你投入多少核心，最终都会撞上一个硬上限。

在 Agent 开发里，这个串行部分就是判断力。

启动 8 个 Agent 并不会加速你的判断时间。它只会让等待你处理的队列变得更长。

这是性能工程里一个很古老的事实，但很多人依然会被它惊讶到：优化非瓶颈部分，并不会提升整体吞吐量。你只是在瓶颈前面堆起更多尚未完成的工作。

增加 Agent 优化的是那个本来就不是约束的部分。真正的约束是 review 环节，而整个系统的吞吐量，恰好就等于这个环节的吞吐量。

编排税，就是 Agent 生产能力与你实际能够合并的内容之间的结构性缺口。它发生在你让一个单线程资源去管理一个并发系统的时候。

硬扛解决不了结构性上限

在那场圆桌上，我说过一句话：我从未像现在这样觉得自己的工具如此高效，但我也从未像现在这样疲惫。

这两种感受都完全真实，而且它们来自同一个原因。

这种疲惫有一个非常具体的来源：它就是把一个串行处理器持续压到 100%、且不给任何余量时的感觉。

每次你回头查看一个已经离开你注意力范围的 Agent，你都要支付一次上下文切换成本。你必须清空大脑，然后从零开始重新加载另一个语境。

CPU 可以在微秒内完成这件事，即便如此，架构师仍然会尽量避免频繁切换。而你要花几分钟才能完成，而且永远无法完美恢复上下文。

5 个 Agent 并不是 1 倍工作量重复 5 次。它是 5 次冷启动式的上下文重载，再加上一个在后台持续运行的大脑进程，不停担心你现在到底该去检查哪个 Agent。

你不能靠「更努力」来解决一个结构性限制。这笔税总是要付的。

如果你试图硬扛，它最终会以另一种形式出现：要么是代码 review 变得越来越浅，要么是你进入一种「认知投降」状态——因为形成自己的判断太消耗注意力，你干脆直接接受 Agent 写出来的代码。

你要么主动支付这笔税，要么任由它在暗处慢慢摧毁你对自己系统的理解。

像设计系统一样设计你的注意力

所以，你必须把自己的注意力当作一种稀缺的串行资源来对待。

你不会在设计一个分布式系统时完全不考虑瓶颈。那么，也请给你的大脑同样的尊重。

以下是一些对我来说真正有效的方法：

按照 review 能力扩张 Agent 队伍，而不是按照 UI 能力扩张。

一个好的并发系统会使用反压机制，避免队列无限增长。生产者要放慢速度，以匹配消费者的处理能力。

你的 Agent 数量就是生产者，你的 review 能力就是消费者。正确的并行 Agent 数量，应该是你能够认真完成代码 review 的数量。对大多数人来说，这通常只是一个很低的个位数。

AI 工具当然会很乐意让你启动 20 个 Agent，但那只是一个 UI 功能，不代表你真的有能力管理它们。

给任务分类。

Richard 问我怎么处理这件事时，我提到过这个方法。我会把任务分成两堆。

第一堆，是相对独立的工作，我愿意交给在云端后台运行的 Agent。这些任务可以异步执行，通常只需要我在最后关口做一次把关。

第二堆，是复杂任务，真正的工作本身就是判断。比如一个很奇怪的 bug，或者一次架构设计。

最大的错误，就是试图把第二类任务也并行化。并行处理多个复杂任务，并不会扩大你的产出，只会让那把锁被反复争抢，最终所有结果都会变差。

批量 review。

每次上下文切换都会让你付出很高成本。一次性坐下来 review 4 个 Agent 的结果，要比先看一个、去做别的事、再冷启动回来继续看另一个便宜得多。

给 Agent 更长的牵引绳。让工作稍微积累一点，然后把它们作为一个批次来处理。

只把这把锁用在判断上。

不要把你的大脑浪费在机器可以自行验证的事情上。让 Agent 写出能通过的测试，或者生成截图。

让它们自己证明那 80% 枯燥但可验证的部分。这样，你稀缺的注意力只需要花在真正需要人类判断的 20% 上。

保护你的串行时间。

瓶颈需要你最好的时间，而不是你在几次 Agent 检查之间剩下的碎片时间。

有时候，最高杠杆的动作反而是完全停止编排：关掉那个塞满 Agent 的电脑，只专注思考一个问题，并在整个过程中牢牢持有那把锁。

编排不是真正的工作。它只是围绕工作产生的开销。

Aja 指出，架构能力现在已经成了最紧迫的技能：你需要知道什么任务适合放进一个 Agent，什么任务对它来说太大了。

我还想补充一点：你自己也是这个系统里的一个组件。你的注意力有一个已知的、很低的串行吞吐量。系统要么尊重这个数字，要么就会通过悄悄降低你的标准来绕过它。

忙碌不等于高产

这一点非常重要，因为这种失败模式对你本人来说几乎是不可见的。

20 个正在运行的 Agent 会给你一种「生产力爆棚」的感觉。仪表盘满满当当，所有东西都在动。但这种感觉和真正把高质量代码合并进主分支之间，已经脱钩了。

你可以忙到极限，却几乎没有真正产出。从内部体验上看，这两者几乎一模一样。

Ciera 提到了 Margaret-Anne Storey 关于债务的研究。我们聊到了技术债，也聊到了认知债。

没有支付的编排税，会让你同时积累这两种债务。

你合并了自己没有认真读过的东西。你对代码库的心智模型彻底过期。这些问题今天不会出现在仪表盘上。它们会在生产环境出故障时显现出来——那时你看着系统，突然意识到自己已经不知道它到底是怎么运行的了。

所以，真正的结论是：启动 Agent 不是能力。任何人都可以运行 20 个。

真正的能力，是围绕那个无法被克隆、无法被并行化的串行资源来设计系统。

这个资源，就是你的注意力。

像设计任何生产环境中依赖的关键组件一样，去设计它。

[原文链接]