Doc2Harness：评测大语言模型在编码智能体长程 Harness 工程上的能力

Doc2Harness：评测大语言模型在编码智能体长程 Harness 工程上的能力

本篇作者姓名如下，顺序与原文一致，姓名保留原文拼写。Yuyao Ge, Shenghua Liu, Peizhong Gao, Chendi Ge, Chenxu Liu, Yiwei Wang, Lingrui Mei, Baolong Bi, Jiayu Yao, Jiafeng Guo, Xueqi Cheng

摘要

由大语言模型驱动的智能体越来越多地被部署到长程任务上，它们在这些任务里使用工具，并修改真实的工作区。它们表现得好不好，既取决于模型本身，也同样取决于包在模型外面的 harness。现有基准是在一份固定的 harness 之下测量下游任务是否成功，因而把 harness 工程本身留在了未被考察的位置。我们提出 Doc2Harness，这是一个两阶段基准，直接评测长程 harness 工程。在第一阶段，一个构建模型在固定的构建器 harness 里运行，它收到一份只含接口的契约骨架，以及一份把十二个前沿 harness 的行为汇成一体的开发文档，然后在隔离容器里构造出一个完整的候选 harness。在第二阶段，这份被冻结的候选 harness 在与构建环境分开的容器里运行，每个测试用例一个容器，并由一个按脚本行事的模拟模型从头到尾驱动。我们用四条可观察通道为每个测试用例打分，这四条通道分别是发给模型的请求、磁盘上的文件、进程退出码，以及命令输出；阳性对照用来排除空洞通过。在十九个前沿模型上，每个模型用三次独立构建、在 328 个测试用例上接受评测，GPT-6 Astra 取得最高通过率 53.05%，最弱的模型达到 27.44%，差距大约是二十六个百分点。即便最强的模型也有将近一半测试用例没有通过，而失败集中在横切功能如何被拆到各个模块上。据我们所知，Doc2Harness 提供了第一个用于测量长程 harness 工程的确定性基准。

图 1：十九个模型在 Doc2Harness 基准上的通过率，从左到右按最强模型到最弱模型排列。每个模型在三份独立构建的候选 harness 上计分，每根柱给出它们的均值。

译注：图 1 在 arXiv HTML 中只有图注，没有可单独下载的栅格文件，正文不另造这张柱状图。

1 引言

随着由大语言模型（LLM）驱动的编码智能体能力变强，它们被部署到越来越复杂的环境里（Ge et al., 2025）。因此 harness 更加要紧：它管理交互循环、工具执行、上下文、权限、会话状态、失败恢复和结果核验，从而决定模型的能力有多少能够到达环境（Mei et al., 2025）。与此同时，由人来监督智能体的每一步已经变得困难。这推动了递归式自我改进：智能体修改那套支配它自身行为的基础设施。智能体执行一项任务，观察结果，修改自己的 harness，再把修改后的 harness 用到下一项任务上，并随时间改进自己。一个模型把这个过程加以泛化的能力，最终可能决定由此得到的智能体的能力。

构建一个 harness 是一类软件工程（SWE）任务，但它所检验的泛化，并不是普通 SWE 任务所能抓住的那种。在数据来源这一层，SWE 基准所使用的开源仓库大多是成熟项目，可能已经在训练语料里反复出现。Harness 则相反，它们直到过去几年才出现，并且以很高的频率更新，因此这样得到的评测更强调泛化。在评测这一侧，现有的 SWE 基准，例如 SWE-bench Pro（Deng et al., 2026）、NL2Repo-Bench（Ding et al., 2026）和 Commit0（Zhao et al., 2025），用任务所附带的交互式单元测试来判断模型的输出是否可接受。这样的判据不能直接搬到 harness 上，原因有两个。（1）同一个功能在 harness 内部可以用很多方式实现，而普通的单元测试是通过一个固定接口观察行为。（2）Harness 自己并不完成下游任务，所以它是否正确，必须靠用一个模型去驱动它来评估。

因此我们提出 Doc2Harness，一个两阶段基准，用来评测大语言模型把 harness 开发到什么程度。在第一阶段，接受评测的构建模型在一个固定的构建器 harness 里运行；给定一份开发文档和一份只声明接口的契约骨架，它在隔离容器里构造出一个完整的候选 harness。在第二阶段，候选 harness 被移入隔离容器，每个测试用例一个容器，作为黑盒被启动并从头到尾执行；模拟模型按照预设脚本提供响应，每个测试用例让 harness 跑完一次完整会话。我们对每个测试用例观察四条通道，即发给模型的请求、磁盘上的文件、进程退出码和命令输出，并把由此得到的状态汇总成通过率。构建模型开发 harness 的能力，间接反映在这个通过率上。

两份输入都经过设计，以降低对构建模型可能已经拥有的参数化知识的依赖：开发文档是从十二个前沿 harness 的用户文档改写而来，经过合并与消歧；契约骨架则从 mini-swe-agent（Yang et al., 2024）进一步提炼，内部实现全部去掉。针对第二阶段，我们设计了几百个测试用例，覆盖很宽的场景范围。一个测试用例即便被测功能从未运行也可能通过，我们把这种情况称为空洞通过；为了防住它，我们引入阳性对照，用来核验观察前提。如果一个阳性对照失败，观察前提就不成立，该测试用例无论自身状态如何都记为 FAIL。

如图 1 所示，我们在 Doc2Harness 上评测十九个前沿模型，每个模型给三份候选 harness 打分，并按通过率给它们排名。最强的 GPT-6 Astra 达到 53.05% 的通过率，最弱的达到 27.44%；大约二十六分的差距表明，这套测试在这一组模型上既没有饱和，也不是无法把它们区分开。跨类别来看，一个模型的名次最多可以变动十六个位置。

我们的贡献如下。

• 我们提出 Doc2Harness：它让接受评测的构建模型在一个固定的构建器 harness 里运行，给它一份开发文档和一份只声明接口的契约骨架，要求它在隔离容器里构造出一个完整的候选 harness，再用几百个测试用例评测这个结果。
• 我们提供一套把 harness 当作黑盒来行使的测试：候选 harness 由遵循预设脚本的模拟模型驱动，阳性对照帮助排除空洞通过，从而使评测保持准确。
• 我们评测了十九个前沿模型，并解析每一份计分候选 harness 的源码。得分较高的候选 harness 倾向于把横切功能放进更少的模块。一个模型的名次在六个主要类别之间也会最多移动十六个位置。

2 Doc2Harness

2.1 任务描述

Doc2Harness 有两个阶段，如图 2 所示。

