一个 LLM agent 的表现从来不是模型单独决定的，还有一层经常被低估的东西，harness，也就是围绕模型运行的系统层：系统提示词、工具集、记忆机制、验证规则、编排逻辑、失败恢复流程。同一个模型换一套 harness，表现能差出一倍以上。这个事实本身不新鲜，但它带出一个越来越棘手的工程问题：不同模型的失败模式、工具使用习惯、对提示格式的敏感度都不一样，一套对 A 模型有效的 harness 换到 B 模型上可能是次优的。而现在新模型发布的速度已经快到没有人力能跟上手工调优的节奏，为每个新模型定制一套 harness 正在变成一件成本失控的事。
这篇来自上海人工智能实验室的论文提出了一个直接的应对思路，Self-Harness：让 agent 自己改自己的 harness，不依赖人类工程师，也不依赖一个更强的外部 agent 来指导。这个设定和此前的 Meta-Harness 路线明确不同，Meta-Harness 是用一个更强的外部 agent 去优化一个较弱 agent 的 harness，本质上还是外部指导。Self-Harness 把这个改进循环收进了目标 agent 自己内部，同一个模型既是被评估的执行者，也是提出修改方案的提议者。这个区分不是文字游戏，它直接决定了这套方法的适用边界，对于没有更强外部 agent 可用的前沿模型，或者外部指导和目标模型的失败模式本身不匹配的场景，内部化的自我改进是唯一可行的路径。
具体机制是一个三段式的迭代循环。第一段叫 Weakness Mining，模型在当前 harness 下跑一批任务，把失败的执行轨迹按照一个三元签名聚类，这个签名记录了验证器最终判定的失败原因、agent 行为在这次失败里起到的因果作用、以及暴露出来的抽象行为机制。这里有个设计上的关键考量，两次失败即使表面上是同一种验证器错误，比如都是超时，如果背后的 agent 行为机制不同，也不会被聚到一类里，因为它们需要的 harness 修改是不一样的。聚类的目的不是发现语义相似性，是找出哪些失败可能被同一个 harness 级别的干预解决。
第二段是 Harness Proposal，同一个模型换上提议者的角色，基于聚类出来的失败证据生成一组候选修改。这里强制了两个约束，多样性和最小性，多个候选方案要指向不同的失败机制或者不同的 harness 编辑面，不能是同一个改动换种说法；而单个候选方案又必须收得足够窄，只改动它针对的那个机制需要的部分，不动整体的控制架构。这个约束本身在回应一个常见的失败模式，模型的自我改进很容易滑向给系统提示词堆砌越来越多的通用指令，看起来在优化，实际上什么具体问题都没解决。
第三段是 Proposal Validation，每个候选 harness 会被拿到 held-in 和 held-out 两个任务集上重新评估，只有同时满足两个 split 都不退步、且至少一个 split 有提升的候选，才会被接受合并进下一版 harness。这个验收规则是保守的，宁可放过一些只是拆东墙补西墙的候选，也不接受用一个 split 的退步去换另一个 split 的提升。这套机制本质上是把 harness 的迭代变成了一个有审计轨迹的实证过程，每一次版本跃迁都有明确的证据、明确的修改面、明确的评估结果，这个可审计性在我看来比性能数字本身更重要，因为它意味着这套自我改进不是一个黑箱式的漂移，而是一串可以回溯、可以复现、必要时可以回滚的决策记录。
实验在 Terminal-Bench-2.0 上跑了三个来自不同家族的模型，MiniMax M2.5、Qwen3.5-35B-A3B、GLM-5，起点是一套刻意做得很简陋的初始 harness，只有基本的文件读写编辑和 shell 执行工具，外加一句系统提示。结果是三个模型在 held-out 集上的通过率分别从 40.5% 涨到 61.9%，23.8% 涨到 38.1%，42.9% 涨到 57.1%，相对提升在 33% 到 60% 之间。这里最值得注意的不是提升的幅度，是提升发生在 held-out 集上，也就是提议阶段完全没见过的任务。这说明被接受的修改指向的是可复用的执行机制，不是针对已知失败案例的死记硬背式补丁，这也是判断一套自我改进方法有没有在真正泛化、还是只是在过拟合评估集的核心检验点。
三个模型学到的修改内容彼此并不相同，这一点本身构成了对核心假设的支持证据。MiniMax M2.5 的问题集中在拖太久才产出必需文件、结构化工具输出处理不够严谨、以及陷入低效的工具调用循环，对应的修改是让 agent 更早创建输出文件、更谨慎处理工具返回的结构化内容、以及给总工具消息数设一个上限逼着它在循环变得冗长之前转向。Qwen3.5 的问题集中在不检查依赖就动手、重复尝试同一个失败命令、陷入无止境的探索循环，对应的修改是提前检查依赖、打断重复失败的命令、以及在工具报错后提醒 agent 恢复到产出必需文件的轨道上。GLM-5 的问题是环境设置在 shell 命令之间不能持久保留，以及从探索阶段迟迟不转向实现和测试，对应的修改是让环境变更在会话间保持，并加入一条规则，如果一直在探索却没有产出任何必需文件，就该切换到实现和验证。三套修改指向三种完全不同的执行病理，这比单纯的分数提升更能说明这套方法确实在做诊断式的干预，而不是给所有模型贴同一张万能膏药。
不过这套结果的边界也需要老实交代，论文自己也承认了这几点。第一，这是一个有界的、封闭基准下的 harness 编辑，不是开放式的自我改进，被接受的修改很可能带着 Terminal-Bench-2.0 这个具体基准的印记，换到另一个完全不同的任务分布上，这些修改是否依然是最优解并不确定。第二，整套验收机制依赖验证器判定和执行轨迹记录的质量，如果验证器本身有系统性盲区，比如某类失败被误判为通过，那么建立在这个验证器之上的证据链条会连带出问题，这是一个自指式的风险，用来判断 harness 是否改进的标尺，本身没有被单独验证过。第三，验收规则只是 pass count 不退步这一条硬性条件，对于高风险场景，比如涉及资金操作或者不可逆动作的 agent，仅凭一个基准上的非退步就放行一次 harness 变更，这个门槛显然是不够的，论文里也明确提到更高风险的 harness 变更需要比通过率不退步更强的验收门。
往更大的图景看，这篇论文真正有意思的地方，不是它把某个基准的分数往上推了多少，是它把 harness 工程从一种人工设计活动，重新定义成了一个可以被系统化、可审计、可复现的实证状态转移过程。过去 harness 怎么写，很大程度上依赖工程师对某个模型的经验直觉，这个经验没法沉淀、没法迁移，换一个模型往往要重新摸索。Self-Harness 把这个摸索过程本身变成了一个带证据、带验收规则的循环，这意味着未来面对模型迭代速度进一步加快的局面，某种程度的 harness 自适应可能会从一个加分项变成一个必要项，就像模型训练本身早就离不开自动化的超参数搜索一样。当然，从一个受控基准上的验证走到真实生产环境里的自适应 harness，中间还隔着验证器可靠性、风险分级验收、以及跨任务分布泛化这几道没有被这篇论文完全解决的坎，这些坎恰恰是判断这条路线能走多远的关键，而不是它现在展示出的这几个百分点。
