# The Orchestration Tax
**作者**: Addy Osmani
**日期**: 2026-05-28T03:48:32.000Z
**来源**: [https://x.com/addyosmani/status/2059844244907696186](https://x.com/addyosmani/status/2059844244907696186)
---
Starting more AI agents is easy now. However, more agents running doesn’t mean there's more of you available - your cognitive bandwidth doesn’t parallelize. All the judgement to actually steer them and merge the changes they make still has to route through exactly one serial processor which is just you. Orchestration tax is basically the price you pay for forgetting this and the only real fix is to start architecting your own attention like you architect any concurrent system.
I was on a panel at Google I/O with Richard Seroter, Aja Hammerly and Ciera Jaspan talking about what software engineering looks like right now and how it will probably evolve. Near the end Richard asked us what is one thing developers should walk away and do differently. I said the thing I been circling around for months: feeling busy is definitely not the same as being productive. You can run 20 agents and feel completely busy. But thats not 20 agents worth of shipped work.
Earlier in that chat Richard gave this problem a name. "You talked about the orchestration tax" he said. "You can't manage twenty agents successfully in your own brain." He is totally right. I want to breakdown this idea properly because its not a discipline problem. It is an architecture problem.
The line from the panel I keep thinking about is something I said almost randomly: running multiple agents does not mean there is more of you.
## The asymmetry people don’t price in
There is this hidden asymmetry in agentic workflows. Starting an agent is very cheap. It is just a keystroke or a sentence prompt. But closing the loop on the agent is not cheap at all. Someone has to check if what came back is correct and reconcile it with whatever the other agents touched. That someone is you. And there is exactly one of you.
I wrote about a piece of this last month in Your parallel Agent limit, mostly about the ambient anxiety of not knowing which paralell thread is quietly failing. This post is about the shape underneath that cost. When you start seeing agent development as a concurrent system, you realize the human is just a component inside it. The slow serial component.
## You are the single thread resource
If you ever wrote concurrent code you already have the right intuition. You just been pointing it at the wrong part of the system.
Python has the Global Interpreter Lock (GIL). You can spawn as many threads as you want but only one executes python bytecode at a time because they must acquire the lock. You are the GIL of your AI agents. They all can run at once. But when any of their work needs genuine understanding of the architecture or resolving merge conflicts, that work has to acquire the lock. There is one lock. You hold it.
Amdahl’s Law makes this very precise. The speedup you get from parallelizing is capped by the fraction of work that stays serial. If a big chunk of your pipeline cant be parallelized, you top out at a hard limit no matter how many cores you throw at it. In agent development the serial fraction is the judgement. Spawning 8 agents doesn’t speed up your judgement time. It just makes the queue of things feeding into it much deeper.
This is an old performance engineering fact that still surprise people: optimizing the non bottleneck part doesn’t increase throughput. You just grow the pile of unfinished work sitting in front of the bottleneck. Adding agents optimize the part that was never the constraint. The constraint is the review step and the throughput of your system equals exactly the throughput of that step. The orchestration tax is the structural gap between agent production and what you can actually merge. It’s what happens when you put a single-threaded resource in charge of a concurrent one.
## Grinding won't fix structural limits
At the panel I said I never felt more productive with my tools but I am also more tired than I ever been. Both halves are completely real and they have the same cause.
The tiredness has a very specific cause. It is how running a serial processor at 100% with no slack feels like. Everytime you check on an agent you been away from you pay a context switch cost. You flush your brain and reload a different context from cold. CPUs do this in microseconds and architects still work hard to avoid it. You do it in minutes and you never reload the context perfectly. Five agents is not 1x workload done five times. It is 5 cold reloads plus a background brain process constantly worrying about which agent you should be checking.
You can’t just try harder to fix a structural limit. The tax will be paid anyway. If you try to grind it out, the limit just shows up as shallow code reviews or experiencing cognitive surrender where you just accept the agent’s code because forming your own opinion costs attention you don’t have anymore. You either pay the tax deliberately or you let it quietly destroy your understanding of your own system.
## Architect your attention
So you have to treat your attention as the scarce serial resource it is. You wouldn’t design a distributed system without thinking hard about the bottleneck. Give your brain the same respect.
Some things that actually held up for me:
Scale fleet to review rate, not the UI. A good concurrent system uses backpressure so the queue doesn’t grow infinitely. The producer slows down to match the consumer. Your agent count is the producer and your review rate is the consumer. The right number of parallel agents is how many you can actually code review properly. For most of us this is a low single digit. The AI tool will happily let you spawn 20 but that is just a UI feature.
Sort the work. I mentioned this to Richard when he asked how I navigate it. I keep two piles of tasks. One is isolated work that I’m happy to delegate to background agents running in the Cloud. These can run async and often just need me at the final gate. The other pile is complex tasks where the judgement is the work. Like a weird bug or architecture design. The big mistake is trying to paralellize the second pile. Doing multiple complex tasks doesn’t scale your output. It just thrashes the lock and everything comes out worse.
Batch your reviews. Context switching cost you heavily everytime you do it. Reviewing 4 agents at the same time in one sitting is much cheaper than checking one, leaving to do something else and returning cold. Give agents a long leash. Let the work pile up a bit and process the batch.
Only spend the lock on judgement. Dont waste your brain on things the machine can verify itself. Make the agent write a passing test or generate a screenshot. They can prove the boring 80% themselves so you only spend your scarce attention on the 20% that genuinely needs a human.
Protect your serial time. The bottleneck needs your best hours, not the leftover minutes between agent check-ins. Sometimes the highest leverage move is to stop orchestrating entirely, close the laptop full of agents and just think hard about one single problem with the lock held the whole time. Orchestrating is not the real work. Its the overhead around the work.
Aja pointed out that architecture is the urgent skill now. Knowing what belongs inside one agent and what is too much for it. I would add that you are a component in that system. Your attention has a known, low serial throughput. The system either respects that number or it routes around it by secretly lowering your standards.
## Busy vs Productive
This is really important because the failure mode is invisible to you. Twenty running agents gives you this feeling of massive productivity. The dashboard is full and everything moves. But that feeling is decoupled from actually shipping good code to main. You can be maximally busy and barely produce anything. From the inside it feels identical.
Ciera pointed out Margaret-Anne Storey’s work on debt. We talked about technical debt and cognitive debt. The orchestration tax left unpaid is how you accumulate both at once. You merge stuff you didn’t read well. Your mental model of the codebase goes completely stale. None of this shows up on the dashboard today. It shows up when production breaks and you look at the system and realize you have no idea how it works anymore.
So this is the actual takeaway. Spawning agents is not the skill. Anyone can run 20.
The real skill is designing the system around the one serial resource that cannot be cloned or parallelized. That resource is your attention.
Architect it the way you architect anything else you depend on in production.
## 相关链接
- [Addy Osmani](https://x.com/addyosmani)
- [@addyosmani](https://x.com/addyosmani)
- [417K](https://x.com/addyosmani/status/2059844244907696186/analytics)
- [panel](https://www.youtube.com/watch?v=VTYx7Ex-0bA)
- [Your parallel Agent limit](https://addyosmani.com/blog/cognitive-parallel-agents/)
- [Amdahl’s Law](https://en.wikipedia.org/wiki/Amdahl's_law)
- [cognitive surrender](https://addyosmani.com/blog/cognitive-surrender/)
- [Margaret-Anne Storey’s work on debt](https://margaretstorey.com/blog/2026/02/09/cognitive-debt/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:48 AM · May 28, 2026](https://x.com/addyosmani/status/2059844244907696186)
- [417.5K Views](https://x.com/addyosmani/status/2059844244907696186/analytics)
- [View quotes](https://x.com/addyosmani/status/2059844244907696186/quotes)
---
*导出时间: 2026/5/30 10:39:52*
---
## 中文翻译
# 编排税
**作者**: Addy Osmani
**日期**: 2026-05-28T03:48:32.000Z
**来源**: [https://x.com/addyosmani/status/2059844244907696186](https://x.com/addyosmani/status/2059844244907696186)
---
现在启动更多的 AI 智能体很容易。然而，运行更多的智能体并不意味着你有更多的时间可用——你的认知带宽无法并行化。实际引导它们并整合它们所做更改的所有判断，仍然必须通过唯一的串行处理器，也就是你。编排税基本上是你因忽略这一点而付出的代价，而唯一真正的解决方案是像设计任何并发系统一样，开始规划你自己的注意力。
最近在 Google I/O 的一个小组讨论上，我和 Richard Seroter、Aja Hammerly 以及 Ciera Jaspan 一起探讨了软件工程的现状以及它可能的演进方向。接近尾声时，Richard 问我们开发者应该去做哪一件不同的事情。我说出了我几个月来一直在思考的事情：感到忙碌绝对不等同于富有成效。你可以运行 20 个智能体并感到完全忙碌。但这并不代表完成了 20 个智能体的工作量。
在交谈的前半部分，Richard 给这个问题起了一个名字。“你谈到了编排税，”他说，“你无法在自己的大脑中成功管理二十个智能体。”他完全正确。我想恰当地拆解一下这个概念，因为这并非一个纪律问题，而是一个架构问题。
我在那个小组讨论中一直念念不忘的一句话是我脱口而出的一句话：运行多个智能体并不意味着有更多个“你”。
## 人们未将其计入成本的失衡
在智能体工作流中存在这种隐形的不对称。启动一个智能体的成本非常低。只需要敲击一次键盘或输入一句话。但是，闭环处理智能体的任务成本一点都不低。必须有人检查返回的内容是否正确，并将其与其他智能体修改的内容进行协调。那个人就是你。而你只有一个。
上个月我在《你的并行智能体极限》中写到了部分内容，主要讨论的是那种不知道哪个并行线程正在悄悄失败背景焦虑。这篇文章是关于这种成本背后的形态。当你开始将智能体开发视为一个并发系统时，你会意识到人类只是其中的一个组件。那个缓慢的串行组件。
## 你是单线程资源
如果你写过并发代码，你已经有正确的直觉。你只是把它指向了系统中错误的部分。
Python 有全局解释器锁（GIL）。你可以想生成多少线程就生成多少线程，但同一时刻只能有一个执行 Python 字节码，因为它们必须获取锁。你就是你 AI 智能体的 GIL。它们都可以同时运行。但是，当它们的任何工作需要真正理解架构或解决合并冲突时，那项工作必须获取锁。只有一把锁。你拿着它。
阿姆达尔定律（Amdahl’s Law）非常精确地阐明了这一点。并行化带来的加速上限取决于保持串行的那部分工作所占的比例。如果管道的很大一部分无法并行化，那么无论你投入多少核心，你都会碰壁。在智能体开发中，串行部分就是判断。生成 8 个智能体并不会加快你的判断速度。它只会让输入队列的堆叠变得更深。
这是一个古老的性能工程事实，但仍然让人们感到惊讶：优化非瓶颈部分并不能提高吞吐量。你只是增加了堆积在瓶颈前的未完成工作量。增加智能体优化了从来不是瓶颈的部分。瓶颈在于审查步骤，你系统的吞吐量完全等于该步骤的吞吐量。编排税就是智能体产出与你实际能合并的内容之间的结构性差距。这就是当你把一个单线程资源置于一个并发资源之上时发生的事情。
## 蛮干无法解决结构性限制
在那个小组讨论上，我说我觉得我的工具让我前所未有的高效，但我也比以往任何时候都更累。这两个感觉是完全真实的，它们有着共同的起因。
这种疲劳有一个非常具体的原因。这就是以 100% 的负荷且没有余量运行串行处理器的感觉。每次你检查一个你之前离开过的智能体时，你都要付出上下文切换的代价。你清空大脑，然后从冷状态重新加载一个不同的上下文。CPU 做这件事只需要微秒，架构师们仍然努力避免这种情况。你做这件事需要几分钟，而且你永远无法完美地重新加载上下文。五个智能体不是 1 倍的工作量做了五次。它是 5 次冷加载，加上一个后台的大脑进程，不断担心你应该检查哪个智能体。
你不能仅仅通过更努力来修复结构性限制。这笔税反正都要付。如果你试图死磕硬抗，这个限制就会表现为肤浅的代码审查，或者经历“认知投降”（cognitive surrender），即你只是接受智能体的代码，因为形成自己的观点需要你已经没有的注意力。你要么刻意付税，要么任由它悄悄摧毁你对系统的理解。
## 架构化你的注意力
所以你必须把你的注意力视为它本来的稀缺串行资源。你不会在不仔细考虑瓶颈的情况下设计一个分布式系统。请给你的大脑同等的尊重。
以下是一些对我真的很管用的方法：
**根据审查速度，而不是 UI，来缩放规模。** 一个好的并发系统会使用背压，这样队列就不会无限增长。生产者会减慢速度以匹配消费者。你的智能体数量是生产者，你的审查速度是消费者。正确的并行智能体数量是你真正能进行代码审查的数量。对我们大多数人来说，这是一个个位数的低值。AI 工具会很乐意让你生成 20 个，但这只是一个 UI 功能。
**对工作进行分类。** 当 Richard 问我如何应对时，我提到了这一点。我把任务分成两堆。一堆是独立的工作，我很乐意委托给在云端运行的后台智能体。这些可以异步运行，通常只需要我在最后把关。另一堆是复杂的任务，其中判断就是工作本身。比如一个奇怪的 Bug 或架构设计。最大的错误是试图将第二堆任务并行化。同时处理多个复杂任务并不能扩大你的产出。它只是猛烈地争抢锁，结果一切都会变得更糟。
**批量审查。** 每次进行上下文切换，代价都很高。在一次会议中同时审查 4 个智能体，比检查一个、离开去做别的事然后冷返回要便宜得多。给智能体一根长绳。让工作堆积一点，然后处理这一批。
**只在判断上消耗锁。** 不要把你的大脑浪费在机器可以自己验证的事情上。让智能体编写通过的测试或生成截图。它们可以自己证明无聊的 80% 的部分，这样你只把你稀缺的注意力花在真正需要人的 20% 上。
**保护你的串行时间。** 瓶颈需要你最好的时间，而不是智能体检查之间剩余的几分钟。有时，最高杠杆的操作是完全停止编排，关上充满智能体的笔记本电脑，只是专注于思考一个单一的问题，全程保持锁的占用。编排不是真正的工作。它是围绕工作的开销。
Aja 指出，架构现在是当务之急的技能。知道什么属于一个智能体内部，什么对它来说太多了。我想补充一点，你是那个系统中的一个组件。你的注意力有一个已知的、低吞吐量的串行吞吐量。系统要么尊重这个数字，要么通过暗中降低你的标准来绕过它。
## 忙碌 vs 高效
这非常重要，因为失败模式对你来说是不可见的。二十个正在运行的智能体会给你一种生产力巨大的感觉。仪表盘是满的，一切都在动。但那种感觉与实际将优秀的代码发布到主干是脱节的。你可以极度忙碌却几乎没有产出任何东西。从内部感觉来看，它们是一模一样的。
Ciera 指出了 Margaret-Anne Storey 关于债务的研究。我们讨论了技术债和认知债。未支付的编排税就是你同时积累两者的方式。你合并了你没有仔细阅读的东西。你对代码库的心理模型变得完全陈旧。这些在今天都不会显示在仪表盘上。它们会在生产环境崩溃时出现，当你看着系统，意识到你不再知道它是如何工作的时候。
所以这才是真正的要点。生成智能体不是技能。任何人都能运行 20 个。
真正的技能是围绕那个无法被克隆或并行的唯一串行资源来设计系统。那个资源就是你的注意力。
像架构化你在生产中依赖的任何其他东西一样，去架构化它。
## 相关链接
- [Addy Osmani](https://x.com/addyosmani)
- [@addyosmani](https://x.com/addyosmani)
- [417K](https://x.com/addyosmani/status/2059844244907696186/analytics)
- [panel](https://www.youtube.com/watch?v=VTYx7Ex-0bA)
- [Your parallel Agent limit](https://addyosmani.com/blog/cognitive-parallel-agents/)
- [Amdahl’s Law](https://en.wikipedia.org/wiki/Amdahl's_law)
- [cognitive surrender](https://addyosmani.com/blog/cognitive-surrender/)
- [Margaret-Anne Storey’s work on debt](https://margaretstorey.com/blog/2026/02/09/cognitive-debt/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:48 AM · May 28, 2026](https://x.com/addyosmani/status/2059844244907696186)
- [417.5K Views](https://x.com/addyosmani/status/2059844244907696186/analytics)
- [View quotes](https://x.com/addyosmani/status/2059844244907696186/quotes)
---
*导出时间: 2026/5/30 10:39:52*