论文解读 · 2026年10月16日
Doc2Harness：衡量编程智能体长期 Harness 工程能力的 LLM 基准
Doc2Harness: Benchmarking LLMs on Long-Horizon Harness Engineering of Coding Agents
让 LLM 依据开发文档和仅含接口的骨架直接构建智能体 Harness，并用 Mock 模型进行确定性评分，以衡量 Harness 工程能力。
问题
编程智能体的性能不仅取决于模型，也同样取决于管理工具执行、上下文、权限和会话状态的 Harness。然而现有基准在固定 Harness 的前提下只衡量最终任务是否成功，并不衡量 LLM 构建 Harness 本身的能力。此外，同一功能的实现方式多种多样，而 Harness 需要模型才能运行，因此很难用一般的单元测试来评估。
方法
在第 1 阶段，被评估的模型在固定的构建器 Harness（OpenCode）中工作。模型会收到整合、整理了 12 个最新 Harness 用户文档的开发文档，以及仅含接口的契约骨架（基于 mini-swe-agent），并在隔离的容器中完成 Harness。在第 2 阶段，将完成的 Harness 按每个测试用例放入单独的容器，用按脚本应答的 Mock 模型运行到底。评分通过四个通道进行：发送给模型的请求、磁盘文件、退出码和命令输出。功能实际上并未运行却通过测试的情况，通过阳性对照（positive control）过滤掉。测试用例通过分析 2 万余条公开 issue、与现有 Harness 比较，以及每次只改变一个变量的扩展来构建。
结果
- 对 19 个最新模型进行了评估，每个模型独立构建 3 次，共 328 个测试用例。GPT-6 Astra 的通过率最高，为 53.05%；最低的模型为 27.44%（相差约 26 个百分点）。
- 即使是最强的模型，也有近一半的测试用例失败。作者报告称，失败集中在跨多个模块的功能的划分方式上。
- 得分越高的 Harness，越倾向于把跨多个模块的功能集中到更少的模块中。
- 按六个主要类别来看，同一模型的排名最多相差 16 位。
局限
构建器 Harness 只固定为 OpenCode 一种，在其他构建器环境下结果可能不同。Mock 模型按既定脚本应答，因此并不直接衡量与真实 LLM 交互时的质量。契约骨架来自基于 Python 的 mini-swe-agent，测试用例由作者设计。由于提供的正文被截断，详细分析只确认了一部分。
意义
首次以确定性方式衡量“构建 Harness 的能力”，这在智能体不断改进自身基础设施的自我改进场景中将是核心能力。对于自行构建或选择编程智能体的团队，可作为模型选择的参考。
关键术语
- Harness
- 包裹 LLM、管理交互循环、工具执行、上下文、权限、会话状态和错误恢复的智能体运行框架。Claude Code、Codex CLI 等就是例子。
- Mock 模型
- 代替真实 LLM、按预先设定的脚本返回响应的模拟模型。它使评估具有确定性和可复现性。
- Vacuous Pass（空洞通过）
- 要检查的功能实际上并未运行，但断言恰好为真而通过测试的情况。
- 阳性对照（Positive Control）
- 通过确认在同一场景中必然应发生的结果，来验证观察前提是否成立的辅助测试。如果失败，原测试也按 FAIL 处理。
原文
作者: Yuyao Ge, Shenghua Liu, Peizhong Gao, Chendi Ge, Chenxu Liu, Yiwei Wang, Lingrui Mei, Baolong Bi, 等 · 发布 2026-10-14 · 许可 CC BY 4.0 · 基于全文分析
本解读是 AI 阅读论文后撰写的摘要，请以论文原文为准。