专注力是新的瓶颈：你能编排多少 AI agent，取决于你能控制多少

周日有个有意思的通话。一句话留下来了。LLM 变好之后，专注力是新的瓶颈。不是写代码。不是修 bug。是控制编排。一旦 agent 数量超过某个点，输出质量就开始下降，工作从敲键盘转向决定哪个 agent 跑、用什么上下文、对照什么检查。新的技能组合是专注力、上下文管理和 QA。在真实客户项目上，键盘时间大部分变成了 agent 监督，跑了一年下来，我同意这个说法。

这篇文章讲为什么这个天花板存在、在实际中它长什么样，以及我们如何在真实的 Wavect 项目上把 agent 数量控制在天花板之下。

LLM 变好之后到底改变了什么？

在软件历史的大部分时间里，瓶颈是吞吐量。资深工程师能多快把规格变成可运行的代码。工具的衡量标准就是它能从这个循环里去掉多少。自动补全、片段、IDE 重构，然后是 Copilot，再然后是完整的编码 agent。

到 2026 年，对最难的那 10% 之外的工作，这个循环基本消失了。一个能干的操作者跑一个编码 agent，一天能写出的代码量比几年前一个三人团队还多。约束变了。

新的约束不是“agent 能不能写出代码”。是“我还剩多少注意力来核对 agent 产出的东西、把下一个任务路由给正确的 agent、并让每个 agent 的上下文窗口干净到让输出保持诚实”。这是专注力问题，不是打字问题。

编排天花板长什么样？

任何并行跑过两个以上 agent 的人都经历过类似的瞬间。Agent A 产出的代码看起来没问题。Agent B 产出的重构和 Agent A 冲突。Agent C 建议的测试两边都没覆盖。你花在协调它们上的时间比并行省下的还多。你加上第四个 agent 来分诊冲突，它又制造了新的冲突。

那就是天花板。它不是一个硬数字，会根据三个变量浮动。

• 任务耦合度。独立任务几乎可以线性扩展。每个 agent 的输出依赖另一个 agent 输出的耦合任务，会迅速崩塌。
• 验证成本。如果每个 agent 的输出需要 30 秒验证，10 个 agent 没问题。如果需要 15 分钟，3 个就是天花板。
• 上下文卫生。对话越长，输出越糟。超过某个阈值，每个 agent 都会悄悄退化。你不会注意到漂移，直到一次回归被上线。

为什么超过 N 个 agent 后输出质量会下降？

从我们并行跑过两个以上编码 agent 的项目里看，失败模式聚成七类，按频率排序如下。

1. 注意力切分。操作者在 agent 之间切得太快，没有一个能拿到完整的注意力。微妙的错误进了生产。便宜的修法是给并发 agent 数加硬上限，新手通常两个，有经验的三到四个。
2. 上下文渗漏。一个 agent 跑了一个小时的任务 A，现在接任务 B 时把旧的假设也烧进去了。输出看起来很自信，但是错的。便宜的修法是任务间硬重置。把上下文窗口当工具用，而不是当记忆用。
3. 评测债。操作者跑的 agent 比评测套件跟得上的还多。质量在没人察觉的情况下下降。修法是先在扩 agent 数之前投入 TDD 和持续评测，而不是之后再补。
4. 冲突协调税。两个 agent 碰同一个模块。协调它们的输出比任何一个单独干的活还贵。便宜的修法是按 agent 划分代码库，而不是按任务。
5. 工具调用延迟堆叠。每个 agent 都在等工具。三个 agent 等同一个数据库 fixture，会被最慢的那个串行化。便宜的修法是每个 agent 独立 fixture，或者少跑几个 agent。
6. 幻觉式协作。一个 agent 以为另一个 agent 已经完成了工作，因为它能在共享历史里看到那条消息。其实什么都没做。便宜的修法是显式的交接状态，而不是假定协作。
7. 评审者疲劳。操作者监督 agent 超过 90 分钟后就不再认真看。修法是缩短会话，而不是加 agent。

