我在重新思考智能代理编码工作流中的执行层时学到的东西

我在2025年初带领工程团队转向智能代理编码工作流，虽然不是全面切换，但已经足以开始奠定基础性的变革。然后在第四季度，我们彻底撕掉创可贴，全面投入。正如大家所知，@mattshumer_ 在他的文章中指出，今年二月一切发生了翻天覆地的变化，而我更加庆幸我们趁早做出了这些调整。

如果你还没读过马特的文章，并且仍然生活在2026年2月之前的思维或实践模式里，请先读那篇文章再继续往下看。在我看来，这是了解我们现在身处何方的必读材料——如今我们拥有来自OpenAI、Anthropic以及现在的SpaceXAI等公司的现代推理模型。

Matt Shumer @mattshumer_ · 2月11日 文章
大事正在发生
回想2020年2月。
如果你当时密切关注，可能会注意到少数人在谈论一种病毒在海外蔓延。但大多数人并未密切关注。股市……
6.5万 41万 11.8万 87万

现在我们有了一个全新的模型类别，随之而来的还有新的智能代理编码工作流，通常分为三个层次：

• 编排
• 执行
• 代码审查

在继续之前，我想分享一点历史背景，因为这听起来像是新概念，但实际上是一个非常古老的概念。信不信由你，它来自斯坦福大学的一个AI实验室，时间是1975年——没错，51年前。

这个概念最初由Earl D. Sacerdoti提出，并在一篇题为《计划的非线性本质》（The nonlinear nature of plans）的论文中发表。

是的，今天你仍然可以读到这篇论文，它在网上多处发布，这里有一个阅读地址。

随后的五十年里，无数论文发表，继续阐述和发展这一主题。最近一篇更直接地应用于目前已成为行业标准的智能代理编码工作流的论文，来自普渡大学，发表于去年十月，标题是《面向多智能体系统的验证感知规划》（Verification-Aware Planning for Multi-Agent Systems）。

这篇论文既讨论了当前的智能代理编码模型（即将其分解为三个层次），又提出了一种名为VeriMap的优化方法以进一步优化。如果你想读这篇论文，这里是链接。

我就此打住历史课，但我的观点是，这个概念自70年代就已存在，而在过去几年中，它被应用于现代智能代理编码工作流，并且人们仍在不断深入思考。

对我作为CTO、带领工程师团队的人来说，我能看到这一切在实践中如何融合。过去一年里，我学到了很多，尤其发现这个工作流在执行层存在一个我认为真正的缺陷——目前我正在和团队测试不同的解决方案。

那么执行层的问题出在哪里？

当前框架的问题是（通常）为编排选择一个模型，比如擅长规划的Opus；然后为执行选择另一个模型，比如Composer 2.5或GLM 5.2；再用第三个模型运行验证/代码审查步骤——最近我喜欢用Grok Build来做这件事。

现在你可以根据任务的复杂程度在每个位置更换模型。假设任务的复杂程度较低，你可能可以使用中等推理努力的Opus，然后在执行层选择Composer 2.5或DeepSeek v4。在某些情况下，这就能解决问题。

挑战在于，对于更复杂的任务，人们往往选择像Opus 4.8 High或Extra、或GPT 5.5 High或xHigh这样的模型来执行。虽然这些模型通常更擅长处理复杂任务，但它们也会思考更多、消耗大量token。

这就是我几个月前的顿悟时刻。

几乎所有复杂任务，并非在任务的每个方面都同样复杂。事实上，通常只有任务的一部分是高度复杂的，其中也常常包含相对容易的部分，以及一大块中等难度的编码工作需要完成。

通过在执行层只选择一种模型，并说“嗯，这是一个非常复杂的任务，所以我们需要Opus 4.8 Max来确保正确完成”，你最终会用同一个模型来处理简单、中等和困难的部分——而这个模型思考时间长、调用大量工具、消耗巨量token。

实际上，对于那个复杂任务，是的，你很可能需要Opus 4.8 Max或GPT 5.5 xHigh的马力，但只需要用它处理其中的20%。其余部分可能可以用另外两个模型来完成：一个处理简单任务，另一个处理虽不太简单但也不疯狂困难的任务。

在过去的几个月里，我一直在大量实验这种新模式，对更复杂的任务在执行层使用三个模型。我发现了非常有意义的提升——既体现在速度上，也体现在最终代码质量上，同时token使用量显著减少。

为了实现这一点，我一直在编排层进行更详细的定制，因为不应该由我渺小的人类大脑来琢磨如何将任务最优地拆分成三个组件——一个极其聪明、深度思考的LLM可以轻松击败我，并且能随时间不断学习。

但我现在使用的模式是：创建一个计划，然后将这个计划传递给一个执行层编排器。这个编排器知道我有哪些可用的模型，然后在将计划按难度和所需思考深度分成三个不同部分后，不仅选择模型，还选择模型运行的推理努力级别。

我不知道该给这种方法起什么名字，暂时就叫它“执行模型路由器”。我相信以后会想出更好的名字。

我能说的是，如果你在领导一个工程团队，并且让每个人都只使用Opus High或GPT 5.5 High来处理所有事情，我可以向你保证，你在token上过度花费了，同时由于过度使用这些模型的思考深度导致速度更慢。但如果你更进一步，决定用不同的模型来做编排、执行和代码审查，我认为你仍然没有正确优化模型使用，特别是在执行层。

看看你的团队有多少时间在使用高思考深度的模型来编写代码。虽然你应该使用Opus 4.8 High或Extra、或GPT 5.5 High或xHigh的马力来编写部分代码，但如果执行层只用这些，那么还有一条真正的优化路径可以走。

当然，当你向团队部署了一个工作流后，做出改变可能很棘手，但与此同时，如果你发现自己为了获得相同的代码质量和更快的速度，用了2到3倍的token，那又该如何？我认为人们实际运用这一点后会看到这些token效率，并且速度提升巨大。

像这样将执行层分成三部分，也意味着你几乎不需要再使用模型的“快速”模式，甚至完全不用。相反，像Opus 4.8 Medium，或者如我几周前分享的Fable Low这类模型，速度非常快——虽然你不会把它们扔给高复杂度的任务，但它们能很好地处理常规任务，而且只需几分之一的成本和token，当然也比更高推理努力/思考深度的模型快得多。

好吧，我想把这一切从脑子里搬出来公之于众，既然我已经研究了几个月，并且看到了效果，我确信这里有些有价值的东西。

最重要的是，我希望任何工程领导者读到这篇文章，都能更深入地思考他们的团队在执行层是如何看待模型和推理努力水平的。如果你的团队总是只用高努力模式下的模型，这就是一个容易开始深入思考的切入点。

后续还有更多内容，我一直在摆弄一些相关的有趣工具，希望能尽快分享更多，但就目前而言，这就是我脑中思考的东西，我很兴奋能进一步探索它。