40 倍 token，成功率几乎没动：换个模型不如换个脚手架

Mon, 26 Oct 2026 00:00:00 +0800

你有没有过这种时刻：明明换了个更强的模型，代理写出来的代码却没更稳，token 账单倒是涨了一截。

你也可能反过来。某天你升级了一次代理，行为立刻变了：以前一句话说得清的事，它现在绕三个圈；以前一次改对的文件，它要改两遍还改错。你大概率把这笔账记在了模型头上。

2026 年有三篇论文把这个账重新算了一遍。结论有点反直觉：决定你花多少钱、干活利不利索的，主要不是模型，是模型外面那层壳。

那层壳有个专业名字，harness，论文里也常写成 scaffold，中文就是脚手架。它管的是：工具怎么发出去、上下文怎么管、什么时候停下来、失败了怎么重试。你用的 Claude Code、Codex CLI、Cursor、OpenCode、Goose，全都是 harness。

40 倍 token，成功率几乎没动

第一篇论文 2026 年 6 月 8 日挂上 arXiv：《The Scaffold Effect in Coding Agents》（arXiv:2607.22585）。

作者做了件很笨的事：把模型按住不动，换 harness。

“We evaluate Qwen 3.6 Plus and MiniMax M2.5 across three open-source harnesses (Goose, OpenCode, OpenHands-SDK) on a stratified 50-task subset of Terminal-Bench Pro. Harness choice induces up to a 40x difference in tokens per solved task, while paired within-model pass-rate differences remain 0-8 percentage points (95% paired-task bootstrap CIs include zero except for the largest gap).”

翻成人话：换个 harness，每解一道题的 token 消耗最多能差 40 倍；同一个模型下，成功率只差 0 到 8 个百分点——除了差距最大的那一档，其余 95% 置信区间都包含 0，也就是「测不出差别」。

40 倍是什么概念。你以为自己在为「模型能力」付钱，账单的大头可能只是壳在反复读同一个文件。

更扎心的是失败方式也跟着 harness 走，而且换个模型也改不掉：

“Failure fingerprints replicate across models (REASON for Goose, VERIFY/MAX_TURNS for OpenHands-SDK, idle-loop/TIME for OpenCode), indicating harness-level biases that are largely model-independent.”

Goose 老是卡在「继续想」上，OpenHands-SDK 老是把次数用光，OpenCode 老是原地转圈不干活。三种不同的病，模型换了照样犯。

病根在壳上。

论文最后那句建议，我认为是全文最值钱的一句：

“We therefore recommend selecting harness-model pairs by pass rate under token/latency budgets, and reporting token usage, latency, and full harness specifications alongside any model comparison.”

注意它的落点：不是「选更强的模型」，是「在 token 和延迟的预算约束下，选成功率最高的 harness-模型配对」。这是一个采购决策，不是一个技术信仰。

这是一篇 7 页的 preliminary work，投稿在 ICML 2026 的 DL4C Workshop，尚未正式发表。数据量不大，但控制变量的设计干净，值得当作信号看。

35 个版本，模型根本没动

第二篇是同年 7 月 4 日的《Don’t Blame the Large Language Model》（arXiv:2607.03691），标题几乎就是答案。

它做的是纵向研究：固定底座模型，把 Qwen Code CLI 的连续 35 个版本一个一个拿来测，每个版本跑 50 道分层的 SWE-bench Verified 任务。

“Unlike prior work that fixes the agent harness and varies the model, we fix the model and vary only the agent harness, evaluating 35 sequential releases to measure their impact on agent effectiveness and efficiency.”

它顺手统计了五个主流开源 harness（Codex、Qwen Code、Gemini、OpenCode、OpenHands）的开发节奏，然后发现了一件事：

“revealing extreme release velocities exceeding two releases per day and thousands of issues within months.”

脚手架自己一天发两个版本。

这篇论文的贡献不只是数据，它还给了一个命名。以前你升级代理觉得它变笨了，大家习惯归罪于模型。这篇论文说，这种归因很可能是错的。质量波动应该去脚手架里找，而且能追到具体的 PR。

“We trace the resulting quality fluctuations to specific development patterns and architectural components, and illustrate our findings with concrete qualitative evidence linking individual pull requests to measured quality shifts.”

同一个模型，换个代理差 6 倍

第三篇是 SWE-Bench Mobile（arXiv:2602.09540），2 月 10 日发表在 KDD 2026。这个基准用的是真实 iOS 生产代码库，任务来自真实 PRD 和 Figma 设计稿，不是编出来的玩具题。

它测了 22 组「代理 × 模型」配置，四个代理：Cursor、Codex、Claude Code、OpenCode。

“We evaluate 22 agent-model configurations across four coding agents – three commercial (Cursor, Codex, Claude Code) and one open-source (OpenCode) – and find that even the best configurations achieve only 12% task success rate.”

最好的配置也只有 12% 成功率。

而它最狠的发现是这个：

“agent design matters as much as model capability – the same model shows up to 6× performance gap across agents”

同一个模型，换个代理，成功率差 6 倍。

这篇里还有一条我特别想单独拎出来：简单的「防御式编程」提示词，比复杂的提示词好 7.4%。天天写提示词的人该记住这一条：在 agent 那边，很多复杂度是你自己加上去的。

40 倍不只活在论文里

工程上有没有对应的数？有。

