内容
现在启动更多智能体很容易。不过，运行中的智能体变多，并不意味着“你”也变多了——你的认知带宽无法并行化。真正负责指挥它们、把它们写出的代码合并进代码库的所有判断，仍然必须经过同一个串行处理器，也就是你自己。协调税本质上就是你忘记这一点所要付出的代价，而唯一真正的解决办法，就是像设计任何并发系统一样，开始为自己的注意力做架构设计。
本周我和 Richard Seroter、Aja Hammerly 以及 Ciera Jaspan 一起参加了 Google I/O 的一个▶ 圆桌讨论，聊了聊当下的软件工程是什么样子，以及它大概率会如何演变。接近尾声时，Richard 问我们：开发者离开后最应该做的一件不同的事是什么。我说了我这几个月一直在反复思考的一点：感觉很忙，绝对不等于高效产出。你可以同时跑 20 个智能体，感觉自己忙得不可开交，但那并不是 20 个智能体对应的已交付成果。
在那场对话的前面，Richard 给这个问题起了个名字。“你刚才提到了协调税，”他说，“你没法在自己的大脑里成功管理二十个智能体。”他说得完全对。我想把这个概念认真拆开讲清楚，因为这不是纪律问题，而是架构问题。
那场圆桌里最让我一直反复回想的一句话，是我几乎随口说出来的：运行多个智能体，并不意味着“你”就变多了。
人们没有计入的非对称性
在智能体工作流里，有一种隐藏的非对称性。启动一个智能体非常便宜——按一下键，或者输一句提示词就行了。但把这个智能体真正收尾，却一点也不便宜。总得有人检查它返回的结果是否正确，并把它和其他智能体碰过的内容协调起来。这个人就是你。而你只有一个。
上个月我写过这件事的一部分，见你的并行智能体上限，主要讲的是那种始终萦绕在心头的焦虑：你并不知道哪个并行线程正在悄悄失败。这篇文章则讲这种成本背后的真实结构。一旦你开始把智能体开发看作一个并发系统，你就会意识到，人类只是其中的一个组件——而且是那个慢速的串行组件。
你就是那个单线程资源
如果你写过并发代码，你其实已经有了正确的直觉。只是你一直把它用在了系统的错误部分。
Python 有全局解释器锁（GIL）。你可以创建任意多的线程，但同一时间只有一个线程能执行 Python 字节码，因为它们必须先拿到这把锁。你就是 AI 智能体的 GIL。它们都可以同时运行。但凡它们的工作需要真正理解架构，或者解决合并冲突，就必须先获取这把锁。锁只有一把，而这把锁在你手里。
Amdahl 定律把这件事说得非常清楚：并行化带来的加速，受限于仍然保持串行的那部分工作比例。如果流水线里有很大一部分无法并行化，那么不管你往里塞多少核心，速度都只能到一个硬上限。在智能体开发里，那个串行部分就是判断力。启动 8 个智能体，并不会加快你做判断的时间，只会把排队等着被你判断的任务堆得更深。
这是一个老派的性能工程事实，但至今仍会让人惊讶：优化非瓶颈部分，并不会提升整体吞吐量。你只会让瓶颈前面那堆未完成的工作越堆越高。增加智能体，优化的是本来就不是约束的那一段；真正的约束是评审环节，而你的系统吞吐量，正好就等于这个环节的吞吐量。协调税，就是智能体产出速度与你实际可合并速度之间的结构性差距。它发生在你让一个单线程资源去管理并发资源的时候。
硬扛不会解决结构性限制
在圆桌上我说过，用这些工具时我从未感觉自己更高效，但我也比以往任何时候都更累。这两种感受都是真实的，而且它们有同一个原因。
疲惫感有非常具体的来源：就像把一个串行处理器长期跑在 100%、没有任何余量的状态下。每次你去查看一个离开过你的智能体，都会付出一次上下文切换成本。你把大脑内容清空，再从冷启动状态重新加载另一个上下文。CPU 用微秒来完成这件事，架构师们仍然会尽力避免它。而你要花的是分钟，而且你永远不可能把上下文完美重载回来。5 个智能体并不是把 1 倍工作量做 5 次那么简单，而是 5 次冷启动重载，再加上一个在后台不断操心“该去看哪个智能体”的大脑进程。
你不能靠更拼去解决结构性限制。税迟早都要交。如果你硬扛，这个限制最后就会表现为浅层代码评审，或者出现认知让渡——你干脆接受智能体写出来的代码，因为再形成自己的判断，已经要消耗你所剩无几的注意力了。你要么主动把税交掉，要么就眼看着它悄悄摧毁你对自己系统的理解。
为你的注意力做架构设计
所以，你必须把注意力当作那种稀缺的串行资源来对待。你不会在设计分布式系统时不认真考虑瓶颈。对你自己的大脑也该如此。
下面这些做法，对我确实有效：
按评审速度来限定智能体数量，不是按界面上能开多少来定。 一个好的并发系统会用背压机制，避免队列无限增长。生产者会放慢速度，去匹配消费者。你的智能体数量是生产者，你的评审速度是消费者。并行智能体的合理数量，就是你能真正认真做代码评审的数量。对我们大多数人来说，这个数字通常只有个位数。AI 工具当然会让你一下子开到 20 个，但那只是一个界面功能。
把任务分门别类。 Richard 问我怎么处理这些事时，我提到过这一点。我把任务分成两堆。一堆是隔离性较强的工作，我乐意交给在云端运行的后台智能体去做。这些任务可以异步运行，往往只需要我在最后关口把关。另一堆是复杂任务，而判断本身就是工作的一部分，比如一个奇怪的 bug，或者架构设计。最大的错误，就是想把第二堆也并行化。多个复杂任务一起做，并不会提升你的产出，只会疯狂冲击那把锁，最后什么都变差。
把评审批量处理。 每次上下文切换都会让你付出很高成本。一次性坐下来评审 4 个智能体的结果，远比看一个、离开去做别的事、再冷启动回来检查要便宜得多。给智能体更长的“牵引绳”。让工作先攒一攒，再批量处理。
只把锁用在判断上。 不要把大脑浪费在机器本可以自己验证的事情上。让智能体自己写出能通过的测试，或者生成截图。让它们自己证明那些无聊的 80%，这样你就只需要把稀缺注意力花在真正需要人类判断的 20% 上。
保护你的串行时间。 瓶颈需要的是你状态最好的时段，而不是智能体检查之间那些零碎的剩余分钟。有时候，最高杠杆的动作就是彻底停止协调，合上那台装满智能体的电脑，然后在持有这把锁的整个时间里，只专注思考一个问题。协调本身并不是主要工作，它只是工作周围的开销。
Aja 指出，架构能力现在是最紧急的技能。你要知道，什么该放进一个智能体里，什么对它来说太多了。我想补充的是：你本身就是这个系统里的一个组件。你的注意力有明确且很低的串行吞吐量。这个系统要么尊重这个数字，要么就会通过悄悄降低你的标准来绕过去。
忙碌 vs 高产出
这一点尤其重要，因为这种失败模式对你自己来说是隐形的。二十个正在运行的智能体，会让你产生一种自己产能巨大、几乎无所不能的感觉。仪表盘满满当当，一切都在流动。但这种感觉，和真正把高质量代码交付到 main 分支之间，并没有直接关系。你可以忙到极致，却几乎什么也没产出。从内部看，这两者的体感几乎一模一样。
Ciera 提到了Margaret-Anne Storey 关于债务的研究。我们聊到了技术债和认知债。未支付的协调税，正是你同时积累这两种债务的方式。你合并了那些自己根本没认真读过的内容。你对代码库的心智模型也彻底过时了。这些在今天的仪表盘上都不会显现出来。它们会在生产环境出问题时显现；那时你看着系统，才发现自己已经完全不知道它是怎么运作的了。
所以，这才是真正要带走的结论。启动智能体不是技能，谁都能开 20 个。真正的技能，是围绕那个无法复制、无法并行化的单一串行资源去设计系统。这个资源就是你的注意力。要像对待生产环境里任何其他依赖一样，去为它做架构设计。