如果你在 SWE-Bench Verified 的榜单上看到两个 harness 相差几个百分点，最自然的解释是「模型更强」。但这个解释有个漏洞：同一条赛道上的参赛者常常用同一个基础模型，分数差距来自外面那层壳。
这层壳有个不太统一的叫法——coding harness。它包含给模型的系统提示、工具定义、上下文如何裁剪、什么时候触发规划、失败后怎么重试。它决定了模型能力以什么形式转化为实际的软件工程产出。
一、被忽略的归因问题
论文开门见山地指出，现有工作几乎都把 harness 当单体系统评测。换一版 harness 拿到新分数，你只知道整体变了，不知道是哪个组件起的作用。这在工程上是个很严重的问题：团队花两周优化上下文压缩，结果真正带来提升的是工具定义的改动，而没人知道。
要解决这个问题，必须做组件级消融。论文的设计是：固定执行循环，只允许三个组件变化。
- 规划（planning）：有无显式的计划生成与维护步骤；
- 动作空间（action space）：模型可以调用什么——预定义工具集，还是纯 bash 接口；
- 上下文管理（context management）：轨迹变长后如何裁剪、压缩、舍弃历史。
实验规模不小：4 个模型、SWE-Bench Verified 与 Terminal-Bench 2.1 两个基准、5 种上下文管理策略、4 档上下文窗口预算，加上规划与动作空间的定向消融，合计 176 组匹配配置。全文 43 页。
二、四个结论，每一个都和直觉相反
结论一：上下文管理的收益来自「别死」而不是「想得更好」
大多数人会默认上下文管理的作用是提升推理质量——保留更相关的信息，模型自然表现更好。论文的数据不支持这个解释。
真实情况是：上下文管理的价值随预算收紧而上升，而其中大部分收益来自防止上下文溢出失败。
这个归因的意义在于重新划定了收益上限。如果上下文管理的主要职责是防溢出，那么它的收益天花板就由溢出率决定：预算宽松时溢出率接近零，投入再多压缩算法也换不来分数；预算紧张时，溢出成为主要失分来源，压缩策略的边际收益立刻显性化。工程上这意味着——先量你自己场景里的溢出率，再决定要不要做复杂的上下文压缩。
结论二：规则省略要排在 LLM 摘要之前
在五种上下文管理策略的比较中，效率最高的是分级处理：先用确定性规则把明显可以丢弃的内容剔掉，再把剩下的部分交给 LLM 做摘要。
顺序不能反。规则先行等于用零成本手段完成大部分压缩，LLM 只处理残余的难压缩部分，于是每次压缩的模型调用都被用在刀刃上。反过来只靠 LLM 摘要，虽然单次压缩质量可能更高，但每次都要付出一次模型调用，而且摘要本身有引入幻觉的风险——被摘要掉的信息如果恰好是关键约束，损失是不可见的。
论文还发现一个更值得警惕的细节：让被省略的内容可恢复，没有带来任何精度提升。模型很少真的回去取用被省略的内容。而实现「可恢复」需要额外维护索引、保存原始片段、提供检索接口，全都是实打实的复杂度和 token 开销。
⚠️ 反模式：为「理论上最重要的能力」构建基础设施，但实测使用率极低。判断标准很简单——先埋点统计回收率，再决定要不要建这套机制。
结论三：规划的作用会随模型能力换挡
规划的定位在实验中发生了一次角色转换：
- 对较弱的模型，规划是精度脚手架——把任务拆开之后，模型不容易在中途迷失方向，精度有实际提升；
- 对较强的模型，规划退化为省钱工具——精度基本不变，但因为减少了无效探索的轮次，总 token 消耗下降。
这个结论对选型很有价值。如果你的流水线用的是小模型，规划步骤是必需品；如果用前沿模型，规划应该被当作成本优化项来评估，而不是精度手段。用错预期会导致一种常见误判：团队给强模型加上规划模块，期待精度上涨，结果分数纹丝不动，就认为规划没用——实际上它省了钱。
结论四：纯 bash 接口可能比工具集更便宜
直觉上工具定义越多越好：给模型明确的契约，降低调用难度。论文发现这个直觉只在bash 能力弱的模型上成立。
对 bash 已经很强的模型，直接给一个纯 bash 接口就能有效工作，而且成本明显更低，在命令行中心型任务上尤其突出。原因不难想：每个预定义工具都要占用系统提示的空间，工具集越大，每次请求的固定开销越高；而 bash 本身是通用接口，模型可以用它组合出所有需要的动作。
三、轨迹级分析：三种机制的作用位置不同
论文没有停在分数上，还做了轨迹级分析，试图解释现象背后的机制。三个组件的作用位置完全不同：
| 组件 | 对轨迹的影响 |
|---|---|
| 上下文管理 | 延长执行轨迹，但不显著改变 agent 的行为模式 |
| 规划 | 改变轨迹在哪里停止 |
| 动作空间 | 改变代码被写出来的粒度 |
这个表格可以当作诊断工具用。当你调整某个组件后效果不及预期，可以先看轨迹形态的变化是否符合预期：改了上下文管理但轨迹长度没变，说明压缩策略根本没生效；加了规划但停止点分布没变，说明计划没有被真正执行。
四、给你的 harness 做一次组件审计
这篇论文最大的实用价值，是提供了一套可复用的评测方法论。落到自己的项目上，可以这样操作：
第一步，冻结执行循环。 把重试逻辑、终止条件、消息格式全部固定住，不要在任何消融实验里改动它们。执行循环是变量污染的头号来源。
第二步，一次只动一个组件。 规划、动作空间、上下文管理分别做开关实验。配置数量会很多，但这是唯一能产生可信归因的方式。
第三步，配对而非平均。 每组成果要在同一批任务上比较，而不是拿两个不同任务集的平均分对比，否则任务难度差异会淹没组件效应。
第四步，看轨迹指标而不只是分数。 记录轨迹长度、停止位置分布、写的文件数量级、工具调用构成。分数告诉你效果，轨迹告诉你原因。
论文还特别强调了「针对未来组件的模块化评测框架」这个贡献。对 harness 开发者而言，这比任何单一结论都重要——组件会不断更新，但「固定循环 + 单变量消融 + 轨迹归因」这套方法不会过时。
💡 提示：论文的匹配配置思想值得直接借用——不仅要控制变量，还要保证每组的配置组合在统计上可配对，否则你会在噪声里找规律。