Self-Harness 技术辨析：让 Agent 外层“自进化”，不换模型也能涨 104%
核心事件
上海人工智能实验室团队提出 Self-Harness——一种让 Agent 外层 Harness（运行装置）具备自我改进能力的技术方案。近期，该工作被 LangChain CEO、联合创始人 Harrison Chase 转发，并被 前 OpenAI 副总裁 Lilian Weng 收录进其关于自进化 Agent 的博客文章。
论文题为 Self-Harness: Harnesses That Improve Themselves，论文和项目地址均已公开：
- 论文：https://arxiv.org/abs/2606.09498
- 项目地址：https://github.com/qzzqzzb/Self-Harness
什么是 Agent Harness？
Agent Harness 是包在模型外层的一套运行装置，涵盖系统提示词、工具使用规则、验证器、运行时控制策略和轻量 middleware。在多轮工具任务中，它决定 Agent 如何调用工具、何时停止、失败后如何恢复，以及产物如何验证。
过去，Harness 主要靠工程师手调——读大量执行轨迹、找失败原因、改提示词或工具规则、再反复跑 benchmark。随着模型增多、任务变杂，"一模型一套人工调参"的方式已难以扩展。
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 不让模型凭感觉拍板，而是把每一次改动都放进可记录、可复现、可回退的评测闭环里。
实验结果：不换模型，只改 Harness
论文在 Terminal-Bench-2.0 上做了系统评测。
Terminal-Bench-2.0 是一个多轮智能体 benchmark，任务运行在容器化终端环境中，覆盖文件管理、命令执行、错误恢复、产物验证等真实工具使用能力。
在固定模型、工具集、任务环境和评测配置的前提下，Self-Harness 只改 Harness，三个模型后端均获得 held-out 提升：
| 模型 | 总提升 |
|---|---|
| Qwen3.5-35B-A3B | 104% |
| MiniMax M2.5 | 28% |
| GLM-5 | 24% |
这组结果的核心意义不在于又换了一个更强模型，而在于同一个模型外面，Harness 本身也可以被搜索、验证和迭代。
更重要的是，每个候选修改都经过 held-in 和 held-out 回归测试。Self-Harness 不是堆更长的提示词，而是在一次次验证门控后，只留下真的带来收益、又没有明显回退的 Harness edits。
不同模型暴露出不同弱点
Self-Harness 的另一个重要发现是：不同模型的失败模式并不相同，Harness 需要针对具体模型定制改进。
MiniMax M2.5：找到线索后迟迟不交付
在初始 Harness 下，MiniMax M2.5 有时会持续探索数据集。即使已经找到关键元信息，也迟迟不创建评测所需的答案文件，最后因缺少产物或超时失败。
Self-Harness 保留的修改会鼓励 Agent 更早识别必需输出，先创建初始产物，并在工具调用过长时转向具体实现和验证。
Qwen3.5-35B-A3B：工具失败后容易陷入循环
Qwen3.5-35B-A3B 的常见问题是工具失败后进入重复编辑、重复覆盖或重复命令循环，甚至在停止前删除评测必需文件。
Self-Harness 为它引入依赖预检查、失败后产物恢复、避免完全相同命令重试，以及由工具错误触发的 artifact-focused 提醒。保留下来的 code-level Harness edits 集中在依赖预检查、产物恢复和重试约束。
GLM-5：更需要管住 shell 状态和节奏
GLM-5 暴露出的弱点更集中在 shell 会话状态，以及从探索切到实现的时机。
改进后的 Harness 会提醒 Agent 在修改环境变量、安装工具或调整路径后，确认这些变化能跨命令持续可用。当长时间探索还没有形成产物时，系统也会推动它转向实现与测试。
这说明 Self-Harness 不只是给所有模型加一段通用提示，而是根据每个模型在真实轨迹中暴露出的弱点，生成并筛选适合它的 Harness 改动。
技术辨析：边界在哪里？
价值所在
-
Agent 工程化的新方向：Agent 越来越像跑在工具环境里的系统，而不是只回答单轮问题的模型。模型能力只是一部分，外层 Harness 决定它是否知道何时调用工具、如何从错误中恢复、是否保留正确产物、退出前有没有做验证。
-
从经验活到系统化方法：过去 Harness 工程更像经验活。Self-Harness 给出的方向是让模型自己参与这套经验的挖掘和改写，但最终仍由评测而非自评来拍板。
-
清晰的边界定义：Self-Harness 没有证明"Agent 可以完全自己进化"，也没有绕过 benchmark 范围。论文里的结果主要来自 Terminal-Bench-2.0 和固定模型后端。但它给出了比较清楚的边界——改什么、怎么改、怎么验、什么时候拒绝。
需要注意的局限
- 结果基于 Terminal-Bench-2.0 和固定模型后端，尚未经过更广泛场景验证。
- Self-Harness 本身也需要计算资源来运行弱点挖掘、提案和回归测试。
- 该方法适用于有明确评测协议的场景，对于缺乏标准化评估的环境，落地难度会更高。
对从业者的启示
| 角色 | 关注点 |
|---|---|
| AI 研究者 | Self-Harness 为自进化 Agent 提供了一个结构化的组件范式，值得在更多 benchmark 和模型上验证 |
| 开发者 | 如果你的 Agent 系统频繁遇到同类失败模式，Self-Harness 的思路——聚类失败、提出有边界的 edit、用回归测试验证——可以直接借鉴 |
| 创业者 | Harness 自动化改进可能成为 Agent 平台的基础设施层，值得关注相关赛道 |
参考链接
- 论文：https://arxiv.org/abs/2606.09498
- 项目地址：https://github.com/qzzqzzb/Self-Harness
- 原始报道：量子位公众号（QbitAI）