决定成败的是脚手架，不是模型：为什么同一个 LLM 缺少合适的脚手架就会多烧 4 倍的 token

最近有一张图在网上流传，它重新定义了整个关于 token 成本的讨论。一位工程师在同一个模型上跑了 180 个完全相同的代码修复任务，每次运行之间只改动一样东西——脚手架（harness），也就是包裹在模型外面的那套支撑结构。裸跑时，模型解决了其中 6.7%；配上合适的脚手架后，达到了 68%——而且到达这个成绩用掉的 token 还少了 4 倍。

同样的权重、同样的任务。仅仅靠改动外围接线，成功率就有了 10 倍的摆幅，成本也有了 4 倍的摆幅。

分析师 Aakash Gupta 把商业逻辑说得很直白：“模型是人人都有的大宗商品。脚手架才是你城堡外的护城河——你的竞争优势。” 本文将透过这个博客唯一在意的视角来解读这个观点：token。因为脚手架不仅仅是准确率所在之处，它也是账单所在之处。

这是 如何在 LLM 中节省 token 的姊妹篇。那篇指南是一份战术清单，而这一篇讲的是所有战术底下共通的那条原则——以及为什么整份清单归根结底其实就是脚手架工程。

1. “脚手架” 到底指什么

模型是引擎：纯粹的下一个 token 预测。脚手架是围绕引擎的一切，它把引擎变成一个能真正完成工作的代理：

• 任务是如何被框定的（系统提示、工具文档、示例）；
• 它拥有哪些工具，以及工具的结果如何返回；
• 它能看到仓库/文件/历史的多少内容，以及以什么形态呈现；
• 它失败时会发生什么——是盲目重试，还是被引导纠偏；
• 它在步骤之间、会话之间记住些什么。

Claude Code 就是一套脚手架。Cursor 也是，Codex 也是，一个手写的代理循环也是。两套脚手架驱动同一个模型，产出的结果会天差地别——token 账单也会天差地别——因为它们喂给模型的上下文天差地别，从错误中恢复的方式也天差地别。

2. 为什么 token 恰恰烧在脚手架上

下面这部分对成本至关重要。在一个代理式任务里，token 账单并非由那一条干净利落、解决问题的轨迹主导，而是由沿途出的各种岔子主导：

• 重试。 一个含糊的报错、一个格式错误的工具调用、一个错误的假设——每一次走进死胡同，都是一整轮输入（累积至今的全部上下文）加输出，全额付费，却什么都没产出。
• 重读。 一套无法把恰好那 30 行递给模型的脚手架，会逼着它去读整个 800 行的文件——或者 grep 一遍、失败、再读三个文件。
• 胡乱折腾。 没有引导，一个卡住的模型会用略微不同的措辞重复同一个失败动作，每次重复都要把整个上下文重新发一遍。
• 上下文腐坏。 随着失败的尝试不断堆进上下文窗口，质量随之下降（见 token 指南 的第 3 节），这又导致更多失败，更多失败又烧掉更多 token。恶性循环。

这就是为什么同一个模型裸跑会比带脚手架贵 4 倍。那个成功率 68% 的脚手架不只是更聪明——它根本不为胡乱折腾买单。最便宜的 token，是你压根没花在重试上的那个。脚手架质量和 token 成本，是同一根轴，量了两遍。

3. 研究：适配的是接口，不是模型

这不只是网红式的话术——它如今已成为一个有数据支撑的研究方向。

Life-Harness

Life-Harness（Xu、Wen、Li——arXiv 2605.22166）在标题里就把这个论点讲得直白：“适配接口，而非模型（Adapting the Interface, Not the Model）。” 其主张是：在受规则约束的环境中，代理之所以失败，是因为模型与环境之间的接口失配，而不是因为模型笨。所以，与其微调权重，不如在运行时演进脚手架：把观察到的失败转化为可复用的干预措施，然后把这些措施固定下来用于新任务。它是免训练的——没有梯度更新，没有新权重。

它由四个运行时层构建而成，而且每一层都值得当作一个省 token 的手段来看：

层	它做什么	token 视角
环境契约	事先把任务的真实约束讲清楚	消除那种模型靠违反规则才发现规则的重试循环
过程性技能	复用此前奏效、经过提炼的恢复模式	跳过重新推导代理已经找到过一次的解
动作实现	把模型的意图翻译成一个有效、可执行的动作	去掉格式错误调用带来的往返
轨迹调控	检测并阻断重复出现的失败模式	制止那种把上下文重发 N 次的胡乱折腾循环

