这篇论文我读了两遍。第一遍带着“代码 agent 的 harness 有什么好研究的”这种预设，结果被扇了一巴掌。第二遍才反应过来它真正在做的事：把 coding agent 的 harness 从一个“整体系统黑盒”拆成可比较的组件，然后告诉你每个组件在什么条件下起作用、什么条件下可有可无。这活儿很脏，因为要跑 176 个匹配设置；也很硬，因为它挑战了一个圈内默认——换模型比换 harness 重要。这个默认，我自己也信了很久。
论文九月份挂出来的，43 页，主分类 cs.AI，横跨 CL、LG、SE。作者阵容里有一看就是做 agent 工程和评测的人。但我不打算按部就班讲每个实验。我只想拆一个点：harness 设计不是模型能力的附属品，它在预算紧张和模型能力边界处，决定了你的 agent 是能跑完还是中途崩掉。 剩下的发现我会带上，但不平均着说。
coding agent 的核心循环大家已经很熟了：模型根据上下文做规划，选动作，执行，把结果喂回去。这个循环外面套的那一层——上下文怎么管理、动作空间怎么定义、规划怎么触发——就是 harness。过去两年大家默认 harness 是个“工程实现细节”，论文里写一句“we use a standard harness”就过去了。但如果你真的去复现一个 agent，会发现换一个 harness 实现，同一个模型在同一个 benchmark 上能从 30% 掉到 20%，或者反过来。这个差异不是幻觉，是 harness 在真实地吃掉或保住模型的能力。这篇论文干的，就是把这种“吃掉或保住”的过程摊开。
他们做了一个轻量级 harness，执行循环固定，只改三个组件：规划、动作空间、上下文管理。然后上四个模型、两个基准（SWE-Bench Verified 和 Terminal-Bench 2.1）、176 个匹配设置。176 这个数字你细品一下，它不是随便跑跑，是把三个组件的组合几乎穷举了一遍。这种规模的经验研究在一个追逐新模型、新 benchmark 的领域里属于凤毛麟角。你很难找到第二篇愿意花这个力气去拆 harness 的。
最让我意外的发现是：窗口越紧，上下文管理越值钱。 这个结论反直觉的地方在于，很多人以为上下文管理在“模型上下文不够用”时才有意义，窗口给大了就不用管了。但他们发现的是另一回事：预算紧张时，上下文管理的收益主要来自“避免上下文溢出导致的失败”。翻译成人话：不是模型因为信息太多而推理变差，而是模型因为上下文装不下了而直接崩掉、或者开始丢关键信息。你给它塞 128k 的窗口，它可能根本不会用到那么满；但如果你给它 32k，而 harness 不做上下文管理，失败不是线性的，是断崖式的。
这就把“上下文管理”从一个锦上添花的优化，变成了预算约束下的生存策略。论文里说得很具体：在基于 LLM 的摘要之前先做基于规则的省略，是总体效率最强的策略。 这句话我盯了半分钟。它的意思是：你不需要让一个聪明模型去总结所有历史，你先用规则把显然没用的东西砍掉——比如已经成功写入文件的命令输出、重复的失败信息——剩下的再交给模型去压缩。而且那个“让被省略的内容可恢复”的机制，就是你可以加一个“展开全部”的按钮或者一个可查询的 memory，论文发现模型很少用，还带不来准确率提升。这很残酷：你花工夫做的“可恢复性”，模型根本不领情。
这个发现直接打脸了一类 agent 框架的设计哲学。过去一年我见过不少框架在上下文管理上做“可恢复记忆”“分层历史”“智能压缩”，看起来高级。但这篇论文的数据说：先砍再压缩，模型用得最顺；可恢复性是个幻觉需求。我不是说那些设计全错，但它们可能解决的是“用户以为模型需要什么”，而不是“模型实际需要什么”。这条我觉得做 agent 工程的人该打印出来贴桌上。
再讲规划。论文说规划对较弱模型更像准确率支架，对较强模型更像成本节省手段，准确率变化不大。这里的“支架”不是修辞——弱模型没有规划步骤时，动作是散的，写到后面忘了前面；给它一个规划步骤，轨迹明显更稳。但强模型呢？你给它规划，它本来也会规划，加一层 harness 触发的规划只是让它的轨迹更短、成本更低，准确率不会因为规划而跃升。这意味着如果你在调一个强模型加大预算的 agent，规划组件的设计优先级可以往后放；如果你在调一个中等模型加预算紧的 agent，规划组件是你能抓住的第一根救命稻草。
这里我要插一句，也是我读这篇论文时最舒服的一点：他们没有把规划吹成“让 agent 变聪明”的东西。他们说的很克制——规划改变的是轨迹停止的位置，上下文管理延长轨迹而不改变行为，动作空间改变代码写入的粒度。这句话，原文里就这个意思，但你知道它多值钱吗？它把三个组件各自的“作用截面”划清楚了。轨迹级分析不是看最终分数，是看 agent 在过程中怎么一步步走过来的，这样才能说“这个组件到底在哪个时刻影响了什么”。很多 harness 论文只报最终 pass@1，你根本看不出它改的东西是让代理更聪明了，还是只是让它少走了几步。这中间差着十万八千里。
动作空间的发现也很有意思。预定义工具能提升 bash 能力较弱模型的表现，但具备 bash 能力的模型可以只靠 bash 接口有效工作，而且成本显著更低，尤其在以命令行为主的任务上。这条基本是在说：工具是给弱模型准备的拐杖，强模型自己会走路。你在一个强模型上套一堆精心设计的预定义工具——专用的文件编辑工具、git 工具、检索工具——结果往往是模型根本不用你的工具，它自己写 bash 命令就干完了，而且成本更低。你花两个月设计的工具层，对强模型来说是一层多余且可能碍事的抽象。但对弱模型，没有这套工具它连基础的 bash 都玩不转。
这跟规划那条发现放到一起看，有一个统一的画像：harness 组件的价值高度依赖底层模型的自理能力。 模型越强，harness 的干预应该越少、越透明；模型越弱，harness 的干预就要越结构化、越像支架。而很多 agent 框架的问题在于，它们对强模型和弱模型用同一套 harness，然后惊讶于“为什么我的框架在 GPT 上没提升、在开源小模型上有提升”。因为你的框架是支架，不是放大器。
现在回到开头那个判断。我说 harness 是承重墙，不是壳。这篇论文最让我信服的一点是，它没有声称 harness 能“超越”模型能力，没有给 agent 框架抬轿子。它说的是：harness 真正的作用是决定模型能力在长周期任务里能兑现几成。你有一个强模型，harness 设计得烂，能力打七折；你有一个中等模型，harness 设计得好，能力能多保住两成。这个“打折”和“保住”的过程，以前我们都靠感觉调，现在有人跑了 176 个设置给了你一张地图。
当然这篇文章也有边界。第一，它是经验研究，不是理论框架，所有结论都绑在四个模型和两个 benchmark 上。换一个模型家族、换一个任务类型，具体的策略排名会变——但它给的“预算感知”和“模型感知”这个框架不会变。第二，它的轻量级 harness 和执行循环未必能覆盖生产级 agent 的复杂度，比如多模态上下文、工具调度的并发性、长任务的记忆检索。第三，它没有回答“这些组件组合起来的最优解是什么”，它回答的是“每个组件在什么条件下起什么作用”。如果你指望从这篇论文里抄一套“最佳 harness 配置”，你会失望；但如果你要的是“我今天该优先调哪个组件的判断依据”，这篇论文是目前能给你的最扎实的。
工程上能直接用的结论就是这几条：预算紧就重点搞上下文管理——规则省略加 LLM 摘要，别做可恢复性；弱模型加规划、加预定义工具；强模型少干预，让它自己用 bash。这些都不是新概念，但没有这篇论文的数据，你只能靠直觉和运气去排列它们。现在你有数据了。这篇论文值得读的其实是它的方法论：固定执行循环，只改一个组件，然后看轨迹。这种“控制变量加轨迹级分析”的思路，比换模型跑分高了不知道多少倍。
我可能是过严，但解读论文这事儿，宁可慢一拍也别把半懂当初懂。这篇论文我读的时候也有个反复：一开始觉得它太“工程”、太不像论文；后来发现它解决的问题恰恰是论文最不该回避的问题——我们凭什么相信一个 agent 系统报告出来的提升，是模型强了，还是 harness 变了？把这层拆开，很多被吹爆的 agent 框架就显得可疑了。这堵墙我替你拆了，路得你自己走。