编者按:当 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 个。

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

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

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