不换模型，效果提升104%！上海AI Lab让Harness也能自进化了

让AI自己改自己的Agent Harness，这事已经被顶级Agent社区注意到了。

上海人工智能实验室团队提出的Self-Harness，近期被LangChain CEO、联合创始人Harrison Chase转发，也被前OpenAI副总裁Lilian Weng收进自进化Agent相关博客。

它盯上的不是换模型，而是Agent外层那套Harness。

做法很直接。模型先检查自己的运行轨迹，从失败里挖出模式，再提出有边界的Harness修改，最后交给回归测试决定要不要采纳。

实验结果显示，在Terminal-Bench-2.0上，底层模型、工具环境和评测协议都保持不变，只改Harness，三个模型后端都拿到了held-out提升。

其中Qwen3.5-35B-A3B总提升达到104%，MiniMax M2.5和GLM-5分别提升28%和24%。

论文和项目已经公开，文末附链接。

△LangChain CEO/co-founder Harrison Chase转发Self-Harness

让Harness自己进化

Agent Harness可以理解为包在模型外层的一套运行装置，覆盖系统提示词、工具使用规则、验证器、运行时控制策略和轻量middleware。

在多轮工具任务里，它决定Agent怎么调用工具，什么时候停，失败后怎么恢复，产物又该如何验证。

过去，这套东西主要靠工程师手调。要读大量执行轨迹，找失败原因，改提示词或工具规则，再反复跑benchmark。

模型越多、任务越杂，Harness就越难继续按“一模型一套人工调参”的方式扩展。

△三种Harness改进范式：人工改、强模型外援改，以及Self-Harness让模型基于自身轨迹改

Self-Harness怎么工作

换到Self-Harness，流程被压成三步。先挖弱点，再提改法，最后跑回归。

Weakness Mining：从失败轨迹挖弱点

系统先让当前Harness驱动固定模型完成一批任务，记录完整执行轨迹、工具调用和评测结果。

失败样本不会被当成孤例处理。Self-Harness会结合验证器反馈、Agent行为和失败之间的因果关系，把可复用的失败机制聚起来。

这样，“某个任务没过”会变成“这一类失败可能来自同一种Harness缺陷”。比如缺少最终产物、重复执行无效命令、工具报错后不恢复，或者探索太久却迟迟不进入实现。

Harness Proposal：提有边界的改法

拿到结构化失败证据后，同一个模型会切换成proposer，针对已挖出的失败机制提出候选Harness edit。

这些edit只能落在预先声明的可编辑表面上，不能把整个Agent控制架构推倒重来。

每个提案都要说明想改变哪种行为，可能带来什么回归风险，以及为什么可能修好当前失败模式。

Proposal Validation：用回归测试拍板

候选Harness会在同一评测协议下重跑，并和当前Harness对比。

接受规则很保守。held-in或held-out至少一个split要提升，另一个split不能退化，才会进入下一代Harness。

这也是它和普通“自动改prompt”的差别。Self-Harness不让模型凭感觉拍板，而是把每一次改动都放进可记录、可复现、可回退的评测闭环里。

△Self-Harness自改进闭环，包括弱点挖掘、修改提案和回归验证

不换模型，只改外层也能涨

论文在Terminal-Bench-2.0上做了系统评测。

Terminal-Bench-2.0是一个多轮智能体benchmark，任务运行在容器化终端环境中，覆盖文件管理、命令执行、错误恢复、产物验证等真实工具使用能力。

在固定模型、工具集、任务环境和评测配置的前提下，Self-Harness只改Harness。结果三个模型都出现提升。

MiniMax M2.5总提升28%，Qwen3.5-35B-A3B总提升104%，GLM-5总提升24%。

这组结果的重点不是又换了一个更强模型，而是在同一个模型外面，Harness本身也可以被搜索、验证和迭代。

△Terminal-Bench-2.0结果，三个模型后端在Self-Harness后均获得held-out提升

更重要的是，每个候选修改都经过held-in和held-out回归测试。

换句话说，Self-Harness不是堆更长的提示词，而是在一次次验证门控后，只留下真的带来收益、又没有明显回退的Harness edits。

△Qwen3.5 Self-Harness进化路线，通过多轮验证门控保留有效edits

不同模型暴露出不同弱点

Self-Harness的另一个观察更像工程现场。不同模型不是同一种失败。

MiniMax M2.5：找到线索后迟迟不交付

在初始Harness下，MiniMax M2.5有时会持续探索数据集。即使已经找到关键元信息，也迟迟不创建评测所需的答案文件，最后因为缺少产物或超时失败。

Self-Harness保留的修改会鼓励Agent更早识别必需输出，先创建初始产物，并在工具调用过长时转向具体实现和验证。

Qwen3.5-35B-A3B：工具失败后容易陷入循环

Qwen3.5-35B-A3B的常见问题，是工具失败后进入重复编辑、重复覆盖或重复命令循环，甚至在停止前删除评测必需文件。

Self-Harness为它引入依赖预检查、失败后产物恢复、避免完全相同命令重试，以及由工具错误触发的artifact-focused提醒。

△Qwen3.5保留下来的code-level Harness edits，集中在依赖预检查、产物恢复和重试约束。

GLM-5：更需要管住shell状态和节奏

GLM-5暴露出的弱点更集中在shell会话状态，以及从探索切到实现的时机。

改进后的Harness会提醒Agent在修改环境变量、安装工具或调整路径后，确认这些变化能跨命令持续可用。当长时间探索还没有形成产物时，系统也会推动它转向实现与测试。

这说明Self-Harness不只是给所有模型加一段通用提示。它会根据每个模型在真实轨迹中暴露出的弱点，生成并筛选适合它的Harness改动。

为什么会引起关注

Agent越来越像跑在工具环境里的系统，而不是只回答单轮问题的模型。

在这种设定里，模型能力只是一部分。外层Harness决定它是否知道何时调用工具，如何从错误中恢复，是否保留正确产物，退出前有没有做验证。

过去，Harness工程更像经验活。Self-Harness给出的方向是，让模型自己参与这套经验的挖掘和改写，但最终仍由评测而不是自评来拍板。

它没有证明“Agent可以完全自己进化”，也没有绕过benchmark范围。论文里的结果主要来自Terminal-Bench-2.0和固定模型后端。

但作为一个自进化Agent的组件，它给出了比较清楚的边界：改什么，怎么改，怎么验，什么时候拒绝。

研究团队

该工作来自上海人工智能实验室团队，论文题为Self-Harness: Harnesses That Improve Themselves。

从现有文档看，团队公开了论文和项目地址，读者可以查看具体实验设置、Harness edits和代码。

论文：https://arxiv.org/abs/2606.09498
项目地址：https://github.com/qzzqzzb/Self-Harness