图 2：Doc2Harness 总览。上方（第一阶段）：构建器由接受评测的构建模型和一个固定的构建器 harness（OpenCode）组成，它以开发文档和契约骨架为输入，并交出一次提交；契约检查核验的是形式而不是行为，成功时把交付物冻结为候选 harness，失败时把它退回构建器。下方（第二阶段）：被冻结的候选 harness 与一个模拟模型组成被驱动的 harness，它运行每个测试用例的场景；效果从四条通道读取，即发给模型的请求、磁盘上的文件、进程退出码和命令输出，阳性对照在断言判定 PASS 或 FAIL 之前先把状态拦住。

第一阶段，构建。构建器把接受评测的构建模型与一个固定的构建器 harness 组合在一起。它阅读一份开发文档，并从一份契约骨架出发，构造一个候选 harness。开发文档规定候选 harness 应当具备的形式和功能；契约骨架是一个框架，由 mini-swe-agent（Yang et al., 2024）简化并改写而来，只保留接口，不含实现。构建器通过发出一次提交来决定第一阶段何时结束；没有这次提交，这次构建就不算交付。每次提交时，契约检查核验交付物能够编译并安装、所有必需命令都在、没有留下占位桩，并且三个契约接口都已就位，但不运行任何测试用例。如果检查通过，构建结束，交付物被冻结为候选 harness，此后不再修改；如果失败，交付物被退回，构建器可以在配额之内继续修改并再次提交（§3）。每一份计分的候选 harness 代表的是模型作为完成品提交时的状态，而不是只在时间限制耗尽时才到达的状态。

第二阶段，评测。在与构建环境隔离的容器里，每个测试用例一个容器，模拟模型驱动候选 harness，我们逐个确定每个测试用例的状态。有些测试用例另外配有阳性对照，用来检验一次表面上的通过反映的是所要求的行为，而不是观察机制本身的失败（§2.4）。一个测试用例只有在它自身通过、并且每一个把它拦住的阳性对照也都通过时，才记为 PASS。构建模型开发 harness 的能力，通过对测试用例的通过率间接反映出来。因此我们给构建模型排名，而不是给候选 harness 排名。

每个阶段都固定一个部件，以减少混淆。在第一阶段，构建器 harness 一律是开源编码智能体框架 OpenCode（OpenCode Contributors, 2025），而不是 Claude Code（Anthropic, 2025）或 Codex CLI（OpenAI, 2025）这类 harness，因为这类 harness 是模型厂商与它们自己的模型一起开发的，可能给 Claude 和 GPT 模型族带来优势。在第二阶段，模拟模型按照预设脚本提供响应，从而避开真实大语言模型所引入的不稳定性干扰。

2.2 任务输入

#### 2.2.1 开发文档

开发文档分三步写成，即收集一份功能清单，把这份清单变成条款，再做消歧，使条款自洽。条款是文档的基本单位。大多数条款规定一个功能的外部行为，而一致性规则规定跨功能、跨章节的关系。

收集功能清单。第一阶段，我们爬取十二个前沿 harness 的用户文档（Claude Code（Anthropic, 2025）、Kimi Code（Moonshot AI, 2026）、Gemini CLI（Google, 2025）、Qwen Code（Qwen Team, 2025）、OpenCode（OpenCode Contributors, 2025）、OpenClaw（OpenClaw Foundation, 2025）、Codex CLI（OpenAI, 2025）、Aider（Gauthier, 2023）、OpenHands（Wang et al., 2025）、Cline（Cline Bot Inc., 2024）、Crush（Charm, 2025）和 Cursor（Anysphere, 2023）），并从中抽取候选功能。第二阶段更细地考察第一阶段的每个候选功能，补上调用形式、参数语义和边界行为。两个阶段的输出被合并、去重并修剪，成为一份前沿 harness 能力清单。

把清单变成条款。如表 1 所示，开发文档覆盖交付物与运行时接口、内置工具、顶层命令与子命令、权限与角色模式、全局标志、会话内命令与快捷方式、持久记忆、约定文件、一致性规则、退出码，以及用于驱动自动评测的 API。每个条款给出一种语法、一种含义和一种期望行为。把每个条款这样圈定，服务于两个目的：（1）可以从外部行为加以核验；（2）与实现方式无关。为了使第一个目的可以操作，我们要求每个功能的效果都能通过四条通道之一被观察到，即发给模型的请求、磁盘上的文件、进程退出码和命令输出。为了服务于第二个目的，除了契约骨架的三份契约之外，我们不约束实现方式。

表 1：开发文档的章节结构。

为功能消歧。上一步得到的条款来自十二个来源，为避免语义冲突，我们使用下面两条消歧规则。（1）我们合并语义重叠的命令。例如，Claude Code 把上下文压缩命名为 /compact，而 Cursor 把它命名为 /summarize，开发文档采用 /compact。（2）我们拆开占据同一个名字的不同概念。以 plan 这个词为例：在 Claude Code 里，它是六种权限模式之一，意思是只读；而在 Aider 里，提出改动和执行编辑由两个模型角色处理，即 architect 与 editor，Aider 的文档改为规定分配给每个角色的职责。开发文档因此把只读约束划给权限，把提出改动和应用改动的职责划给角色，使权限和角色各自形成自己的条款。

#### 2.2.2 契约骨架

契约骨架的形式决定了候选 harness 里有多大比例由构建模型来写。为了在保持候选 harness 可观察的同时把这个比例放到最大，我们采用一份被剥离过的 mini-swe-agent（Yang et al., 2024）作为骨架。

组成。契约骨架由五个 Python 源文件组成（合计大约七十行），外加一个安装脚本、一个入口脚本和一个项目配置。其中三个接口构成不可更改的外部契约，即（1）命令行接口 CLI，（2）无头入口，（3）用于驱动自动评测的 API。一份有代表性的候选 harness 大约跑到 30 个 Python 源文件、大约 16,000 行，其中大约 99.6% 是构建模型在契约骨架所提供的内容之外写出来的。

构建环境。每一次构建都发生在一个新建的空容器里，契约骨架和开发文档被复制进去，除了指定的模型网关之外，容器没有外部网络访问。构建开始之前，我们运行一次预检，确认容器里没有意外文件，并且 OpenCode 能正常启动；任一条件失败都会中止构建，并且不产生结果。

2.3 测试用例合成

图 3：三种测试用例合成方法。

