夜雨聆风一句话讲清楚👉🏻 上海人工智能实验室提出 Self-Harness 范式，让固定权重的 LLM Agent 根据执行轨迹挖掘自身弱点、提出并回归验证 Harness 修改，在 Terminal-Bench-2.0 上把三款模型的 held-out 通过率分别推到 61.9%、 38.1%、 57.1%；其中 Qwen3.5 在 held-in 集上相对提升高达 138%，说明极简 Harness 对小模型的压制有多狠。
论文标题：Self-Harness: Harnesses That Improve Themselves
论文链接：https://arxiv.org/abs/2606.09498
Claude Code 、 Codex 、 OpenHands 这类 Agent 产品背后，真正决定成败的往往是底座模型 + Harness 的组合。 Harness 就是包住模型的「执行脚手架」——系统 Prompt 、工具集、验证规则、失败恢复策略、运行时控制逻辑，全都算在内。同一个 GPT 级模型，换一套 Harness ，终端任务通过率能差出十几个百分点。
问题是： Harness 至今仍主要靠人类工程师手工打磨。模型家族越来越多、迭代越来越快，给每个新模型单独调一套 Harness ，成本已经跟不上了。上海人工智能实验室（ Shanghai AI Lab ）刚挂出的 Self-Harness 论文，换了一条路——让 Agent 自己改自己正在用的 Harness，不依赖更强外部模型，也不靠人类逐行改配置。
Harness 改进的三种范式：人类工程、 Meta-Harness （强模型改弱模型）、 Self-Harness （模型自我改进）。
Harness 到底是什么？为什么它比 Prompt 更重要？
论文把 Harness 定义为模型与环境之间的非参数化执行协议层。它包括：
可以把 LLM 想成技能固定的工人， Harness 是他的操作手册。 Self-Harness 不雇新工人、也不改造工人，只不断修订手册，再用实际产出验证修订是否有效。形式化地说，固定模型 在 Harness 下处理任务 ，产生执行轨迹 和输出 ；评估器 给出 pass/fail 。优化对象是 Harness 序列 ，模型权重和评估器始终冻结 ，只改周围的执行协议。
这和 Reflexion 、 Agentic Context Engineering 等「自我改进」工作有本质区别：后者改的是记忆、上下文或单次回复策略； Meta-Harness 等外部优化器则由更强 Agent 搜索 Harness 代码。 Self-Harness 要求同一个固定模型，在当前 Harness 约束下，根据自己的失败证据 提出有界修改——更像 Agent 在给自己写「操作手册」。
Self-Harness 三阶段闭环
整条链路可以概括成 Weakness Mining → Harness Proposal → Proposal Validation，论文 Algorithm 1 给出了完整伪代码。核心直觉是：先把零散失败变成可操作的证据，再让模型当 Proposer 出补丁，最后用回归测试决定是否合并进下一代 Harness 。
一轮 Self-Harness 优化循环：评估→聚类失败→并行提案→回归验证→合并或拒绝。
阶段一： Weakness Mining （弱点挖掘）
在轮次 ，用当前 Harness 在 held-in 任务集 上跑固定模型 ，收集轨迹记录 ，其中 为验证结果。
失败记录集合 会先经过验证器驱动的确定性聚类，再结构化交给 Proposer 。每条失败轨迹被归因成一个三元组签名：
只有签名完全相同的失败才归入同一簇 。这一步刻意避免「语义相似但机制不同」的失败被混在一起——比如两个任务都超时，一个是因为死循环调工具，另一个是因为没写输出文件，需要的 Harness 补丁完全不同。
每个簇再整理成结构化失败模式（簇大小、代表任务、共享症状、验证器证据），按支持度和可修复性排序，打包成证据束 交给下一阶段。 只描述问题，不预设怎么改——评估器与优化器职责分离。
阶段二： Harness Proposal （ Harness 提案）
同一模型 在 Proposer 角色下，读取 、当前 Harness 可编辑接口、历史通过行为、以往被拒提案摘要，并行生成 个互异提案：
每个 把 映射到候选 Harness ， 是审计记录（针对的失败模式、修改表面、预期行为、回归风险）。
提案必须满足两条硬约束：
Proposer 还会过滤「不可修复」的簇——纯能力上限、任务特异性难度、证据不足的失败，不会硬凑修改。
阶段三： Proposal Validation （提案验证）
候选 Harness 不能「提议即采纳」。对每条提案，在 和 held-out 上分别重跑评估（ held-out 轨迹从未暴露给 Proposer ，专做回归门）。
记 、 为 Harness 在两个 split 上的通过任务数，候选相对当前 Harness 的增益为：
接受规则 极其保守：
也就是说：至少一个 split 有提升，另一个 split 不能退步；靠「牺牲 held-in 换 held-out 」的提案一律拒绝。同一轮多个兼容提案可合并进 ；被拒提案只记日志，不改活跃 Harness 。评估带随机性时会重复跑并聚合 pass 计数，降低单次侥幸过关的概率。
实验设置：极简 Harness 上的公平对比
论文在 Terminal-Bench-2.0 上验证——89 个容器化终端任务，考察工具调用、产物管理、验证行为、错误恢复等 Agent 基本功。主实验固定 64 个任务子集，剔除依赖不稳定外网或多模态输入、初始 Harness 不支持的条目，降低评测噪声。
三个底座模型覆盖不同家族：
初始 Harness 基于 DeepAgent SDK ，刻意保持极简：一段 Terminal-Bench 默认系统 Prompt + 基础文件读写编辑 + Shell 工具。 Self-Harness 只能修改声明好的 Harness 配置接口（指令、工具策略、验证引导、运行时策略、子 Agent 、 Skill 等），模型、解码、工具集、评测环境、评估器全部锁定。
Self-Harness 的起点：极简 DeepAgent Harness 及允许修改的声明接口。
任务集预先划分为 held-in / held-out ； held-in 供弱点挖掘与提案， held-out 仅用于晋升门控。主指标为 Pass (%)：每个 Harness 候选默认重复 2 次尝试，由任务验证器对最终容器状态判定成败。
论文未公开单轮迭代的完整 token 账单，但每个提案候选都要在 held-in 和 held-out 上各跑一遍完整评估——成本大致与「再刷一轮 benchmark 」同量级。对按 API 计费的模型，迭代轮次得精打细算。
主结果：三模型全线上涨， Qwen 相对提升最猛
下表汇总三个模型在 held-in 与 held-out 上的初始 / Self-Harness 最终通过率（数据来自论文 Figure 4 与 Section 4.2 ）：
数字背后有几个反直觉的细节：
held-out 同步上涨尤其关键：改进抓住了可泛化的执行机制缺陷，没有停留在死记 held-in 失败案例上。
进化轨迹：试错与合并并存
Self-Harness 的真实运行更像分支搜索，表面看会有平台期和回撤。论文为每个模型画了进化曲线：绿点=接受、灰叉=拒绝、阶梯线连接有效候选。
MiniMax M2.5 的 Self-Harness 进化轨迹：多次拒绝后两条接受分支合并为最终 Harness 。
MiniMax M2.5 在论文绘制的进化曲线上从 42.2% 爬到 53.9%（主结果表基于 64 任务子集报 43.0%→50.0%，统计口径略有差异），最终保留三类补丁：
Qwen3.5 从 20.3% 到 36.7%，引入了依赖预检 Skill 、工具错误 Middleware 、探索循环熔断、 artifact-ensure 子 Agent 等更重型的结构机制；其中 subagent 和 skill 分支曾因无进一步收益被整体丢弃——说明系统会主动放弃无效探索。
GLM-5 从 46.1% 到 57.0%，侧重会话级环境持久化、分阶段外部下载、以及「探索太久就转入实现与测试」的验证阶段约束。
GLM-5 进化轨迹：早期两条分支被放弃，剩余路径收敛为最终 Harness 。
三条跑下来都绕不开 artifact reliability （产物可靠性）；但补丁方向截然不同——M2.5 补内容标签和工具预算上限， Qwen 补依赖预检和重试纪律， GLM 补 Shell 环境持久化和探索—实现切换。三套脚手架没法互相抄作业，有效 Harness 必须按模型量身裁剪。
案例深潜：补丁如何改变真实执行轨迹？
论文用 Terminal-Bench 具体任务做了 before/after 轨迹对比，比宏观数字更能说明 Self-Harness 在干什么。
GLM-5 ： build-pov-ray 从「硬下完再说」到「分阶段验证」
GLM-5 在 build-pov-ray 任务上：左为初始 Harness 下长时间单体下载、忽视 sanity check ；右为编辑后分阶段操作、先验 archive 再投入、修复渲染检查后才收尾。
初始 Harness 下， Agent 把大量 tool budget 砸在漫长的外部资源下载上， sanity check 反复非零仍强行 finalize 。编辑后的 Harness 要求分阶段下载、先检查压缩包完整性、发现超时证据后换源、修复失败的渲染检查——行为路径被 Harness 从「探索型」拧向「工程型」。
MiniMax M2.5 ： count-dataset-tokens 的「先写答案文件」
接受补丁后， bootstrap 指令从「找最小编辑面」变成「识别必需输出产物并尽早创建初版」；运行时策略启用 tool message 上限。失败轨迹里 Agent 在数据集元数据里打转直到超时；成功轨迹则锁定 science subset 、算出 token 总数、写入 /app/answer.txt 并回读验证——早产物 + 有界探索 直接转化为 pass 。
Qwen3.5 ： extract-elf 的工具错误恢复
初始轨迹中 Agent 写好 extractor 后陷入反复 overwrite/edit 失败，最终删掉 /app/extract.js，验证器因缺文件判 fail 。编辑后增加 tool-error 触发的系统 Prompt ，把 Agent 拽回「补产物」主线：重建 extractor 、修正解析逻辑、校验 JSON 、确保文件在位——这是 Middleware 级干预，比堆叠礼貌用语管用得多。
与相关工作的位置关系
论文刻意把自己放在「可控、可审计」的一端：每次 Harness 变更都记录修改表面、 split 结果、接受/拒绝决策，形成可追溯的 lineage 。这对工程团队意味着——Harness 可以像代码一样走 PR + 回归测试流程，告别纯靠手感调 Prompt 的黑盒时代。
局限与未来：自进化≠无限进化
作者也坦诚了几条边界：
但从工程视角看，这篇论文给了一个清晰可落地的范式：把 Harness 改进当成经验驱动的状态转移，用执行证据替代凭直觉堆 Prompt 。当新模型每周发布、 Agent 栈越来越厚，「让每个模型自己长出合适的执行脚手架」可能比雇更多 Harness 工程师更可持续。
一点个人判断
Self-Harness 最打动我的地方，是它把「模型弱点」和「系统补丁」之间的映射做成了可验证的闭环。过去调 Agent ，常见做法是看几条失败 log 然后手写规则；这里用 verifier-grounded 聚类把失败机制结构化，再用 held-out 回归挡住过拟合——本质上是在 Harness 层做了一套轻量 RLHF ，奖励信号就是确定性验证器。
如果这条路线继续往外推，我预期会看到两类落地：
Terminal-Bench 毕竟是容器化封闭任务。真实生产的 Harness 还要处理权限、合规、多租户隔离，接受门控只会更严，这段路还很长。但至少方向是对的——Agent 时代的竞争，会越来越像「模型 × Harness 」的联合优化，参数规模只是一半故事。