评估基于大语言模型的端到端 CLI 工具场景中的从零到一软件生成

评估基于大语言模型的端到端 CLI 工具场景中的从零到一软件生成（中文全译）

翻译说明：本文是 arXiv 论文 Evaluating LLM-Based 0-to-1 Software Generation in End-to-End CLI Tool Scenarios（arXiv:2604.06742）的中文全译，由智测团队翻译。原作者：Ruida Hu、Xinchen Wang、Chao Peng、Cuiyun Gao、David Lo。原文以 CC BY-SA 4.0 许可发布。译文保留原文全部章节、数据与结论；参考文献列表从略。

摘要

大型语言模型（LLM）的演进催生了向意图驱动软件开发范式的转变，其中自主智能体被期望从头开始设计并交付完整的、可运行的软件系统。然而，由于两个根本性局限，现有基准测试未能充分评估这种从零到一的生成能力。首先，它们依赖于预定义的结构脚手架，这将任务简化为 mere 文件填充。其次，它们依赖于僵化的白盒单元测试，这迫使生成的代码符合特定的内部实现，而不是验证以用户为中心的端到端行为。

为了弥补这一差距，我们引入了 CLI-Tool-Bench，这是一种新颖的、与结构无关的基准测试，旨在评估命令行界面（CLI）工具的从零到一生成。该基准由自动黑盒差异测试框架驱动，包含 94 个高质量的真实世界仓库，涵盖多种编程语言和复杂度级别。对于每个任务，智能体仅提供一个空工作区，迫使它们自主处理仓库规划和依赖项。我们通过在隔离沙箱中执行生成的软件来评估它。然后，使用严格的多层等价度量标准，将系统级副作用和终端输出与人工编写的预言机（oracle）进行比较。

对七个最先进的大语言模型的广泛评估表明，顶级模型的最大整体成功率仅为 43.8%，凸显了从零到一的软件生成仍然是一个极具挑战性的前沿领域。此外，我们发现智能体表现出强烈的生成单体代码结构的倾向，并且更高的 token 消耗并不一定带来更好的任务性能。

I 引言

大型语言模型（LLM）的出现催化了自动化软件工程领域的范式转变 [1, 2, 3, 4]。超越简单的代码补全，最近的进展促进了基于 LLM 的自主智能体 [5, 6, 7, 8] 的发展，这些智能体能够应对复杂的编程任务。这种快速进步正推动行业进入"氛围编码"（Vibe Coding）或意图驱动开发的时代 [9, 10, 11]。在这种新范式中，用户只需用自然语言表达其高层需求。自主智能体随后应解释这些需求，并从头开始生成一个完整的、可运行的软件仓库。

为了衡量这些智能体的能力，稳健的评估基准不可或缺。然而，现有基准在评估智能体创建真实世界软件的能力方面存在不足。传统基准，如 HumanEval [12] 和 MBPP [13]，局限于函数级生成。虽然最近的努力如 SWE-bench [14] 将评估提升到了仓库级别，但它们主要关注软件维护任务，而非从头开始的软件创建。更近期的基准如 NL2Repo-Bench [15] 探索了从零到一的软件生成。然而，它们的评估方法揭示了阻碍准确评估现代 LLM 智能体的关键局限性。具体而言，我们在当前评估格局中确定了两个主要挑战：

挑战 1：依赖预定义的仓库结构。 评估 LLM 智能体真正的从零到一软件生成能力仍然是一个开放挑战。即使在以生成为重点的基准中，评估也严重依赖于固定的、预定义的仓库结构 [15]。这些基准通常为智能体提供预先构建的文件骨架和目录脚手架，从而将复杂的软件生成任务简化为 mere 代码填充。这种依赖结构的范式从根本上绕过了软件创建中的仓库结构规划。

在真实的软件开发中，开发人员必须决定如何组织目录、模块化文件和管理依赖项。通过将智能体限制在预定义的结构中，当前基准无法评估 LLM 是否能够独立规划和构建一个连贯的仓库。

挑战 2：缺乏端到端黑盒测试。 此外，现有评估严重依赖白盒单元测试 [16, 15, 14, 12]。这些测试与软件的内部实现细节紧密耦合，迫使生成的代码符合特定的函数签名或类定义。这种方法严重限制了 LLM 的结构自主性和创造性。更重要的是，从以用户为中心的角度来看，像命令行界面（CLI）工具这样的软件实用程序通常作为黑盒被消费。用户关心的是工具是否正确解析命令行参数、产生预期的终端输出以及产生预期的系统级副作用（例如文件系统修改）。因此，依赖僵化的白盒测试无法为这些关键的对外行为提供真实且端到端的验证。

为了弥合这些差距，我们引入了 CLI-Tool-Bench，这是一种新颖的、与结构无关的基准测试，专门设计用于评估 CLI 工具的从零到一生成。我们选择 CLI 工具作为评估目标，因为它们代表了基础软件实用程序。它们的外部可观察行为，包括解析标准输入和产生终端输出或文件系统更改，使它们非常适合严格的黑盒测试，而无需内部代码检查。