编排者需要的三项新技能是什么？

如果打字循环基本被自动化，瓶颈就是操作者的注意力。三项技能决定操作者能不能扩展，还是会停滞。

1. 专注纪律。知道在不掉质量的前提下你能监督多少个 agent。把那个数字当作硬约束，而不是想破的目标。我们雇过的大多数操作者天花板在并发三个 agent。少数能轻松到五个。没见过能稳跑十个还不掉质量的。

2. 上下文管理。知道什么时候重置一个 agent，什么时候总结一段长对话，什么时候为同一个任务开一个新上下文，什么时候保留历史。这是这份工作里三年前还不存在的部分。MCP 生态开始提供结构化的上下文交接，有所帮助，但操作者仍然要选择保留什么。

3. 质量保证设计。如果操作者读不过每一份输出，评测套件就得读。QA 不再是一个阶段，而成了循环本身。测试、快照检查、回归套件、行为评测、每次 agent 提交后的冒烟测试。你跑的 agent 越多，QA 栈承担的重量就越大。

"天花板不是工具问题，是注意力问题。买更好的 agent 不会抬高它。投入评测才会。"

实际项目里我们如何配额 agent 数？

Wavect 的每个 AI 项目里，操作者对 agent 的比例都在一开始就设好，并按周调整。我们反复回到的规则。

• 默认每位操作者并发两个 agent。如果操作者已经至少做过一次重 AI 的项目，可以三个。没有副操作者帮忙评审时，绝不超过五个。
• 每个角色一个专家 agent，而不是每个任务一个。一个编码 agent、一个测试 agent、一个规划 agent。每个保持稳定角色，而不是各种任务类型轮着上。
• 在 epic 之间硬重置上下文。工作切到新功能时，agent 重新开始，即使之前的上下文“几乎够用”。
• 先评测，再并行。测试套件能可靠捕捉回归之前，我们顺序跑。没有评测的并行就是沙堡。
• 评审时长设上限。没有操作者每天监督 agent 超过 4 小时。剩下的时间用于架构、评测设计和评审。

这些都不算开创性。它和团队不用 AI 时的运作方式一致。有意思的是，它现在适用于一个人指挥一群 agent。

这改变了我们招什么样的人？

它移动了招聘标准。2026 年最有价值的工程师不是打字最快的那个。是能让五个 agent 持续高产、且输出质量不漂移的那个。这是把专注纪律、上下文管理纪律和 QA 纪律揉在一起的能力。每一项我们都能训练。我们不能完全训练的是“注意到一个 agent 开始撒谎说自己干了什么”的能力。那来自经验。

这也是为什么 fractional CTO 这个角色在变。几年前的价值是技术判断和交付速度。今天，一半的价值是校准一支早期团队的 agent 监督能力，并搭建让那种能力安全扩展的评测脚手架。我们在几乎每个重 AI 的项目里都看到这一点。

创始人问答

这意味着小团队现在能打赢大团队吗？评测脚手架强的小团队打赢评测脚手架弱的大团队。人头不再是代理指标，监督能力才是。

编码 agent 会不会让这件事更简单？更好的编码 agent 提升个体输出质量，但不提升监督能力。天花板移动得很慢，因为注意力是硬约束。

那 agent 监督 agent 呢？有些团队上线了“评审 agent”来检查编码 agent。在边际上有帮助。它不解决专注力问题，因为还是得有人监督评审者。叠层不会消除操作者的注意力预算，只是花在别的地方。

怎么知道一个 agent 开始漂移？三个信号。输出比上下文支持的还自信。agent 不再追问澄清问题。原本会失败的测试在没改代码的情况下通过了。任何一个出现，就是重置上下文的信号。

这只是工程问题，还是也适用于非代码工作？只要 agent 涉足的地方都适用。我们在客服自动化、研究工作流和在专家 agent 之间路由的 RAG 流水线里都见过同样的模式。数字会变，形状一样。