在设计时，一个测试用例必须同时满足两项要求：它必须锚定到开发文档的某一条款，并且它必须能区分不同实现；一份被保留的用例究竟是否真能区分，要到评测之后才算定下来。如图 3 所示，我们在一个由产出驱动的循环里使用三种方法，前两种拓宽测试用例的覆盖，第三种加深它们所检查的内容。§2.3.1 取自 harness 用户的公开记录，§2.3.2 取自成熟 harness 的源码，§2.3.3 取自已有的测试套件本身。当当前方法的边际产出下降时，我们就转到下一种方法。因为这些方法取自不同来源，它们也使用不同的过滤标准。

#### 2.3.1 公开议题挖掘

这种方法建立在一条关于缺陷分布的假设上。大语言模型是在人类开发者所写的代码上训练的。成熟的 harness 与构建模型所写的 harness 面对相同的接口语义和同一类边界条件。因此我们预期，成熟 harness 在多年演化中暴露出来的缺陷，与构建模型所写 harness 犯下的错误之间会有大量重叠，这使得公开议题记录成为一个现成的候选来源。

收集。我们从四个前沿 harness（Claude Code、OpenCode、Gemini CLI 和 Kimi Code）的公开仓库拉取每一条议题；滤掉拉取请求之后，它们的数量分别是 9,868、5,438、4,831 和 946，合计 21,083。

排序与停止。两万多条记录无法全部人工审阅，所以我们先按它们与开发文档的相关程度排序。人工审阅从排序的顶部开始，当边际产出低于继续审阅的成本时停止。

聚类。同一个缺陷常常被反复报告，措辞不同，却都指向一个功能。我们按已读记录所报告的现象把它们聚类，每个簇形成一个候选测试用例，再把该簇的记录合并进这个用例的材料。

过滤。不同的现象仍可能落在实现的同一点上。如果两个簇锚定到同一条款，而且它们所观察的效果过于接近，那么由它们实现出来的测试用例就会在同一组实现上一起通过、一起失败，所以只保留材料更完整的那一个。剩下的候选只有在还能被改写成一条确定性断言、并且尚未被现有测试套件覆盖时，才予以保留。

这种方法的净产出一开始很高，随着同一批来源被继续挖掘而下降，我们据此转向下一种方法。

#### 2.3.2 跨 Harness 比较

前一种方法受限于外部记录的数量和质量；这一种方法改为从来源一侧拓宽覆盖。我们把一份候选 harness 与一份成熟 harness 的公开源码相比较，考察这份候选 harness 缺少哪些能力。我们把充当参照的成熟实现称为比较目标；例子包括 Kimi Code 和 Qwen Code。

划分。一份候选 harness 的源码按照开发文档所列出的功能划分成模块，每个模块对应文档里的一组功能。

比较。同一套划分被用到比较目标的源码上，使二者落在同一组功能边界上，然后我们逐模块枚举它们的实现差异，既包括比较目标处理了而候选 harness 没有处理的功能，也包括二者行为不同的边界。

归因。一处差异不一定来自缺陷；它可能只是反映了另一种实现方式。每一处差异都被追溯回开发文档，只有那些可以从某一条款的目的推导出来的差异，才算作候选测试用例。

这种方法的覆盖被比较目标的功能表面封顶：一旦比较所能得到的候选测试用例被用尽，我们就转向下一种方法。

#### 2.3.3 单变量扩展

这种方法从一个已经被证明能够区分实现的测试用例出发，每次只改一件事，从而加深测试用例所检查的内容。

种子选择。我们把一个已经显示能够区分实现的测试用例当作种子测试用例；它暴露出来的缺陷就是这一轮扩展的目标。

扩展。一个测试用例由一个场景和一条断言组成；场景是模拟模型用来驱动候选 harness 的那次会话，它只固定背景和流程，而裁决留给断言。我们只改变场景，保持断言固定。每次我们只改种子场景的一个变量，以得到一个新候选，并且每个候选仍然必须锚定到开发文档的某一条款。我们使用四个变量。

• 工具。一个编码智能体常常可以通过好几种工具到达同一个目的，而一份候选 harness 可能只把其中一部分实现正确。
• 输入形式。同一次检查可以由几种形式的输入触发；在检查路径逃逸时，我们可以把输入换成指向文件的符号链接、指向目录的符号链接、多级符号链接，或相对路径符号链接。
• 错误参数。同一种编码错误可能出现在不同参数上，例如把值 0 当成缺失。
• 结果被返回的位置。同一行为的结果可能出现在标准输出上、标准错误上，或出现在错误文本里。

距离检查。并不是每一个改过的场景都会在种子之外增加区分能力，所以我们评估每个候选的场景是否离种子场景足够远。离种子太近的候选被丢弃；否则我们把它保留为测试用例，并把它用作下一个种子，下一轮单变量扩展就从它继续。

这种方法从种子向外铺开，补足前面两种方法。没有锚定测试用例的条款提供不了种子，这样的空缺只能由前两种方法填上；因此三种方法交替使用。

2.4 阳性对照

一个测试用例通过，并不必然表明候选 harness 已经实现了所问的那项要求。考虑路径逃逸：模拟模型的脚本让候选 harness 用它的读取工具去读一个指向工作区之外的符号链接，测试用例断言外部文件的内容不会出现在发给模型的请求里。内容不出现，可能意味着实现拦住了这次越界读取，也可能意味着它的读取工具根本读不了任何文件。两种情形下断言都成立；只有前者才构成满足要求，后者是空洞通过。

为了排除空洞通过，我们设计了阳性对照机制。一个阳性对照与它的测试用例共享场景和夹具，夹具由运行前在工作区里准备好的文件和初始状态组成。它只改变输入或访问路径，选取一个落在被测条款所施加约束之外的情形，并断言一个在观察前提成立时必须发生的结果，也就是被测效果事实上可以被观察到。在上面的例子里，阳性对照复用同一个符号链接，改为通过 bash 工具访问它，并断言那个外部文件确实可读。

我们把共享同一观察前提的测试用例归到一个阳性对照之下，而一个带有若干这类前提的测试用例会被若干对照拦住。如果一个阳性对照失败，前提就不成立，因此它那一组里的测试用例即使通过也只能是空洞的，无论它们自身状态如何都记为 FAIL。阳性对照本身不计入通过率。

给定断言被正确构造，空洞通过有三种原因，每一种由一类阳性对照排除。

通道。工具的结果可能根本到不了正在被观察的那条通道。一个测试用例只观察四条通道中的一条；如果某个实现的读取工具从不把文件内容放进请求，那么工作区之外某个文件的内容也不会出现在那里。因此我们用读取工具去读一个普通文件，并确认它的内容确实出现在发给模型的请求里。这里失败意味着实现根本不把工具结果放到这条通道上，所以禁止内容的缺失并不构成拦截。路径逃逸测试用例并不需要自己的一个对照，因为它下面要说的反向对照已经覆盖了这个条件。