我们策划了一个高质量的数据集，包含 94 个真实世界的 CLI 仓库，涵盖三种编程语言（即 Python、JavaScript、Go）和各种复杂度级别。为了克服对预定义结构的依赖，每个智能体仅提供自然语言需求和空工作区，迫使其对内部结构和依赖项拥有完全自主权。我们提出了一种基于黑盒差异测试的新颖评估方法。具体而言，生成的工具在隔离沙箱中执行，其终端输出以及系统级副作用（例如文件系统更改）与人工编写的预言机进行严格比较。为了确保公平评估而不惩罚架构多样性，我们提出了一个多层等价度量标准，涵盖执行可靠性、副作用一致性和行为等价性。

总之，本文的贡献如下：

• 我们引入了 CLI-Tool-Bench，这是第一个用于评估从头开始的端到端软件生成的与结构无关的基准测试，它在没有预定义脚手架依赖的情况下强制执行真正的结构自主性。

• 我们提出了一种自动黑盒差异测试管道，它在隔离沙箱中评估生成的仓库，严格验证执行可靠性、副作用一致性和行为等价性。

• 我们对 94 个真实世界任务上的七个最先进的 LLM 和智能体框架进行了广泛评估。我们的结果显示，表现最佳的模型的最大整体成功率仅为 43.78%，强调了这项任务的重大难度。我们还发现了关键的行为模式，例如智能体对单体设计的强烈偏好以及代价高昂且无成效的调试循环的普遍存在。

II 构建与评估管道

图 1：CLI-Tool-Bench 框架概述。

为了评估从零到一的软件生成，我们提出了一个自动化管道（图 1），包含三个核心模块：(1) 仓库筛选，(2) 模式引导的任务合成，以及 (3) 黑盒差异评估。

II-A 仓库筛选

为了构建一个具有代表性的数据集，我们针对 CLI 开发中广泛采用的三种主流编程语言：Python、JavaScript 和 Golang [17]。通过多阶段过滤过程，我们最终得到了一个包含 94 个高质量预言机仓库的精选集。

#### II-A1 静态元数据过滤

我们最初使用特定标准从 GitHub 检索候选仓库：(1) star 数 >>10；(2) 主要语言比例 >>60%；(3) 存在 CLI 相关关键词；(4) 开源许可证；以及 (5) 存在语言特定的构建配置文件（例如 "setup.py"、"package.json" 或 "go.mod"）。

#### II-A2 动态入口识别

然而，并非所有检索到的仓库都提供功能性的独立 CLI 工具。为了严格选择有效的仓库，我们在隔离环境中全局安装每个候选仓库。一个关键挑战是自动识别用于调用已安装 CLI 的确切命令名称，这经常与仓库名称不同。为了解决这个问题，我们的管道在安装过程中监控系统的二进制目录，以捕获所有新生成的可执行文件。然后，我们使用启发式匹配算法将仓库名称与这些捕获的文件进行比较，该算法优先考虑精确匹配、首字母缩写和字符串相似性。

一旦识别出最可能的可执行文件，就通过运行 "--help" 命令对其进行验证。如果此命令成功返回标准使用信息而没有错误，则认为该仓库包含功能性 CLI 入口点。

#### II-A3 分层手动验证

通过此动态验证的仓库还要经过两位软件工程专家的分层手动验证。此步骤确保仓库可以在没有环境错误的情况下运行。它还过滤掉具有隐式依赖项的任务（如非标准本地服务器环境），以确保完全无歧义的规范。这种严格的过滤过程确保了精选预言机仓库的高质量。

II-B 模式引导的任务合成

大规模生成全面的测试用例是一个关键挑战。我们通过使用 LLM 从每个精选的预言机仓库中提取结构化命令模式来解决这个问题，该模式随后指导评估提示和测试套件的自动生成。

#### II-B1 迭代模式提取

对于每个预言机仓库 $R_{oracle}$，LLM 迭代解析其 README 文档和 "--help" 输出。它逐层探索嵌套子命令以提取分层元数据模式。该模式定义了 CLI 的外部接口，包括可用命令名称、子命令、接受的参数及其数据类型，以及严格的执行约束，如互斥标志或必需参数。

#### II-B2 LLM 导向的模糊测试用于测试生成

基于提取的模式，我们实施 LLM 导向的模糊测试以系统地覆盖 CLI 的功能。我们首先将模式扩展为一组不同的命令模式。每个模式代表一种使用 CLI 的特定方式，例如唯一的子命令与有效的标志组合配对。

对于每个模式，LLM 利用预定义的测试框架生成多样化的测试实例，涵盖常见用法、边界条件和错误处理。此过程的核心是自动执行-反馈循环。每个生成的测试命令都直接针对人工编写的预言机 $R_{oracle}$ 执行。至关重要的是，这些测试用例的有效性由预言机本身确定。任何在真实仓库上成功执行而没有错误的命令都被视为有效且受支持的用法。然后，我们捕获预言机的确切执行状态、标准输出和任何文件系统状态更改。这种输入命令和捕获的预言机执行结果的组合形成了一个完整的、真实的行为测试用例，有效地消除了手动测试验证的需要。如果生成的命令在此阶段意外失败，则错误跟踪会被反馈给 LLM 以完善命令，直到建立有效的测试模板。

