AI 编程工具的核心瓶颈已从模型转向编排框架

几个月前，我写过一篇文章，探讨的是我至今仍有的一种感受：AI 模型，尤其是编程 Agent，不再像以前那样给我那种巨大飞跃的感觉了。

我不是说它们没有进步。更新的模型通常会犯更少的错误，更好地遵循指令，有时还能解决旧版本无法解决的问题。但我越来越难把这些进步感受为真正的能力跃升。

最近，我看到一篇文章大致在论证：目前各模型之间已经没有好坏之分，只是行为不同，真正有好坏之分的是控制它们的工具链（harness）。文章甚至暗示，如果有人还在抱怨当前的模型，很可能是因为他们不知道如何正确使用或控制它们。

我同意其中部分观点。

但我认为走得太远就错了。

首先，我们需要把那些经常被混为一谈的东西分开。

模型不是 Agent。

GPT、Claude、Gemini、GLM 或任何其他 LLM 只是系统的一部分。在模型周围，有一整套基础设施：工具、上下文管理、系统提示词、规划、重试机制，以及许多其他东西。

That is, simplifying a lot, the harness.

换句话说，简化很多之后，这就是工具链（harness）。

在花了时间构建自己的编程 Agent 之后，我更加确信这一层至关重要。

你可以把完全相同的模型放进两个不同的产品中，得到完全不同的体验。

一个 Agent 可能在上下文管理上优于另一个。它可能有更好的工具、更有效地从错误中恢复，或者为模型提供更多完成任务所需的相关信息。

所有这些都会改变结果。

所以是的：仅仅因为某个模型在 X Agent 中表现不好就说"这个模型很烂"是不公平的。

但这和说模型之间已经没有好坏之分之间，有巨大的鸿沟。

对我而言，一个 Agent 的结果更像这样：

Result = model + harness + context + tools + instructions + task

显然，这不是真正的数学公式，但它有助于理解问题。

改变工具链，结果就会改变。

改变模型，结果也会改变。

我在类似环境中使用不同模型时，多次看到这种情况。

我试过一些模型，纸面上据说与前沿模型相当，但在同样的项目中它们表现就是更差。它们需要更多修正、更频繁地忘记指令，或者做出更差的决策。

工具链实际上还是一样的。

改变的是模型。

这就是为什么我不认为我们可以把模型之间目前的所有差异都简化为简单的"行为差异"。

如果某种行为导致一个模型完成任务的正确率远高于另一个，这种差异最终会成为实际的能力差距。

我认为这是整个讨论中最有趣的部分。

几年前，问题是：

它能构建一个应用吗？它能修改多个文件吗？它能理解错误并修复它吗？

今天，对于其中许多问题，答案简单就是"能"。

问题现在不同了：

它能正确且一致地完成吗？

因为模型能做某件事，不代表你能相信它每次都正确地做到。

而这正是我仍然看到重大问题的地方。

最近，我在用一个已有项目做 Claude Code 的实验。

我明确告诉它我不想用 alert() 做确认，这个应用应该用模态框。

Claude Code 理解了这个指令。

在我们工作的那部分，它正确地把 alert() 替换成了模态框。

但后来在系统的另一个相关部分，它留下了另一个 alert() 没有处理。

我认为这是当前许多 Agent 状态的一个很好写照。

系统知道怎么做。

它理解了我的指令，甚至已经证明它知道如何实现正确的替代方案。

然而它没能把这个决定贯彻到整个项目中。

这个例子有趣的地方在于，我用的不是自己刚搭建的实验性工具链。我用的是 Claude Code，一个专门为 Agent 化处理代码库而设计的工具。

所以一个重要的问题出现了：

如果我从未给出过这个指令，那可能是我的错。

如果这个指令从上下文中消失了，那可能是工具链的问题。

如果它从未检查过项目中其他相关部分，那可能是 Agent 的问题。

但如果模型有这个指令、有必要的代码访问权限，却仍然忽略一个明确的约束，那在某个时刻我们必须接受一个相当简单的事实：

the model made a mistake.

不是所有失败都必然是工具链的失败。

我认为这里有一个重要的混淆来源。

如果我们知道模型经常忘记某些约束，我们可以构建系统来审查它们的工作、运行测试、重试失败的尝试，或反复将重要的项目规则重新插入上下文中。

所有这些都能显著改善最终结果。

但有一件事我们不应该混淆：

我们不一定是让模型变得更聪明了。

我们构建的是检测、防止或纠正其错误的机制。

这也是进步。事实上，这是构建 Agent 极其重要的一部分。

但好的工具链通常并不能消除模型的局限性。

它是在补偿这些局限性。

而且如果运行得足够好，它甚至可以让这些局限性对用户几乎不可见。

这也让衡量进步变得更加复杂。

如果新版 Agent 感觉好很多，是模型本身真的改进了吗？上下文管理改进了吗？它们加了审查阶段吗？它在放弃前现在会更多地重试吗？

从外部看，所有这些经常被笼统地总结为"AI 变强了"，尽管严格来说这些是非常不同的东西。

我认为这是我觉得模型进步越来越慢的原因之一。

在 LLM 开发的某些阶段，跃升是非常容易注意到的。

以前，一个模型根本做不到某项任务。

这是一个质的飞跃。

至少对我的感受而言，现在是不一样的。

现在的许多进步看起来更像是模型少犯了一些错误、少需要几次尝试，或在更长的任务中保持正轨。

这仍然是进步。

在生产环境中，这可能非常有价值。

但它不像拥有一个聪明十倍的模型。