这四层每一层都瞄准了一类被浪费的 token。结果是：在 7 个确定性环境和 18 种模型主干上，Life-Harness 改善了 126 种设置中的 116 种，平均相对增益为 88.5%——而且在一个模型上演进出的脚手架能迁移到另外 17 个模型。这份采用 MIT 许可证的代码已发布在 GitHub 上。（论文报告的是成功率，而不是一个 token 头条数字；“少 4 倍 token” 这个数字来自上文那个从业者实验——但其机制正是一套好脚手架所做的事情：更少的失败轨迹，更少的 token。）

Meta-Harness

如果说 Life-Harness 是从失败中演进脚手架，那么 Meta-Harness（Lee、Nair、Zhang、Lee、Khattab、Finn）则是端到端地：自动优化脚手架本身——任务描述、提示、评估标准——把它当作一个可学习的对象，完全不碰模型。它的主标题是 “脚手架问题（harness problem）”：同样的任务，以不同方式框定，会产出差别巨大的结果，而系统性的脚手架优化能媲美甚至超过升级模型带来的收益。该研究在 T-Bench 2 上，就意图检测、情绪识别和代码任务进行了测试。

两篇论文，同一个季度，从不同角度得出了同一个结论：接口是一根一等重要的杠杆，而对于一个固定的模型来说，它是你手上仅剩的唯一杠杆。

4. 这对你的 Claude Code 账单意味着什么

对 Claude Code 用户来说，重点在这里：节省 token 指南 里的一切，都是脚手架工程。 你没有一个标着 “脚手架” 的旋钮，但你每次做下面这些事，其实都在搭建脚手架：

• 把任务委派给上下文很小的子代理（第 2 节）——这样失败就留在子上下文里，不会腐坏父上下文；
• 用技能替换 MCP（第 5 节）——这就是过程性技能层的另一个名字：按需加载、可复用的诀窍，而不是每次重新推导；
• 用钩子过滤工具输出、用 rtk 压缩命令（第 11 节、第 13 节）——这就是动作实现：得到有效、紧凑的结果，而不是 500 行的日志；
• 查询图谱，而不是通读整个仓库——graphify，以及现在的 CodeGraph 和 Serena（见指南更新后的第 7/13 节）——这是对 “把所有东西重读一遍” 这项税负最大的一刀砍削；
• 管理会话，用 /rewind、/compact、/clear（第 4 节）——这就是轨迹调控：别让一条走进死胡同的路径一直反复计费。

把这份清单和 Life-Harness 的四层对照着读，其映射几乎是一一对应的。学术上的表述只是给那些精打细算的代理用户凭直觉早已在做的事情起了个名字。这套技术栈不是一堆花招的堆砌——它是一套脚手架，其中每一块都消除了一类被浪费的 token。

5. 获得更好脚手架的两条路：自己搭，或者租

自己搭。 这正是 claude-code-token-savers 这套配置所做的事——把 rtk、graphify、caveman，以及现在的 pxpipe/headroom 接进 Claude Code，让围绕一个旗舰模型的脚手架不再为胡乱折腾买单。你保留 Anthropic 的模型，只升级外围接线。

租一套。 有些产品直接把脚手架当成产品来卖。比如 commandcode.ai，它不是 Claude Code 的代理——它是一个独立代理（每月 1 美元，赠送 10 美元额度），在自家脚手架背后运行廉价的满血、从不量化的开源模型（DeepSeek V4 Pro、MiniMax M3、MiMo V2.5 Pro），并配有一套 “taste-1” 学习系统，它会观察你的接受/拒绝/编辑动作，自动写出项目级技能——这正是过程性技能层的产品化。它的经济账是第 6 节的打法（廉价模型），外加一套越用越好的脚手架。作为一个品类，它值得了解：当脚手架足够好时，一个跑在它上面的大宗商品模型，能打败一个裸跑的旗舰模型——这正是那张 6.7% 对 68% 的图，只不过被打包成了订阅制。（它是一个替代性代理，而不是你 Claude Code 技术栈的附加组件。）

两条路押的是同一个注：把钱花在脚手架上，而不是模型上。

要点

模型是引擎，而引擎已经变成了大宗商品——DeepSeek、MiniMax、Qwen、Claude，全都在一个 $1 订阅或一个廉价 OpenRouter 别名的触手可及之处。在同一个任务上，让一个 6 美元的会话和一个 42 美元的会话区分开来的，不是引擎，而是脚手架：外围接线把模型稳稳地保持在轨道上的能力有多强、能否恰好递给它所需的上下文、以及能否拒绝为同一个错误付两遍费。

Aakash Gupta 把脚手架称为护城河。而对任何盯着自己 token 账单的人来说，它其实更简单：脚手架就是你的 token 被花掉还是被省下的地方。 搭一套好的——或者租一套——同一个模型就能以四分之一的成本干出 10 倍的活。

---

延伸阅读：如何在 LLM 中节省 token——一份实用的 Claude Code 指南，那份逐条战术的清单，正是这条原则所依托的底座。