你的 Agent 又崩了。
它跑了一个终端任务，前三十步一切顺利，然后突然陷入了一个死循环：反复执行同一条命令，反复得到同一个报错，反复重试，直到超时。任务失败，产物缺失，验证器打了个叉。
你打开日志，从头到尾看了一遍，发现问题出在 harness 层面：agent 没有在失败后切换策略，没有在超时前创建产物，没有在探索阶段和实现阶段之间做切换。这些都不是模型能力的问题，是"操作系统"的问题。
于是你又开始改 prompt 了。加一条"如果工具调用失败，请检查错误并调整策略"。加一条"在结束前，请验证结果"。加一条"不要盲目重试相同的操作"。
改完，跑一遍，好了一点。但另一个任务又崩了，崩在一个你没预料到的地方。你又改 prompt。再跑，再崩，再改。
这个循环，每一个做 Agent 开发的人都经历过。
上海AI Lab(上海人工智能实验室)最近的这篇论文，Self-Harness，提出了一个不同的思路：别再你改了，让 Agent 自己改自己的 harness。
Harness：Agent 真正的"操作系统"
先搞清楚一个概念。很多人把 harness 和 system prompt 混为一谈，觉得 harness 就是那一段开场白。不是。
Harness 是围绕语言模型的完整环境中介系统。它包括系统提示，但也远不止于此。它还包含工具定义、运行时控制策略（比如最大工具调用次数、错误重试上限）、验证规则、编排逻辑、故障恢复程序、子 agent 配置、技能定义。
打个比方。语言模型是 CPU，harness 就是操作系统。CPU 再强，如果操作系统调度不行、内存管理混乱、IO 处理低效，整台机器的性能就是上不去。同一个 CPU，换个操作系统，性能可以差几倍。
论文里有一句话很精准："许多重要的 agent 失败是 harness 层的失败，而非孤立模型响应的失败。"
什么意思？你的 agent 没有在结束前验证产物，这往往不是模型不会验证，而是 harness 里没有"结束前验证"这个运行时规则。你的 agent 陷入了重复无效动作的死循环，同样，harness 里可能缺少"连续 N 次相同错误后重定向"的控制策略。你的 agent 在长上下文中丢失了关键信息，问题也可能出在 harness 里没有"定期回溯关键事实"的编排逻辑。
这些失败，改模型权重解决不了，改 system prompt 的一句话也解决不了。它们需要的是对 harness 这个"操作系统"做结构性的修改。
人类的困境：为什么手工调 harness 不可持续
当前 harness 设计主要有两种范式，但两种都有硬伤。
第一种是人工工程范式。ReAct、Claude Code、Codex、OpenHands、SemaClaw，这些系统的 harness 都是人工设计和调优的。人类专家研究 agent 的失败模式，手动修改指令、工具定义、运行时策略。
这个范式的问题在于扩展性。现在的 LLM 生态是高度多样化的：不同模型家族、不同参数规模、不同训练数据、不同的工具使用习惯。你为 MiniMax 调好的 harness，直接用在 Qwen 上可能效果很差。为 Qwen 调好的，用在 GLM 上又是另一套。每出一个新模型，你就得重新来一遍。
更要命的是，模型在快速迭代。你的 harness 刚调好，下一代模型出来了，行为模式变了，你之前的调优又白费了。人类工程师的速度跟不上模型迭代的速度。
第二种是外部优化范式。用一个更强的 agent 来改进较弱目标 agent 的 harness。比如 Meta-Harness，用源代码、分数、轨迹直接优化 harness 代码。
这个范式的问题是：你需要一个更强的 agent。但前沿模型不是随时都有的，也不便宜。而且，一个"更强的外部 agent"提出的 harness 编辑，可能和目标模型的实际故障模式不匹配。它从自己的视角看问题，但目标模型的弱点和它不一样。
两种范式的共同问题：设计者不是模型自己。 不管是人类还是更强的外部 agent，都是从外部视角来改 harness。但最了解一个模型在什么 harness 下会怎么行为的，恰恰是那个模型自己。
Self-Harness 的核心思想：三层分离
Self-Harness 的方案说起来很简单：让模型自己改自己的 harness。但"怎么做"才是论文真正的贡献。
论文设计了一个精巧的实验架构，核心是三层分离。
模型层不动。语言模型 M 是固定的，不管是 MiniMax M2.5、Qwen3.5-35B-A3B 还是 GLM-5，权重不变，推理参数不变。你不是在微调模型，你是在改模型周围的"脚手架"。
评估器不动。评估器 E 是固定的，它负责判断任务是通过还是失败。这个评估器不是 agent 自己说了算，是外部的、确定性的验证器。agent 不能自己给自己打分。
只有 harness 动。所有的改进都发生在 harness 层面。harness 从初始版本 h₀ 开始，经过若干轮迭代，演化为 h₁, h₂, ..., h_T。每个迭代都是对 harness 的有限编辑，不是推倒重来。
这个设计有几个妙处。
它隔离了改进行为的来源。如果性能提升了，你可以确定地说：这是因为 harness 变了，不是因为模型变了，不是因为评估标准变了。这在实验上非常干净。
它也让自我改进成为模型内在能力的体现。同一个模型，在同样的评估器下，能不能自己改好自己的 harness？如果能，说明这个模型有"自我认知"的能力，它能看到自己的失败模式并提出改进。
还有可审计性。harness 的每一次变更都是明确的、记录在案的、可回溯的。不是黑箱微调，是白纸黑字的"改了这一行指令，加了这一条运行时规则"。
论文引了柏格森的一句话："对于一个有意识的存在，存在就是变化，变化就是成熟，成熟就是不断自我创造。"Self-Harness 做的就是让 agent 的"操作系统"持续自我创造。
三阶段闭环（一）：Weakness Mining
整个 Self-Harness 的流程是一个三阶段闭环，每一轮迭代都走一遍这三个阶段。第一个阶段叫 Weakness Mining。
大多数 agent 自我改进系统处理失败的方式是：记录失败，存一条反馈，下次遇到类似问题时调用。Reflexion 就是这个思路。但 Self-Harness 的做法不一样，它不是简单地记录"这个任务失败了"，而是要搞清楚这个失败属于什么类型。
具体怎么做？每个失败的任务实例会产生一条执行轨迹，包括任务输入、agent 的所有操作、最终输出、以及验证器的判定。Self-Harness 的评估系统会分析这条轨迹，提取一个失败签名，包含三个维度。
第一个维度是终端验证器层面的原因（c）：验证器为什么拒绝了这次运行？是产物缺失？是超时？是产物格式不对？是 sanity check 没过？
第二个维度是相关 agent 行为的因果状态（q）：agent 做了什么导致了这个验证器拒绝？是在该创建产物的时候没创建？是陷入了重复操作？是在探索阶段浪费了太多时间？
第三个维度是抽象 agent 机制（m）：这个失败暴露了什么可复用的行为机制缺陷？是"缺乏产物交付意识"？是"没有失败重定向策略"？是"环境持久性缺失"？
三个维度组合起来，构成一个失败签名 φ(rᵢ) = (cᵢ, qᵢ, mᵢ)。然后，失败签名完全一致的案例被聚类在一起。
这个聚类规则是确定性的、验证器锚定的。两个失败案例只有在验证器拒绝原因相同、agent 行为因果相同、抽象机制缺陷相同时，才会被分到一组。
为什么要这么做？因为目标是聚合可能接受相同 harness 层干预的失败。如果两个超时失败的底层原因不同，一个是因为重复操作浪费了时间，另一个是因为下载外部资源太慢，它们需要完全不同的 harness 修改。把它们放在一起没有意义。
论文特别强调了一个设计原则：区分表面症状与可复用失败机制。两个运行可能共享相同的验证器结果（比如都超时了），但因为底层 agent 行为不同，需要不同的 harness 变更。如果你只看验证器结果来聚类，你就会把不该放在一起的案例放在一起，导致后续的 harness 提议打偏。
最终，每个聚类会被整理成一个结构化的失败模式，包含聚类大小、代表性任务实例、共享轨迹症状、验证器证据、推断的 agent 机制。聚类按支持度和估计可操作性排序。
所有这些失败模式被打包成一个证据束 Bₜ。这个证据束不预设任何 harness 编辑方案，它只是把"验证器层面的失败"和"agent 层面的机制"分离开来，让下一阶段的提议者可以针对特定的可复用弱点来设计修改，而不是在粗粒度的失败结果上打补丁。
三阶段闭环（二）：Harness Proposal
第二个阶段叫 Harness Proposal。拿到了证据束 Bₜ 之后，需要把失败模式转化为候选的 harness 编辑。
这个阶段有一个关键设计：提议者就是模型自己。不是外部优化器，不是更强的 agent，是同一个固定模型 M，在当前 harness hₜ 下，以"提议者"的角色被调用。
这意味着什么？模型是在自己的"操作系统"里，看着自己的失败记录，提出修改自己"操作系统"的方案。它不是从外部视角来看问题，它是在内部视角下做自我诊断。
但提议者不是随便提的。它在一个受限上下文下工作，只能看到：当前 harness 的可编辑表面（哪些配置点可以改）、来自评估系统的失败模式（证据束 Bₜ）、应该被保留的通过行为记录、以及之前尝试过的编辑摘要（避免重复提议已经被拒绝的方案）。
模型会并行生成 K 个相互不同的提议束。每个提议包含两部分：一个编辑 Δⱼ（描述如何把当前 harness 映射到候选 harness），和一个审计记录 aⱼ（描述目标失败模式、编辑的 harness 表面、预期行为效果、回归风险）。
候选必须满足三个要求。
第一是锚定性。每个提议必须锚定于一个主要失败机制，并映射到具体的可编辑表面。不能泛泛地说"改进 agent 的执行能力"，必须说"修改 bootstrap 指令，从'识别最小编辑表面'改为'识别所需输出产物并尽早创建初始版本'"。
第二是实质性不同。K 个候选之间不能只是措辞不同的同一修改。它们要针对不同的失败机制，或者选择不同的 harness 表面，或者表达不同的改进假设。
第三是可寻址性。不是每个失败聚类都意味着有用的 harness 修改。有些聚类反映的是任务本身太难、模型能力不够、或者结果不稳定。这些不是 harness 能解决的，提议者需要识别并跳过它们。
还有一个设计原则贯穿整个提议阶段：跨提议分支鼓励多样性，每个分支内强制最小性。不同的候选可以大胆尝试不同的方向，但每个候选内部的修改要尽可能小，只改解决选定机制所需的表面，不动不相关的 harness 行为，不做大范围重写。
这个设计背后的哲学是：harness 编辑应该是外科手术式的，不是推倒重来。你改的是操作系统的几个配置项，不是重装系统。
三阶段闭环（三）：Proposal Validation
第三个阶段叫 Proposal Validation。候选提出来了，不等于就会被采纳。Self-Harness 的验证机制非常保守，保守到几乎偏执。
每个候选 harness 变体会在两个数据分割上被评估：held-in 和 held-out。Held-in 是提议者看到过的数据，用来验证提议是否解决了驱动它的证据。Held-out 是提议者从未看到过的数据，作为对提议者未可见行为的回归测试。
计算两个分割上的改进量：
Δᵢₙ = Pᵢₙ(候选) - Pᵢₙ(当前) Δₕₒ = Pₕₒ(候选) - Pₕₒ(当前)
接受规则是：
候选必须在至少一个分割上改进，且不在任何分割上退化。
换句话说，Δᵢₙ ≥ 0 且 Δₕₒ ≥ 0 且 max(Δᵢₙ, Δₕₒ) > 0。
这个规则比你想象的严格。它拒绝了所有"在一个分割上改进但在另一个分割上退化"的提议，即使总通过数增加了。为什么？因为如果你在 held-in 上改进了 5 个案例但在 held-out 上退化了 3 个案例，你不确定这个改进是真正的行为改善还是对 held-in 数据的过拟合。保守的接受规则确保每个被采纳的修改都是真正的、泛化的改进，而不是在训练数据上刷分。
当评估有随机性时，候选会被重复评估，跨重复的通过计数都要满足规则。如果一个提议不修改任何可编辑表面，或者在获得有效评估结果前就执行失败了，也会被拒绝。
每个候选的评估记录都会被保存：变更了什么表面、两个分割的结果、评估重复次数、提议摘要、接受还是拒绝。这让 harness 演化过程中的每一步都可审计。你可以回溯到任何一个世代，看到当时改了什么、为什么改、结果如何。
如果同一轮中有多个兼容的候选被接受，它们的编辑会被合并到下一个 harness 世代。如果没有候选被接受，harness 保持不变，进入下一轮。
这个验证机制的核心价值观是：宁可不改，也不错改。 harness 的每一次变更都必须是经过验证的、稳健的、可泛化的改进。一个错误的 harness 修改可能引入新的失败模式，而这些新的失败模式可能比原来的更难诊断。保守的门控是这个系统能稳定运行的基础。
Terminal-Bench-2.0：三场战役
论文在 Terminal-Bench-2.0 上做了实验。这是一个多轮 agentic 基准测试，agent 需要与真实的容器化终端环境交互，完成 89 个任务，涉及产物管理、命令使用、验证行为、执行错误恢复。评估集是固定的 64 个案例子集，排除了依赖不稳定外部资源或需要多模态输入的任务。通过与否由确定性验证器基于最终容器状态判定。
三个模型参赛：MiniMax M2.5、Qwen3.5-35B-A3B、GLM-5。来自三个不同的模型家族，能力水平和行为模式差异很大。初始 harness 是一个最小化配置：短系统提示、默认文件系统和 shell 工具、运行时控制策略关闭、无子 agent、无技能。
结果：
三个模型，全部改进。没有一个 promoted harness 在任何分割上退化。所有模型在 held-out 上都有提升，说明改进不局限于构建提议证据的 held-in 数据，是真正的泛化。
最亮眼的数据：MiniMax M2.5 在 held-out 上绝对增益 21.4 个百分点，相对增益 53%。Qwen3.5 在 held-in 上相对增益 138%，从 15.1% 直接干到 36.0%，翻了一倍多。
但比这些数字更精彩的，是每个模型到底"学会了什么"。
每个模型学会了什么？
这是论文最有意思的部分。三个模型经过 Self-Harness 迭代后，保留的 harness 编辑截然不同。不是因为它们在做同一类任务遇到了同一类问题，恰恰相反，每个模型的失败模式都不一样，所以它们给自己开的药也不一样。
MiniMax M2.5：学会了"早点交卷"
它的主要问题是：在找到相关信息后还在继续探索，导致超时，且没有创建所需产物。Self-Harness 给它加了两条修改。一是把 bootstrap 指令从"识别最小编辑表面"改成了"识别所需输出产物并尽早创建初始版本"。二是启用了运行时控制策略，设置了最大工具消息数限制，防止 agent 在工具调用循环里耗太久。
有个具体案例。count-dataset-tokens 任务，要求 agent 计算数据集的 token 总数并写入 /app/answer.txt。初始 harness 下，MiniMax 找到了相关元数据配置后还在继续探索数据集，最后超时，answer.txt 根本没创建。编辑后的 harness 下，它识别出元数据支持的 science 子集，算出 token 总数，写入文件，回读验证，任务通过。就这么简单。不是模型变聪明了，是 harness 告诉它"别逛了，先把作业交了"。
Qwen3.5：学会了"丢分后补考"
Qwen 的问题完全不同。它确实会创建产物，但经常在中途把产物搞丢。比如 extract-elf 任务，它创建了提取器脚本 /app/extract.js，但随后进入了反复覆盖和编辑失败的循环，最后居然把 extract.js 自己删了。验证器一看，产物没了，直接判失败。
Self-Harness 给 Qwen 加了一个工具错误触发的产物恢复中间件。当工具调用出错时，系统提示会重定向 agent 去检查所需产物是否存在，如果不存在就重建。这个中间件还附带了预先检查依赖、避免重复失败命令、打破无尽探索循环的指令。
效果：工具出错后，agent 不再继续盲目操作，而是先检查产物，发现缺失就重建提取器、修复解析逻辑、写入输出文件、对 JSON 结果做验证。任务通过。
Qwen 的另外几条保留编辑也很有意思：预先检查依赖（别等到跑起来了才发现缺东西）、避免重复失败的命令（同样的命令报了三次错就别再试了）、打破无尽探索循环（探索够了就动手干活）。这些听起来都是常识，但 Qwen 在初始 harness 下就是做不到，因为初始 harness 里没有这些运行时规则。
GLM-5：学会了"从探索切换到实干"
GLM-5 的问题又是另一种。它有一个很贵的毛病：喜欢长时间下载外部资源。build-pov-ray 任务里，它花了大量工具预算在一个单体外部下载上，后来虽然做了一些工作，但 sanity check 是非零的（说明有问题），它还是直接最终化了。验证器一看，没过。
Self-Harness 给 GLM-5 加了两条修改。一是环境持久化：跨 shell 命令保持环境设置持久，让安装的工具或路径变更在 shell 会话间不丢失。二是从探索到实现的过渡约束：如果 agent 在探索而未产生所需产物，应该过渡到实现和测试解决方案。具体来说，使用有界分阶段操作，在提交更多工作前检查外部存档证据，在最终化前修复失败的 sanity check。
三个模型，三种完全不同的"学习成果"。这正是 Self-Harness 的核心价值：它不是给所有模型套同一个优化模板，而是让每个模型发现自己的失败模式，然后针对性地修改自己的 harness。
论文的数据也印证了这一点。三个 promoted harness 都添加了改善产物交付的机制，但方式完全不同：MiniMax 是"尽早创建输出"，Qwen 是"产物中间件恢复"，GLM-5 是"从探索过渡到实现"。同一种问题（产物交付），三个模型用三种不同的 harness 编辑来解决。
为什么这个范式重要
Self-Harness 不是一篇"我们比 baseline 高了 3 个点"的论文。它提出的是一个范式转变。
以前，harness 的设计和优化是人类工程师的活。你需要理解模型的失败模式，手动设计运行时规则，手动调优指令。Self-Harness 说这件事可以自动化，而且应该自动化，因为模型自己最了解自己的行为模式。这就是从"人类改 harness"到"Agent 自己改 harness"的范式转变。
harness 的每一次变更都有完整的记录：改了什么、为什么改、改之前和改之后的表现如何。这是白盒子的、可追溯的、可回滚的。如果某个 harness 世代引入了问题，你可以精确定位到是哪个编辑导致的，撤销它就行。这在生产环境里很重要，你不可能让一个黑箱优化器随便改你 agent 的运行规则然后祈祷不出事。
放到模型多样性时代的背景下来看，这件事的紧迫性更明显。现在有几十个模型家族，每个家族有不同规模、不同训练数据、不同行为模式。为每个模型手工调 harness 不可持续。Self-Harness 提供了一条可扩展的路径：不管什么模型，丢进同一个框架里，让它自己改自己的 harness。
还有一个更远的想象空间。如果一个 agent 能改自己的 harness，那多个 agent 能不能互相改 harness？一个 agent 发现了某个 harness 配置的改进，能不能迁移给另一个 agent？这些问题 Self-Harness 还没有回答，但它把门推开了。
最脆弱的假设
说完好的，说说这篇论文最脆弱的地方。
第一个要质疑的假设：弱模型能自我诊断。Qwen3.5-35B-A3B 的初始 pass rate 只有 15.1%，这是一个相当弱的模型。它真的有能力分析自己的失败轨迹并提出有效的 harness 编辑吗？论文的数据显示它可以（相对增益 138%），但这里有一个潜在的选择偏差：被接受的编辑通过了回归测试，但被拒绝的编辑有多少？如果提议者生成了大量无效甚至有害的提议，只是被验证机制挡住了，那"自我改进"的功劳有多少应该归于提议者的智慧，多少应该归于验证机制的保守？
第二个假设关于泛化。所有实验都在 Terminal-Bench-2.0 上做的。接受的编辑可能反映的是这个基准特定的失败模式。换个基准，比如 SWE-Bench 或者 WebArena，同样的 Self-Harness 流程还能产生有效的 harness 编辑吗？论文自己也在局限性里承认了这一点。
第三个问题更微妙：太保守的门控错过了什么？接受规则要求"至少一个分割改进且不退化"。这个规则很安全，但它会拒绝那些"在一个分割上大幅改进但在另一个分割上小幅退化"的提议。如果有些真正有价值的结构性改进需要短期的小退化才能换来长期的大提升，保守的门控会把它们全部挡在门外。你永远不知道你错过了什么。
下一次，不是你改 prompt
回到开头的场景。你的 Agent 又崩了，你又要去改那个该死的 prompt 了。
但现在有了一个不同的选项。
你可以不自己改。你可以让 Agent 跑一轮，收集失败轨迹，聚类失败模式，让 Agent 自己看着自己的失败记录，提出 harness 的修改方案，然后在回归测试中验证这些修改是否真的有效。如果有效，接受；如果无效，拒绝。下一轮再来。
你不再是 harness 的设计师，你成了 harness 演化的观察者。你的工作不是想出"正确的" harness 配置，而是设计一个让 harness 能自我改进的框架。
Self-Harness 做的事情，说到底就是把"改 harness"这件事从人类的手里交到了 Agent 自己手里。不是一次性交出去，是一轮一轮地、有验证地、可回溯地交出去。
柏格森说"成熟就是不断自我创造"。现在你的 Agent 也有了自我创造的机会。不是创造自己的权重，而是创造自己运行的规则。
下次你的 Agent 崩了，先别急着打开 prompt 编辑器。问它一句：你觉得你的操作系统哪里需要改？
也许它自己知道答案。
