AI 编程重度用户和团队管理者会感同身受——多 Agent 不等于高产，反而可能让人更累。这篇把人的注意力瓶颈讲透了，建议点开看看怎么优化自己的审查流程。
Addy Osmani 提出“编排成本”概念，指出在 AI 编程中，人的审查与判断是系统瓶颈，无法并行。多 Agent 看似高效，但最终所有任务都需开发者逐一审查、合并，导致上下文切换和认知负荷剧增。文章类比 Python GIL 和 Amdahl 定律，强调优化非瓶颈部分不会提升整体产出。建议根据审查能力控制 Agent 数量、任务分层、批量审查，并保护深度思考时间。
活人开发者的注意力是整个 AI Coding 系统里最稀缺、最慢、最不能并行的资源！ 启动 Agent 很容易，但理解结果、判断质量、处理冲突、决定能不能合并，仍然必须由人完成。Agent 可以并行...
活人开发者的注意力是整个 AI Coding 系统里最稀缺、最慢、最不能并行的资源！ 启动 Agent 很容易，但理解结果、判断质量、处理冲突、决定能不能合并，仍然必须由人完成。Agent 可以并行工作，但人的判断不能并行。所以真正限制产出的，不是 Agent 数量，而是人的审查与决策能力。 @addyosmani 把这个问题称为 Orchestration Tax，可以理解为“编排成本”或“调度成本”。 你启动 10 个、20 个 agent，看起来很忙，界面上也有很多任务在跑。但这些任务最后都会排队等待你： · 看结果是否正确 · 判断是否符合架构 · 检查代码质量 · 处理不同 Agent 之间的冲突 · 决定哪些可以合并 这一步无法完全交给机器，因为它涉及系统理解、工程判断和长期维护责任。 所以，多 Agent 并不等于多了几个“你”。最后真正承担责任的，还是一个人。 最关键的工程类比 第一是 Python 的 GIL。线程可以很多，但真正执行关键部分时，要经过一个单线程限制。Addy 说，人就是 AI Agent 系统里的 GIL。Agent 可以同时跑，但一到需要理解、判断、合并时，都要等你。 第二是 Amdahl’s Law。系统加速的上限，取决于仍然无法并行的那部分。在 AI 编程里，无法并行的部分就是人的判断。Agent 数量增加，只是让等待你审查的任务变多，不会自动提高最终交付质量。 这也是文章最重要的技术含义：优化非瓶颈部分，不会提高系统吞吐量。 如果瓶颈是审查和判断，继续增加 Agent，只会制造更多待处理工作。 为什么“忙”不等于“高产” Addy 反复强调：现在的工具确实让人更有生产力，但也让人更累。 原因是，多 agent 工作会带来大量上下文切换。你每次去看一个 agent 的结果，都要重新加载它的任务背景、改动范围、相关代码和潜在风险。CPU 的上下文切换很快，但人的上下文切换很慢，而且恢复不完整。 所以 5 个 agent 不是 5 倍产出，而可能是： · 5 次重新进入不同问题 · 5 组需要审查的改动 · 持续担心哪个任务正在出错 · 更容易降低审查标准 最危险的情况是，人因为太累，开始接受自己并没有真正理解的代码。短期看似推进了，长期会损害对系统的理解。 所以真正成熟的 AI 编程能力，不是同时开更多 agent，而是知道： · 哪些任务适合交给 agent · 哪些任务必须自己深度参与 · 什么时候应该批量审查 · 什么时候应该停止调度，专心思考一个复杂问题 · 哪些验证可以让机器先完成，减少人的负担 Addy 给出的实践原则 第一，Agent 数量要按你的审查能力来定，而不是按工具界面能开多少来定。多数人真正能认真审查的并行任务，可能只是个位数。 第二，把任务分层。隔离、明确、低耦合的任务适合放给后台 Agent；复杂 bug、架构设计、关键重构，不适合同时并行太多，因为这些任务本身就需要人的判断。 第三，批量审查。频繁来回查看不同 Agent，会消耗大量注意力。让 Agent 多跑一段时间，然后集中审查，比不断切换更有效。 第四，把人的注意力留给真正需要判断的部分。测试、截图、格式检查、基础验证，可以要求 Agent 自己先完成。人主要看关键设计、边界条件、风险和可维护性。 第五，保护深度思考时间。有些时候最高价值的动作不是继续管理 Agent，而是停止多线程工作，完整地思考一个核心问题。 Addy Osmani @addyosmani x.com/i/article/2059… 🔗 View Quoted Tweet 💬 1 🔄 0 ❤️ 0 👀 219 📊 1 ⚡