证据级别提示： 本文解析的是 2026 年 9 月 26 日发布的 arXiv 预印本，尚未经过正式会议同行评审。它进入本专题是因为研究问题直接针对 Harness，而不是因为它已达到“顶会定论”的证据等级。结论需要等待独立复现。

论文档案

这篇论文终于直接问了什么

过去的 Agent 论文常同时改变模型、prompt、工具、预算和环境，然后把分数提升归因于“Agent 架构”。这篇预印本反过来问：

1. 同一个模型装在不同 harness 中，差多少？
2. 差异是否随模型能力和任务类型变化？
3. 工具、上下文压缩、规划、子 Agent 和技能各自贡献什么？
4. 更复杂 harness 的收益来自更多 token，还是更有结构的交互？

它把常被当作产品黑盒的 Harness 拆成可控制变量，这比单纯比较排行榜上的“模型+系统”组合更接近因果分析。

两阶段研究设计

Study 1：模型 × Harness × 任务

作者选择 Qwen 与 DeepSeek 两个开源权重模型家族，共 10 个从较弱到较强的模型，比较轻量 mini-SWE-agent 与更复杂 OpenCode。

三个 benchmark 覆盖不同软件工程形态：

SWE-bench Pro 工作流相对固定，通常修改少量文件；ProgramBench 要从头生成数万行级仓库；GitTaskBench 任务目标更灵活。任务形态被视为 Harness 效果的调节变量。

Study 2：NanoHarness 组件消融

作者在 mini-SWE-agent 上实现轻量、模块化 NanoHarness，五类能力可独立开关：

mini-SWE-agent
  + Tool Registry
  + Context Compression
  + Explicit Planning
  + General / Task-Specific Subagents
  + Lazy Skills
  = NanoHarness

在 ProgramBench 全量 200 题上，用 Qwen3.7-Max 与 DeepSeek-V4-Pro 测每个单项和全量组合，同时收集 step、tool call、prompt/response token 与轨迹失败模式。

五个组件到底实现了什么

Tool Registry

把 mini-SWE-agent 原本依赖 Bash 的交互升级为原生结构化工具：读文件、局部编辑、glob、shell 等。工具统一注册、描述和调用，减少模型拼命令与解析输出的负担。

这与 SWE-agent 的 ACI 结论一致：仓库操作的结构不是“外围 UI”，会直接改变模型能够稳定完成的行为。

Context Compression

超长工具输出先持久化，再生成压缩摘要；达到约 350k token 预算、手动触发或上下文报错时压缩，并保留最近 20 条消息。日志保留用于审计。

这实现了“完整事件存储”和“模型可见视图”的分离。但摘要可能丢失需求细节、接口约束和调试状态，正是论文后来观察到负效应的来源。

Explicit Planning

类似 TodoWrite 的计划工具允许 Agent 维护最多 10 个 todo；若多轮不更新，Harness 注入提醒。它是轻量外部状态，不是一次性让模型先生成完整大计划。

Subagents

父 Agent 保留任务控制、预算和最终提交，子 Agent 使用新上下文、共享 workspace 和受限工具 whitelist，完成后返回结构化报告。禁止嵌套委派，并记录子轨迹。

论文区分两类：

• 通用 SE 子 Agent：需求分析、架构、代码生成、测试、缺陷修复；
• 任务特定子 Agent：行为分析、差分测试、提交审查。

这个区分最后比“是否多 Agent”更重要。

Lazy Skills

主 prompt 只暴露技能名称与简述，需要时再加载完整流程知识，覆盖实现、调试、测试、fuzzing 与最终审查。目标是减少启动 prompt，同时提供可复用 procedure。

执行协议

所有模型温度设为 0。SWE-bench Pro、GitTaskBench 最多 250 步，ProgramBench 从原 benchmark 的 1,000 步降到 300 步；每题 6 小时 wall-clock、3 次重试上限。

容器任务禁网，分配 20 CPU、60GB 内存，容器最长 7 小时并禁用 SYS_PTRACE。GitTaskBench 在本地隔离工作目录并阻止越界操作。NanoHarness 子 Agent 最多 50 轮。

这些细节非常重要：Harness 结果依赖巨大的执行预算，不能只看最后百分点而忽略资源约束。

RQ1：复杂 Harness 是否总是更好

论文观察到交互效应，而非单调规律：

• 在 SWE-bench 类 issue repair 上，OpenCode 对弱/中等模型帮助较明显；模型越强，边际收益趋于缩小；
• 在 ProgramBench 与 GitTaskBench 这类开放、长程仓库任务上，复杂 harness 更像能力放大器，强模型更能利用额外机制；
• 较弱模型可能无法可靠使用复杂工具和工作流，反而承担额外提示与协调负担。

所以“先进 Harness 能提升任何模型”与“模型足够强后 Harness 不重要”都过于简单。效果取决于 model × task × harness。

