导读
模型解决“能不能做”，Harness（工程外壳）解决“敢不敢用”，而 Self-Harness 解决的是“谁来持续维护这个 Harness"——答案是 Agent 自己。上海 AI 实验室最新提出的 Self-Harness 框架，通过让 Agent 分析自身执行轨迹、自动提出修改方案并进行回归测试，实现了零人工干预的 Harness 持续迭代。实验显示，该机制在 Terminal-Bench-2.0 上将多个模型的通过率最高提升 21.4 个百分点，相对提升高达 138%。
Harness 为何难以依靠人工调优
Harness 是包裹在模型之外的工程层，涵盖系统提示词、工具定义、执行规则及失败恢复策略等。同一模型在不同 Harness 下性能差异巨大，核心痛点在于不同模型的失败模式截然不同：
针对 MiniMax 的优化规则对 Qwen 往往无效，因为故障根源不同。通用 Harness 是个伪命题，每个模型都需要专属配置，且随着模型按月迭代，人工调优已无法跟上节奏。
通用 Harness 是个伪命题。每个模型需要专属的 Harness，而模型还在以月为单位迭代。
现有改进范式分为三类：人工调优（不可扩展）、Meta-Harness（依赖更强外部模型，不适用于前沿模型）以及 Self-Harness（模型自我迭代，无外部依赖）。
Self-Harness 三阶段核心机制
Self-Harness 构建了一个全自动的迭代循环，包含故障挖掘、提案生成与回归验证三个关键阶段。
阶段一：Weakness Mining（故障挖掘）
系统收集所有失败案例的执行轨迹，关键在于对失败进行结构化归因。论文采用三元组标签法：(c, q, m)，分别代表验证器拒绝原因、Agent 行为与失败的因果关系、可复用的行为机制。只有三元组完全一致的失败才会被归为一类，从而将表面症状与可修复的深层机制区分开，避免混淆处理。
阶段二：Harness Proposal（并行提案）
模型基于故障证据，并行生成多个候选修改方案。每个方案必须明确针对的故障模式、修改面、预期行为改变及潜在回归风险。核心约束是最小化修改：仅调整解决当前故障所必需的部分，严禁大规模重构，以降低回归风险并确保验证通过率。
阶段三：Proposal Validation（双集回归验证）
这是框架最严格的设计。每个候选 Harness 需同时在 held-in（提案证据来源）和 held-out（未暴露数据）两个集合上运行。接受标准极为严苛：
# Self-Harness 接受规则（简化版）
def should_accept(delta_in, delta_ho):
# 两个集合性能均不能退化
if delta_in < 0 or delta_ho < 0:
return False
# 至少一个集合要有实质提升
return max(delta_in, delta_ho) > 0若任一集合性能下降，提案直接拒绝，Harness 保持原样。全程无人工豁免，确保每次合并都是净增益。
极简初始 Harness 与显著效果
实验基于 DeepAgent SDK，初始 Harness 极度简化：仅包含基础系统提示词、引导指令、验证指令及失败恢复指令，关闭了所有 Skills、Subagents 及运行时管控。Self-Harness 仅通过修改这几个函数的返回值，便实现了性能的显著提升，证明多数 Agent 的初始执行规则存在巨大优化空间。
# 初始 Harness 示例（简化）
def build_system_prompt() -> str:
return "You are running inside a Terminal Bench 2 Harbor task environment..."
def build_runtime_control_policy() -> dict:
return {"enabled": False, "max_total_tool_messages": None} # 全部关闭数据验证：泛化能力与模型特异性
在 Terminal-Bench-2.0 的 64 个容器化终端任务中，三个模型均表现出显著提升。其中 Qwen3.5 在 held-in 集上的通过率从 15.1% 跃升至 36.0%，相对提升 138%。更重要的是，held-out 集的性能同步提升，证明模型习得的是可泛化的执行机制，而非对特定任务的过拟合。
最具工程价值的发现是：不同模型进化出了完全不同的 Harness 策略。
- MiniMax M2.5：学会“尽早创建输出文件”并开启消息上限，解决了无限探索导致的超时问题。
- Qwen3.5：引入工具错误触发的提示重定向及重试纪律，避免了因反复重试而误删文件。
- GLM-5：增加分阶段操作约束及环境状态持久化检查，解决了资源耗尽及状态丢失问题。
同一套 Self-Harness 流程，针对不同模型的缺陷“对症下药”，证明了 Harness 最优解的模型特异性，不存在银弹。
对 Agent 工程的三大实操启发
- 建立证据链：Harness 改进不能凭感觉。每次修改应遵循“故障模式→修改面→预期效果→验证结果”的闭环，确保过程可追溯、可量化。
- 坚守回归测试底线：任何改动合并前，必须通过 held-out 集验证，防止修复旧 Bug 时引入新退化。
- 坚持最小化修改：小步快跑优于推倒重来。改动越小，回归风险越可控，越容易通过严格的双集验证。
局限性与展望
该方法论在拥有明确验证器的任务（如代码生成、终端操作、结构化输出）中价值最大。而在开放式业务场景（如客服对话、内容创作）中，由于验证器设计本身具有挑战性，Self-Harness 的应用尚需进一步探索。
结语
Self-Harness 将 Harness 改进定义为一次经验性的状态转移：每次修改必须清晰阐述改动了什么行为、依据何种证据、验证结果如何。这一理念不仅适用于自动化框架，对所有从事 Agent 工程的团队同样具有指导意义。面对多模型适配的挑战，未来的方向或许不再是投入更多人力，而是赋予 Agent 自我进化的能力。
相关论文已开源（arXiv 2606.09498），Terminal-Bench-2.0 亦为公开基准，可供业界复现与研究。