让 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%。
论文和项目已经公开，文末附链接。
Agent Harness 可以理解为包在模型外层的一套运行装置，覆盖系统提示词、工具使用规则、验证器、运行时控制策略和轻量 middleware。
在多轮工具任务里，它决定 Agent 怎么调用工具，什么时候停，失败后怎么恢复，产物又该如何验证。
过去，这套东西主要靠工程师手调。要读大量执行轨迹，找失败原因，改提示词或工具规则，再反复跑 benchmark。
模型越多、任务越杂，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 不让模型凭感觉拍板，而是把每一次改动都放进可记录、可复现、可回退的评测闭环里。
论文在 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 本身也可以被搜索、验证和迭代。
更重要的是，每个候选修改都经过 held-in 和 held-out 回归测试。
换句话说，Self-Harness 不是堆更长的提示词，而是在一次次验证门控后，只留下真的带来收益、又没有明显回退的 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 提醒。
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
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
— 完 —
【学术投稿】请在工作日发送邮件至：ai@qbitai.com，标题注明【投稿】，并告诉我们：你是谁，从哪来，投稿内容附上项目 / 主页链接，以及联系方式。
我们会 ( 尽量 ) 及时回复你 : )
点亮星标
科技前沿进展每日见
