代码 agent 的天花板，一半卡在 harness 上：176 组消融拆穿三个想当然

Zoom 与 UMass Amherst 把编码 agent 的 harness 拆成规划、动作空间、上下文管理三个变量，跑了 176 组匹配设置。结论很不客气：这三样没有一样是普适的，全看模型能力和窗口预算。

2026年9月21日深度解析已修订代码智能 AI Agent SWE-Bench Harness工程上下文管理深度解析

同一个模型，换个壳子就换了个成绩

过去两年，编码 agent 的公开讨论几乎全被模型占据。谁家模型在 SWE-Bench Verified 上多两个点，能上热搜；谁家把 harness 里的工具集从 12 个改成 6 个，没人关心。

这个偏好正在被一份实证研究纠正。9 月 17 日上线的《An Empirical Study of Harness Design for Coding Agents》（arXiv:2609.20804，Zoom Video Communications 与 UMass Amherst、Emory、UNC Charlotte 合作）做了一件此前没人系统做过的事：把编码 harness 当成可拆的实验对象，固定执行循环，只变动规划、动作空间、上下文管理三个组件，做了 176 组匹配设置。

结论的第一层其实业内早有感觉——换 harness 能显著改变同一个模型的成绩。真正有价值的是第二层：它把”哪个组件在什么条件下有用”这个问题，给出了带数字的边界。而这个问题的答案，对每一个正在自己搭编码 agent 的团队，比多两个点的榜单分数有用得多。

三个变量，五档策略，四档窗口

实验设计值得先讲清楚，因为后面所有结论都挂在这几个坐标上。

模型侧取了一条族内能力轴——Nemotron-3 的 30B、120B、550B 三个尺寸，外加 Mistral-Medium-3.5-128B 做跨族对照。基准取两个互补的长程任务：SWE-Bench Verified 考仓库级 issue 修复，Terminal-Bench 2.1 考端到端终端任务完成。

上下文管理定义了五档：T0 不做任何跨轮压缩，窗口超了直接终止；T1 删掉过期的工具观测；T2 在 T1 基础上加外部存储和 recall_event，让被删的内容可回捞；T3 只用 LLM 摘要；T4 把删除、可回捞存储、摘要串成分级策略，先删后摘。四档上下文窗口预算是 32k、64k、96k、128k token。规划和动作空间的消融则固定在 T4/128k 上做。

被刻意保持不变的东西同样重要：权限处理、编辑后诊断、卡死检测这些机制全部锁死，提供一个共同的执行底座。这正是以往跨 harness 评测最缺的东西——此前 Cao 等人 2026 年的跨 harness 评测只能告诉我们 Claude-Opus-4.5 在 OpenHands 上最好、Claude-Sonnet-4.5 在 SWE-Agent 上最好，说不清这个差别来自规划、工具设计还是上下文策略。

上下文管理值钱，是因为它挡住了溢出

第一个结论最反直觉：上下文管理带来的收益，绝大部分不是”压缩”带来的，是”没被截断”带来的。

模型平均后，受管档位（T1–T4）与不管（T0）的成功率之差，随窗口放宽单调收窄。SWE-Bench 上从 32k 时的 35.7 个百分点一路降到 64k 的 15.9、96k 的 5.5、128k 的 2.7；Terminal-Bench 上从 9.5 降到 7.5、4.8、2.8。

对照 T0 的溢出率就能看懂这条曲线：窗口从 32k 放宽到 128k，T0 在 SWE-Bench 上的窗口溢出率从 78.7% 掉到 8.7%，Terminal-Bench 上从 61.0% 掉到 12.1%。而所有受管档位在整个过程中溢出失败为零。

换句话说，受管档位并没有让 agent 变聪明，它们只是让 agent 活到了该干完活的时候。窗口一旦够大，T0 自己也能跑完，差距就塌了。

这对工程决策的含义很直接：如果你手上的模型上下文窗口已经很宽，再往里堆上下文压缩策略，边际收益接近于零，还平白多一轮 LLM 摘要调用的钱。

第二个结论关于怎么压。T4——先规则删除，删不下去再上 LLM 摘要——在八个模型-基准面板中的七个里成本最低，且在全部四档窗口预算下平均峰值上下文占比最低。原因是便宜的规则删除挡在前面，把大量情况处理掉了，昂贵的摘要调用次数随之下降。

