把编码代理的 harness 拆开来测：上下文管理的价值大半是「别撑爆窗口」
176 组配对实验、四款模型、两个基准：规划对弱模型是精度脚手架、对强模型是省钱工具；让被裁剪的上下文可恢复几乎没人用；预定义工具只对 bash 弱的模型有明显收益（+15.0%），bash 强的模型只给 bash 更便宜。
中文
复制
一篇新的实证研究把「编码代理的 harness」拆开做了组件级对比。以往的工作大多把 harness 当成一个整体来评测，看不出各个部件到底贡献了什么。这篇论文的做法是固定执行循环，只变三个部件——规划（planning）、动作空间（action space）、上下文管理（context management）——然后在四个模型、两个基准（SWE-Bench Verified、Terminal-Bench 2.1）上跑了 176 组配对实验，覆盖 5 种上下文管理策略、4 种上下文窗口预算，以及对规划与动作空间的针对性消融。
结论有四条，都不是「加得越多越好」那类直觉。
一、上下文管理：价值主要来自「别撑爆窗口」
上下文管理的作用随窗口预算收紧而变大；而它的收益大部分来自防止上下文溢出导致的失败，而不是让模型变聪明。随着更多「未被管理的轨迹」也能装进窗口，它带来的精度提升会收缩，且越来越依赖具体模型。
二、先规则裁剪、再 LLM 总结，性价比最高
在几种策略里表现最好的是 T4：先用基于规则的 elision 做粗裁剪，再用 LLM 做总结。反直觉的一点是，让被裁掉的内容可恢复（recall / M2 机制）几乎没有意义——模型极少调用它，精度相比只有 elision 也没有提升。研究者的原话是：这引入了模型很少使用的机械结构，却没有换来精度。
Takeaway: 在几种上下文管理策略精度相当的情况下，T4 靠着廉价的早期 elision 减少对 LLM 总结的依赖，取得最好的整体成本表现。
三、规划：对弱模型是脚手架，对强模型是省钱工具
规划的价值随模型能力改变性质：
- 对较弱的模型，规划让轨迹活到足以尝试一次编辑，从而抬高成功率，代价是更多计算；
- 对更强的模型，精度变化很小，规划主要省掉「编辑后重复验证」这类冗余，从而降低成本。
数据上看，为 Nemotron-3 30B 打开规划会同时增加轮数、工具调用次数和每次调用的平均输入 token；而在更强模型上，它更多是效率手段。在中等能力区间，它的价值还取决于任务类型。
四、动作空间：强弱模型的分水岭
预定义工具集对 bash 能力较弱的模型帮助明显，而能熟练使用 bash 的模型只给一个 bash 接口就够，且成本显著更低，在命令行类任务上尤其明显。
具体数字：
| 模型 | 预定义工具集带来的成功率提升 |
|---|---|
| Nemotron-3 30B | SWE-Bench +15.0%，Terminal-Bench +10.1% |
| Nemotron-3 120B | SWE-Bench +1.6%，Terminal-Bench +4.5%（但执行更高效） |
还有一个很有说服力的现象：在 Terminal-Bench 上，66% 的 bash-only 轨迹会因为发出接口之外的东西而终止，把平均轨迹长度从 71 轮压缩到 15 轮。也就是说，「只给 bash」这件事本身对弱模型是一道坎，而不只是风格差异。
轨迹层面的解释
论文的轨迹分析给出了机制层面的解释：上下文管理延长了执行轨迹但没有实质改变代理的行为；规划改变了轨迹在哪里停下；动作空间改变的是写代码的粒度。
六个模型的价格参照
论文按 OpenRouter 2026 年 8 月的价格折算成本（每百万输入/输出 token）：Nemotron-3 30B 为 $0.05 / $0.20，Nemotron-3 120B 为 $0.08 / $0.45，Nemotron-3 550B 为 $0.50 / $2.20，Mistral-Medium-3.5 为 $1.50 / $7.50。
对做 agent 的人意味着什么
这篇论文给出的实践指向比较清楚：
- 按模型能力和预算来配 harness，而不是找一套「最佳配置」通吃；
- 上下文的钱花在「别撑爆」上最划算，先规则裁剪再动用 LLM 总结；
- 「可恢复的裁剪」这种看起来更安全的设计，很可能只是增加复杂度；
- 如果你的模型 bash 够强，工具集可以少给——那是成本优化，也是能力适配。
论文共 43 页，包含完整的 176 组设置与消融结果，也提供了一个模块化框架，便于后续按组件评测新的 harness 设计。