核心思想
启动一个智能体很廉价，但给它”收尾”（审查、合并、与其他智能体对齐）很贵——而这一切判断都得挤过唯一的串行处理器：你。这就是编排税。作者借 Python GIL、阿姆达尔定律和背压等并发概念论证：并行智能体的正确数量，等于你能认真审查的数量；真正的技能不是堆智能体，而是把注意力当作稀缺的串行资源去”架构”它——否则你会同时欠下技术债与认知债。
如今多开几个 AI 智能体太容易了。但是，跑着更多的智能体并不意味着多出了几个”你”——你的认知带宽是不会并行的。真正去引导它们、把它们改出来的东西合并到一起，所有这些判断，最终都得经过那唯一的串行处理器，也就是你。所谓编排税，本质上就是你忘了这一点之后要付的代价；而唯一真正有效的解法，是开始像设计任何并发系统那样，去设计你自己的注意力。
我在 Google I/O 上参加了一场圆桌讨论，同台的还有 Richard Seroter、Aja Hammerly 和 Ciera Jaspan，我们聊了聊软件工程当下是什么样子、未来又会怎么演变。临近尾声时，Richard 问我们：有没有哪一件事，是开发者应该带回去、并且换种做法去做的？我说了那个我心里盘桓了好几个月的念头：**忙碌的感觉绝对不等于真正的高产**。你可以同时跑 20 个智能体，忙得脚不沾地。但那并不等于交付了 20 个智能体那么多的成果。
早些时候那场对话里，Richard 给这个问题起了个名字。“你刚才说到了编排税，“他说，“你没办法在自己脑子里成功管理二十个智能体。“他说得太对了。我想把这个想法好好拆开讲讲，因为它不是一个自律的问题，而是一个架构的问题。
那场圆桌上有一句我几乎是脱口而出的话，我一直在反复琢磨：跑多个智能体，并不意味着多出了几个你。
人们没有算进去的那种不对称
智能体工作流里藏着一种不对称。启动一个智能体非常廉价，无非是敲一下键盘，或者写一句提示词。但要给一个智能体”收尾”——把闭环闭上——可一点都不便宜。总得有人去检查它返回的东西对不对，还得把它和其他智能体动过的地方重新对齐、捋顺。那个人就是你。而你只有一个。
上个月我写过这件事的一个侧面，那篇《你的并行智能体上限》，主要谈的是那种弥散的焦虑——你不知道哪一条并行的线程正在悄无声息地崩掉。而这篇文章谈的，是那份代价底下的”形状”。当你开始把智能体开发看作一个并发系统，你就会意识到：人只是这个系统里的一个组件。而且是那个慢吞吞的、串行的组件。
你就是那个单线程资源
只要你写过并发代码，你其实早就有了对的直觉，只是一直把它对准了系统里错误的那部分。
Python 里有个全局解释器锁（GIL）。你想开多少个线程都行，但同一时刻只有一个线程能执行 Python 字节码，因为它们必须先拿到那把锁。在你的 AI 智能体面前，你就是那个 GIL。它们可以一起跑，但只要它们当中任何一个的工作真正需要对架构的理解、或者需要解决合并冲突，这份工作就得去抢那把锁。锁只有一把。攥在你手里。
阿姆达尔定律把这件事讲得无比精确：你靠并行化拿到的加速比，会被那部分始终串行的工作所封顶。如果你流水线里有一大块没法并行，那么无论你往上堆多少个核心，最终都会撞上一道硬天花板。在智能体开发里，那个串行的比例就是判断。多开 8 个智能体并不会加快你做判断的速度，它只会让排着队等你判断的东西堆得更深、更长。
这是性能工程里一条老掉牙、却还在让人惊讶的事实：优化非瓶颈的部分，并不会提升吞吐量。你只是让那堆没干完的活在瓶颈跟前越积越高罢了。多加智能体，优化的恰恰是那个从来就不是约束的环节。真正的约束是审查这一步——而你整个系统的吞吐量，精确地等于这一步的吞吐量。编排税，就是智能体的产出与你实际能合并进去的东西之间那道结构性的落差。当你让一个单线程的资源去掌管一个并发的系统，付出的就是这个代价。
硬扛解决不了结构性的极限
在圆桌上我说，我从没觉得用着这些工具能这么高产，但我同时也比以往任何时候都更累。这两半都千真万确，而且它们出自同一个根源。
这份累有一个非常具体的成因：它就是你把一个串行处理器拉满到 100%、不留一点余量时的那种感觉。每一次你回头去看一个晾了一阵子的智能体，你都在支付一笔上下文切换的成本。你得清空大脑，从零开始重新载入另一套上下文。CPU 干这件事只要几微秒，可架构师们仍然费尽心思去避免它。而你干这件事要花上几分钟，而且你永远没法把那套上下文完美地重新装回脑子里。五个智能体，不等于”一份工作量做五遍”。它等于五次冷启动重载，外加一个永不停歇的后台脑内进程，时刻在替你操心：现在到底该去看哪一个智能体？
你没法靠”再加把劲”去解决一个结构性的极限。这笔税横竖都得交。如果你硬要把它扛过去，这个极限就会以另一种形式冒出来：要么是越来越敷衍的代码审查，要么就是认知投降——你干脆全盘接受智能体写的代码，因为形成你自己的判断，要花掉你已经掏不出来的那点注意力。你要么主动地、有意识地交这笔税，要么就放任它悄悄地把你对自己系统的理解一点点蛀空。
去设计你的注意力
所以，你必须把你的注意力当作它本来的样子来对待：一种稀缺的串行资源。你不会在不认真琢磨瓶颈的情况下去设计一个分布式系统。请给你的大脑同样的尊重。
下面这几条，是真正在我身上经受住了考验的：
按审查速率来调整你的智能体编队规模，而不是按 UI。 一个好的并发系统会用背压来防止队列无限膨胀——生产者放慢脚步，去和消费者匹配。你的智能体数量就是生产者，你的审查速率就是消费者。并行智能体的正确数量，是你真正能好好做代码审查的那个数量。对我们大多数人来说，这个数是个很小的个位数。AI 工具会乐呵呵地让你一口气开 20 个，但那不过是个 UI 功能而已。
给任务分类。 Richard 问我是怎么驾驭这一切的时候，我跟他提过这一点。我手里始终摞着两堆任务。一堆是相互隔离的活儿，我很乐意把它们丢给在云端跑的后台智能体——这些可以异步地跑，往往只需要我在最后那道关口出现一下。另一堆是复杂任务，在这些任务里，判断本身就是工作，比如一个诡异的 bug，或者架构设计。最大的错误，就是去试图并行化第二堆任务。同时做好几件复杂的事，并不会放大你的产出，它只会让那把锁来回空转、剧烈抖动，结果是每件事都做得更糟。
把审查攒成批。 每做一次上下文切换，都会狠狠地耗你一笔。在一次坐下来里一口气审查 4 个智能体，要比”看一个、走开去干别的、再冷启动回来”便宜得多。把缰绳放长一点，让活儿先攒上一阵，然后整批一起处理。
只把锁花在判断上。 别把你的脑力浪费在机器自己就能验证的事情上。让智能体写出一个能通过的测试，或者生成一张截图。那些枯燥的 80%，它们自己就能证明给你看；这样你那点稀缺的注意力，就只花在真正需要人来定夺的那 20% 上。
保护好你的串行时间。 瓶颈需要的是你状态最好的那几个小时，而不是两次查看智能体之间剩下来的零碎几分钟。有时候，杠杆最大的一招，恰恰是彻底停止编排：合上那台开满了智能体的笔记本，全程攥着锁，就一个问题狠狠地想下去。编排不是真正的工作，它只是工作周围的开销。
Aja 指出，架构如今成了那项最紧迫的技能——知道什么东西该装进一个智能体里，什么东西对它来说又太重了。我还要补一句：你自己就是那个系统里的一个组件。你的注意力，有一个已知的、很低的串行吞吐量。这个系统要么尊重那个数字，要么就绕开它——靠偷偷拉低你的标准来绕开。
忙碌 vs 高产
这一点真的至关重要，因为这种失败模式对你自己是隐形的。二十个跑着的智能体，会给你一种产能爆棚的错觉。仪表盘填得满满当当，一切都在动。但那种感觉，和”真正把好代码交付到主干上”这件事，早就脱钩了。你可以忙到极致，却几乎产出不了什么。而从你自己的视角往里看，这两种状态感觉一模一样。
Ciera 提到了 Margaret-Anne Storey 关于”债”的研究。我们聊到了技术债和认知债。一笔没交的编排税，正是你同时欠下这两种债的方式。你合并了一些自己根本没好好读过的东西，你脑子里那套关于代码库的心智模型彻底变馊。今天，这一切都不会显示在仪表盘上。它会在线上崩掉的那一刻显现出来——你盯着这个系统，猛然发现：你已经完全不知道它是怎么跑起来的了。
所以，这才是真正该带走的那一条。开智能体不是什么技能，谁都能开 20 个。
**真正的技能，是围绕那个无法被克隆、也无法被并行的唯一串行资源去设计整个系统。那个资源，就是你的注意力。**
请像设计任何一个你在生产环境中依赖的东西那样，去设计它。
相关笔记
- Harness 工程：智能体时代真正的护城河 —— 同为 Addy Osmani，谈智能体时代工程重心的转移
- 多智能体协调模式：五种方案及其适用场景 —— 当你决定多开智能体时，可选的具体协调模式
- 为什么你的「AI 优先」战略很可能是错的 —— 对”盲目堆 AI / 堆智能体”的另一记冷静提醒