第三个结论是这份论文里最锋利的一条：给删掉的内容做可回捞机制，白搭。

T1 与 T2 只差一个 M2（外部存储 + recall_event），是干净的配对比较。在 32 组模型-基准-窗口比较里，T2 赢 15 组、输 14 组、平 3 组，等权平均差 −0.36 个百分点（SWE-Bench +0.40，Terminal-Bench −1.12）。统计上就是噪声。

更扎心的是调用数据：64 个 T2 与 T4 设置里，36 个（56.3%）从头到尾没调用过一次 recall_event，调用率的中位数是零。均值从 32k 的每任务 0.540 次，掉到 64k 的 0.069、96k 的 0.011、128k 的 0.007；T4/128k 下那 16 个规划与动作空间设置，记录到的调用次数是零。用得最狠的配置——Nemotron-3 30B 在 Terminal-Bench、32k 窗口、T2 档——平均每任务 4.326 次。

一个被反复写进各种 agent 框架设计文档的”可回捞记忆”，在真实长程编码任务里几乎不被使用。这值得每一个正在往自己的 harness 里加记忆模块的团队停下来想一想：你加的这个东西，有没有埋点验证过调用率？

规划：弱模型拿它买命，强模型拿它省钱

规划的效应随模型能力翻转，是这份实验里最漂亮的结果。

对最弱的 Nemotron-3 30B，开启规划在 SWE-Bench 上把成功率抬了 11.6 个百分点，Terminal-Bench 上抬了 4.5 个百分点，代价是两个基准上成本都上升。对最强的两档——Nemotron-3 550B 和 Mistral-Medium-3.5-128B——规划反过来省钱：SWE-Bench 上成本分别降约 30% 和 32%，成功率各降 2.0 和 0.4 个百分点。中间的 120B 没有稳定的成功率收益，成本在 SWE-Bench 上上升、在 Terminal-Bench 上下降。

执行统计把机制讲清楚了。表 5 显示，开规划后 30B 在 SWE-Bench 上回合数 +293.2%、工具调用 +474.0%、每次调用平均输入 token +104.1%；550B 则是 −24.3%、−24.5%、−12.4%。

轨迹层的证据更能说明问题。表 6 给出 SWE-Bench 上”没做任何编辑就终止”的 runs 占比：30B 关掉规划时 68.6% 的 runs 在改任何一行代码之前就结束了，其中 58.4% 死在定位阶段；打开规划后这两个数字降到 27.8% 和 10.4%。关掉规划，30B 的 SWE-Bench 中位轨迹长度从 40 个回合塌到 5 个回合。

也就是说，对弱模型，规划不是”计划得更周全”，而是让轨迹活到能试着改一次代码。多出来的回合数是成本，买的是一次编辑机会。对强模型，规划砍掉的主要是编辑之后的验证回合——它们本来就知道该改哪，规划只是免得它们反复确认。

这个分化对产品定价有直接影响。同一套 harness 默认配置，跑在便宜的小模型上是准确率工具，跑在贵的大模型上是成本工具。按模型档位分开配默认开关，比全公司统一一套配置划算得多。

动作空间：bash-only 不是更自由，是更粗的粒度

第三个消融比较了预定义工具集与 bash-only 接口。

预定义工具对弱模型的支撑很明显：30B 用上预定义工具后，SWE-Bench 提升 15.0 个百分点、Terminal-Bench 提升 10.1 个百分点。论文给的解释是动作词汇表的对齐——没有预定义工具时，模型会退回训练时习得的调用模式，而 bash-only 的工具注册表里没有这些工具，harness 无法把模型吐出来的调用解析成可执行动作。在 Terminal-Bench 上，30B 有 66% 的 bash-only 轨迹就是在这种”越界输出”之后终止的，平均轨迹从 71 个回合缩到 15 个。

强模型反过来。550B 在 bash-only 下 SWE-Bench 提升 3.6 个百分点、Terminal-Bench 提升 5.6 个百分点，成本分别降 53% 和 30%，工具调用次数少 32% 和 24%。