Tempest 是个并行跑多个 CLI 代理的桌面工具（Apache-2.0，193 star）。它做的事很具体：在你本机建一张代码知识图，所有并行的代理会话共享这一张图，而不是各自把代码库扫一遍。

它自己贴的基准表是这样的：

仓库	语言	接入后 token	未接入 token	节省	工具调用节省
`tokio`	Rust	119K	1.02M	88%	87%
`okhttp`	Kotlin	73K	417K	83%	91%
`excalidraw`	TypeScript	210K	1.19M	82%	84%
`django`	Python	78K	416K	81%	92%
`gin`	Go	84K	243K	66%	71%
`alamofire`	Swift	184K	493K	63%	69%
`vscode`	TypeScript	307K	676K	55%	63%

README 写明这是每个仓库每组 4 次有效运行的中位数，同代理、同模型、同提示词，唯一变量是接不接那张共享图。

它对问题本身的描述值得贴出来：

“Run five agents in parallel and each one reads your entire codebase from scratch — the same files, the same context, five times over. You pay for every token, every time.”

并行代理的边际成本不是线性的，因为上下文是最贵的那部分。 五个代理并行，就是把同一份上下文买了五遍。

这张表和前面那篇 40 倍的论文，讲的是同一件事的两头：论文说换个 harness 能差 40 倍，Tempest 说就算 harness 不换，把同一份上下文喂五遍也能差好几倍。

脚手架自己一天发两个版本

我用 GitHub API 扫了 2026 年 9 月 26 日到 10 月 26 日这 30 天：

Claude Code：25 个 release，全是稳定版，预发布 0 个，覆盖 20 个发布日，最新是 v2.1.310（10 月 23 日）。
Codex CLI：92 个 release，其中稳定版 12 个、预发布 80 个，覆盖 25 个发布日。

（Codex CLI 这个数是按全部 release 翻页统计的。如果只翻第一页 30 条，会低估成 30 个以内。）

25 个稳定版、0 个预发布，意味着 Claude Code 的稳定线一天能推好几版。这种节奏下，你昨天跑得好好的代理，今天可能就已经不是同一只了。

而且这些改动里，混着货真价实的「壳的问题」。v2.1.309（10 月 22 日）的 release notes 里有一条：

“Fixed sandboxed Bash commands on macOS and Linux running the shell’s startup files outside the sandbox before each command”

沙箱里的命令在执行前，先在沙箱外面把 shell 的启动文件跑了一遍。这是壳的漏洞，跟模型一点关系都没有。

同一天的 v2.1.307 则开始把「被拦下」这件事变成可观测数据：

“Added the claude_code.safety_event OpenTelemetry event for each tool call a permission rule, auto mode, a safety check, a hook or the sandbox stopped, prompted or sent back”

每次权限规则、自动模式、安全检查、hook 或沙箱把工具调用拦下来，都会单独产生一个遥测事件。你终于能看见壳在替你做决定了。

三条能拿去用的判断标准

落到你手上该怎么做，三条。

一、别再只比模型，把 harness 当一等变量测。

比模型的时候，harness 是个没写进报告的隐藏条件。同一个模型在 Claude Code 和在 Goose 里跑出完全不同的账单，你把这笔账算给了模型。

二、给每个配对定预算，别只看通过率。

论文给的方法很直接：在 token 和延迟的预算下，选成功率最高的配对。预算卡长这样：

{
 "harness": "goose",
 "model": "MiniMax M2.5",
 "harness_version": "写具体版本号，别写 latest",
 "budget": {
 "tokens_per_task": 120000,
 "latency_p90_seconds": 180,
 "max_no_action_turns": 3
 },
 "measured": {
 "pass_rate": null,
 "tokens_per_solved_task": null,
 "no_action_turns_per_task": null
 }
}

（null 是故意的：第一次跑先留空，填了数才有意义。）

论文还留了一个容易被忽略的口子：no-action turn 就是「代理这一轮什么都没干」。它不只是 token 税，还是等待税——你盯着屏幕等它转圈，那是实打实的时间。

三、拿不准的时候，并排看原始答案，别只看一个代理的结论。

一个代理给一个答案，你没法判断这是模型的水平还是壳的水平。让两三个 harness 各跑一遍同一个任务，把原始答案并排放着看，差异会自己跳出来。

MCO（MIT，540 star）就是干这个的，它自己管这叫 CLI 优先的编排层：

# 1) 先看本机装了哪些 harness
mco doctor --json

# 2) 同一条任务，并排跑三个 harness
mco review \
 --repo . \
 --prompt "Review this repository for high-risk bugs." \
 --providers claude,codex,pi

# 3) 固定模型，只换 harness —— 这正是论文里的控制变量
mco review \
 --providers codex,pi \
 --provider-models-json '{"codex":"gpt-5.4","pi":{"provider":"seal","model":"deepseek-v4-pro"}}' \
 --prompt "Review this repository for bugs."

第三条最关键：把模型钉死，只换 harness。你在自家仓库上复现的，就是那三篇论文用的方法。

MCO 有一点很值得学：它明确说自己不生成结论。

“MCO keeps answer text opaque. It does not turn natural-language output into findings, severity, confidence, consensus, or an automatic decision.”

编排层最容易犯的错，就是替你想好了结论。

最后问一句：你现在用的那个代理，你知道它的 token 账是怎么算的吗？