Addy Osmani @ Google I/O 2026

The Orchestration Tax

为什么启动更多 AI Agent 反而让你更累、产出更低?Addy Osmani 用 Python GIL 和 Amdahl's Law 解释了这个反直觉的现象——你就是系统的瓶颈。

~2500原文词数
12 min阅读时间
X Article来源类型
中级难度(需要并发编程直觉)

全文翻译

Addy Osmani 的长文,来自 Google I/O 面板讨论后的深度思考。原文发布于 2026-05-28。

启动更多 AI Agent 现在很容易。但更多 Agent 在跑,不代表你有更多的"你"可用——你的认知带宽无法并行化。所有真正用来引导它们、合并它们产出的判断力,仍然必须通过唯一的一个串行处理器——也就是你自己。编排税(Orchestration Tax)本质上就是你忘记这一点后付出的代价,而唯一真正的解决方案,是像架构任何并发系统一样,架构你自己的注意力。

我在 Google I/O 上和 Richard Seroter、Aja Hammerly、Ciera Jaspan 一起参加了一个面板讨论,聊的是软件工程的现状和未来演进。快结束时 Richard 问我们:开发者应该带走的一个行动建议是什么。我说了我几个月来一直在琢磨的事:感觉忙碌和真正高效完全不是一回事。你可以跑 20 个 Agent,感到无比忙碌。但那不是 20 个 Agent 的交付量。

Richard 在讨论中给这个问题起了名字。"你说的就是编排税",他说,"你不可能在自己的脑子里同时成功管理二十个 Agent。"他说得完全对。我想好好拆解这个概念,因为这不是一个自律问题,这是一个架构问题

你就是 GIL

Python 有一个全局解释器锁(GIL)。你可以创建任意多的线程,但同一时刻只有一个线程能执行 Python 字节码,因为它们必须获取这把锁。你就是 AI Agent 的 GIL。它们可以同时运行,但当它们的工作需要真正理解架构,或解决合并冲突时,这些工作必须获取锁。只有一把锁。你持有它。

Amdahl's Law 让这一定义更加精确。并行化带来的加速比,受限于必须串行执行的那部分工作。如果你的流水线中有很大一部分无法并行化,无论投入多少核心,都会撞到一个硬上限。在 Agent 开发中,串行部分就是判断力。启动 8 个 Agent 不会加速你的判断速度,它只是让排在你前面等待处理的工作队列变得更长。

这是一个老牌性能工程事实,至今仍让人惊讶:优化非瓶颈部分不会增加吞吐量。你只是让堆积在瓶颈前方的未完成工作变得更多。

Optimizing the non-bottleneck part doesn't increase throughput. You just grow the pile of unfinished work sitting in front of the bottleneck.

上下文切换的真实代价

在面板上我说过,我从未觉得工具让我如此高效,但我也从未如此疲惫。这两半都是真实的,而且它们有同一个原因。

疲惫有一个非常具体的原因:这就是以 100% 利用率运行一个串行处理器且毫无余量时的感受。每次你检查一个离开过一段时间的 Agent,你都要付出上下文切换成本。你清空大脑,从冷启动重新加载一个不同的上下文。CPU 在微秒内完成这件事,架构师们仍然竭力避免它。你在几分钟内完成,而且你永远无法完美重载上下文。

5 个 Agent 不是 1 倍的工作量做 5 遍。它是 5 次冷重载,外加一个后台脑进程不断担忧你应该去检查哪个 Agent。

不能靠更努力来解决

你不能靠"更努力"来修复一个结构性限制。税总是要交的。如果你硬撑,这个限制只会表现为浅层代码审查,或一种审查疲劳——你直接接受 Agent 的代码,因为形成自己的判断所需的注意力你已经没有了。你要么刻意交税,要么让它悄悄摧毁你对自己系统的理解。

五条实战策略

策略 1

按 review 速率缩放

正确的并行 Agent 数量,是你能真正做好 code review 的数量。对大多数人来说,这是一个低个位数。AI 工具很乐意让你启动 20 个,但那只是一个 UI 功能。

策略 2

对工作进行分类

保持两堆任务:隔离工作(可委托给后台 Agent)和复杂任务(判断本身就是工作)。最大的错误是试图并行化第二堆。

策略 3

批量审查

一次坐在那里审查 4 个 Agent,比检查一个、离开做别的、再冷启动回来便宜得多。让工作积累一些,然后批量处理。

策略 4

只在判断上花锁

让 Agent 写通过测试或生成截图来证明那无聊的 80%,你只花注意力在真正需要人类的 20%。