至关重要的是，此模糊测试过程充当最终的质量过滤器。如果 LLM 持续未能为任何记录的命令模式找到成功的执行实例，则整个仓库将从我们的基准中丢弃。通过这个多阶段过滤过程，我们最终得到了包含 94 个高质量任务的最终数据集。对于这些剩余仓库中成功验证的命令模式，我们恰好合成了 50 个端到端测试用例，以平衡评估覆盖率和计算成本。这些实例故意包括正常执行路径的有效正面输入以及无效或边缘情况的负面输入，例如格式错误、超出范围的值或恶意字符串。这种设计使我们能够严格评估生成的软件是否准确地重现了原始预言机的错误处理行为和鲁棒性。

#### II-B3 标准化任务提示构建

最终的评估提示旨在模拟真实的和新软件开发需求，而不泄露内部实现细节。提示包含三个匿名化组件：(1) 源自 README 的清理后的功能上下文；(2) 完整的、迭代提取的 "--help" 文档，作为严格的外部接口规范；以及 (3) 每个命令模式的一个验证成功的执行示例，这是在模糊测试阶段获得的，用于清楚地展示预期行为。为了降低评估期间数据污染的风险（例如，模型从互联网或其训练语料库中检索原始源代码），整个管道固有地嵌入了多层防御机制。

具体而言，评估在没有网络访问的 Docker 容器中进行。在上述提示构建过程中，我们系统地删除了所有识别元数据，如作者姓名和 GitHub 链接。此外，精选阶段选择的 94 个仓库中的大多数是在所评估的 LLM 的主要训练截止期之后创建的。

II-C 黑盒差异评估

为了在不依赖预定义结构脚手架或内部实现的情况下评估智能体生成的仓库 $R_{test}$，我们设计了基于隔离 Docker 沙箱的黑盒差异评估引擎。该管道包含三个关键阶段：

#### II-C1 环境初始化

对于每个任务，我们为相应的编程语言实例化两个相同的 Docker 容器。我们将冻结的预言机仓库 $R_{oracle}$ 和生成的仓库 $R_{test}$ 分别挂载到它们的容器中。在执行标准包安装命令后，我们捕获工作区的初始状态作为干净快照。这种快照-恢复机制保证了严格的无状态隔离，避免了跨顺序测试的文件系统污染（持久副作用）。我们将这些可恢复的基础环境表示为 $E_{oracle}$ 和 $E_{test}$。

#### II-C2 差异执行

对于模糊测试阶段生成的每个测试用例 $t$，我们在 $E_{oracle}$ 和 $E_{test}$ 中独立执行它。我们的引擎监控执行过程，并将 resulting 状态转换记录为一个元组 $Exec(R,t,E) \rightarrow \langle C_{ret}, \Delta S, O_{std} \rangle$，其中 $C_{ret}$ 是返回码，$\Delta S$ 表示原始系统级副作用（例如文件系统修改），$O_{std}$ 是标准输出流。

#### II-C3 多层等价评估

基于捕获的执行状态，我们使用严格的渐进式三步流程评估功能等价性。仅当测试用例通过所有三个连续检查时，才被视为成功：

1. 执行可靠性 ($M_{code}$)：我们严格评估预言机成功执行而没有错误（$C_{ret}^{oracle}=0$）的有效功能路径。我们首先验证智能体生成的工具是否也能成功完成而没有抛出未处理的异常（$C_{ret}^{test}=0$）。我们将此度量的通过率表示为 Exec。

2. 副作用通过 ($M_{diff}$)：许多 CLI 工具从根本上通过与文件系统交互来操作。通过比较执行前后的工作区状态，我们提取有效的文件系统更改 $\Delta S'$（过滤掉琐碎的伪影如隐藏缓存）。仅当测试用例执行没有错误且其有效副作用与预言机完美匹配（$\Delta S'_{oracle}=\Delta S'_{test}$）时，测试用例才通过此度量，以下称为 SP。这防止了工具运行成功但未执行实际操作的情况下的误报。

3. 行为等价性 ($M_{out}$)：只有通过 Exec 和 SP 检查的测试用例才会进行标准输出比较（$O_{std}^{test}$ 对比 $O_{std}^{oracle}$）。因为功能正确的 CLI 工具可能天生以多样的格式或风格布局呈现其输出，所以严格的字符串匹配通常是不够的。因此，我们实施了三种互补的匹配标准（EM、FM 和 SM），以确保在不同语义层面进行全面和公平的评估：

• 精确匹配 (EM) 在基本空白规范化后要求严格的字符串等价。

• 模糊匹配 (FM) 计算归一化的 Levenshtein 编辑距离，并在字符串相似度超过阈值 $\tau$ 时记录匹配，从而允许轻微的格式差异。

• 语义匹配 (SM) 使用 LLM 作为裁判（GPT-5.4）来验证核心信息载荷是否等价，同时忽略风格差异。为了验证此度量，对 1,000 个输出对的大规模人工标注研究产生了 Cohen's Kappa 系数 $\kappa>0.9$，确认与专家判断的强一致性。两名具有至少 4 年软件工程经验的标注员独立标注每对是否从 CLI 用户的角度语义等价，忽略表面格式差异但要求保留核心信息、错误消息和可观察行为。分歧通过讨论解决。

为了提供所构建基准的清晰概览，表 I 总结了最终 94 个精选任务在三个关键维度上的统计分布：任务难度、编程语言和应用领域。我们专注于 Python、JavaScript (Node.js) 和 Go，以提供现代 CLI 开发中广泛使用的解释型和编译型语言的代表性混合。遵循 NL2Repo-Bench [15] 建立的分类法，我们根据预言机的代码行数将任务难度分为三个级别（Easy ≤1500，Medium 1500−4000，Hard ≥4000）。我们还将仓库分为九个不同的真实世界应用场景。如表 I 所示，最终基准保持了高度多样化和平衡的组成，使评估能够反映智能体的通用软件生成能力。

