---
title: "聚焦是新的瓶颈 - 博客"
canonical: https://wavect.io/zh/blog/focus-bottleneck-orchestrating-ai-agents/
language: zh
description: "LLM 把瓶颈从打字转到了聚焦。编排上限、Agent 数量超过 N 之后的七种失败模式，以及我们在真实项目里如何控制 Agent 数量。"
image: "https://wavect.io/img/blog/headers/header_focus-bottleneck-orchestrating-ai-agents.png"
---

[**返回**](/zh/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/)

[Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt

7 分钟 阅读 · 2026年5月26日

[**下一篇**](/zh/blog/why-ai-agent-projects-get-cancelled/)

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

要点速览

LLM 变好之后，专注力成了新瓶颈：约束不再是 agent 能不能写代码，而是操作者还剩多少注意力去验证输出、路由任务、保持上下文干净。超过某个并发数输出质量就下降，常见失败包括注意力切分、上下文渗漏、评测债和评审者疲劳。我们的实践规则：默认每位操作者并发两个 agent、epic 之间硬重置上下文、先建评测再并行、每天监督不超过 4 小时。

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

这篇文章讲为什么这个天花板存在、在实际中它长什么样，以及我们如何在真实的 Wavect 项目上把 agent 数量控制在天花板之下。如果智能体属于不同的人，编排还会变成身份、同意与投递问题。我们的 [Band、A2A 与 MCP 跨所有者智能体通信指南](/zh/blog/ai-agents-talk-to-each-other-band/) 专门处理这条信任边界。

如果你正在评估员工私有 agent 与公司共享空间的基础设施，我们的 [QM AI Agent 评测](/zh/blog/qm-ai-agent-harness-review/) 会从部署 ownership、隔离和安全限制三个角度审视这套架构。

## 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](/zh/glossary/tdd/) 和持续评测，而不是之后再补。
4. 冲突协调税。 两个 agent 碰同一个模块。协调它们的输出比任何一个单独干的活还贵。便宜的修法是按 agent 划分代码库，而不是按任务。
5. 工具调用延迟堆叠。 每个 agent 都在等工具。三个 agent 等同一个数据库 fixture，会被最慢的那个串行化。便宜的修法是每个 agent 独立 fixture，或者少跑几个 agent。
6. 幻觉式协作。 一个 agent 以为另一个 agent 已经完成了工作，因为它能在共享历史里看到那条消息。其实什么都没做。便宜的修法是显式的交接状态，而不是假定协作。
7. 评审者疲劳。 操作者监督 agent 超过 90 分钟后就不再认真看。修法是缩短会话，而不是加 agent。

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

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

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

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

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

![Kevin Riedl](/img/team/kevin.webp)

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

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

Wavect 的每个 [AI 项目](/zh/services/artificial-intelligence/) 里，操作者对 agent 的比例都在一开始就设好，并按周调整。我们反复回到的规则。

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

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

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

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

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

## 创始人问答

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

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

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

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

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

## 最终思考

周日通话里的观察是对的。瓶颈从打字移到了专注力，大多数团队还在用旧的约束衡量自己。盯着你的团队能在不掉质量的前提下监督多少 agent，现在是一个领先指标。投入评测和上下文纪律会抬高天花板。买更多 agent 不会。

如果你 2026 年在扩一支重 AI 的团队、输出质量正在出毛边，正确动作不是更多 agent。是每位操作者更少的 agent、更强的评测，以及更短的监督会话。无聊。有效。

你觉得你团队的天花板在哪里。告诉我们，我们想对一下笔记。

## 你可能也喜欢..

[**为什么 40% 的 AI Agent 项目被砍掉** 我们在 AI agent 项目里反复看到的八种失败模式。是什么把它们杀死，以及发现得早时的便宜修法。](/zh/blog/why-ai-agent-projects-get-cancelled/) [**Wavect vs 一家通用型开发外包** 通用型卖产能，我们卖产品判断加上能交付的工程能力。](/zh/compare/wavect-vs-dev-agencies/)

AI 增强团队

## 继续浏览此集群

当 AI 改变软件工作方式时的团队设计、采用与管理。

[从核心文章开始**如何在 2026 年把 AI 落地到团队内部**](/zh/blog/internal-ai-adoption-2026/)

- [微型机构还是中型机构：2026 年你的软件合作方该有多大？](/zh/blog/micro-agency-vs-mid-size-software-partner-2026/)
- [Vibe Coder 是新一代初级开发者吗？](/zh/blog/vibe-coders-new-junior-developers/)
- [如何在 2026 年把 AI 落地到团队内部](/zh/blog/internal-ai-adoption-2026/)

只收重要内容

## 关注与你相关的内容

每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。

[**返回**](/zh/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/)

[Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt

7 分钟 阅读 · 2026年5月26日

[**下一篇**](/zh/blog/why-ai-agent-projects-get-cancelled/)

邮件订阅新文章 ×

×

通过邮件获取新文章

我们发布时给你一封简短邮件。免费，不做跟踪。

## Structured Data

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@id": "https://wavect.io/#organization",
      "@type": [
        "Organization",
        "ProfessionalService",
        "LocalBusiness"
      ],
      "employee": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "founder": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "legalRepresentative": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "name": "Wavect GmbH",
      "subjectOf": {
        "@id": "https://wavect.io/verified-claims.json#dataset",
        "@type": "Dataset",
        "creator": {
          "@id": "https://wavect.io/#organization",
          "@type": [
            "Organization",
            "ProfessionalService",
            "LocalBusiness"
          ]
        },
        "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.",
        "inLanguage": "en",
        "isAccessibleForFree": true,
        "license": "https://creativecommons.org/licenses/by/4.0/",
        "name": "Wavect verified publication claims",
        "url": "https://wavect.io/verified-claims.json"
      },
      "url": "https://wavect.io/"
    },
    {
      "@id": "https://wavect.io/team/kevin-riedl/#person",
      "@type": "Person",
      "jobTitle": "Managing Director",
      "name": "Kevin Riedl",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q139796365",
        "https://www.linkedin.com/in/wsdt",
        "https://github.com/wsdt"
      ],
      "url": "https://wavect.io/team/kevin-riedl/",
      "worksFor": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      }
    },
    {
      "@id": "https://wavect.io/team/christof-jori/#person",
      "@type": "Person",
      "jobTitle": "Managing Director",
      "name": "Christof Jori",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q139796367",
        "https://www.linkedin.com/in/jocr77/",
        "https://github.com/jo-chris"
      ],
      "url": "https://wavect.io/team/christof-jori/",
      "worksFor": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      }
    },
    {
      "@id": "https://wavect.io/#website",
      "@type": "WebSite",
      "inLanguage": [
        "en",
        "de",
        "es",
        "zh"
      ],
      "name": "Wavect",
      "potentialAction": {
        "@type": "SearchAction",
        "query-input": "required name=search_term_string",
        "target": {
          "@type": "EntryPoint",
          "urlTemplate": "https://wavect.io/search/?q={search_term_string}"
        }
      },
      "publisher": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      },
      "url": "https://wavect.io/"
    },
    {
      "@id": "https://wavect.io/zh/blog/focus-bottleneck-orchestrating-ai-agents/#webpage",
      "@type": "WebPage",
      "dateModified": "2026-07-07",
      "inLanguage": "zh",
      "isPartOf": {
        "@id": "https://wavect.io/#website",
        "@type": "WebSite"
      },
      "lastReviewed": "2026-07-07",
      "url": "https://wavect.io/zh/blog/focus-bottleneck-orchestrating-ai-agents/"
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "abstract": "LLM 变好之后，专注力成了新瓶颈：约束不再是 agent 能不能写代码，而是操作者还剩多少注意力去验证输出、路由任务、保持上下文干净。超过某个并发数输出质量就下降，常见失败包括注意力切分、上下文渗漏、评测债和评审者疲劳。我们的实践规则：默认每位操作者并发两个 agent、epic 之间硬重置上下文、先建评测再并行、每天监督不超过 4 小时。",
  "articleBody": " 博客概览/领导力与团队/AI 增强团队 专注力是新的瓶颈：你能编排多少 AI agent，取决于你能控制多少 要点速览 LLM 变好之后，专注力成了新瓶颈：约束不再是 agent 能不能写代码，而是操作者还剩多少注意力去验证输出、路由任务、保持上下文干净。超过某个并发数输出质量就下降，常见失败包括注意力切分、上下文渗漏、评测债和评审者疲劳。我们的实践规则：默认每位操作者并发两个 agent、epic 之间硬重置上下文、先建评测再并行、每天监督不超过 4 小时。 周日有个有意思的通话。一句话留下来了。LLM 变好之后，专注力是新的瓶颈。不是写代码。不是修 bug。是控制编排。一旦 agent 数量超过某个点，输出质量就开始下降，工作从敲键盘转向决定哪个 agent 跑、用什么上下文、对照什么检查。新的技能组合是专注力、上下文管理和 QA。在真实客户项目上，键盘时间大部分变成了 agent 监督，跑了一年下来，我同意这个说法。 这篇文章讲为什么这个天花板存在、在实际中它长什么样，以及我们如何在真实的 Wavect 项目上把 agent 数量控制在天花板之下。如果智能体属于不同的人，编排还会变成身份、同意与投递问题。我们的Band、A2A 与 MCP 跨所有者智能体通信指南专门处理这条信任边界。 如果你正在评估员工私有 agent 与公司共享空间的基础设施，我们的QM AI Agent 评测会从部署 ownership、隔离和安全限制三个角度审视这套架构。 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 的项目里看，失败模式聚成七类，按频率排序如下。 注意力切分。操作者在 agent 之间切得太快，没有一个能拿到完整的注意力。微妙的错误进了生产。便宜的修法是给并发 agent 数加硬上限，新手通常两个，有经验的三到四个。 上下文渗漏。一个 agent 跑了一个小时的任务 A，现在接任务 B 时把旧的假设也烧进去了。输出看起来很自信，但是错的。便宜的修法是任务间硬重置。把上下文窗口当工具用，而不是当记忆用。 评测债。操作者跑的 agent 比评测套件跟得上的还多。质量在没人察觉的情况下下降。修法是先在扩 agent 数之前投入 TDD 和持续评测，而不是之后再补。 冲突协调税。两个 agent 碰同一个模块。协调它们的输出比任何一个单独干的活还贵。便宜的修法是按 agent 划分代码库，而不是按任务。 工具调用延迟堆叠。每个 agent 都在等工具。三个 agent 等同一个数据库 fixture，会被最慢的那个串行化。便宜的修法是每个 agent 独立 fixture，或者少跑几个 agent。 幻觉式协作。一个 agent 以为另一个 agent 已经完成了工作，因为它能在共享历史里看到那条消息。其实什么都没做。便宜的修法是显式的交接状态，而不是假定协作。 评审者疲劳。操作者监督 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 流水线里都见过同样的模式。数字会变，形状一样。 最终思考 周日通话里的观察是对的。瓶颈从打字移到了专注力，大多数团队还在用旧的约束衡量自己。盯着你的团队能在不掉质量的前提下监督多少 agent，现在是一个领先指标。投入评测和上下文纪律会抬高天花板。买更多 agent 不会。 如果你 2026 年在扩一支重 AI 的团队、输出质量正在出毛边，正确动作不是更多 agent。是每位操作者更少的 agent、更强的评测，以及更短的监督会话。无聊。有效。 你觉得你团队的天花板在哪里。告诉我们，我们想对一下笔记。 你可能也喜欢.. 为什么 40% 的 AI Agent 项目被砍掉 我们在 AI agent 项目里反复看到的八种失败模式。是什么把它们杀死，以及发现得早时的便宜修法。 Wavect vs 一家通用型开发外包 通用型卖产能，我们卖产品判断加上能交付的工程能力。 AI 增强团队 继续浏览此集群 当 AI 改变软件工作方式时的团队设计、采用与管理。 从核心文章开始如何在 2026 年把 AI 落地到团队内部 微型机构还是中型机构：2026 年你的软件合作方该有多大？ Vibe Coder 是新一代初级开发者吗？ 如何在 2026 年把 AI 落地到团队内部 集群中的上一篇如何在 2026 年把 AI 落地到团队内部 查看相关服务： AI 咨询 看看生产环境中的应用: Twinsoft AI 先做决定: 如何为 MVP 选择技术栈 只收重要内容 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 Company 电子邮箱 你希望接收哪些内容？ 完整的 Wavect 博客接收六个主题下的每一篇新文章。 仅接收所选主题请在下方选择一个或多个分类。 选择主题 AI 与智能体 产品与 MVP 交付与 QA 领导力与团队 商业与监管 Web3 与隐私 我希望接收所选的 Wavect 博客邮件，并已阅读 隐私信息。我可以随时退订。 发送确认邮件→ 免费、双重确认、不使用跟踪像素。 ",
  "articleSection": "Engineering",
  "author": {
    "@id": "https://wavect.io/team/kevin-riedl/#person",
    "@type": "Person",
    "name": "Kevin Riedl",
    "sameAs": [
      "https://www.wikidata.org/wiki/Q139796365",
      "https://www.linkedin.com/in/wsdt",
      "https://github.com/wsdt"
    ],
    "url": "https://wavect.io/team/kevin-riedl/"
  },
  "dateModified": "2026-07-07",
  "datePublished": "2026-05-26",
  "description": "LLM 变好之后，专注力成了新瓶颈：约束不再是 agent 能不能写代码，而是操作者还剩多少注意力去验证输出、路由任务、保持上下文干净。超过某个并发数输出质量就下降，常见失败包括注意力切分、上下文渗漏、评测债和评审者疲劳。我们的实践规则：默认每位操作者并发两个 agent、epic 之间硬重置上下文、先建评测再并行、每天监督不超过 4 小时。",
  "headline": "专注力是新的瓶颈",
  "image": "https://wavect.io/img/blog/headers/header_focus-bottleneck-orchestrating-ai-agents.svg",
  "inLanguage": "zh",
  "mainEntityOfPage": {
    "@id": "https://wavect.io/zh/blog/focus-bottleneck-orchestrating-ai-agents/",
    "@type": "WebPage"
  },
  "publisher": {
    "@id": "https://wavect.io/#organization",
    "@type": [
      "Organization",
      "ProfessionalService",
      "LocalBusiness"
    ]
  },
  "url": "https://wavect.io/zh/blog/focus-bottleneck-orchestrating-ai-agents/",
  "wordCount": 333
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/",
      "name": "首页",
      "position": 1
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/overview/",
      "name": "博客概览",
      "position": 2
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/topics/leadership-teams/",
      "name": "领导力与团队",
      "position": 3
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/clusters/ai-teams/",
      "name": "AI 增强团队",
      "position": 4
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/focus-bottleneck-orchestrating-ai-agents/",
      "name": "聚焦是新的瓶颈 - 博客 | ",
      "position": 5
    }
  ]
}
```