2026 年 8 月初的 arXiv cs.AI 和 cs.CL 新论文里，Harness-R1 是一篇很适合代码 Agent 团队阅读的工作。它的题目指向一个被低估的问题：Agent 失败后，真正缺的往往不是下一段代码，而是一个能把失败转化为学习信号的 runtime harness。
过去一年，代码 Agent 的评测叙事集中在 SWE-Bench、Terminal-Bench、真实仓库修复率和多步工具调用。大家关心模型能不能读 issue、定位文件、写补丁、跑测试。但在实际工程里，失败经常发生在更外层：测试跑不起来，依赖版本错了，服务 mock 不完整，数据库 fixture 缺字段，日志没有保留，断言太宽或太窄。模型在这种环境里反复尝试，得到的反馈只有“失败”，很难知道该修业务逻辑还是先修验证环境。
Harness-R1 的价值就在这里：它把 agent failure trajectories，也就是 Agent 执行过程中的失败轨迹，转成学习如何编辑可执行 harness 的数据。换句话说，它让模型学习“不只是写答案，还要修好出题器”。
什么是 runtime harness
在代码任务中，runtime harness 是围绕任务的一整套可执行外壳。它可能包括：
| 组成 | 例子 | 作用 |
|---|---|---|
| setup | 安装依赖、启动数据库、准备 fixture | 让任务可运行 |
| entrypoint | 测试命令、CLI 参数、服务启动脚本 | 定义执行入口 |
| mocks | 第三方 API、本地文件、时间函数 | 隔离外部不确定性 |
| assertions | 单测断言、快照、属性测试 | 判断行为是否正确 |
| logs | stdout、trace、覆盖率、错误栈 | 帮助定位失败 |
很多人把 harness 简化成“测试文件”，但它更像一个小型运行系统。一个优秀的 harness 能给 Agent 明确反馈：哪里失败、输入是什么、期望是什么、环境是否可信。一个糟糕的 harness 会把所有问题压缩成一行红色日志，导致模型只能猜。
论文的关键思路
Harness-R1 可以概括为三步：
- 收集代码 Agent 在真实或近真实任务中的失败轨迹。
- 从轨迹里识别 harness 层面的缺口，例如测试缺失、环境错误、mock 不足或断言不稳定。
- 训练模型生成 harness 编辑，使后续 Agent 能获得更高质量的执行反馈。
这里有一个重要转向：传统自动修复把“代码补丁”当作主要输出，Harness-R1 把“验证补丁”也纳入能力空间。这个转向很实际。因为代码 Agent 想进入生产，不可能只靠静态答案；它必须依赖可重复运行的检查，而检查本身也需要维护。
举一个简化例子。某个 Agent 修复日期解析 bug 时失败，日志是：
Error: expected 2026-08-05T00:00:00Z but got 2026-08-04T16:00:00Z如果 harness 没写清楚时区，模型可能反复修改业务代码。真正的修复也许是测试 fixture 应该固定 timezone，或者断言应该比较本地日期而不是 UTC 时间戳。Harness-R1 关注的正是这类“失败不是业务代码本身造成的”场景。
为什么失败轨迹有价值
失败轨迹比最终补丁更丰富。它包含模型看过哪些文件、运行过哪些命令、遇到哪些错误、做过哪些错误假设。把这些轨迹结构化以后，可以挖出 harness 的常见缺口：
- 依赖未安装或版本漂移。
- 测试入口没有覆盖真实 bug。
- mock 服务返回结构和生产不一致。
- 断言只检查状态码，不检查业务字段。
- fixture 太少，无法暴露边界条件。
- 日志没有保留关键输入。
这些问题在人类开发中也常见，只是被 CI 和 review 稀释了。代码 Agent 因为行动速度快，会把 harness 的缺陷放大：它可以在十分钟内跑几十次错误尝试，如果反馈质量差，就会高频产生无效补丁。
与代码 Agent 评测的关系
今天的主流代码 Agent benchmark 大多默认任务环境已经准备好。模型的目标是提交一个补丁，通过隐藏测试或公开测试。但真实仓库经常没有这么理想。一个遗留系统的测试可能多年没人维护，一个微服务的本地环境可能依赖内部镜像，一个数据任务可能需要复杂 fixture。
Harness-R1 暗示下一代评测会从“能不能修 bug”扩展到“能不能让 bug 可验证”。这对生产系统更重要。因为团队不是每天都遇到标准化 benchmark，而是每天都要处理不完整需求、不完整测试和不完整环境。
可以把能力分成三层：
| 能力层 | 典型任务 | 价值 |
|---|---|---|
| patch generation | 修改业务代码 | 解决已知问题 |
| test generation | 增加测试用例 | 防止回归 |
| harness editing | 修复运行与验证环境 | 让反馈可信 |
只有第三层做好，前两层才有稳定收益。
工程启示一：先诊断反馈质量
生产代码 Agent 流程里，可以加一个“反馈诊断”阶段。每次任务失败后，不要立刻让模型重写补丁，而是先问：
请分析这次失败属于哪一类：
1. 业务逻辑错误
2. 测试断言错误或不完整
3. 环境依赖错误
4. mock 或 fixture 不可信
5. 信息不足，需要人工补充
请给出证据，不要修改文件。这一步能减少盲目重试。尤其是当 Agent 连续两次修改业务代码但错误栈没有变化时，系统应该怀疑 harness，而不是继续让模型扩大补丁。
工程启示二：harness 补丁必须单独审查
Harness 编辑有双刃剑属性。它能让任务更可测，也能让模型作弊。最危险的情况是 Agent 为了让 CI 变绿，删除断言、跳过失败用例、降低覆盖范围，或者把 mock 改得过于理想。
因此，harness patch 应该和业务 patch 分开：
change set A: tests, fixtures, mocks, scripts
change set B: production code
review rule: A must fail on old code and pass on fixed code这条规则非常关键。一个新的测试如果在旧代码上也能通过，它就没有证明 bug 被捕获。一个修改后的 mock 如果让所有路径都成功，它可能掩盖了真实错误。
工程启示三：保留原始轨迹
不要只保存最终回答。原始失败轨迹是之后训练、调试和审计的基础。建议至少记录：
- 任务描述和初始上下文。
- Agent 读过的文件列表。
- 每次命令、退出码和关键日志。
- 每次补丁 diff。
- 模型对失败原因的归因。
- 人工最终判定。
有了这些数据，团队才能知道 Agent 是因为模型能力不足失败，还是因为 harness 不可信失败。前者需要换模型或改提示，后者需要改工程环境。
一个最小落地流程
把 Harness-R1 的思想落到现有代码仓库，可以从这个流程开始：
1. Agent 生成初始补丁
2. 运行测试
3. 如果失败，进入 feedback diagnosis
4. 若诊断为 harness 问题，生成单独 harness patch
5. 验证 harness patch 在旧代码上能暴露问题
6. 再生成业务补丁
7. 全量 CI 和人工审查这看起来比“让 Agent 多试几次”麻烦，但它解决的是根因。Agent 重试次数越多，反馈质量越重要。没有可靠 harness，多轮推理只是更昂贵的猜测。
论文局限
这类方法也有明显挑战。第一，失败轨迹数据质量很难保证。轨迹里既有有用信号，也有模型自己的错误归因。第二，harness 是否正确需要外部标准，不能只看通过率。第三，不同语言和框架的 harness 形态差异很大，迁移并不容易。
但方向是对的。代码 Agent 真正进入企业工作流后，竞争点不会停留在“谁更会写补丁”。更重要的是谁能构造可靠反馈，谁能把失败变成可学习、可审查、可复现的信号。Harness-R1 把这个问题明确摆上了桌面。
参考来源：arXiv 论文 Harness-R1: Learning to Edit Executable Runtime Harnesses from Agent Failure Trajectories，以及今日 Hugging Face Daily Papers 与 arXiv cs.AI/cs.CL 新论文检索结果。