表 I：我们基准的统计分布

III 实验设置

III-A 选定的 LLM 和智能体框架

为了全面评估自主软件生成的最新水平，我们选择了 7 个最先进的 LLM，包括领先的闭源模型和高度能力的开源模型：GPT-5.4、Claude-Sonnet-4.6、DeepSeek-V3.2、Qwen-3.5-plus、GLM-5、MiniMax-M2.5 和 Kimi-k2.5。

为了有效评估这些模型作为软件工程师的能力，我们采用了两个专门为仓库级任务设计的代表性智能体框架：

• OpenHands（带 CodeAct） [18]：一个突出的开源智能体框架，利用 CodeAct 范式，允许 LLM 迭代执行代码、与 bash 终端交互并观察环境反馈。

• Mini-SWE-Agent [19]：流行的 SWE-agent 框架的精简适配，专门优化用于迭代仓库构建和基于终端的调试。

通过在两个框架上评估七个模型，我们为本基准中的 94 个仓库中的每一个进行了总共 14 种不同的智能体配置。

生成设置。 为了模拟真实的自主软件工程场景，我们采用了一种不受约束的、零外部反馈的生成设置。对于每个仓库，智能体提供任务提示和空工作区。它被允许不受限制的对话轮次，在其沙箱内自由探索、编写和执行代码。生成轨迹完全基于智能体自己的终止信号（例如，执行特定的 "exit" 动作）结束，我们的评估引擎不提供中间测试反馈。这种"单次轨迹"范式与我们评估从零到一软件生成的核心目标无缝对齐，其中智能体被 tasked 在单个会话中从头开始架构并交付一个完整的、可运行的工具。

III-B 评估指标和评分机制

为了系统地量化智能体生成仓库 $R_{test}$ 的性能并填充我们的最终评估表，我们计算第 II-C 节中定义的指标的最终分数。

首先，我们计算 Build（全局安装成功率），测量 $R_{test}$ 是否可以使用标准包管理器成功安装。未能通过此基本先决条件的仓库在所有后续评估指标中都被罚为零分。这种零容忍惩罚反映了意图驱动的"氛围编码"范式的最基本要求：如果智能体未能交付结构上有效且可安装的包，则任何下游功能评估都变得毫无意义。因此，Build 指标作为智能体基础仓库规划和环境配置能力的主要指标。

对于成功安装的仓库，我们采用宏观平均聚合策略来计算第 II-C 节中定义的上述指标（Exec、SP、EM、FM 和 SM）的分数。这确保了逻辑较简单的命令模式不会不成比例地主导整体评估。具体而言，让 $C$ 表示给定仓库 $R_{test}$ 的所有识别命令模式的集合。对于每个命令模式 $c \in C$，让 $T_c$ 是其对应的 50 个测试用例套件。我们定义特定命令模式在给定指标 $m \in \{\text{Exec, SP, EM, FM, SM}\}$ 下的通过率为：

$$P_m(c) = \frac{1}{|T_c|} \sum_{t \in T_c} \mathbb{I}_m(t) \quad (1)$$

其中 $\mathbb{I}_m(t) \in \{0,1\}$ 是测试用例 $t$ 是否成功通过指定指标检查的二进制指示器。注意，对于行为指标（EM、FM、SM），$\mathbb{I}_m(t)=1$ 严格要求测试用例已经通过了先决条件副作用一致性门。

仓库 $R_{test}$ 在指标 $m$ 下的最终聚合分数是其所有命令模式的未加权平均值：

$$Score_m(R_{test}) = \frac{1}{|C|} \sum_{c \in C} P_m(c) \quad (2)$$

我们实验结果中报告的最终值代表所有评估仓库的平均 $Score_m$。

III-C 实现细节

为了防止数据污染，我们在生成期间明确禁用智能体沙箱内的网络访问，确保模型无法检索原始仓库实现。此外，我们在所有模型和框架上消除了所有人为约束——如最大迭代限制或 token 预算。生成过程完全是开放式的，允许智能体自主确定软件构建何时完成并自愿终止执行。

对于我们自动化管道中的所有辅助任务——包括迭代模式提取、LLM 导向的模糊测试生成和语义匹配裁判——我们严格使用 GPT-5.4。为了消除生成随机性并确保高度确定性的评估结果，这些辅助 GPT-5.4 API 调用的温度统一设置为零。此外，本工作中 $\tau$ 设置为 0.8。

III-D 研究问题

我们调查以下四个研究问题（RQ）：

• RQ1（整体能力）：最先进的 LLM 在从零到一的 CLI 工具生成中表现如何，不同的智能体框架如何影响其功能正确性？

• RQ2（复杂度影响）：这些模型的自主生成能力如何随项目复杂度的不同程度而扩展或退化？

• RQ3（生成效率）：在不受约束的开放式生成设置下，这些智能体的计算开销和 token 消耗模式是什么？

• RQ4（结构自主性）：在完全结构自由的情况下，智能体生成的软件的仓库级设计与人工编写的预言机有何不同？

IV 实验结果

在本节中，我们展示评估结果以回答我们的四个研究问题。

