Harness-of-Harness：让 coding agent 在多日循环中不退化

单轮评测已经够难，但真正的问题不是”Agent 今天能不能解决这个问题”，而是”Agent 能不能在连续 70 轮迭代里持续交付可用的软件”。

Haoyang Yan 等人在 arXiv:2609.01481 提出了 Harness-of-Harness（HoH）：在现有 coding-agent harness 之上再套一层元 harness，把”规划-编码-测试”组织成多轮迭代环，在多日尺度上观察自主开发能力的演化。

核心设计：四层约束

HoH 的思路不是在单轮 harness 里塞更多功能，而是明确区分两类约束：

约束可验证产出，而不是规定工作流：给 Agent 一个可量化验证的目标（”这个函数返回正确结果”、”这个 UI 可以交互”），而不是规定它必须按什么顺序、用什么工具完成。

分离实现期测试与独立评测：实现期的测试是用来让 Agent 自我修正的，评测期的测试是用来独立验证的。两套测试不混用，防止 Agent 过拟合评测集。

小可验证增量：每个循环周期只推进一个有限范围的功能，而不是一次性实现全部需求。论文发现，当增量足够小时，repair（修复错误）和 capability growth（能力增长）可以同时进行而不互相挤压。

渐进暴露工具和技能：不是第一天就给 Agent 全部工具权限，而是根据任务复杂度逐步开放。这防止了 Agent 在复杂工具面前迷失，也防止了它在简单任务上过度设计。

三套 harness×模型组合（Codex+GPT-5.5、OpenCode+DeepSeek-V4-Pro、Pi+MiniMax-M3），在 GameCraft-Bench、FrontierSWE、ProgramBench 上，平均相对提升 52.25%，最大单次提升 82.86%。

最极端的案例：超过 70 轮迭代，自主开发了一个完整可玩的第一人称射击游戏，包括连贯剧情、完整核心机制、可玩体验、视觉特效和集成音频。没有人工介入，没有中期指令注入。

HoH 有一个关键发现：Agent 在长程任务里最大的敌人不是能力不足，而是”遗忘”——忘记自己之前为什么做了某个决定，然后在某轮迭代里把它改坏了。

论文的解决方案是维护版本化项目历史，让 Agent 在每次规划前先回顾历史决策。跳过这一步的实验组，在 15 轮之后错误率显著上升——不是新错误，而是之前已经解决过的问题重新出现。

Prime Agent 回答的是”Agent 怎么改进自己”，HoH 回答的是”平台怎么让 Agent 在多轮里不退化”。一个是自我改进，一个是平台稳定性。两者都需要——但顺序是先稳定、再改进。

参考

Harness-of-Harness：arXiv:2609.01481，GitHub: github.com/Flesymeb/HarnessOfHarness