Chunlin 的论文科普

AI 写代码越来越慢，是模型变笨了还是框架的锅？

LLM 与智能体

你有没有过这种体验：用 AI 编程助手，前一天还好好的，今天突然就变笨了——同样的问题，之前能一次改对，现在反复试错、token 烧了一堆还不解决。你第一反应是不是：模型又偷偷更新退化了？

这个直觉很自然，毕竟大模型是整个系统里最”黑盒”的部分，出了问题不找它找谁？但最近的一项研究给出了一个反直觉的答案：很多时候，锅真不在模型，而在你和模型之间那层你可能从没注意过的中间件。

为什么你总觉得「AI 编程助手越更新越难用」

先给个直觉：你用的 AI 编程助手，并不等于”大模型直接写代码”。在你和大模型之间，还有一层叫做**代理中间件（agent harness）**的软件层——它负责组织系统提示词、调用工具（比如读文件、跑测试、查文档）、管理上下文窗口、控制多轮推理的循环节奏 [1]。你可以把它想象成导演：大模型是演员，导演怎么说戏、给什么道具、安排什么场次，直接决定了最终成片的质量。

问题是，这层中间件的演化速度，快得离谱。研究统计了 5 个主流开源编码代理中间件，发现它们平均每周发布 1.5–18 次，每天有 2.8–34 次代码提交，PR 的中位审查时间不到 4 小时 [1]。作为对比，VS Code 每周才发布 0.8 次，GitHub CLI 每周 0.6 次——也就是说，最激进的中间件项目，更新速度是成熟开发工具的 20 多倍。

这么快的迭代速度，质量波动几乎是必然的。但用户感知到波动时，几乎都会默认是”模型变笨了”，很少怀疑中间件。这也难怪：中间件藏在后台，更新日志你可能都不会看，而模型是那个”输出答案”的角色，自然成了背锅侠。

一个疯狂的实验：把模型焊死，只换中间件

怎么证明波动来自中间件而不是模型？最直接的办法就是做受控纵向实验：把模型彻底固定住，只换中间件，看质量会不会变。如果模型没变、质量却上下跳，那锅就肯定在中间件 [1]。

这个思路说起来简单，做起来却不容易——你得真的能把模型”焊死”。很多研究是反过来的：固定中间件，换不同模型来比好坏；但要固定模型、换 35 个版本的中间件，就得保证模型从头到尾一个权重都没变，连 API 服务端的隐式更新都不能有。

研究团队选了 Qwen Code CLI 这个开源中间件做深潜，用本地 vLLM 部署 Qwen3-Next-80B-A3B-Instruct 模型——相当于把模型关进了一个不会变的”小黑屋”，然后依次测试了从 v0.0.10 到 v0.10.3 的 35 个连续版本 [1]。任务方面，他们从 SWE-bench Verified 里分层抽了 50 个 bug 修复任务（20 个简单、25 个中等、5 个困难），每个任务跑 2 次取平均，用标准 Docker 环境评测，保证任务本身也不会变 [1]。

衡量的维度有两个：一个是有效性，也就是能不能把 bug 修好（解决率）；另一个是效率，也就是修这个 bug 花了多少 token、调用了多少次工具 [1]。毕竟光解决问题不够，烧钱太多也不行。

当然，实际情况比这个比喻更复杂——中间件的版本演化不是随机的，开发者是在有意识地加功能、修 bug，所以我们还能进一步分析：什么样的改动会提升质量，什么样的改动反而会拖后腿。

35个版本跑下来，我们发现了什么？

实验结果可以用一句话概括：解决率没怎么涨，token 消耗却接近翻倍 [1]。

具体来说，35 个版本迭代下来，bug 解决率没有统计学上的显著提升——也就是说，过了这么多版本，中间件”能不能修好 bug”这件事，整体上没什么进步。但代价却涨了：后期版本的 token 用量和工具调用次数，在部分场景下几乎是早期版本的两倍，却没有换来对应的质量提升 [1]。

更有意思的是不同开发模式的差异。研究把版本分成”功能密集型”和”修复密集型”两类，发现：

还有两个反直觉的细节：平均 PR 尺寸越大，token 消耗反而越低；删代码越多，token 消耗也越低 [1]。一个合理的猜测是：小步快跑的零散修改，容易引入零碎的逻辑分支，让代理在决策时更犹豫、走更多弯路；而大刀阔斧的重构和清理，反而能让系统路径更清晰，减少无效尝试。

那哪些组件最容易出问题？研究自建了一个 10 组件的参考架构，把每次提交映射到对应组件，发现 LLM Provider 层和上下文管理（Context Management） 是最高风险的组件——改这两个地方，最容易导致质量下降；而扩展性和安全组件的改动相对安全，很少带来质量波动 [1]。

「烧 token」的不止中间件：语言和任务也在偷偷加成本

中间件演化是效率下降的重要原因，但不是唯一原因。另外两项研究提醒我们：效率问题是多层因素叠加的结果，从模型本身的行为模式，到任务的具体特性，都在偷偷消耗你的 token。

先看编程语言的影响。你可能以为代码越长的语言越费 token，但实际情况是：模型越不熟悉的语言，越烧 token [2]。一项对比 Python、Java、Rust、OCaml 四种语言的研究发现，控制问题难度后，模型在 OCaml 上的 token 消耗是 Python 的 1.28–1.69 倍，而且这个差异在 5 个不同模型上一致存在 [2]。

为什么会这样？轨迹分析揭示了几个有趣的行为模式：