在深入详细的 RQ 之前，重要的是要理解我们发现的规模和统计可靠性。在现实的单次轨迹设置下（第 III-A 节），七个评估的 LLM 中的每一个都在两个框架上独立生成了 94 个仓库。因为我们的基准利用 LLM 导向的模糊测试为每个命令模式合成恰好 50 个端到端测试用例，所以单个生成的仓库会产生数百个独立的测试实例。因此，后续部分中呈现的宏观平均分数是从每个模型数万次测试执行的巨大分布中得出的。

为了验证在这个庞大数据集上观察到的模型之间的性能差异是可靠的而不仅仅是偶然，我们在通过/失败结果上使用了 McNemar 检验，并结合 Bootstrap 重采样（10,000 次迭代）来估计 95% 置信区间（CI）。我们的基线分析确认，顶级模型的排名在统计上是显著的（$p<0.05$）。这证明它们聚合分数的差异反映了其编码能力的真实变化，而不是单次生成运行的采样噪声，从而为以下研究问题建立了严格的基础。

IV-A RQ1：整体性能和框架影响

表 II：评估的 LLM 在两个智能体框架上的整体性能。最右列和最底行呈现宏观平均值。最佳结果以粗体突出显示。

图 2：七种模型在三种编程语言上的性能比较。雷达图说明了每种模型的不同能力，径向轴表示语义匹配（SM）分数。

为了回答 RQ1，我们在两个不同的智能体框架上评估了七个最先进的 LLM。如表 II 详述，结果显示了一个清晰的性能层次。Kimi-k2.5 成为领先者，实现了最高的平均语义匹配（SM）分数 43.78%，其次是 MiniMax-M2.5（34.59% SM）。中间层由 GPT-5.4、Qwen-3.5-plus 和 GLM-5 组成，SM 分数在 29% 到 31% 左右。关于框架影响，我们观察到一致的趋势：与 OpenHands 相比，模型通常在使用 Mini-SWE-Agent 时获得更高的分数。这表明智能体框架的动作空间和界面设计在从零到一的生成场景中显著影响任务完成。

相反，Claude-Sonnet-4.6 表现出明显较低的性能（平均 10.61% SM），主要在初始 Build 阶段遇到瓶颈。我们注意到，我们的基准严格不提供提交后的测试反馈。在这种设置下，我们观察到 Claude-Sonnet-4.6 中的一种独特行为模式：它经常在编写初始代码后立即结束生成轨迹。例如，在多个 Go 项目中，智能体提交仓库而没有调用标准编译检查如 go build 或 go mod init。因此，这些仓库在我们评估的初始构建检查中失败。相比之下，日志分析显示，像 Kimi-k2.5 这样的模型通常在发出终止信号之前进行更广泛的容器内 Bash 验证。这表明 Build 阶段的性能差距部分由模型在提交前自主验证其代码的倾向差异驱动。

除了单个模型的能力外，我们的渐进式评估漏斗揭示了当前自主工作流程中的根本瓶颈。在所有模型中，从 Build 阶段（平均 76.75%）到执行可靠性（59.32%）存在急剧下降，并且在副作用通过（45.66%）门进一步下降。最终，当通过精确匹配（EM，23.50%）评估时，性能急剧下降。这种大幅下降表明，虽然智能体在许多情况下成功编写了语法正确且可执行的代码，但它们难以完美复制人工预言机的确切字符串输出。然而，在 FM 分数（39.00%）和 SM 分数（29.64%）中观察到的显著恢复验证了我们的方法论设计：智能体经常生成功能正确且语义等价的 CLI 工具，而这些工具被严格的 EM 指标不公平地惩罚。

对编程语言分布的更深入分析（图 2）进一步揭示了当前 LLM 中固有的明显语言偏见。如雷达图所示，几乎所有评估的模型在解释型语言如 Python 和 JavaScript 上表现出更大的覆盖区域，而 Golang 成为一个严重的瓶颈（由收缩的内部绿色多边形表示）。这表明模型经常难以导航 Golang 的严格类型匹配和刚性编译约束，经常生成无法构建的代码。

此外，智能体框架的选择似乎影响生成结果。我们观察到，精简的、以 bash 为中心的 Mini-SWE-Agent 始终比更复杂的 OpenHands 框架获得更高的分数。这表明最小主义界面可能天然更好地与以终端为中心的工作流程对齐。对单个智能体轨迹的仔细检查支持了这一观察。例如，当尝试解决 mol-lang 仓库中的缺失库引用时，OpenHands 智能体经常调用浏览器工具，结果被多页 HTML 淹没，淹没了它们的上下文窗口。相反，Mini-SWE-Agent 直接读取简短的终端 stderr，执行包管理器，并成功继续。

发现 1： 尽管顶级模型展现出有希望的能力，但它们在评估漏斗中的急剧性能下降以及对编译型语言的严重挣扎将最高整体成功率限制在 43.78%。这凸显了端到端、从零到一的软件生成仍然是一个极具挑战性的前沿领域。

IV-B RQ2：任务复杂度的影响

图 3：仓库复杂度与智能体性能之间的相关性。每个散点代表一个单独的测试用例。点的颜色表示难度级别：绿色表示 Easy，橙色表示 Medium，红色表示 Hard。黑色虚线表示 LOESS 趋势线。

