上海
Self-Harness团队 投稿
量子位 | 公众号 QbitAI
让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
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