策略 5

保护你的串行时间

有时候最高杠杆的举动是完全停止编排,关掉满载 Agent 的笔记本电脑,只想一个问题。编排不是真正的工作,它是工作周围的开销。

真正的结论

启动 Agent 不是技能。任何人都能跑 20 个。真正的技能是围绕那个无法克隆或并行化的唯一串行资源来设计系统。那个资源就是你的注意力。像架构你在生产环境中依赖的任何其他东西一样,架构它。

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.

深度解读

GIL 类比的工程精度、Amdahl's Law 的映射、以及为什么"感觉忙碌"是最大的陷阱。

Addy Osmani 在 Google I/O 面板上说了一句话,然后这句话就没离开过他的脑子:"运行多个 Agent 并不意味着有更多的你。"

这句话看似简单,但底下藏着一个精确的工程隐喻,也是这篇文章真正的贡献——你就是 GIL

Python 的全局解释器锁是一个臭名昭著的设计。你可以开一千个线程,但同一时刻只有一个在执行字节码。GIL 的存在不是为了限制你,而是因为 Python 的内存管理在多线程下不安全。这是一个结构性的权衡,不是努力就能绕过的。Addy 把这个类比平移到了 AI Agent 工作流上。

这不是一个新鲜问题。1967 年 Gene Amdahl 提出了阿姆达尔定律:并行计算的加速比受限于程序中必须串行执行的部分。如果 95% 可以并行化,理论上无限核心可以让系统快 20 倍。但如果只有 50% 可以并行化,上限就是 2 倍。再怎么加核心也没用。

Addy 的洞察是:在 Agent 工作流中,串行部分不是计算,是判断。你加再多的 Agent,判断的速度不会变快。你只是让排队等审查的东西变多了。

感觉忙碌和真正高效完全不是一回事。你可以跑 20 个 Agent,感到无比忙碌。但那不是 20 个 Agent 的交付量。

Feeling busy is definitely not the same as being productive. You can run 20 agents and feel completely busy. But that's not 20 agents worth of shipped work.

文章最锐利的部分不是理论,而是对失败模式不可见性的描述。20 个 Agent 在跑,仪表盘满满当当,一切都"在动"。但这种感觉和真正把高质量代码合入 main 分支完全解耦。从内部感受来看,它们是一样的。这是整篇文章最可怕的句子。

五条建议的工程对应

编程概念Agent 工作流对应核心逻辑
背压(Backpressure)Agent 数量 ≤ 审查速率生产者减速匹配消费者
任务调度隔离任务委托,复杂任务串行可并行的才并行
批处理(Batching)一次审查多个 Agent减少上下文切换次数
减少锁竞争只在判断上花注意力自动化验证降低锁粒度
临界区保护保护最好的时段给最难的问题瓶颈优先获得资源

压力测试:三个隐性假设

假设一:人类审查永远是瓶颈。但 Claude Code 的 Dynamic Workflows 就在尝试自动化 Agent 间的 handoff——如果编排本身能被自动化,审查的认知负荷可能比 Addy 描述的低得多。

假设二:当前工具状态是静态的。Google 自己的 AutoCommenter 已经在做 AI 代码审查了。如果审查步骤能被 AI 辅助,GIL 的粒度会变细——从"整个审查过程必须串行"变成"只有最终决策需要串行"。

假设三:视角局限于个人开发者。放大到公司层面,一旦多个团队用多个 Agent 改同一个代码库,协调成本是指数级的。团队级编排才是真正复杂的场景。

苏格拉底对话

如果 Addy 说的是对的,那你每天跑的那些 Agent 到底在干什么?

