现在启动更多 AI agent 已经很容易了。然而，运行更多 agent 并不意味着「你」也变多了。你的认知带宽不会并行化。真正用来引导它们、合并它们改动的所有判断，最终仍然必须经过一个串行处理器，而那个处理器就是你自己。所谓编排税，本质上就是你忘记这一点时要付出的代价。真正的修复方式，是像设计任何并发系统一样，开始设计你自己的注意力。
我参加了 Google I/O 上的一场圆桌讨论，和 Richard Seroter、Aja Hammerly、Ciera Jaspan 一起聊当下的软件工程是什么样子，以及它可能会如何演进。接近结尾时，Richard 问我们：开发者离开会场后，应该改变的一件事是什么。我说出了这几个月里一直在反复琢磨的那件事：感觉很忙，绝对不等于真的有产出。你可以运行 20 个 agent，并且感觉自己忙到不行。但那并不是 20 个 agent 份量的已交付工作。
在那次讨论稍早的时候，Richard 给这个问题起了一个名字。「你提到了编排税，」他说，「你不可能只靠自己的大脑成功管理二十个 agent。」他说得完全正确。我想把这个概念好好展开，因为这不是一个纪律问题，而是一个架构问题。
那场圆桌里我一直反复想起的一句话，是我几乎随口说出的：运行多个 agent，并不意味着有更多个你。
人们没有计入成本的不对称性
agent 工作流里存在一种隐藏的不对称。启动一个 agent 非常便宜。它只是一次按键，或者一句 prompt。但把 agent 的工作闭环收回来一点也不便宜。总得有人检查返回的内容是否正确，并且把它和其他 agent 动过的东西调和起来。那个人就是你。而且你只有一个。
上个月我在 Your parallel Agent limit 里写过其中一部分，主要是关于那种不知道哪条并行线程正在悄悄失败的背景焦虑。这篇文章想谈的是这个成本背后的结构。当你开始把 agent 开发看作一个并发系统时，你会意识到人类只是系统里的一个组件。那个缓慢的串行组件。
你是那个单线程资源
如果你写过并发代码，你其实已经有了正确的直觉。只是你一直把它用错了系统位置。
Python 有全局解释器锁（Global Interpreter Lock，GIL）。你可以启动任意多线程，但同一时间只有一个线程能执行 Python 字节码，因为它们必须先拿到这把锁。你就是你的 AI agent 的 GIL。它们都可以同时运行。但只要它们的工作需要真正理解架构，或者需要解决合并冲突，那份工作就必须获取这把锁。锁只有一把。它在你手里。
Amdahl 定律把这一点说得非常精确。并行化能带来的加速，被仍然保持串行的工作比例所限制。如果流水线里有一大块无法并行化，那么无论你往里面扔多少核心，都会撞到硬上限。在 agent 开发里，串行部分就是判断。启动 8 个 agent 不会加速你的判断时间。它只会让等待你判断的队列变得更深。
这是一个古老的性能工程事实，但仍然会让人意外：优化非瓶颈部分不会提升吞吐量。你只是让堆在瓶颈前面的未完成工作变多。增加 agent 优化的是那个从来不是约束的部分。真正的约束是 review 步骤，而你这个系统的吞吐量，恰好等于那个步骤的吞吐量。编排税就是 agent 产出和你实际能合并的内容之间的结构性落差。它发生在你让一个单线程资源去负责一个并发系统的时候。
硬扛修不好结构性限制
在圆桌上我说，我从来没有像现在这样觉得自己的工具让我更有产出，但我也从来没有像现在这样疲惫。这两半都完全真实，而且原因相同。
这种疲惫有一个非常具体的来源：它就是把一个没有余量的串行处理器持续跑到 100% 时的感受。每次你回头检查一个离开了一阵子的 agent，都要支付一次上下文切换成本。你清空大脑，再从冷启动状态重新加载另一个上下文。CPU 用微秒完成这件事，架构师们仍然会努力避免它。你用分钟完成，而且永远无法完美地重新加载上下文。五个 agent 不是一倍工作量重复五次。它是五次冷加载，再加上一个一直在后台担心你该检查哪个 agent 的大脑进程。
你不能只靠更努力来修复结构性限制。这笔税无论如何都会被支付。如果你试图硬扛，它就会表现为浅层 code review，或者表现为认知投降：你直接接受 agent 的代码，因为形成自己的判断需要你已经没有的注意力。你要么主动支付这笔税，要么让它悄悄摧毁你对自己系统的理解。
设计你的注意力
所以你必须把自己的注意力当成它本来的样子：一种稀缺的串行资源。你不会在设计分布式系统时不认真思考瓶颈。也请给自己的大脑同等的尊重。
一些对我来说真的站得住脚的做法：
按 review 速率扩展 agent 队伍，而不是按 UI 能力扩展。一个好的并发系统会使用背压，防止队列无限增长。生产者会慢下来，以匹配消费者。你的 agent 数量是生产者，你的 review 速率是消费者。合适的并行 agent 数量，是你真正能够认真 code review 的数量。对大多数人来说，这只是一个很低的个位数。AI 工具当然很乐意让你启动 20 个，但那只是一个 UI 功能。
给工作分类。Richard 问我怎么在这些任务中导航时，我提到过这一点。我会把任务分成两堆。一堆是隔离性好的工作，我愿意委托给在 Cloud 后台运行的 agent。它们可以异步运行，通常只需要我在最后一道门那里介入。另一堆是复杂任务，在这些任务里，判断本身就是工作。比如诡异的 bug，或者架构设计。最大的错误，是试图并行化第二堆任务。同时做多个复杂任务不会扩展你的产出。它只会让那把锁剧烈抖动，最后所有结果都变差。
批量 review。每次上下文切换都会让你付出很高成本。一次坐下来同时 review 4 个 agent，比检查一个、离开去做别的事、再冷启动回来要便宜得多。给 agent 更长一点的绳子。让工作稍微积累起来，然后按批处理它。
只把锁花在判断上。不要把大脑浪费在机器自己能验证的事情上。让 agent 写一个通过的测试，或者生成一张截图。它们可以自己证明无聊的 80%，这样你只需要把稀缺的注意力花在真正需要人类的那 20% 上。
保护你的串行时间。瓶颈需要你最好的时间，而不是夹在 agent 检查之间剩下的几分钟。有时候最高杠杆的动作，是完全停止编排，合上那台跑满 agent 的电脑，只用完整持有锁的状态，认真思考一个单独的问题。编排不是真正的工作。它是围绕工作的开销。
Aja 指出，架构已经是现在最紧迫的技能：知道什么适合放进一个 agent，什么对它来说太多。我想补充的是，你也是这个系统里的一个组件。你的注意力有一个已知的、很低的串行吞吐量。系统要么尊重这个数字，要么通过暗中降低你的标准来绕过它。
忙碌 vs 产出
这一点真的很重要，因为失败模式对你来说是不可见的。二十个正在运行的 agent 会给你一种生产力爆棚的感觉。仪表盘是满的，所有东西都在动。但这种感觉和真正把好代码交付到 main 是脱钩的。你可以忙到极限，却几乎没有产出。从内部感受上看，它们一模一样。
Ciera 提到了 Margaret-Anne Storey 关于债务的研究。我们谈到了技术债和认知债。未支付的编排税，会让你同时积累这两种债。你合并了没有认真读过的东西。你对代码库的心智模型彻底过期。这些都不会出现在今天的仪表盘上。它们会在生产环境出问题时出现：你看着系统，突然意识到自己已经完全不知道它是怎么工作的了。
所以真正的 takeaway 是这个：启动 agent 不是技能。谁都可以运行 20 个。
真正的技能，是围绕那个无法被复制、无法被并行化的串行资源来设计系统。那个资源就是你的注意力。
像设计任何你在生产环境中依赖的东西一样，设计它。