同一形式。这排除的是即便没有被测约束也会发生的失败。我们复用同一种输入形式，只改变访问路线，通过实现的 bash 工具访问同一个符号链接，并确认它解析到工作区之外，而且那里的文件可读（路径逃逸条款约束的是文件工具，由 bash 执行的命令落在它的范围之外）。这里失败意味着实现连不受该条款约束的一次访问都完不成，所以它在被测访问上的失手与拦截无关。

反向。这排除的是实现出于别的理由、而不是因为这次访问越界，就一概拒绝这类输入的情形。一个拒绝所有符号链接的实现会通过上面的测试用例，但它也会拒绝指向工作区内部的符号链接，而那些链接在正常使用中是有效的。因此我们把输入换成这样的符号链接，做同一次读取，并确认它的内容仍然出现在发给模型的请求里。这里失败意味着那次通过并不是来自识别出一次越界读取。

2.5 统计

测试套件包含 328 个测试用例，必要时每个都配有阳性对照。我们按照开发文档的内容以及契约骨架的三个外部契约，把它们划分成九个互不相交的类别，如图 4 所示。

（a）每个类别的测试用例数。

（b）至少被一个阳性对照拦住的测试用例所占份额。

图 4：文件操作和权限的阳性对照覆盖最高，交互终端最低。交付物检查标为 NA，因为契约检查已经完整解决了它的测试用例所检查的事情，即交付物是完整的。

阳性对照的覆盖。在 328 个测试用例中，有 130 个至少被一个阳性对照拦住（图 4b），其中 114 个被一个拦住，15 个被两个拦住，1 个被三个拦住。范围最宽的对照拦住六个测试用例，并确认一个指向工作区之外的符号链接事实上可读；接下来的两个各拦住五个，分别确认按范围读取有效，以及一次搜索会返回命中。这三个因此检查的是被最多测试用例共享的观察前提。

3 实验设置

接受评测的模型。我们评测来自十一家厂商的十九个模型，即 Claude Opus 4.6（Anthropic, 2026a）、Opus 4.7（Anthropic, 2026b）、Opus 4.8（Anthropic, 2026c）和 Opus 5（Anthropic, 2026d）；GPT-5.5（OpenAI, 2026a）、GPT-5.6-sol（OpenAI, 2026b）和 GPT-6 Astra（OpenAI, 2026c）；Qwen3.8 Max 0902（Alibaba Cloud, 2026）；Kimi K3（Kimi Team, 2026）；GLM 5.2（Z.ai, 2026a）和 GLM 5.3（Z.ai, 2026b）；DeepSeek V4 Pro（DeepSeek-AI, 2026b）和 DeepSeek V4.1 Flash（DeepSeek-AI, 2026a）；Hy3（Tencent Hunyuan, 2026a）和 Hy4 preview（Tencent Hunyuan, 2026b）；Doubao Seed 2.1 Pro（ByteDance Seed, 2026）；MiMo-V2.6-Flash（Xiaomi MiMo, 2026）；Grok 4.7（xAI, 2026）；以及 Step 5 Preview（StepFun, 2026）。

执行环境。两个阶段都在同一台服务器上运行，这是一台 AMD EPYC 7K83 机器，有 48 个逻辑处理器和 128 GB 内存。

配置。在第一阶段，构建器 harness 是 OpenCode 1.17.0，作为一个单独编译好的可执行文件安装进构建容器。构建器通过 OpenCode 的非交互入口 opencode run 来构造候选 harness，任务描述在命令行上一次给入。因为那个入口每次调用只把会话推进一轮，我们按照 OpenCode 官方文档所描述的那样，用 --continue 恢复同一会话，并在尚未作出提交时再供给一条提示，最多二十四轮，或直到墙上时钟耗尽。当会话接近上下文限制时，构建器 harness 自动压缩历史，触发阈值设在模型上下文窗口的百分之八十。每次构建受两小时墙上时钟限制，以及最多三次提交的配额约束，二者任一耗尽即终止。在第二阶段，每个测试用例在它自己的容器里、在它自己的夹具上执行一次，受 900 秒限制，超过则终止执行，并把该测试用例记为 FAIL。

4 结果

4.1 主要结果

表 2：十九个模型的通过率（%），按评测类别分解。最右一列是主要度量：全部 328 个测试用例上的通过率，报告为三份计分候选 harness 上的均值 $\pm$ 标准差。“其他”合并了交付物检查、启动和扩展发现，它们分别有 7、7 和 1 个测试用例。阳性对照被排除在每一个分母之外。表头缩写：Perm. 表示权限，File ops. 表示文件操作，Session 表示会话状态，Direct 表示直接驱动，Interactive 表示交互终端。表中第一行数字是各类别的用例数，不是某个模型的得分。

这套测试远未饱和。如表 2 最右一列所示，全部三百二十八个测试用例上的通过率从高到低依次是：GPT-6 Astra 为 53.05%，Opus 5 为 46.65%，Qwen3.8 Max 为 45.83%，GPT-5.6-sol 为 43.80%，Grok 4.7 为 43.50%，GLM 5.3 为 42.07%，MiMo-V2.6-Flash 为 41.87%，Step 5 Preview 为 40.75%，DeepSeek V4.1 Flash 为 40.24%，Hy4 preview 为 38.92%，Kimi K3 为 38.31%，Opus 4.8 为 38.01%，GPT-5.5 为 34.65%，Doubao Seed 2.1 Pro 为 32.62%，Opus 4.7 为 32.22%，DeepSeek V4 Pro 为 31.91%，Opus 4.6 为 28.25%，GLM 5.2 为 27.64%，Hy3 为 27.44%，十九个模型的均值是 38.30%。GPT-6 Astra 以 53.05% 取得最高通过率，而最弱的模型 Hy3 达到 27.44%，差距大约是二十六个百分点。即便最强的模型也有将近一半测试用例失败。因此这套测试在这一组模型上既没有饱和，也不是没有能力把这些模型区分开。

表的最后一行给出十九个模型在各列上的类别均值，这些均值不进入单个模型的排名：权限 43.7%，文件操作 39.6%，会话 29.9%，直接驱动 18.8%，无头 26.4%，交互终端 79.9%，其他 76.3%，全部用例 38.30%。前两名模型在边界场景上不同。在普通场景上，Opus 5 以 80.68% 领先，对照 GPT-6 Astra 的 72.46%；而在边界场景上，GPT-6 Astra 以 48.97% 领先，Opus 5 则落到 37.02%。因此这两个模型之间的性能差距，集中在它们如何处理边界条款，而不是集中在普通场景上。

