你只需要前沿模型进行单次编辑

# 你只需要前沿模型进行一次编辑 来源：https://stencil.so/blog/prewalk 猴子看，猴子做！🍌 97%的前沿性能 成本降低41% 完成速度提升1.9倍 作弊概率降低约3倍 成本 vs 通过率，7个分支 · SWE-Bench Pro · 裸模型 = 单次 · $/任务包含前沿模型的初始轮次 · † 使用 Flash 3.5 执行 · ‡ 使用 5.6 Luna 执行 ## /plan 看似合理。其实根本不该这样！ 你听过这套说辞，甚至可能已经上线过。昂贵模型显然是更好的架构师，但把它用于整个流水线感觉浪费。为什么不让它做“困难的部分”？阅读代码、深度思考、写出精确计划。然后用一个价格只有十分之一的模型来执行计划。高级架构师，初级工程师。听起来很棒，对吧？ 找到上面标有 `Opus 4.8 + /plan†` 的红点。Opus 只读模式规划，Gemini Flash 实现：**每个任务3.18美元，12.7分钟，通过率84.6%**。Opus 独自完成整个任务，没有交接，没有初级模型：**2.78美元，10.1分钟，通过率84.6%**。这个“节省成本”的措施，反而比不节省多花了14%。**啊？** 它读取所有内容·$$$ 再次读取所有内容·$$ 🗒️ 代码 · ~10万tokens opus · 规划 plan.md · 一张2K tokens的明信片 flash · 实现补丁 · ~2K tokens 错误出在架构图的上游。人们给智能体定价的方式和给人定价一样：高级人员的时间贵，所以尽量减少高级人员参与。但智能体的昂贵部分不在于修复、构建、甚至思考。**Opus 修复东西不花钱。Opus *阅读*东西才花钱。** 看一下下面这个基于经验的数据分布（我们 token 的去向）；全自动智能体毫无二致。18.1亿 tokens 跨越约200万次工具调用 · “执行任务”（每次编辑和写入）占9%；阅读才是账单增长的来源，两个模型都按全额支付。 百分之九的 token 是编辑。其余都是阅读，这种分离不是某个框架的特性，也不是你能“修复”的。信我们，我们试过——正是这样才诞生了 snapcompact (https://stencil.so/blog/snapcompact)。任何智能体、任何模型、任何框架：账单本质上就是 `O(读取)`。 现在，带着这个认识，重新审视每一个你会用 /plan 的理由： - **“我想要大模型的深度理解。”** 理解存在于超过10万tokens的扎实上下文中：读取的文件、排除的死胡同、检验的假设。计划文档是一张2K tokens的明信片，从那个上下文寄出。执行者得到的是明信片，而不是理解，并且必须自费重建其余部分。 - **“任务非常复杂。”** 那么你根本不希望主体智能体去*执行*；一个只读的规划轮次不是答案。让它探索，然后派遣子智能体去做工作。传话游戏在这里帮不了你。 - **“我成本受限。”** 阅读就是成本。/plan 让前沿模型以前沿价格读取一切，然后让廉价模型*再次*读取。你没有移动昂贵部分；你把它复制了一份。 以下是实际中的表现，附一张我们花了太多时间的示意图： OPUS 4.8 + /PLAN† · $3.18 `bash opus read opus bash opus bash opus read opus bash opus read opus read opus read opus grep opus read opus read opus grep opus grep opus read opus read opus read opus ¶¶ prose opus read opus recon: sessions ▸ signing write opus resolve opus ▸ flash plan read flash read flash edit flash read flash edit flash edit flash read flash bash error flash grep flash edit flash grep flash read flash edit flash bash flash bash flash ¶¶ prose flash verify ▸ debug ▸ pass` Σ1.34M OPUS 4.8 · 相同任务 · $2.78 `bash opus read opus read opus bash opus bash opus read opus grep opus read opus read opus bash opus read opus grep opus recon: sessions ▸ signing edit opus read opus edit opus fix read opus edit opus bash opus grep opus read opus grep opus read opus edit opus tests ▸ debug warnings bash opus bash opus bash opus read opus ¶¶ prose opus verify ▸ close` Σ1.10M OPUS 4.8 + /PREWALK† · $1.46 `bash opus read opus nudge read opus bash opus bash opus read opus read opus bash opus read opus ¶¶ prose opus todo opus recon ▸ plan edit opus ▸ flash fix read flash edit flash todo error flash todo flash tests bash error flash grep flash grep flash read flash read flash edit flash bash flash debug warnings grep flash read flash grep flash grep flash bash flash todo flash todo flash ¶¶ prose flash checks ▸ close` Σ1.13M `opus flash read write exec todo ¶ prose error harness event Σ tokens` django-13279 测试运行 † 使用 Flash 执行 看顶部的条带。Opus 读取 `base.py`、`signing.py`、测试文件（二十张灰色卡片），然后写出计划并离开。Flash 拿到那份漂亮的文档后做的第一件事是什么？它重新读取 `base.py` 和测试文件，因为计划不是文件，你无法编辑散文。灰色的读取不断累积，先以 Opus 的价格，再以 Flash 的价格。没有任何版本能让第二个读者成为成本优化方案。 ## 传递轨迹，而不是童话 计划文档是一张字面意义上的明信片，描述了一段从未经历过的旅程。真正能传递价值的是上下文窗口本身：`/prewalk` 就是这样做的： 1. 在前沿模型上开始任务，并附加一条隐藏指令：*深入规划，然后将计划捕获为待办列表，然后开始。* 2. 前沿模型探索、写出计划、初始化待办列表。 3. 在**第一次编辑落地**（即模型足够自信并采取行动的节点）的那一刻，你切换到廉价模型，并从上下文中**裁剪掉规划指令**。 关键在于： - 廉价模型永远不会想“等等，我以为我们在规划。”它的上下文中已经没有规划指令。 - 就它所知，它探索了一番，创建了一个全面的计划（以待办列表形式），然后自信地开始执行。 - 更棒的是，它已经**做了一次有效操作**！*（一个免费提供上下文中的例子）* 5.6 SOL + /PREWALK‡ · $1.04 `read sol nudge ¶¶ prose sol todo sol orient ▸ plan grep sol glob sol grep sol ls sol read sol read sol read sol read sol read sol read sol grep sol grep sol read sol read sol grep sol read sol grep error sol recon: mti internals todo sol todo sol edit sol first edit ▸ luna bash error luna edit luna swap ▸ fix todo luna todo luna bash luna todo luna grep luna bash luna bash luna todo luna todo luna ¶¶ prose luna verify ▸ close` Σ710K 5.6 SOL · 相同任务 · $1.71 `read sol grep sol grep sol read sol read sol read sol grep sol glob sol read sol ¶¶ prose sol read sol read sol read sol grep sol read sol read sol read sol recon: mti internals grep sol grep sol read sol read sol bash sol bash sol bash sol git archaeology todo sol eval sol bash sol eval sol bash sol read sol grep sol repro script read sol read sol read sol read sol read sol read sol read sol read sol read sol read sol cheats off of 🗒️ 🤣 todo sol edit sol eval sol fix read sol read sol read sol edit sol tests grep sol grep sol bash sol grep sol grep sol read sol bash sol bash sol todo sol ¶¶ prose sol suite ▸ close` Σ1.78M `sol luna read write exec todo ¶ prose error harness event Σ tokens` django-12325 测试运行 ‡ 使用 Luna 执行 ### 我们是如何走到这一步的 在开源框架中工作的好处是，你可以和人们交流他们如何做事，几乎每个人都有一个完全不同的设置。总之：我偶尔会用前沿模型开始简单到中等难度的任务，然后在几个回合后切换到 Kimi K27，这样它就不会陷入常见的思考循环。我从没费心去衡量这是否合理……直到别人提到也在做同样的事情。很自然地，我们必须对其基准测试：我们是傻吗，还是这确实有效，并且在什么时候有效？ **第一次尝试：** 在固定回合切换，比如第4回合。事后看来明显不好：有时前沿模型在第四回合仍然迷失，有时它已经完成了整个修复。 **第二次尝试：** 在第一次编辑后切换。模型已经在合适的位置、以合适的风格展示了一次模式。很不错，但仍然不稳定：小模型会莫名其妙地声称任务完成。解决方案是让我们不知情的指挥智能体逐步列出计划，然后，当它准备好执行时，初始化一个待办列表，每个项目带有验证步骤。然后它编辑某段代码，这时我们触发切换。仅依赖任何编辑本身不好；待办列表仍然扮演着非常重要的角色。我们的小家伙可能会忘记计划、验证步骤或它正在做的事情，但它无法忘记那个不断烦扰它的待办提醒，这给了我们免费的引导。 另一个有趣的失败模式：GPT 5.6 作为引导者非常喜欢创建60项的待办列表并批量完成（他们是不是随便给什么都奖励？），所以提示中必须设置项目数量限制。 ### 数据 **GPT-5.6 Sol：** | 分支 | pass | cost | duration | |------|------|------|----------| | Executor: oneshot (GPT 5.6 Luna) | 77% | $0.60 | 570s | | /prewalk | 85% (+10%) | $1.04 (-39%) | 300s (-47%) | GPT 5.6 Sol: oneshot 88% $1.71 372s Sol 通过率的97%，成本为其61%，而且是**三者中最快的**，因为 Sol 在开场后停止消耗缓慢的前沿 tokens，而 Luna 不会在丛林中浪费回合。 **Opus 4.8：** | 分支 | pass | cost | duration | |------|------|------|----------| | Executor: oneshot (Gemini Flash 3.5) | 60% | $1.16 | 360s | | /prewalk | 78% (+30%) | $1.46 (-47%) | 402s (-34%) | Opus 4.8: oneshot 85% $2.78 606s Opus 的92%，成本为其53%，速度1.5倍，比 oneshot Flash 高18个百分点。 在继续之前，滚动回上面来自 django-13279 测试运行的条带 (https://stencil.so/blog/prewalk#django-13279-ribbons)，找一下**不存在**的东西：作弊！ ## 我们没预料到的效果 每个 SWE-bench 任务都是一个多年前在公开资源中真正修复过的 bug。考试答案就在 GitHub 上。下面：去网上搜索答案的运行比例。**肮脏的作弊者！** | 模型/配置 | 作弊比例 | 工具调用次数 | |------------|----------|--------------| | Claude Opus 4.8 oneshot | 44% | 163t | | /plan | 72% (+28pts) | 273t | | /prewalk† | 13% (-31pts) | 65t | | GPT-5.6 Sol: oneshot | 95% | 234t | | Luna: oneshot | 100% | 308t | | /prewalk | 70% (-25pts) | 162t | 相同的模型，相同的框架，几乎相同的想法，行为却截然不同。为什么 `/plan` 仍然作弊而 `/prewalk` 不？我们最好的解释是：**prewalk 从两端饿死它。** 作弊是能力强的模型在绝望时做的事情。在单独轨迹中，GitHub 调用在运行中途开始，一旦探索停滞：Sol 大约在第14回合崩溃，Opus 大约在第12回合。Prewalk 在其努力预算的*开头*就终止前沿模型，中位数约7个回合：它在模型仍在推导方法和完成第一次编辑（自信阶段）时退出，远在它开始谷歌搜索的阶段之前。`/plan` 没有这样的仁慈：它没有回合限制，而且它的交付物（一份全面解释修复*应该*如何工作的文档，从未测试过任何编辑与代码的接触）正是那种滋生绝望的任务。执行者继承的却是相反的状态：一个已证明方法与代码接触过的上下文。重现脚本已写好，第一次编辑已落地，清单在打勾。该上下文中没有任何东西看起来像搜索，所以模仿机器不会搜索。 ## Prefill 铺路，prewalk 才能奔跑 这都不是新想法。这是最古老的技巧：**prefill**。助手不按你想要的做？你自己开始助手的回合，模型会继续，好像那些话是它自己说的。它最初是在语法约束解码之前的某一一致性技巧。omp 和其他许多项目仍然这样做：会话标题来自一个很小的本地模型，这个模型恰好在你以 ``` ```` 开始时表现得更好。那么小的模型不能被*说服*进入某种格式，但可以被骗进去。 然后红队发现了另一头。Prefill “当然，这里是怎样……” 然后一个更大的模型轻松绕过它自己的拒绝：它没有渠道区分自己说的话和被放在它嘴里的话，与“已经接受”的一致性胜过系统提示。Prefill 成为一个标准的越狱类，强大到如今几乎所有推理层都禁止它，从 Anthropic（大概是 Sonnet 4.5 开始）。JSON 模式和结构化输出覆盖了合法用途，它逐渐消失。 但这个原理不可能失效，因为它不是一个小怪癖；它就是自回归的*本质*。你不能再给前沿模型十个预填充的 tokens 了；有些甚至不允许你禁用思考，正是为了防止你恶意预填充回合（模型*希望*能在思考过程中意识到，因为助手思考块缺失）。但没有什么能阻止你给它十圈无辜地预填充的**回合**：已经发生的探索，正在打勾的待办列表。 --- 我们将其上游到了 omp，今天起作为 `--prewalk`、`--prewalk-into <模型>` 或直接使用 `/prewalk` 发布。它应该很容易在任何地方实现，所以如果你有机会尝试，请告诉我们效果如何！