你让 AI 改一个文件，它可能做得不错。可如果任务变成：先读需求，再改十几个文件，运行测试，记住前面的决定，遇错后继续修——真正决定成败的，往往不只是哪一个模型，还包括外面那套“带它做事”的系统。
这套系统叫 Agent Harness（智能体脚手架）：它负责组织提示、提供工具、保存历史、执行命令、管理权限，并在出错后恢复。好比同一个人去修房子，梯子、工具箱和施工流程不同，最后的表现也会不同。
Doc2Harness 换了一个少见的考法。它不把脚手架固定下来，再看模型完成多少编码任务；它直接让模型从文档出发，把脚手架本身造出来，然后逐项检查成品是否合格。论文报告称，这项工作热度一日增长 760%。不过，以下方法和结果均来自论文作者的单一材料，尚无独立复现或第三方评测交叉印证。
不考“会不会用”，改考“能不能造”
Doc2Harness 是一个 Benchmark（评测基准）——也就是一套统一考题和评分办法。它把测试分成两个阶段。
第一阶段是施工。待评模型会拿到两样东西：一份开发文档，以及一个只有接口、没有内部实现的 contract skeleton（契约骨架）。接口契约规定组件可以接收什么、必须返回什么，却不规定内部怎样写，很像插座标准只规定形状和电气要求，不替你设计整台电器。
开发文档汇总并消解了 12 套前沿脚手架的功能差异，涵盖工具、命令、权限、会话状态、持久记忆、退出码等内容。骨架则只有约 70 行 Python 代码，保留命令行、无界面入口和自动评测 API 三类接口。一个典型成品约有 30 个 Python 文件、1.6 万行代码，其中约 99.6% 由模型补写。
模型在无外部网络的隔离容器里工作，最多进行 24 轮、提交 3 次，最长两小时。每次提交先接受契约检查：能否编译安装、必要命令是否存在、占位代码是否清除、三类接口是否齐全。通过后，成品立即冻结，不能再针对测试修改。
第二阶段才是验收。每个测试用例都在独立于施工环境的新容器里运行，并由 scripted mock model（按预设脚本回答的模拟模型）驱动完整会话。这样做是为了固定“使用者”，减少真实语言模型随机波动带来的干扰。换句话说，这里测的是脚手架在规定交互下是否守约，不是真实模型与脚手架组合后的整体办事成功率。
四扇窗口，看见系统真正做了什么
普通编码评测常看最终答案是否正确。脚手架却可能表面答对，过程已经越权。Doc2Harness 因此从四个可观察通道判分：发送给模型的请求、磁盘上的文件、进程退出码，以及命令输出。
其中最巧的一步是 positive control（阳性对照）。例如，测试要求脚手架阻止读取工作区外的文件。结果中没有出现文件内容，看起来像是成功拦截；但也可能是读取工具彻底坏了，什么文件都读不了。这种“什么也没发生，所以碰巧过关”被论文称为 vacuous pass（空通过）。
阳性对照会补问：普通文件能否正常读取？同一个链接通过不受该规则约束的路径能否访问？指向工作区内部的链接是否会被允许？只有这些观察前提成立，原测试的“没读到”才算真正拦住了。328 个测试用例中，有 130 个至少受一个阳性对照约束。
最强模型也只过了一半
作者测试了来自 11 家厂商的 19 个模型，每个模型独立构建 3 次，共得到 57 套候选脚手架。结果中，GPT-6 Astra 的总体通过率最高，为 53.05%；最低的 Hy3 为 27.44%，两者相差约 26 个百分点。最高分仍有接近一半的测试没有通过。
但总分不是全部。Opus 5 在普通场景中以 80.68% 领先 GPT-6 Astra 的 72.46%；到了边界场景，GPT-6 Astra 达到 48.97%，Opus 5 降至 37.02%。差距主要出现在那些不顺手、容易遗漏的边界条件上。
不同能力类别也会改写排名。在六个至少包含 20 道题的主要类别中，同一模型的名次最多可波动 16 位。权限类最能拉开差距：61 个用例里有 51 个能够区分模型，最强与最弱相差 50.8 个百分点。相较之下，交互式终端类平均通过率已达 79.9%，区分度正在下降。
还有 56 道题被所有候选脚手架共同做错。它们集中在直接驱动、会话状态、权限和无界面运行等类别。这说明评测没有被当前模型“刷满”，也提醒我们：能写出大量代码，不等于能把长程运行系统的细节接稳。
问题常出在“拆得太散”
作者进一步分析了 57 套候选脚手架的源码。不同模型写出的规模差异很大：各模型平均代码量从 1,271 行到 16,681 行不等；全部单次构建则介于 1,062 行和 19,208 行之间。代码量与通过率存在一定正相关，但更多代码并不自动等于更可靠。
论文观察到，在控制代码行数后，模块越多，得分反而越低。作者据此认为，失败往往与 cross-cutting functionality（横跨多个功能区的能力）如何拆分有关。权限、会话状态或错误处理通常不会只待在一个角落；如果模型把它们切散到太多模块，连接处就更容易漏掉。不过，论文给出的材料未完整展示相关统计值，因此这更适合作为作者提出的结构性线索，而不是已经坐实的因果结论。
为什么值得关注
过去谈编码智能体，人们很容易把能力归到模型名下。Doc2Harness 提醒我们，模型只是系统的一部分。脚手架决定它能看见什么、记住什么、可以做什么，以及失败后怎样继续。长程任务尤其放大这些差异：早期一个小错误，会在后续许多步骤里累积。
更重要的是，这套评测把“外围工程”变成了可单独检查的对象。它不靠最终任务成败倒推脚手架好坏，而是逐条验证脚手架自身是否符合规范。作者称，这是首个衡量长程 harness engineering（脚手架工程）的确定性基准；这个“首个”带有“To our knowledge”的限定，仍需更多资料核验。
局限与未知
- Stage 2 使用脚本化模拟模型，测到的是预设交互下的脚手架行为，不能把 53.05% 直接理解成真实编码智能体的整体成功率。
- 所有核心结果目前来自作者论文，尚缺独立复现；“模块拆分导致失败”等分析也不能据此确立因果关系。
- 评测文档融合了 12 套脚手架的功能，并人为消解冲突。它提供了统一考场，但未必代表现实中每一种脚手架设计的最佳取舍。