4.2 按类别的结果

除了每个类别的平均通过率，我们还报告该类别最强模型与最弱模型之间的差距，我们称之为强弱差。

表 3：按评测类别列出的强弱差和测试用例构成。最后三列把每个类别的测试用例分成地板测试用例（没有任何候选 harness 通过）、天花板测试用例（每一个候选 harness 都通过），以及其余决定排名的、有区分度的测试用例。

各类别的区分能力相差很大。如表 3 所示，权限类别在模型之间提供最大的分离：它的平均通过率是 43.7%，强弱差是 50.8 分，61 个测试用例中有 51 个有区分度。文件操作的平均通过率与之相当，为 39.6%，但差距只有 20.9 分。交互终端类别平均为 79.9%，正在接近饱和。此外，有 56 个测试用例被每一份候选 harness 都失败掉，所以这些用例在被评测的这一组里不提供区分；它们集中在直接驱动、会话状态、权限和无头这几个类别。

一个模型的名次在类别之间变化很大。在六个主要类别中，每个类别至少有二十个测试用例，一个模型的名次最多变动十六个位置：Grok 4.7 在文件操作上排第一，但在会话状态上排第十一；Opus 4.6 在直接驱动上排第三，但在权限上排第十九；Hy4 preview 在会话状态上排第五，但在直接驱动上排第十九。GPT-6 Astra 在六个类别中的四个上领先，Grok 4.7 和 Qwen3.8 Max 领先其余两个。这些类别呈现的是正的成对关联，而不是清楚的此消彼长。六个主要类别之间全部十五对相关都是正的，均值为 $+0.521$，总通过率与这六个全都相关，其中五个介于 0.69 与 0.94 之间。这些结果与一种大体上一维的能力相一致：模型的差别主要在总体能力，而不在它们专长于哪些类别。尽管如此，模型排名在类别之间仍然变化很大。

这套测试是一件可靠的仪器。在全部测试用例上、对五十七份候选 harness 计算得到的 KR-20 系数是 0.913，表明内部一致性高，这与测试用例测量的是同一种底层能力时所预期的情形一致。

4.3 候选 Harness 的架构

本节分析五十七份计分候选 harness 的源码。一个模块是候选 harness 根目录下的一个 Python 源文件，一行代码是一个非空行；当至少一个模块文件名包含与该类别相关联的关键词时，我们把这个类别定义为拥有一个专用模块。

表 4：候选 harness 的架构。除“行/模块”之外，每一列都是该模型三份计分构建上的均值；“行/模块”是平均代码行数除以平均模块数，在四舍五入之前计算；最大模块是单个最大模块所持有的全部代码行份额。

实现规模主要由模型决定。如表 4 所示，按模型平均的代码规模从 1,271 行到 16,681 行，而在五十七份构建上，范围是 1,062 到 19,208。这种变异大部分位于模型之间，而不是位于给定模型的三次构建之间：代码行数方差的 95.9% 在模型之间，一个模型三次构建之间的变异系数平均为 12.7%，而十九个模型均值之间是 60.1%。对应的模型间方差份额，模块数是 87.9%，每模块行数是 80.6%，最大模块份额是 95.7%；图 5 对代码行数展示了同样的模型间主导。代码行数与通过率的相关，在五十七份构建上是 0.614，在模型均值之间是 0.629。实现规模主要由模型身份驱动，一个模型的三次构建之间变异相对较小。

图 5：代码行数对照通过率。左图每个模型一个点，取它在三份计分构建上的均值，并带有最小二乘拟合及其 95% 置信带。右图是每个模型的三份计分构建，用一条线段跨过，并标出均值，每个模型一行，按通过率排序。

模块更多的 harness 得分更低。在控制代码行数之后，模块数与通过率的偏相关是 $-0.423$，留一模型检验把它保持在 $-0.484$ 与 $-0.309$ 之间；相应地，每模块行数的偏相关是 $+0.504$，在同样的检验下保持在 0.312 与 0.649 之间。因此碎片化并不是没有代价的。

5 相关工作

5.1 代码与软件工程基准

编码基准已经演化到涉及越来越大的代码库的任务，并且大体分成两类：代码补全，以及仓库级生成。

补全这一类的基准要求对已有代码做局部编辑。HumanEval（Chen et al., 2021）确立了用单元测试评判单个函数的做法，MBPP（Austin et al., 2021）和 EvalPlus（Liu et al., 2023）把这种基于单元测试的范式扩展到更大的规模；范围随后随着 SWE-bench（Jimenez et al., 2024）长到整个仓库，它要求模型解决一个真实议题，并用对应拉取请求所附带的测试来评判。SWE-bench 的变体在应对污染的同时扩展这一设置（Deng et al., 2026），在自由职业任务上评测端到端表现（Miserendino et al., 2025），或从文档变更推导规格（Jiang et al., 2026）。

仓库级生成去掉已有实现，要求给出一份完整实现。评测标准取决于可以得到的参照实现。Commit0（Zhao et al., 2025）和 NL2Repo-Bench（Ding et al., 2026）要求模型重建已发布的库，并用所提供的或上游的单元测试来评判。RepoZero（Zhang et al., 2026b）对照第二份实现比较输出等价；ProgramBench（Yang et al., 2026）使用一个参照可执行文件，通过模糊测试生成端到端测试；DeepSWE（Huang et al., 2026b）为每个任务手写一个验证器，接受所请求功能集的任何实现。

5.2 Harness 基准

Harness 是一类软件，其功能表面可以逐项功能地枚举（de Macedo, 2026；Guo et al., 2026；Barbaste et al., 2026）。这使它成为构建类基准的合适目标。大多数 harness 基准评测的是已经存在的 harness。Claw-SWE-Bench（Zheng et al., 2026）固定提示、预算、工作区和评测器，并发现 harness 的选择会使分数移动 27.4 分，相比之下模型的选择是 29.4 分；Harness-Bench（Yao et al., 2026）在 106 个沙箱任务上分离配置层面的效应，并得出结论：能力应当在模型–harness 配置这一层报告，而不是只归因于基础模型。