再看任务类型的影响。比如表格推理这种任务，如果你直接把整个表格丢给模型，大表格下有些方法直接就”罢工”了——输入塞不下，根本没法跑，准确率直接是 0% [4]。而 ProgramTab 这类框架的思路是：先用 Python 代码把表格洗干净、筛掉无关的行和列，再用 SQL 提取关键信息，这样模型只需要处理很小的子表，自然就省 token 了 [4]。

换句话说，token 浪费不是某一层的问题：模型本身的行为习惯、中间件的流程设计、任务的呈现方式，每一层都在往里加成本。

从「能不能写」到「写得好不好」：编码代理研究的三次转向

这篇关于中间件演化的研究，放在编码代理研究的大脉络里看，其实代表了一个新的阶段。我们可以粗略地把这个领域的研究分成三次转向：

第一次转向：从「能不能做」到「真实环境能不能做」。 早期的编码代理评测，大多是在预置好的环境里测——依赖都装好了，项目结构都给你理清楚了，只要写代码就行。但 SetupBench 这类基准告诉我们：真实世界里，光是把开发环境搭起来，就是个大难题。最先进的代理在仓库环境搭建上成功率只有 38.9–57.4%，本地数据库配置更是只有 20.0–53.3%，而且 38–89% 的动作都是不必要的探索 [6]。这时候研究的核心问题从”会不会写代码”变成了”能不能在真实环境里干活”。

第二次转向：从「结果对不对」到「过程好不好」。 光看最终成功率不够，我们还得知道：成功的代理是怎么成功的，失败的代理又是怎么失败的？对 OpenHands、SWE-agent、Prometheus 三个主流代理的轨迹分析发现：成功的轨迹会用不同的策略（比如防御式编程、充分的上下文收集），而失败的轨迹普遍更长、方差更大；更有意思的是，哪怕失败的轨迹里，也有 72–81% 能正确定位到出问题的文件，成败更多取决于修改是不是”差不多对”，而不是定位准不准 [7]。这时候研究的核心问题从”结果成没成”变成了”过程有什么差异”。

第三次转向：从「静态评测」到「长期演化质量」。 前面的研究都是在某个时间点截个断面、测个分数，但真实世界里的编码代理是在不断迭代的——中间件在变，使用方式在变，代码库本身也在变。Cursor AI 的研究就发现：用 AI 编程助手短期确实能大幅提升开发速度，但会持续增加静态分析警告和代码复杂度，而这些复杂度最终又会反过来拖慢长期的开发速度 [8]。而我们今天讲的这篇核心论文，更是把研究推进到了中间件自身演化的纵向影响这个新维度——它不问”哪个中间件好”，而是问”中间件一直在变，这个变化本身怎么影响质量” [1]。

从”能不能写”到”写得对不对”，再到”长期写得好不好、效率高不高”，研究的关注点越来越贴近真实的工程实践。

然后呢：我们还不知道的事

说了这么多，这篇论文的结论也不是放之四海而皆准的。它有几个明确的边界，我们得心里有数：

第一，它只深入研究了 Qwen Code 这一个中间件。为什么只选一个？因为要严格控制模型不变，就得支持本地模型端点，不是所有中间件都满足这个条件 [1]。其他 4 个主流中间件是不是也有同样的规律？目前还不知道，需要更多类似的纵向研究。

第二，它只用了一个模型。Qwen3-Next-80B 上的现象，换更小的模型、换闭源模型会不会不一样？比如小模型可能对中间件的提示词设计更敏感，波动可能更大？这也得进一步验证 [1]。

第三，任务场景有限。实验用的是 SWE-bench 的 bug 修复任务，而且只抽了 50 个，没有包含最难的 Very Hard 级别，也没有测加新功能、重构、写测试这些其他开发场景，更不用说真实工业界的复杂任务了 [1]。

还有很多开放问题悬而未决：工业界真实的多项目、长周期场景下，中间件演化的影响会不会更大？怎么设计中间件才能在加功能的同时不牺牲效率？有没有办法自动检测中间件更新带来的质量退化，而不是等用户吐槽了才发现？

这些问题，都还没有答案。

如果你只记住一件事

下次你觉得 AI 编程助手变笨了，先别急着骂大模型——很可能只是它的”导演”（中间件）又更新了一版，把流程改乱了。编码代理的质量是模型、中间件、任务、语言多层因素共同决定的，而迭代最快、最容易出波动的，恰恰是最不显眼的中间件层 [1]。

毕竟，在一个每周更新十几次的系统里，不变才是意外，波动才是常态。

参考文献

  1. Don t Blame the Large Language Model: How Agent Harness Evolution Shapes Coding Agent Quality（arXiv、2026、全文精读）
  2. The Best Programming Language for Tokenmaxxing: An Investigation of Coding Agent Behavior Across Programming Languages（arXiv、2026、全文精读）
  3. ReasFlow: Assisting Reasoning-Centric Scientific Discovery in Applied Mathematics via a Knowledge-Based Multi-Agent System（arXiv、2026、全文精读）
  4. ProgramTab: Boosting Table Reasoning of LLMs via Programmatic Paradigm（arXiv、2026、全文精读）
  5. KyrgyzLLM-Bench: Benchmarking Kyrgyz Language Understanding（arXiv、2026、全文精读）
  6. SetupBench: Assessing Software Engineering Agents Ability to Bootstrap Development Environments（ArXiv.org、2025、仅摘要）
  7. Understanding Code Agent Behaviour: An Empirical Study of Success and Failure Trajectories（ArXiv.org、2025、仅摘要）
  8. Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects（ArXiv.org、2025、仅摘要）