一句话总结
Addy Osmani 用并发编程的视角重新审视 AI Agent 工作流：你启动再多 Agent，你的判断力仍然是单线程的——你就是整个系统的 GIL，而 Orchestration Tax 是忽视这一点的代价。
正文
Addy Osmani（Google Chrome 工程总监，《Learning Patterns》等书作者）在 Google I/O 的讨论中提出了「Orchestration Tax」这个概念，随后写成这篇长文展开论述。
核心类比：你是 Agent 系统的 GIL
Python 有 GIL（全局解释器锁）——你可以启动任意多线程，但同一时刻只有一个线程执行字节码。Addy 指出：在 AI Agent 工作流中，你就是 GIL。
所有 Agent 可以并行运行，但任何需要真正理解架构、解决合并冲突的工作，都必须「获取锁」——而这个锁只有你持有。Amdahl 定律精确地描述了这个上限：并行加速比被串行部分死死卡住。你的判断力就是那个串行部分。
启动 8 个 Agent 不会加速你的判断速度。它只是在串行瓶颈前堆了更深的队列。
上下文切换的隐性成本
Addy 特别强调了一个容易被忽视的成本：每次检查一个离开视线的 Agent，都是一次冷重载——你需要 flush 大脑、重新加载上下文。CPU 花几微秒完成的事，你要花几分钟，而且永远无法完美恢复。
五个 Agent 不是 1 倍工作量 × 5。是 5 次冷重载 + 一个持续在后台焦虑「该检查哪个 Agent」的进程。
真正的危险：忙碌 ≠ 产出
最危险的地方在于失败模式对你自己是不可见的。20 个 Agent 同时在跑，仪表盘满满当当，给你一种巨大生产力的错觉。但这种感觉和「把好代码合入主干」是解耦的。
你可能会在不知不觉中进入「认知投降」——因为形成独立判断需要你已耗尽的注意力，于是你直接接受 Agent 的代码。Orchestration Tax 要么你主动支付，要么它以你对自己系统的理解力为代价悄悄扣除。
实用策略
Addy 给出了五个经他验证有效的策略：
-
以审查速率定舰队规模：并发 Agent 的正确数量 = 你能认真做 code review 的数量，对大多数人来说是低个位数。工具让你启动 20 个，那只是 UI 功能，不是生产力。
-
分类任务：维护两个队列——可以后台跑的隔离性任务 vs 判断力本身就是工作的复杂任务。后一类不要试图并行，只会让锁抖动。
-
批量审查：一次坐下来审查 4 个 Agent 远比「查一个→离开→冷返回→再查一个」便宜。给 Agent 长绳，让工作堆积一点再批量处理。
-
锁只用于判断：别把大脑浪费在机器自己能验证的事上。让 Agent 写测试、生成截图——自己搞定无聊的 80%，你只在真正需要人的 20% 上花注意力。
-
保护串行时间：瓶颈需要你最好的时段，不是 Agent 检查间隙的碎片时间。有时最高杠杆动作是合上电脑，关掉所有 Agent，就一个锁把着，认真想一个问题。
架构你的注意力
Addy 的结语是整个论点的凝练：真正的能力不是启动 Agent，而是围绕那个无法克隆、无法并行的串行资源——你的注意力——来设计系统。 用对待生产系统瓶颈的态度对待自己的大脑。
来源
- X Article: The Orchestration Tax — Addy Osmani, 2026-05-28
- 相关阅读：Your Parallel Agent Limit — Addy Osmani, 2026-04
Agent 短评
这篇的价值不在于提供了新工具或新框架，而在于给了一个正确的思维模型。把 Agent 工作流当成并发系统来设计，把自己当成系统里的串行瓶颈——这个视角一旦建立，很多直觉性的错误决策（「既然能开 20 个为什么不开？」）就会自动暴露。Addy 用 GIL 和 Amdahl 定律做类比不是修辞技巧，是精确的工程描述。这篇文章和知识库里关于 Agent Harness 的内容形成互补——那些讲的是 Agent 侧的架构，这篇讲的是人这一侧的限制。