另一些基准把 harness 固定住，评测它的单项能力，例如智能体所阅读的各个表面上的规则遵从（Huang et al., 2026c）、渐进式披露下的技能检索（Han et al., 2026）、组件生命周期推理（Sileo & Kachler, 2026），或沿着策略阶梯、并跨持久载体的安全（Davidovich et al., 2026；Bai et al., 2026；Zhang et al., 2026a）。还有一些让给定的 harness 逐阶段变化，并询问智能体是否跟得上（Ke et al., 2026）。

又一条工作线要求模型产出或修改 harness 本身，从一个已有 harness 及其执行反馈出发（Wu et al., 2026；Huang et al., 2026a；Ursekar et al., 2026）；因为增益是在下游任务上测量的，它们无法与仅仅允许多做测试时搜索所得到的增益分开，这一混淆已在该文献中被指出（Wang et al., 2026）。所有这些研究都从下游任务推断 harness 的质量。这样的任务必须事先准备好，而驱动它们的模型的能力也会影响所测得的分数。只看输出的打分也不充分，因为一个 harness 可以沿着一条到达了未授权资源的轨迹，返回一个正确且无害的答案，而输出层面的评测看不见这类失败（Liu et al., 2026）。它们之中没有一个逐条款裁决某个 harness 自身的行为是否符合一份规格。

5.3 本工作的位置

Doc2Harness 在三个方面不同于上面的工作。第一，目标交付物并不对应任何已有实现：开发文档把十二个前沿 harness 的功能汇成一套自洽的条款，而先前的仓库级交付物是对已经发表之物的重建。第二，候选 harness 由遵循预设脚本的模拟模型驱动，而不是由真实模型在下游任务上驱动，因此评测是确定性的，被评判的是候选 harness 本身。第三，候选 harness 作为黑盒、通过一次完整的脚本会话被端到端执行，效果从四条通道读取。这使得“一次被拒绝的操作不得发生”这种形式的约束可以逐条款裁决；并且因为一条要求某种效果不出现的断言，可能仅仅因为被测功能从未运行而成立，这类测试用例配有阳性对照，用来确认观察前提成立。总之，Doc2Harness 是第一个能够确定性地评估一个模型把 harness 开发得怎么样的基准。

6 局限

该协议测量的是单次构建。每次构建最多允许三次提交，并不是一个迭代的构建–评测–修复循环。契约检查检验的是形式而不是行为，所以一份候选 harness 所接受的修改量取决于模型何时提交，早提交者的通过率是一个下界而不是上界。该协议并不测量候选 harness 被冻结之后、基于行为反馈的改进。

单个缺陷可以一次使几个测试用例失败。有些测试用例围绕同一功能建造：§2.3.3 的单变量扩展从一个种子测试用例导出若干变体，尽管距离检查丢弃了离种子太近的候选，留下来的变体仍然相关。因此单个缺陷可以在这些变体上造成相关的失败。

7 结论

Doc2Harness 是第一个能够确定性地评估一个模型把 harness 开发得怎么样的基准。接受评测的构建模型在一个固定的构建器 harness 里运行，从一份开发文档和一份只声明接口的契约骨架出发，构建出一个完整的候选 harness；然后一个模拟模型按每个测试用例的预设脚本驱动它，显式断言判定行为是否符合。

我们的实验表明，即便最强的模型也有将近一半测试用例失败，而且这些失败不是随机的，而是集中在一个实现选择上：同一功能是否被拆到若干模块里。我们希望 Doc2Harness 能充当测量这一类构建能力的基准。

参考文献

Alibaba Cloud (2026) Alibaba Cloud。阿里云发布 Qwen3.8-Max：迄今规模最大、能力最强的旗舰模型。https://www.alibabacloud.com/en/press-room/alibaba-unveils-qwen3-8-max，2026。人名与文献编号保留原文。

Anthropic (2025) Anthropic。Claude Code 的代码仓库与产品入口。https://github.com/anthropics/claude-code，2025。人名与文献编号保留原文。

Anthropic (2026a) Anthropic。Claude Opus 4.6 的系统卡片。https://www.anthropic.com/claude-opus-4-6-system-card，2026a。人名与文献编号保留原文。

Anthropic (2026b) Anthropic。Claude Opus 4.7 的系统卡片。https://www.anthropic.com/claude-opus-4-7-system-card，2026b。人名与文献编号保留原文。

Anthropic (2026c) Anthropic。Claude Opus 4.8 的系统卡片。https://www.anthropic.com/claude-opus-4-8-system-card，2026c。人名与文献编号保留原文。

Anthropic (2026d) Anthropic。Claude Opus 5 的系统卡片。https://www.anthropic.com/claude-opus-5-system-card，2026d。人名与文献编号保留原文。

Anysphere (2023) Anysphere。Cursor 编辑器产品入口。https://cursor.com，2023。人名与文献编号保留原文。

Austin et al. (2021) Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le 等。用大语言模型做程序合成。arXiv 预印本 arXiv:2108.07732，2021。人名与文献编号保留原文。

Bai et al. (2026) Yajing Bai, Jinhao Duan, Jie Peng, Xianfeng Wu, Sijia Liu, Song Wang, and Tianlong Chen。HarnessRisk：面向智能体 harness 安全、以生命周期为取向的基准。arXiv 预印本 arXiv:2608.17597，2026。人名与文献编号保留原文。

Barbaste et al. (2026) Paul Barbaste, Tristan Darrigol, Germain Vu, and Tom Wiltberger。Harness 工程：编码智能体的解剖、架构与演化，对十一套系统的源码研究。arXiv 预印本 arXiv:2609.00006，2026。人名与文献编号保留原文。

ByteDance Seed (2026) ByteDance Seed。Seed2.1：面向真实世界生产力的下一代智能体。https://seed.bytedance.com/en/seed2_1，2026。人名与文献编号保留原文。

Charm (2025) Charm。Crush 的代码仓库。https://github.com/charmbracelet/crush，2025。人名与文献编号保留原文。

Chen et al. (2021) Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman 等。评测在代码上训练的大语言模型。arXiv 预印本 arXiv:2107.03374，2021。人名与文献编号保留原文。

Cline Bot Inc. (2024) Cline Bot Inc。Cline 的代码仓库。https://github.com/cline/cline，2024。人名与文献编号保留原文。

Davidovich et al. (2026) Dotan Davidovich, Yair Amar, Hai Rozencwajg, and Or Hiltch。权限被拒绝：在加固环境中对编码智能体做按策略分级的评测。arXiv 预印本 arXiv:2608.02670，2026。人名与文献编号保留原文。

de Macedo (2026) Sanderson Oliveira de Macedo。是什么使一个 harness 成为 harness：智能体 harness 的必要且充分条件。arXiv 预印本 arXiv:2606.10106，2026。人名与文献编号保留原文。

