瓶颈迁移定律
2026年5月27日 · 201 字 · 1 分钟 · AI Agent 系统工程
有一个数字经常被引用：95% 的 AI 项目失败了。据说从 GPT-3 到 Claude 4.7，纹丝不动。
这个数字是不是精确的 95%，不重要。重要的是它指向的东西是真的：模型在变强，但企业用不好 AI 这个现象没有改善。为什么？
常见的答案是「模型还不够强」。但这个答案解释不了一件事——不改模型，只动周边系统，性能就可以翻倍。
第一层：实验证据
AHE 论文做过一个实验。不改模型参数。只优化七个 harness 组件——工具定义、中间件、记忆、上下文压缩、验证策略、调度逻辑、错误恢复。十轮迭代。1
TerminalBench pass@1 从 69.7% 提到 77.0%，冲到全球第 3。
同一个实验藏着一个更重要的细节。单独编辑 system prompt 反而让性能退化 2.3 个百分点。不是 prompt 写得不够好。是「调 prompt」这个瓶颈已经被突破了。给模型更精确的指令不再产生收益。下一个瓶颈浮出水面：怎么定义工具的输入输出、怎么处理工具的异常返回、怎么在多个工具之间传递状态。
瓶颈迁移了。Prompt 曾经是瓶颈。现在不是了。Harness 曾经不是瓶颈。现在是了。
Harness 发生在软件层。往下看一层。
第二层：物理推导
Reiner Pope 从第一性原理推导过 LLM 推理的时间公式：推理时间 = max(T_compute, T_memory)。小 batch 时内存带宽是短板，大 batch 时计算才是瓶颈。2
关键在上下文。计算成本随上下文长度几乎不变，但内存带宽成本线性增长。每多 1K token context，就要多加载 1K token 的 KV Cache。
把上下文从 4K 扩展到 1M 之后，瓶颈从「模型能不能处理这么多 token」变成了「内存带宽能不能喂饱这么多 token」。模型够强。硬件跟不上了。
Agent 场景把这个问题放大了一个数量级。长任务 Agent 在第 40 步、第 80 步携带的不是几个 token——是代码库的快照、工具的历史输出、错误日志、中间决策。KV Cache 占用随步数线性膨胀。瓶颈从「Agent 够不够聪明」迁移到了「系统能不能管好 KV Cache」。
看起来是模型在退化。其实是瓶颈在迁移。
第三层：归纳推断
证据强度不同——前两层有实验和物理推导支撑，这一层是我的归纳。
AI 对工程师的效率提升，行业估算在 55-80% 之间。3 对市场部？没人敢报数字。
不是工程师更聪明。是工程工作有四个特性：bounded（边界明确）、checkable（可验证）、structured（结构化）、verifiable（可独立判断对错）。一段代码跑不跑得通，测试过不过——答案客观存在。
市场部的选题、品牌调性、用户洞察没有这四个特性。把 AI 放进去，它不是不工作。它工作了。但没人能判断它对不对。
一个合理的推断：模型瓶颈被突破后，流程的可验证性成为新瓶颈。不是模型不够好。是大多数组织的工作方式还没有为 AI 准备好验证层。
注意这个推断有一个替代解释。企业 AI 失败率不变，可能不是因为瓶颈迁移了——可能是因为企业在用更难的场景测试 AI，难度在同步升级。瓶颈未必在迁移，可能是起点在移动。这个替代解释目前没有数据能驳倒。我把它放在这里，因为诚实比完美重要。
模式
三个例证，一个模式。
第一层（实验证据）：Prompt → Harness。AHE 实验证明 prompt 瓶颈已被突破，harness 成为新瓶颈。
第二层（物理推导）：模型能力 → 硬件带宽。长上下文把瓶颈从模型推到了内存。
第三层（归纳推断）：模型 → 流程。模型够强了，但组织的工作方式不具备可验证性，流程成为新瓶颈。
每一次效率提升都没有「解决问题」。它只是把问题推到了更深的一层。
这不是一个精确的序列。真实系统里瓶颈可能并行、可能跳级、可能逆转。这里的顺序是例示，不是定律。你面对的系统，瓶颈可能是其中任何一层，也可能是还没列出来的层。
流程之后是什么？一个推测：当 AI 能执行任何流程，最稀缺的会变成「知道该执行什么流程」的人。
重要的是这个追问习惯：突破当前瓶颈之后，下一层在哪？
反面：熵增陷阱
瓶颈迁移有一个反面。当瓶颈无法迁移，系统不往外突破，往内耗。
PocketOS 的 Agent 删库事件是一个例子——没有权限门控时，系统消耗自身能量维持运转而非向外迁移瓶颈。
判断信号：团队花在「协调」上的时间超过了花在「突破」上的时间。瓶颈卡住时，人开始相互管理而非向外推进。
怎么用
不是哲学。是操作。
第一，识别当前瓶颈。
别猜。用数据找。问三个问题：
当前系统里，哪个环节的等待时间最长？不是感觉——是计时。Agent 等 API 返回的时间、工程师等 Code Review 的时间、产品经理等需求澄清的时间。瓶颈是等出来的，不是想出来的——哪里在等，哪里就是瓶颈的候选。
哪个环节的限制一旦放宽，系统吞吐量会增加最多？这是约束理论的核心问题——瓶颈不是最慢的环节，是限制全局产出的那个。一个 Agent 的推理速度慢 30% 可能不是瓶颈，如果它只有 10% 的时间在推理。但如果它在等工具返回的结果占了 60% 的时间，瓶颈在工具调用，不在模型。
哪个环节的改善在过去三个月里没有带来任何可见的系统级提升？如果 prompt 质量从 70 分提到 90 分但线上指标纹丝不动——这个环节的瓶颈已经被突破了。瓶颈在别处。
第二，预判下一层。
突破当前瓶颈之前，先问：暴露的下一层是什么？能处理吗？
如果下一层完全没能力处理——比如正在优化 prompt，下一层是流程审计，而组织根本不具备流程可验证性的基础——那当前最优策略可能不是突破当前瓶颈。是接受这层的不完美。至少知道极限在哪。
反过来，如果能预判下一层并提前布局，竞争对手在解决当前瓶颈的时候，已经在下层等他们了。AHE 实验团队冲到全球第 3，不是因为他们解决了「prompt 怎么写」。是因为他们在 prompt 瓶颈被突破之前，已经在设计工具合约、中间件和记忆层了。
第三，区分真瓶颈和假瓶颈。
一个具体例子。一个 10 人团队用 Claude Code 写代码。看起来的瓶颈是「AI 生成的代码质量不稳定」。突破方案是加 review agent、加自动化测试、加 lint 规则。三个月后代码质量稳定了。然后呢？新瓶颈暴露了——「需求说不清楚，AI 实现的和产品经理想的不一样」。从「怎么写好代码」迁移到了「怎么说清需求」。
如果团队一开始就预判了这一层，在优化代码质量的同时就开始训练团队写结构化的需求文档、建验收标准模板，就不会被新瓶颈打个措手不及。
反过来，如果三个月后没有新瓶颈暴露——代码质量稳定了，需求也一直清楚——怎么区分「真正突破了」和「认错了瓶颈」？看系统产出。突破了真瓶颈，产出会有可测量的提升：速度变快、吞吐量变大、某种约束消失。如果三个月没有任何可测量变化，要么是假瓶颈，要么瓶颈在更下层还没被碰到。两种情况下，都需要回头重新识别。
这个框架可证伪吗？
可以。证伪条件：如果你在一个系统上连续三轮改进，每一次都精准预判了下一层瓶颈并且全部成功处理，但系统整体产出没有显著提升——「瓶颈迁移」这个框架在你面对的系统上就失效了。三轮。
瓶颈迁移定律不教你怎么解决瓶颈。教你的是一件事：别在上一层的战场上打到弹尽粮绝。下一层的战场上已经有人在等了。