学生
我最近特别爽,Claude Code 同时给我跑 8 个 Agent,每个都在写代码。感觉效率爆炸了。
老师
那这 8 个 Agent 的产出,你都 review 了吗?
学生
还没来得及……有一个在改数据库 schema,一个在写 API 测试,还有一个在重构认证模块。我先看看这个 schema 的……
老师
停一下。你刚才从"看看 schema"切到"这个测试怎么挂了"用了多久?
学生
大概……五六分钟吧。我得回忆一下上次这个表的字段定义是什么样的。
老师
这就是上下文切换成本。CPU 切换上下文要微秒,你切换要分钟,而且永远不能完美重载。你刚说的五六分钟,有三分之二是在"回忆"而不是在"判断"。
学生
所以 Addy 说我是 GIL……意思是所有 Agent 都在等我?
老师
不是"等你"这么被动。是所有需要判断力的环节,都必须经过你。启动 Agent 不需要判断力——一句话就行。但"这个改法对不对"需要。一个需要判断,一个不需要,这就是不对称性。
学生
那我多招几个工程师不就行了?
老师
你在团队里加人,需要给每个人足够的上下文。每个新人理解代码库的时间是串行的,不能并行加速。这和加 Agent 是同一个问题——生产者变快了,消费者还是那么慢。
学生
好吧那我少跑几个 Agent?
老师
不是"少跑",是跑到你能审查过来的数量。好的并发系统用背压让生产者慢下来匹配消费者。你的 Agent 数量是生产者,review 速度是消费者。对大多数人来说,能真正做好 code review 的并行数量是个位数。
学生
有个回复说"上下文工程比模型能力更重要"——这是什么意思?
老师
如果你的 Agent 带着"这个项目不用 React Query""这个 API 返回的是 snake_case"这类上下文出发,它回来的时候你就只需要检查逻辑,不用检查风格和约定。GIL 持有时间变短了。这不就是优化锁的粒度吗?
学生
所以核心不是"跑多少 Agent",而是让我每次持锁的时间最短?
老师
对。而且最好的状态是——有些锁根本不需要你持。让 Agent 自己写测试证明那 80% 是对的,你只花注意力在 20% 真正需要人类判断的地方。编排不是真正的工作,它是工作周围的开销。
学生
那有时候最好的做法是……
老师
关掉所有 Agent,只想一个问题。你已经知道答案了。

个性化洞察

跟你的日常使用场景直接相关的 4 条发现。

[最直接] 你每天都在用 Claude Code 跑 Agent

Addy 说的"低个位数"可能比你想的更少。如果你同时在跑 deep-analysis + translate-analyze + 日记 + 多个 subagent,你的 GIL 已经在剧烈抖动了。

建议:给每类任务设一个 WIP limit,deep-analysis 一次最多 1 个,translate-analyze 最多 2 个并行。不是工具限制你,是你的审查速率限制你。

[架构思维] 你的 skill 体系本身就是在减少 GIL 时间

你把重复操作固化为 skill(dual-store.sh、translate-analyze 流水线),就是在把"需要人类判断的部分"和"机器可以自动化的部分"分开。这恰好就是 Addy 建议的第 4 条。

建议:审查现在的 skill 中,哪些还有"人工检查点"可以进一步自动化。

[警惕] "感觉忙碌 ≠ 高效"值得打印出来

你经常一天开多个会话跑多个任务。每个会话在后台跑 Agent 时你都"很忙",但如果每个产出你都没时间认真看,那就是在积累认知债。

建议:给自己设一个每日审查配额——每天最多认真看 3 个 Agent 的完整产出。

[趋势] 编排税会成为 AI 工具的差异化战场

Claude Code 的 Dynamic Workflows、Cursor 的 Agent 模式、Windsurf 的 Cascade 都在解决同一个问题——减少人类在编排中的认知负荷。

建议:持续关注哪些工具在真正减少审查步骤的认知负荷,而不只是让"启动 Agent"更丝滑。前者是解决瓶颈,后者是优化非瓶颈部分。

精选评论

来自 X/Twitter 回复区的高质量讨论。

@poteto(54 likes)
编排用在对的方向上很棒——用于深度而非广度。这就是我为什么做了这个工具。
Orchestration is great when it's applied for depth. It's why I made and use this tool.
@dezeloper
一个无人引导的 Agent 偏离轨道已经够糟了,一群无人引导的更可怕。不幸的是 ultracode 模式就是干这个的——不加判断地并行发射。
The only thing worse than one unguided agent wandering off course is a swarm of them. Unfortunately ultracode mode does exactly that—parallel dispatch without judgment.
@nitmusai
这就是为什么上下文工程现在比原始模型能力更重要。嵌入正确上下文的 Agent 产出更可审查的结果,减少了你的 GIL 时间。
This is why context engineering matters more than raw model capability right now. Agents embedded with the right context produce more reviewable results, reducing your GIL time.
@BensHasThoughts
我转了一圈回来了——现在主要是在一个项目上深度工作,可能两个,只有 5 个左右的 Agent。少即是多。
I've come full circle now where I'm mostly working deeply on a single project, maybe two, and only have 5 or so agents.
@tushinskiy
编排税比单个开发者的 review 队列更大。放大到公司层面——一旦多个团队用多个 Agent 改同一个代码库,协调成本是指数级的。
I think the orchestration tax is bigger than one dev's review queue. Zoom out to a company. Once multiple teams use multiple agents on the same codebase, coordination cost is exponential.