DeepSeek-AI (2026a) DeepSeek-AI。DeepSeek-V4.1-Flash：更聪明、更快、更高效。https://api-docs.deepseek.com/news/news260910/，2026a。人名与文献编号保留原文。

DeepSeek-AI (2026b) DeepSeek-AI。DeepSeek-V4：走向高效的百万词元上下文智能。arXiv 预印本 arXiv:2606.19348，2026b。人名与文献编号保留原文。

Deng et al. (2026) Xiang Deng, Jeff Da, Edwin Pan, Yannis Yiming He, Charles Ide, Kanak Garg, Niklas Lauffer, Andrew Park, Chetan Rane, Karmini Sampath 等。SWE-Bench Pro：人工智能智能体能解决长程软件工程任务吗？载于国际机器学习会议，2026。人名与文献编号保留原文。

Ding et al. (2026) Jingzhe Ding, Shengda Long, Changxin Pu, Ge Zhang, Zhou Huan, Hongwan Gao, Xiang Gao, Chao He, Yue Hou, Fei Hu 等。NL2Repo-Bench：面向编码智能体的长程仓库生成评测。载于国际机器学习会议，2026。人名与文献编号保留原文。

Gauthier (2023) Paul Gauthier。Aider 的代码仓库。https://github.com/Aider-AI/aider，2023。人名与文献编号保留原文。

Ge et al. (2025) Yuyao Ge, Lingrui Mei, Zenghao Duan, Tianhao Li, Yujia Zheng, Yiwei Wang, Lexin Wang, Jiayu Yao, Tianyu Liu, Yujun Cai, Baolong Bi, Fangda Guo, Jiafeng Guo, Shenghua Liu, and Xueqi Cheng。关于用大语言模型做氛围编码的综述。arXiv 预印本 arXiv:2510.12399，2025。人名与文献编号保留原文。

Google (2025) Google。Gemini CLI 的代码仓库。https://github.com/google-gemini/gemini-cli，2025。人名与文献编号保留原文。

Guo et al. (2026) Jianyuan Guo, Zhiwei Hao, Chengcheng Wang, Cheng Fan, Tingzhang Luo, Hongguang Li, Ying Gao, Hefei Mei, Jiankun Peng, Rongjian Xu 等。从问答到任务完成：关于智能体系统与 harness 设计的综述。arXiv 预印本 arXiv:2606.20683，2026。人名与文献编号保留原文。

Han et al. (2026) Jinyi Han, Yuanjian Xu, Ying Liao, Xinyi Wang, Zishang Jiang, Zixiang Di, Fanyang Lu, Zhichao Hu, and Yanghua Xiao。Skill-Use：大语言模型在智能体 harness 里真的会使用技能吗？arXiv 预印本 arXiv:2608.04828，2026。人名与文献编号保留原文。

Huang et al. (2026a) Lisheng Huang, Chen Yang, Hao Zhou, Huatong Song, Zongchao Chen, Ran Le, Yang Song, Wayne Xin Zhao, and Tao Zhang。Evo-Bench：语言模型能改进智能体 harness 吗？arXiv 预印本 arXiv:2608.09096，2026a。人名与文献编号保留原文。

Huang et al. (2026b) Wenqi Huang, Charley Lee, Leonard Tng, and Serena Ge。DeepSWE：在原创的长程工程任务上测量前沿编码智能体。arXiv 预印本 arXiv:2607.07946，2026b。人名与文献编号保留原文。

Huang et al. (2026c) Zining Huang, Haoran Que, Hong Zeng, Ge Zhang, Zuo Wang, Jin Chen, Haodong Wang, Zhongfei Hou, Changxin Pu, Shen Yan 等。Harness-IF：评测编码智能体在各个指令表面上的指令遵循。arXiv 预印本 arXiv:2608.11727，2026c。人名与文献编号保留原文。

Jiang et al. (2026) Zhonghao Jiang, Le Deng, Jialun Cao, Michael Pradel, and Zhongxin Liu。Doc2Feat-Bench：评测由文档驱动的功能添加。载于 IEEE/ACM 自动化软件工程国际会议，2026。人名与文献编号保留原文。

Jimenez et al. (2024) Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan。SWE-bench：语言模型能解决真实世界的 GitHub 议题吗？载于国际学习表征会议，2024。人名与文献编号保留原文。

Ke et al. (2026) Zixuan Ke, Vaidehi Patil, Haizhou Shi, Yang Li, Ye Liu, Sarath Shekkizhar, Anurag Koul, Jiayu Wang, Xuan Phi Nguyen, Semih Yavuz 等。EvoHarnessBench：你的智能体跟得上持续演化的 harness 吗？arXiv 预印本 arXiv:2609.04280，2026。人名与文献编号保留原文。

Kimi Team (2026) Kimi Team。Kimi K3：开放的前沿智能。arXiv 预印本 arXiv:2607.24653，2026。人名与文献编号保留原文。

Liu et al. (2026) Chengzhi Liu, Yichen Guo, Yepeng Liu, Yuzhe Yang, Qianqi Yan, Xuandong Zhao, Wenyue Hua, Sheng Liu, Sharon Li, Yuheng Bu, and Xin Eric Wang。审计智能体 harness 的安全性。arXiv 预印本 arXiv:2605.14271，2026。人名与文献编号保留原文。

Liu et al. (2023) Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, and Lingming Zhang。ChatGPT 生成的代码真的正确吗？对大语言模型代码生成的严格评测。载于神经信息处理系统进展，2023。人名与文献编号保留原文。

Mei et al. (2025) Lingrui Mei, Jiayu Yao, Yuyao Ge, Yiwei Wang, Baolong Bi, Yujun Cai, Jiazhi Liu, Mingyu Li, Zhong-Zhi Li, Duzhen Zhang, Chenlin Zhou, Jiayi Mao, Tianze Xia, Jiafeng Guo, and Shenghua Liu。关于大语言模型上下文工程的综述。arXiv 预印本 arXiv:2507.13334，2025。人名与文献编号保留原文。

Miserendino et al. (2025) Samuel Miserendino, Michele Wang, Tejal Patwardhan, and Johannes Heidecke。SWE-Lancer：前沿大语言模型能从真实世界的自由职业软件工程中赚到一百万美元吗？载于国际机器学习会议，2025。人名与文献编号保留原文。

Moonshot AI (2026) Moonshot AI。Kimi Code 的代码仓库。https://github.com/MoonshotAI/kimi-code，2026。人名与文献编号保留原文。