RQ2：组件级结果

最稳定的正收益

Explicit Planning 只有小幅正收益；Lazy Skills 对 DeepSeek-V4-Pro 帮助比 Qwen 更明显，说明 procedure 能否被正确调用取决于模型。

两个重要负结果

Context Compression 让 Qwen3.7-Max 降 4.86 pt，DeepSeek-V4-Pro 降 3.85 pt。ProgramBench 需要长期保留细粒度需求、接口和实现状态，压缩节省 token，却可能抹掉后续调试仍需的信息。

General Subagents 对两种模型也都不利。泛化角色产生协调开销，返回产物未必对 repository generation 的细粒度约束有用。相比之下，行为分析、差分测试和提交审查等任务特定委派更可操作。

组合结果：非加法，但整体有效

全量 NanoHarness 接近产品级 Harness，但收益小于正向单组件简单相加。负组件在组合中仍存在，组件之间也会竞争上下文、预算和控制权。结论是“编排质量决定组合效果”，不是“功能越多越好”。

RQ3：收益是否只是多花 token

论文的行为统计提供更强证据：

• Task-specific subagents 让 tool calls 在 Qwen 上增加约 115.76%，DeepSeek 上增加约 73.10%；
• Context compression 把 prompt token 分别降低 54.29% 与 77.02%，但分数同时下降；
• 完整 NanoHarness 让 tool calls 增加 131.18% 与 83.58%，prompt token 只增加 16.37% 与 7.26%，同时分数提高 7.37/6.21 pt。

作者据此推断，收益更像是更有结构的 repository interaction，而不只是更大 prompt 预算。这个推断合理，但仍不是严格等成本因果实验：工具调用和 wall-clock 也属于额外计算。

对 Harness 设计最有价值的结论

组件要按任务做门控

不要默认全开。Issue repair、repository generation、web task 和客服政策任务需要不同机制。可把任务分类结果作为配置选择输入，并保留回退到轻量 loop 的能力。

压缩目标不能只是 token

上下文压缩应区分：不可丢的需求与接口、可重新获取的工具输出、已经失效的旧视图、需要保留的失败证据。应通过任务成功率和事实保留率评估，而不是只看压缩比。

子 Agent 要有窄契约

“你是通用软件工程专家”太宽。有效委派应规定输入、产物、工具、预算和验收，例如“用差分测试找出行为不一致，并返回最小复现与相关文件列表”。

结构化工具通常是首选投资

相对复杂多 Agent，工具 registry 边界清晰、易测试、收益更稳定。先改善搜索、读取、局部编辑和验证接口，再增加组织结构。

独立复现应怎样做

这篇论文很新，最重要的是复现而非转述：

1. 固定一个公开权重模型、一个公开任务集和严格总预算；
2. 从 mini harness 开始，每次只加一个组件；
3. 每个配置至少运行多个种子，不能只用 temperature 0 当作无随机性；
4. 报告成功、步数、tool calls、prompt/response token、wall-clock 和资源；
5. 为 context compression 做事实保留测试；
6. 为 subagent 比较 general、task-specific 与相同预算的单 Agent；
7. 保存全部配置与轨迹，让组件效果可审计。

最好再换一个非 ProgramBench 任务验证单组件结论，尤其是压缩和子 Agent 的负结果是否迁移。

证据边界与威胁

作者自己列出两类主要威胁：只研究五个代表组件，可能漏掉重要机制；模型只覆盖 Qwen、DeepSeek 两个家族。组件实验主要集中在 ProgramBench，外部有效性有限。

还应额外注意：

• 论文是未同行评审的极新预印本；
• OpenCode、Claude Code 等产品级 Harness 快速变化，版本固定非常关键；
• 多个 benchmark 本身也在 2025–2026 年出现，训练污染尚难判断；
• 300/70 的抽样虽配对使用，仍有抽样方差；
• temperature 0 不保证 API、工具和环境确定；
• 组件实现质量会与组件概念混在一起；
• 预算没有完全归一为相同 wall-clock 或工具成本。

因此最稳妥的结论是：Harness 确实值得作为独立实验对象，组件效果高度异质且有交互；还不能把这组具体百分点当作跨模型、跨任务的普遍常数。

它在论文谱系中的位置

ReAct 给出最小循环，SWE-agent 证明 ACI 会改变表现，OpenHands 展示完整运行时，BrowserGym 统一实验接口。这篇预印本再向前一步：把产品中常见的 Harness 能力拆成开关，在固定模型与任务下做消融。

如果后续同行评审与独立复现成立，Harness 研究将从“系统实现经验”走向更成熟的问题：组件的主效应、交互效应、任务适配与成本前沿。

延伸阅读

• 返回论文谱系与单篇索引
• DSPy：程序级自动优化
• SWE-agent：ACI 作为实验变量
• OpenHands：产品级 Harness 架构