Mistral 暴露了这个交叉点的任务边界：全工具集在 SWE-Bench 上给它 +23.2 个百分点，bash-only 却在 Terminal-Bench 上给它 +6.7 个百分点。原因在动作分布——用全工具集时，Mistral 在 Terminal-Bench 上 71.9% 的工作区动作走 bash，在 SWE-Bench 上只有 40.4%。Terminal-Bench 天然更偏 shell，去掉那些跟 bash 抢活的工具反而更贴合它的偏好动作；SWE-Bench 则还需要预定义的读、搜、编辑动作。代价也摆在那里：Mistral 在 bash-only 下 32.8% 的 SWE-Bench runs 一个文件都没编辑就结束了，全工具集下这个数字是 1.2%。

动作粒度的数据给了最后一块拼图。表 7 显示 bash-only 大幅减少对已编辑文件的反复打补丁：30B 从 3.3 次降到 0.4 次，550B 从 4.6 次降到 1.5 次；单次最大编辑的行数上，550B 从 18 行涨到 54 行。Terminal-Bench 上文件写入也整体转向更粗的 create/replace 动作，占比从 51%（550B）升到 76%。550B 的 Terminal-Bench 中位轨迹从 47 个动作缩到 31 个，而写代码动作占比从 16% 升到 27%。

预定义工具降低了单个动作的复杂度，代价是把同一件事摊到更多次交互和更多轮增量修补上。这不是谁更好的问题，是你的模型会不会写复合 shell 命令的问题。

行业：评测层正被单独拆出来卖

技术侧的结论落到行业上，指向一件事——harness 与评测正在从模型公司的内部环节，变成独立的一层生意。

9 月 19 日 TechCrunch 报道的 Vals 是这个趋势的标本。这家 2024 年成立的公司，去年拿了 8VC 与 Bloomberg Beta 领投的种子轮，上个月完成 4000 万美元 A 轮，由 Andreessen Horowitz 领投。它的核心做法有两条和本篇论文高度呼应：测试材料不公开，避免厂商对着考题训练；评测内容从通用知识转向法律、金融、编码这类具体行业的复杂任务。

25 岁的联合创始人 Rayan Krishnan 有一句话可以直接拿来对照前面那批消融数据：“学术基准没有跟上前沿进展。“他还提到 Vals 已经有”递归自我改进”方向的基准。公司营收是去年的 8 倍，团队从年初 8 人扩到 25 人，最近还启动了面向联邦机构的评测项目。

把这两件事放在一起看，脉络很清楚：当模型公司越来越难靠公开榜单证明自己，而 harness 与上下文策略又能显著改写同一个模型的分数时，“谁来验证”就必须从模型公司手里独立出去。Vals 卖的正是这个位置。

未来：harness 自己来找 harness

一个更激进的方向已经出现了。9 月 17 日 NVIDIA 的《SoL-Pi: Recursively Scaling Auto-Research Loops for Efficient Agent Harness》（arXiv:2609.20519）把递归自改进的思路开到了 harness 层：让一个研究型 AI 在大量环境里跑基础 harness，检查自己的执行轨迹，提出候选改动，再用能力门和效率门筛想法池。

最终有四个机制通过了筛选并组成 SoL-Pi：Action Fusion（把编辑与随后的命令合并成一次动作）、Evidence-Preserving Reducer（从构建和测试日志里抽取已验证证据）、ObservationPack（大输出本地归档，只给稳定句柄）、Online Context Compact（在计划步完成时判断是否值得压缩上下文）。

在 51 任务的 EdgeBench 上，SoL-Pi 在 GPT-5.6 Sol 与 Opus 5 上取得与 Pi 相当的成绩，记录到的 token 流量降 44.7%–49.0%，API 成本降约三分之一；折算成每小时节省，相对原生 Codex 与 Claude Code harness 是 $8.75–$13.50，相对 Pi 是 $4.36–$5.71。跨后端迁移的初步证据也有：用 GPT-5.6 Sol 开发出来的 SoL-Pi 直接套到 Opus 5 上，没有再做搜索或适配，保留 Pi 平均分 94.3% 的同时 token 流量降 44.7%、成本降 33.5%。

这条路的意义在于，它把”harness 怎么配”从一个靠经验拍脑袋的问题，变成了一个可以搜的问题。而前面那份 176 组消融恰好提供了搜索时最需要的东西——哪些维度值得搜，以及搜完用什么口径判定”通过”。论文里明确写了 SoL-Pi 在 held-out 评估前会冻结机制源码、配置、指标、能力容差和接受规则，且 EdgeBench 的所有输出都不回流进搜索循环。这套纪律，正是当下大量 agent 自改进实验最缺的部分。