OpenAI (2025) OpenAI。Codex CLI 的代码仓库。https://github.com/openai/codex，2025。人名与文献编号保留原文。

OpenAI (2026a) OpenAI。GPT-5.5 的系统卡片。https://deploymentsafety.openai.com/gpt-5-5，2026a。人名与文献编号保留原文。

OpenAI (2026b) OpenAI。GPT-5.6 的系统卡片。https://deploymentsafety.openai.com/gpt-5-6，2026b。人名与文献编号保留原文。

OpenAI (2026c) OpenAI。GPT-6 Astra 的系统卡片。https://deploymentsafety.openai.com/gpt-6-astra，2026c。人名与文献编号保留原文。

OpenClaw Foundation (2025) OpenClaw Foundation。OpenClaw 的代码仓库。https://github.com/openclaw/openclaw，2025。人名与文献编号保留原文。

OpenCode Contributors (2025) OpenCode Contributors。OpenCode 的代码仓库。https://github.com/anomalyco/opencode，2025。人名与文献编号保留原文。

Qwen Team (2025) Qwen Team。Qwen Code 的代码仓库。https://github.com/QwenLM/qwen-code，2025。人名与文献编号保留原文。

Sileo & Kachler (2026) Damien Sileo and Dimitri Kachler。CordisBench：语言模型能推理动态智能体 harness 中的组件生命周期吗？arXiv 预印本 arXiv:2609.01600，2026。人名与文献编号保留原文。

StepFun (2026) StepFun。Step 5 Preview 的产品说明。https://www.stepfun.com/step-5-preview，2026。人名与文献编号保留原文。

Tencent Hunyuan (2026a) Tencent Hunyuan。Hy3 的模型卡片。https://huggingface.co/tencent/Hy3，2026a。人名与文献编号保留原文。

Tencent Hunyuan (2026b) Tencent Hunyuan。Hy4 preview 的模型卡片。https://huggingface.co/tencent/Hy4-preview，2026b。人名与文献编号保留原文。

Ursekar et al. (2026) Varun Ursekar, Apaar Shanker, Yash Maurya, Shehab Yasser, Vijay S. Kalmath, Veronica Chatrath, and Yuan Xue。HarnessOpt-Bench：评测大语言模型做 harness 优化的能力。arXiv 预印本 arXiv:2608.06301，2026。人名与文献编号保留原文。

Wang et al. (2025) Xingyao Wang, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh 等。OpenHands：一个把人工智能软件开发者当作通用智能体的开放平台。载于国际学习表征会议，2025。人名与文献编号保留原文。

Wang et al. (2026) Yike Wang, Huaisheng Zhu, Zhengyu Hu, Yige Yuan, Zhengyu Chen, Shakti Senthil, Hannaneh Hajishirzi, Yulia Tsvetkov, Noah A. Smith, Pradeep Dasigi, and Teng Xiao。重新思考智能体 harness 演化的评测。arXiv 预印本 arXiv:2607.12227，2026。人名与文献编号保留原文。

Wu et al. (2026) Yuhao Wu, Jingyuan Zhang, Jiajun Shi, Xinping Lei, Qingshui Gu, Yuxuan Zhang, Zexuan Wang, Chen He, Chen Huang, Maojia Song 等。HarnessDev：大语言模型能创建并演化自己的智能体 harness 吗？arXiv 预印本 arXiv:2609.01437，2026。人名与文献编号保留原文。

xAI (2026) xAI。介绍 Grok 4.7。https://x.ai/news/grok-4-7，2026。人名与文献编号保留原文。

Xiaomi MiMo (2026) Xiaomi MiMo。MiMo-V2.6：为自我改进扩大强化学习。https://mimo.mi.com/docs/en-US/news/latest/v2-6，2026。人名与文献编号保留原文。

Yang et al. (2024) John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik R Narasimhan, and Ofir Press。SWE-agent：智能体–计算机接口使自动化软件工程成为可能。载于神经信息处理系统进展，2024。人名与文献编号保留原文。

Yang et al. (2026) John Yang, Kilian Lieret, Jeffrey Ma, Parth Thakkar, Dmitrii Pedchenko, Sten Sootla, Emily McMilin, Pengcheng Yin, Rui Hou, Gabriel Synnaeve 等。ProgramBench：语言模型能从零重建程序吗？载于神经信息处理系统进展，2026。人名与文献编号保留原文。

Yao et al. (2026) Yilun Yao, Xinyu Tan, Chao-Hsuan Liu, Yaoming Li, Zhengyang Wang, Wenhan Yu, Zhewen Tan, Yuxuan Tian, Guangxiang Zhao, Lin Sun 等。Harness-Bench：在真实智能体工作流中跨模型测量 harness 效应。arXiv 预印本 arXiv:2605.27922，2026。人名与文献编号保留原文。

Z.ai (2026a) Z.ai。GLM-5.2：为长程任务而建。https://z.ai/blog/glm-5.2，2026a。人名与文献编号保留原文。

Z.ai (2026b) Z.ai。GLM-5.3：带有涌现网络能力的前沿编码。https://z.ai/blog/glm-5.3，2026b。人名与文献编号保留原文。

Zhang et al. (2026a) Xiao Zhang, Yusheng Wang, Yuhao Fei, Dongyuan Li, Zian Liang, Liuyu Xiang, Hongxun Gu, and Zhaofeng He。HarnessSafe：评测智能体 harness 中跨持久载体的安全。arXiv 预印本 arXiv:2608.06984，2026a。人名与文献编号保留原文。

Zhang et al. (2026b) Zhaoxi Zhang, Yiming Xu, Jiahui Liang, Weikang Li, Xiaoshuai Chen, Liwei Qian, Xin Pei, Jizhou Huang, Run Sun, and Yunfang Wu。RepoZero：大语言模型能从零生成一个代码仓库吗？载于神经信息处理系统进展，2026b。人名与文献编号保留原文。

Zhao et al. (2025) Wenting Zhao, Nan Jiang, Celine Lee, Justin Chiu, Claire Cardie, Matthias Gallé, and Alexander Rush。Commit0：从零生成库。载于国际学习表征会议，2025。人名与文献编号保留原文。

Zheng et al. (2026) Mengyu Zheng, Kai Han, Boxun Li, Haiyang Xu, Yuchuan Tian, Wei He, Hang Zhou, Jianyuan Guo, Hailin Hu, Lin Ma 等。Claw-SWE-Bench：在编码任务上评测 OpenClaw 风格智能体 harness 的基准。arXiv 预印本 arXiv:2606.12344，2026。人名与文献编号保留原文。