Doc2Harness：首次直接评估大模型的长程 Harness 工程能力

导语

评估编码智能体时，人们通常关注模型能否在既定工具链中修复 Bug、修改文件或完成项目任务。但在真实部署中，决定智能体表现的并不只有模型本身，还包括负责组织提示、调用工具、管理工作区和处理执行结果的 Harness。Doc2Harness 关注的正是此前较少被单独测量的一层：模型能否从接口契约和开发文档出发，构建出一个可长期运行的编码代理 Harness。

核心要点

• 两阶段设计。 第一阶段让待测模型在固定的构建环境中，根据只有接口信息的契约骨架，以及汇总了 12 个前沿 Harness 行为的开发文档，完成候选 Harness 的实现。构建过程在隔离容器内进行。
• 冻结后独立运行。 第二阶段不再使用构建环境，而是把候选 Harness 放入与其分离的容器中，每个测试用例单独运行，并由脚本化的模拟模型端到端驱动。这种设计减少了构建过程对结果的干扰。
• 观察可验证结果。 评测同时检查 Harness 发给模型的请求、磁盘上的文件状态、进程退出码和命令输出。正向控制还用于排除“没有真正完成任务却意外通过”的空泛实现。
• 整体表现仍不理想。 19 个前沿模型各进行 3 次独立构建，在 328 个测试用例上，GPT-6 Astra 取得 53.05% 的最高通过率，最低模型为 27.44%，差距约 26 个百分点。

这说明了什么

结果的关键不只是模型之间存在差异，而是即使最佳模型也未能通过近一半测试。换言之，生成一个看似合理的代理程序，与构建一个能在长流程中稳定工作的 Harness，是两种不同难度的能力。模型可能能够实现局部工具调用，却难以保持状态、协调多个组件，并让不同功能在整个执行链中一致工作。

论文指出，失败尤其集中在跨切面功能如何拆分到不同模块这一问题上。这一发现具有实际意义：随着编码智能体从一次性问答转向持续修改真实工作区，工程组织、状态管理和模块边界会逐渐成为瓶颈，而不只是提示词质量或单次代码生成能力。

Doc2Harness 的价值还在于提供了一个确定性的测量框架。它把“模型能否设计并实现自己的运行环境”从模糊的工程印象，转化为可重复、可比较的测试结果。对模型开发者而言，基准可以帮助定位长程执行中的结构性缺陷；对 Harness 设计者而言，结果则提示系统需要更清晰的模块契约和更严格的端到端验证。未来，编码智能体的竞争可能不仅是模型参数或基准刷分，也将取决于模型能否把复杂行为组织成可靠的软件系统。

来源：Hugging Face Daily Papers