为了回答 RQ2，我们调查这些智能体的软件生成能力如何随项目复杂度的不同程度而扩展。图 3 说明了预言机仓库的大小（以代码行数 LOC 衡量）与相应语义匹配（SM）分数之间的关系。直观地说，人们可能期望严格的负相关：随着仓库变大，智能体的性能应该由于扩大的上下文窗口和复杂的依赖解析而单调下降。然而，LOESS 趋势线揭示了一个非单调（U 形）轨迹。

在从 Easy（<<1500 LOC）到 Medium（1500−4000 LOC）仓库的过渡中，我们观察到性能的急剧下降。整体平均 SM 分数从 32.66% 下降到 25.08%，竞争性模型如 GPT-5.4 从 34.60% 暴跌至 21.90%。为了理解这种退化，我们分析了这些仓库的结构特征。我们的数据显示，虽然 Easy 任务主要是扁平的单文件脚本（平均 1.62 个文件），但 Medium 任务需要多文件、跨目录的模块化（平均 2.33 个文件和 1.14 个子目录）。这种结构性飞跃似乎迫使智能体处理复杂的相对导入和跨文件状态管理。分数的急剧下降表明，当前的 LLM 在从局部编码过渡到仓库级架构规划时面临重大困难。

令人惊讶的是，随着 LOC 扩展到 Hard 类别（>>4000 LOC），平均 SM 分数反弹至 28.87%。为了解开这种反直觉现象，我们调查了与大规模仓库相关的上下文丰富性。对我们数据集的定量分析显示，项目的规模与其文档的全面性密切相关：Hard 任务中 README 的平均长度（11,728 个字符）几乎是 Easy 任务（4,501 个字符）的三倍。在我们意图驱动的从零到一生成设置中，这种精心结构的文档提供了高度明确的规范。我们假设这种"规范红利"显著抵消了原始实现难度。虽然智能体可能仍然难以完美地架构大型系统的底层逻辑，但极其丰富和明确的文档可能使它们能够更准确地提取和镜像预期的 CLI 命令模式，从而实现更高的 SM 分数。

发现 2： 智能体性能随仓库复杂度呈现非单调的 U 形趋势。最初的急剧下降凸显了模型在多文件架构规划方面的严重困难。然而，大规模仓库中的性能反弹表明，高度全面、明确的文档显著抵消了原始实现难度，使智能体能够准确地重建语义模式。

IV-C RQ3：智能体成本和生成效率

表 III：每个仓库的生成开销和估计 API 成本，按 LLM 和智能体框架分类。

图 4：不同框架下 LLM 智能体的成本效益分析。散点图说明了任务性能和执行成本之间的权衡。小的半透明点代表单独的任务运行，而大的十字标记表示每个模型的中心。灰色虚线表示整体平均分数和 token 消耗，将空间分为四个象限。

为了回答 RQ3，我们通过将其语义匹配分数与其总 token 消耗作图来分析不同 LLM 的成本效益，如图 4 所示。虚线表示平均分数和 token 使用量，将性能空间分为四个象限。理想情况下，高度能力的智能体应落入左上象限，以低于平均的 token 成本实现高于平均的分数。

在两个框架中，GPT-5.4 和 GLM-5 始终表现出这种最优行为。特别是 GPT-5.4 成为一个高效的引擎。在 Mini-SWE-Agent 框架中，它实现了平均 SM 分数 31.82%，同时仅需 2.33 个交互步骤，每个任务消耗少于 21K token（成本仅为 0.09 美元）。这表明 GPT-5.4 拥有强大的零样本推理能力，生成准确的 CLI 模式而不依赖广泛的、token 密集的试错循环。同样，Kimi-k2.5 作为整体最佳表现者脱颖而出。它在 Mini-SWE-Agent 框架中实现了最高的 SM 分数（51.16%），token 足迹适中（约 375.8K token 和 49.38 步），有效地占据了左上象限。

相反，散点图的右半部分揭示了智能体轨迹中的"收益递减"现象。像 Minimax-M2.5 和 DeepSeek-V3.2 这样的模型经常落入右侧象限。例如，在 OpenHands 中，Minimax-M2.5 消耗惊人的平均 421 万 token，每个任务进行 88.02 步，但未能实现顶级性能（SM 分数仅为 30.11%）。这种极端的 token 消耗和交互计数通常表明"震荡"——智能体陷入重复调试循环或生成过于冗长、无用的命令而没有在实际任务解决方面取得实际进展的情况。在另一个极端，Claude-Sonnet-4.6 始终占据左下象限。其 remarkably 低的 token 使用量（在 Mini-SWE-Agent 中平均约 92K token，在 OpenHands 中平均 197K）和最小的交互计数（分别平均 7.58 和 7.09 步），加上最低的语义分数，暗示了一种独特的"快速失败"倾向。如前所述，这种行为可能源于 Claude 缺乏广泛的自我验证和调试循环；它倾向于产生初始解决方案并过早终止轨迹，而不是从事从零到一软件构建所需的迭代故障排除。

发现 3： 更高的 token 消耗并不等同于更好的任务解决。虽然某些模型由于昂贵的调试循环而经历收益递减，但像 GPT-5.4 这样的高效模型以最少的 token 和交互步骤实现了极具竞争力的性能，展示了卓越的成本效益。

IV-D RQ4：结构自主性和多样性