它感觉更像是一个不那么脆弱的模型。

也许我们正在进入一个阶段，许多可见的进步是可靠性的提升，而不是全新的能力。

这也解释了为什么有时尝试新模型让我感觉相对平淡。

它可能少犯了一些错误。

但我仍然需要审查它的工作、纠正奇怪的决策，并验证它确实完成了我要求的所有事情。

这个跃升仍然不够大，不足以彻底改变我的工作方式。

还有另一个我不断看到的局限性：模型在从零开始创建软件方面比在现有系统上工作要好得多。

当模型开始一个新项目时，它拥有巨大的优势。

它可以选择架构、建立自己的约定，并创建所需的抽象。

从某种意义上说，它是在一个由自己刚刚创建的世界中解决问题。

在现有项目上工作是截然不同的。

现在它必须理解已经做出的决策、找到依赖关系、尊重约定，并避免破坏现有行为。

它必须重建一个接近已经了解该系统的开发者的心智模型。

这正是我仍然看到大量问题的地方。

有时生成的代码单独看是正确的，但完整的变更仍然是错的。

一部分使用了新的实现，另一部分继续使用旧的。一个组件被改了，但依赖它的每个地方没有被全部改到。或者某个现有的设计决策在项目的其他地方被破坏了。

AI 可能理解每个单独的部件，却仍然失去全局一致性。

这就是为什么我认为描述当前问题的一种方式是：

LLM 在生成代码方面比在复杂系统中维护不变量方面要好得多。

在真实软件工程中，这非常重要。

一个新的着陆页可以从单个提示中做得相当好。

修改一个花了数月或数年积累决策、依赖和约定的应用是另一回事。

而在这里，我仍然没有感觉到我们看到了通常宣传的那种巨大飞跃。

这是关于"如果有人抱怨当前模型，他们只是'不知道如何控制它们'"这个想法最困扰我的部分。

因为这很容易变成一个不可证伪的立场。

如果模型运行良好，那就证明模型是好的。

如果它表现糟糕，那就是工具链不好。

如果有人得到更差的结果，他们就是不知道如何正确使用。

在什么时候我们才能被允许接受模型本身Simply有局限性？

如果每个失败都可以事后被解释为模型外部的问题，那么我们就创造了一个永远不会输的假设。

而且这不是评估技术的一种特别有用的方式。

当然，我们应该改进我们的 Agent，并学习更好地使用模型。

但我们也应该能够说：

模型在这里失败了。

而不是自动地把错误变成用户的错。

还有另一点：当我们需要围绕模型构建越来越多的层以确保它正确完成任务时，这些层也在告诉我们关于模型局限性的某些信息。

工具链的存在恰恰是因为仅靠模型是不够的。

这不是对工具链的批评。

这是它存在的理由。

类似的事情也发生在这样一个观点上：模型会变得如此智能，以至于提示工程不再重要。

我确实认为它已经改变了。

我不再认为在提示中填满奇怪的短语或寻找神奇词汇组合非常有用。当前的模型理解正常指令要好得多。

但这不意味着结构化指令不再重要。

如果我希望 Agent 先检查现有实现、尊重某些约束、并避免修改项目的特定部分，告诉它这些仍然是有用的。

提供相关上下文并明确定义预期结果仍然很重要。

也许提示工程只是演变成了更大的东西：上下文工程。

我们不再只考虑我们输入的句子。

我们在思考模型在做出每个决策时需要知道什么信息。

而这与工具链设计直接相关。

我还认为有另一种现象在起作用。

当前的模型已经跨越了一个相当高的能力阈值。

好的模型可以编写代码、理解现有代码、使用工具，并完成多步骤任务。

一旦它们都超过了这个最低水平，差异就不再那么显著了。

一个成功完成我85%任务的模型和另一个完成90%的模型，在对话中可能感觉相对相似。

而它们两个都仍然可能在五分钟后做出极其愚蠢的事情。

剩下的错误百分比也可能恰好出现在工作中最困难的部分。

所以两个看似矛盾的陈述可以同时成立：

当前模型能力超群。

当前模型仍然令人沮丧地不可靠。

我认为两者都是真的。

也许这就是为什么今天的许多比较更多地关注小的百分比改进，而不是全新的能力。

这不意味着这些改进无关紧要。

它只是意味着它们并不都代表智力的重大飞跃。

但我认为我们在谈论这些进步时应该更精确。

有时是模型改进。有时是工具链改进、工具改进，或者仅仅是我们使用它们的方式改进。

而且通常所有这些都在同时演进。

把所有东西都归入一句"AI 现在聪明多了"，就很难理解我们实际看到的是什么样的进步。

我目前的印象是，编程 Agent 最近很大一部分改进来自于为已经极具能力的模型构建更好的系统。

这不意味着模型停止了改进。

这也绝对不意味着所有模型都是等价的。

它意味着我们正在推进的前沿可能已经改变了。

多年来，我们一直在努力让模型能够做新的事情。

现在的挑战可能是让它们可靠地做我们已经知道它们能做的事情。

因为 AI 能够写一个应用已经不再让我那么惊讶了。

让我惊讶的是，能够让它在一个真实代码库上工作几小时，回来后发现它理解了现有的决策、保留了重要的约束，没有留下一堆我现在需要追着修复的小错误。

对我来说，这将像是另一次真正的飞跃。

也许 Agent 的下一个重大突破不会是让它们做新的事情。

也许是让它们可靠地、一致地、无需持续监督地做它们已经知道如何做好的事情。