图 5：人工预言机和各种 LLM 生成的文件总数分布。箱线图结合叠加的带状图显示了中位数和四分位数分布，同时将单独的任务运行突出显示为半透明点。y 轴截断为 20 个文件。极端异常值用红星标注，最大值标注在顶部。

为了回答 RQ4，我们调查不同的 LLM 在被授予完全结构自主权时如何组织仓库结构和管理工作区复杂性。图 5 将智能体生成仓库的文件计数分布与人工 Oracle 进行比较。

人工模块化与智能体单体偏好。

明显的趋势是人工开发人员和自主智能体之间在结构设计上的分歧。人工 Oracle 表现出广泛的分布，反映了标准的软件工程实践，其中代码被模块化为不同的组件。相比之下，所有评估的 LLM 都表现出对单体结构的强烈偏好，其中位数紧密聚集在 1 到 3 个文件之间。这表明 LLM 之间共享的行为策略：将逻辑集中到单个或很少的文件中。从智能体的角度来看，这种单体方法似乎是减少跨文件依赖问题（例如 ImportError）并使整个系统状态在模型有限的上下文窗口内容易访问的实际适应。

工作区管理和调试行为。

除了中位数值外，最大文件计数（用红星标注）揭示了生成过程中的多样化工作区管理行为。像 GPT-5.4 和 Claude-Sonnet-4.6 这样的模型在所有任务中保持严格低的文件计数（最大值分别为 16 和 10）。相反，其他一些模型（例如 DeepSeek-V3.2、Qwen-3.5-plus 和 MiniMax-M2.5）偶尔表现出极端的文件蔓延，生成数百甚至数千个文件（例如，最多 1,629 个文件）。在检查这些仓库时，我们发现这种极端蔓延并不代表手动编写的源代码，而是直接在工区内包含 massive 本地依赖目录（例如 node_modules 或本地虚拟环境）。这表明，虽然某些模型在全局或目标目录外仔细管理依赖项，但其他模型则在其执行过程中诉诸 heavy 本地安装。此外，这种行为 heavily 受环境影响。例如，GLM-5 和 Kimi-k2.5 在 OpenHands 下保持紧凑的工作区，但在 Mini-SWE-Agent 下表现出严重的依赖蔓延，这表明底层框架的提示结构和反馈机制影响智能体的文件系统管理。有趣的是，我们还观察到相当比例的案例生成了恰好零个有效文件[1]，特别是在高自由度的 OpenHands 框架内。

发现 4： 虽然人工开发人员自然采用模块化结构，但 LLM 偏好单体设计（通常 1-3 个文件）以简化上下文管理。此外，模型展现出截然不同的工作区管理策略，从严格的原地编辑到 massive 本地依赖蔓延，这种行为也对所选框架高度敏感。

V 讨论

图 6：CLI 工具开发中 LLM 智能体的代表性失败案例。

V-A 案例研究：分阶段失败分析

阶段 1：构建失败（23.3% 的轨迹）。 近四分之一的运行未能产生结构上可安装的包。图 6 (a) 展示了一种普遍的由文本到文件偏见驱动的"构建失败"。在此 Go 项目场景中，智能体生成了正确的逻辑，但尝试手动将依赖项硬编码到 go.mod 中，而不是执行标准命令如 go mod tidy。缺乏"环境直觉"，智能体默认进行静态文本操作，而不是与动态工具链交互。

阶段 2：执行失败（13.2% 的轨迹）。 在成功安装的仓库中，13.2% 在执行期间完全崩溃。图 6 (b) 说明了一个灾难性的工作区误管理场景。在尝试构建 Python 工具时，智能体将自己困在递归目录生成循环中，创建了深度嵌套的 build/lib/ 结构。这种混乱的文件系统状态破坏了包的入口点，凸显了在诊断损坏环境时的关键空间盲区。

阶段 3：行为不匹配（6.7% 的轨迹）。 也许最具欺骗性的失败模式发生在工具完美执行（退出码 0）但未产生系统级副作用（SM=0）时。如图 6 (c) 所示，智能体生成的删除器工具运行没有崩溃，但未能删除目标文件。这种静默失败坚定地验证了我们多维评估方法的必要性，证明"运行而不崩溃"不等于任务完成。

V-B 发现的启示

研究人员： 我们的研究表明，评估自主智能体需要超越静态代码分析。具体而言：

• 评估范式。 精确匹配、语义匹配和执行成功之间的显著差距证明，传统基于字符串的评估对于智能体任务是不够的。端到端行为验证必须成为新的标准。因此，必须提出新的等价度量和方法，以准确捕获实际的软件行为。

• 智能体架构。 "震荡"和灾难性工作区误管理的普遍问题凸显了结构性差距。未来的研究必须为智能体配备更好的文件系统空间意识和自我反思机制，以摆脱无成效的调试循环。

开发人员： 智能体软件生成是一种新范式，在代码结构和质量方面引入了独特的挑战。基于我们的发现，我们为使用 LLM 智能体的开发人员得出以下见解和注意事项：

• 结构脚手架。 由于智能体普遍偏好单体设计并难以处理复杂的依赖解析，开发人员应提供明确的结构脚手架或强制使用标准化的 CLI 框架（例如 Click 或 Cobra）来指导生成。

• 防御性编程。 虽然由于其精简的、面向目标的编码风格，智能体生成的工具通常比人工基准执行得更快，但它们严重缺乏防御性编程实践。开发人员必须将这些输出视为功能原型，通过 robust 错误处理 actively 加强它们。

• 定制化的"氛围编码"。 开发人员必须采用定制化的交互策略：为快速交付模型（例如 Claude）强制明确的自测试步骤，同时主动监控验证驱动的智能体（例如 Kimi）以防止无限循环。

V-C 对有效性的威胁

• 数据集规模和选择。 我们的数据集由 94 个精选任务实例组成。这个规模代表了一种深思熟虑的权衡：我们优先选择经过严格清理和手动检查的数据集，而不是更大的自动化收集，以确保高质量和无歧义的任务规范。

• 执行可靠性标准。 关于执行可靠性指标（$M_{code}$），如果预言机以零退出码成功执行，我们的管道严格将生成工具的非零退出码视为失败。在实践中，非零退出码可能并不总是表示完全的运行时崩溃，而是自定义警告或特定状态。然而，这种行为违反了常见的 POSIX 设计原则 [20]，其中成功操作应返回零。强制执行这种严格对齐为差异测试提供了客观和标准化的基线。

• 评估设置。 我们的评估采用不受约束的、零外部反馈的设置，其中智能体在单次轨迹中交付最终仓库。虽然结合外部测试反馈（例如，将错误日志反馈给智能体）以实现多轮迭代调试是自动程序修复的一个非常有前景的方向，但它超出了本文的范围，本文专注于评估基线从零到一的构建能力。未来版本旨在扩大数据集规模并探索这些反馈驱动的生成范式。

VI 相关工作

VI-A 软件工程智能体

LLM 在软件工程中的应用已从静态代码补全发展为自主的、与环境交互的智能体 [21, 6, 5, 22]。早期的多智能体框架，如 ChatDev [23] 和 MetaGPT [24]，利用角色扮演和标准化操作程序（SOP）通过模拟协作来编排软件设计。为了实现真实的仓库交互，引入了智能体计算机接口（ACI）。像 SWE-agent [25] 和 OpenHands [18] 这样的框架允许 LLM 直接与命令行终端交互、执行测试并在隔离沙箱内迭代调试。最近，像 Mini-SWE-agent [19] 这样的极简脚手架表明，最先进的模型只需要很少的脚手架就能实现高成功率，主要依赖它们的原生推理能力。

VI-B 软件生成和智能体评估

随着智能体能力的进步，评估方法已转向复杂系统。早期基准如 HumanEval [12] 和 MBPP [13] 专注于静态的函数级合成，但受到数据污染和缺乏仓库上下文的困扰。后续努力通过动态问题 sourced（LiveCodeBench [26]）或复杂 API 集成（BigCodeBench [27]）解决了这个问题。对于系统级任务，SWE-bench [14] 通过评估 GitHub 问题的补丁生成为软件维护建立了标准，而 OSWorld [28] 和 Terminal-Bench [29] 评估实时操作系统中的多步命令执行。

然而，评估从零到一的软件生成仍然是一个关键挑战。最近的工作如 Commit0 [16] 跟踪智能体逐 commit 重建仓库的能力。虽然它扩展到更大的仓库，但 Commit0 提供预先存在的骨架代码，并通过刚性静态分析和预定义单元测试评估正确性。NL2Repo-Bench [15] 从自然语言探索仓库级生成，但它也从根本上依赖白盒单元测试。这种 rigid 方法严重惩罚功能正确但结构多样化的解决方案。

并行地，Terminal-Bench [29] 和 OSWorld [28] 在实时操作系统中评估多步 bash 命令执行。虽然它们测试智能体与终端的交互（例如，导航目录或安装包），但它们既不专注于从头开始编译可交付的软件实体，也不严格验证 resulting 系统级文件副作用。相比之下，CLI-Tool-Bench 通过要求从空工作区进行完整仓库构建并采用动态黑盒差异测试来严格验证系统副作用和输出等价性，弥合了这些差距。

CLI-Tool-Bench 桥接了这些范式，将黑盒差异测试扩展到仓库级别，以在没有结构约束的情况下严格评估端到端软件生成。

VII 结论

我们引入了 CLI-Tool-Bench，这是一种新颖的基准测试，用于评估从头开始的端到端软件生成。广泛的评估显示最大成功率仅为 43.8%，凸显了实质性的改进空间。此外，我们的分析揭示了关键见解：性能随复杂度呈现 U 形趋势，更高的 token 消耗不能保证更好的结果，并且智能体普遍偏好单体设计而非模块化设计以简化上下文管理。

目前，我们专注于 CLI。然而，我们的核心评估方法——与结构无关的黑盒差异测试——具有高度通用性。在未来的工作中，我们计划将此方法扩展到更广泛的软件领域，如 Web 服务、API 后端和 GUI 应用程序，进一步推进完全自主软件创建的评估。

VIII 数据可用性

所有脚本、数据集和原始数据可在 https://github.com/kinesiatricssxilm14/CLI-Tool-Bench 获取。

署名与许可

本文译文由 智测团队 翻译并发布。原文 arXiv:2604.06742 以 CC BY-SA 4.0 许可发布（见 https://arxiv.org/abs/2604.06742）。本译文同样以 CC BY-SA 4.0 许可分发。

CC BY-SA 4.0: https://creativecommons.org/licenses/by-sa/4.0/