LongCLI-Bench：面向命令行长时程智能体编程的初步基准与研究 LongCLI-Bench: A Preliminary Benchmark and Study for Long-horizon Agentic Programming in Command-Line Interfaces
提出长时程CLI编程基准，揭示当前最强智能体通过率不足20%，人机协作可显著提升性能。
前置知识
智能体编程（Agentic Programming）
智能体编程是指AI系统通过命令行接口（CLI）自主执行复杂的软件工程任务，包括代码编写、环境配置、测试调试等。与传统的代码补全不同，智能体编程需要AI像人类工程师一样规划架构、导航代码仓库、管理开发环境，并基于环境反馈执行多步工作流。这种能力依赖于LLM的推理能力与工具使用的结合，如SWE-agent、OpenHands、Claude Code和Codex等系统就是典型代表。
本文评估的核心对象就是这类智能体在长时程任务上的表现，理解智能体编程的概念是理解本文评测目标的前提。
Fail→Pass（F2P）和 Pass→Pass（P2P）测试协议
这是本文提出的双集测试协议。F2P测试验证智能体是否成功实现了新的需求——即原本失败的测试在执行后变为通过。P2P测试则验证智能体的修改是否破坏了已有功能——即原本通过的测试在执行后仍然通过，用于检测回归问题。这种双集设计能同时评估需求实现和回归避免两个维度。
这是本文评测框架的核心设计，理解这一协议才能理解为什么本文能比现有基准提供更精细的评估。
长时程任务（Long-horizon Tasks）
长时程任务是指需要执行大量连续步骤、存在复杂依赖关系的工程任务。与短时程的代码片段生成不同，长时程任务平均涉及104个文件、15000+行代码，专家完成时间超过1000分钟。任务中后续步骤依赖于前面步骤的输出，形成完整的依赖链。这要求智能体具备长期环境上下文维护和复杂依赖工作流导航能力。
本文的核心论点就是现有基准缺乏对长时程任务的评估，而长时程任务恰恰是真实软件工程的常态。
Step-level评分
Step-level评分是本文引入的细粒度评估指标，用于衡量任务完成的百分比程度，而非简单的二值通过/失败。通过将任务需求分解为子步骤并逐一评估，Step-level评分能精确揭示工作流在哪个环节断裂。例如一个任务可能完成了80%的子步骤但最终整体失败，这种部分完成的信息在传统二值评估中完全丢失。
这一指标使本文能够发现多数任务在不到30%完成度就停滞这一关键发现，是诊断智能体失败模式的核心工具。
数据污染（Data Contamination）
数据污染是指评测基准中的任务数据在模型训练阶段被泄露或记忆。许多现有基准如SWE-bench直接从GitHub抓取issue和代码，这些公开数据很可能已被模型学习过，导致评测结果虚高。本文通过从CS课程作业和真实工作流手动构造任务来规避这一问题，确保评测的公正性。
数据污染是本文选择非GitHub数据源的直接动机，理解这一点才能理解本文基准设计的合理性。
研究动机
现有的代码智能体评测基准存在三大关键缺陷，严重限制了对真实软件工程能力的评估。首先，任务时程过短：经典基准如HumanEval和MBPP仅评估孤立代码片段中的算法逻辑，SWE-bench虽然扩展到仓库级别但仍局限于短任务，Terminal-Bench@2平均仅有0.69个文件和227.7行代码。相比之下，真实软件工程任务本质上是长时程的，涉及大量文件和连续的依赖关系。其次，数据污染风险严重：大多数基准从GitHub仓库抓取任务，这些公开数据很可能已被模型训练时学习过，导致评测结果失真。第三，评估粒度不足：现有基准仅提供二值通过/失败反馈，无法诊断智能体在复杂工作流中的具体失败点，也无法衡量部分完成的进展。Terminal-Bench虽然提供了交互式沙盒环境，但其任务仍然简单、时程短，且缺乏细粒度评估来提供有效反馈或诊断失败模式。
本文的目标是本文旨在构建一个全面的评测基准LongCLI-Bench，专门用于评估智能体在长时程、真实CLI环境中的编程能力。具体目标包括：设计20个高质量的长时程任务，覆盖从零构建、功能添加、Bug修复和重构四大工程类别；提出双集测试协议（F2P和P2P）同时评估需求实现和回归避免；引入Step-level细粒度评分来精确定位执行失败点；通过严格的构造流程控制数据污染风险。最终通过大规模实验揭示当前智能体系统的真实能力边界，并探索人机协作对性能的提升效果。
与已有工作不同的是，本文的独特切入角度在于同时解决任务复杂度和评估精细度两个维度的不足。不同于现有基准聚焦于单一类别任务（如仅评估GitHub issue修复），LongCLI-Bench覆盖了软件开发生命周期的四个核心阶段。更重要的是，本文不仅关注最终结果（通过/失败），还通过Step-level评分关注过程质量——即使最终失败，也能知道智能体完成了多少工作、在哪里崩溃。此外，本文从CS课程作业和真实工作流构造任务而非GitHub抓取，在源头上控制了数据污染。这种复杂任务+精细评估+污染控制的三维设计是本文区别于所有已有工作的核心创新。
核心方法
LongCLI-Bench的整体方法论可以分为数据构造、任务组成和评测流程三个层次。在直觉层面，本文认为要真正评估智能体的软件工程能力，就需要构造足够复杂、时程足够长的任务，同时提供足够精细的评估来诊断失败原因。技术路线是：首先从1000+个CS课程作业和50个真实工作流中筛选出20个高质量任务，每个任务包含初始仓库、需求文档、隔离环境、人类解答仓库和测试套件；然后通过双集测试协议（F2P和P2P）和Step-level评分进行细粒度评估。整个构造流程采用并行方法同时构建解答和测试，并通过严格的双集验证机制和迭代优化循环确保基准质量。
本文的核心创新是双集测试协议+Step-level评分的组合设计。与已有基准的本质区别在于：SWE-bench等基准只评估需求是否被满足（类似F2P），但忽略了修改是否破坏了已有功能；而LongCLI-Bench的P2P测试专门检测回归问题，这对于长时程任务至关重要——智能体在处理复杂需求时经常顾此失彼。Step-level评分则突破了二值评估的限制，能够精确量化任务完成百分比，揭示失败集中在早期阶段这一关键发现。另一个重要创新是通过CS课程作业（而非GitHub）构造任务，从根本上降低了数据污染风险。此外，测试脚本仅基于需求文档编写而非参考解答仓库，避免了将实现细节烘焙进测试中。
方法步骤详情
LongCLI-Bench的构造和评测流程包含以下关键步骤：（1）数据收集与筛选：从108门课程收集958个CS作业和50个真实工作流，用Codex执行每个作业并人工评估结果，过滤掉过于简单或难以评估的任务，最终保留20个高质量任务。（2）需求文档编写：对CS作业部分改写原始描述（替换变量名、函数名和背景故事以降低污染风险），对真实工作流则完全手工编写需求。（3）环境和解答代码库构建：在Docker容器中并行构建执行环境和解答代码库，从基础Docker镜像开始迭代求解任务，记录依赖项。最终输出是固化的Dockerfile（基础环境）和人类解答路径（解答仓库）。（4）测试套件设计：仅基于需求文档编写测试脚本（不参考解答仓库），设计F2P测试集验证需求完成度和P2P测试集检测回归，对无预定义测试的任务人工分解需求为子步骤并编写评估脚本。（5）验证与质量控制：采用严格的迭代闭环验证——F2P测试在初始仓库上必须失败、在解答仓库上必须通过，P2P测试在两者上都必须通过。若三次迭代后仍不满足条件则丢弃该任务。每个任务还需经过专家最终审查。（6）评测执行：在隔离Docker环境中初始化，智能体接收需求文档后自主规划和执行，完成后执行测试套件，评分解析器聚合结果计算通过率和Step-level分数。
技术新颖性
本文的技术新颖性体现在多个层面。首先，在评测协议设计上，F2P+P2P双集测试是首次在长时程CLI基准中系统性地评估回归避免，而不仅仅是需求实现。P2P测试发现平均P2P Step Score大于98%但P2P通过率仅为70%-88.3%，说明即使整体回归率低，但在执行复杂编辑时仍有12%-30%的概率引入回归——这种细微差别只有双集设计才能捕捉。其次，Step-level评分在CLI基准中是首创，它将需求分解为子步骤逐一评估，能够精确揭示多数任务在小于30%完成度就停滞和失败集中在早期阶段等关键洞察。第三，在数据构造方法上，本文采用CS课程作业+真实工作流的双源策略而非GitHub抓取，需求文档的改写策略（替换具体名称和背景故事）既降低了污染风险又增强了可读性。第四，测试脚本仅基于需求文档编写的原则避免了实现偏见，这在现有基准中几乎没有被采用。
实验结果
本文在LongCLI-Bench上对9个智能体-模型组合进行了大规模实验，得出了一系列重要发现。首先，所有智能体的通过率均低于20%：最强的Claude Code（Claude-Opus-4.6）仅达到16.7%的通过率，Codex（GPT-5.3-Codex）为15.0%，OpenHands框架下最好的Qwen3-235B-A22B仅为6.7%。这表明长时程CLI任务对当前最先进的智能体仍然极具挑战性。Pass@3（三次独立运行中至少一次通过的比例）最高为25.0%（Claude-Opus-4.6），说明稳定性也不理想。Step-level分析揭示了失败的根本原因：Step Score分布显示[0,30)分段的任务比例最高，所有智能体均超过40%，OpenHands甚至高达58%-65%。这意味着多数任务在起步阶段就遭遇严重困难。商业系统（Codex和Claude Code）在F2P Step Score上显著优于开源框架（44.1%-50.7% vs 25.3%-28.9%），说明通用框架在处理复杂工程任务时缺乏针对性优化。P2P测试结果有趣：平均P2P Step Score都很高（>98%），但P2P通过率仅70%-88.3%，表明智能体在执行非平凡编辑时存在回归风险。DeepSeek-V3.1在OpenHands下P2P通过率最高（88.3%），可能因为其较低的执行能力（F2P Score 25.3%）限制了修改范围，减少了出错表面。在多轮自纠正实验中，T1到T2轮有显著提升（如Claude-Opus-4.6从16.7%提升到40.0%），但T2到T3轮改善边际递减。P2P通过率在后期轮次可能下降（如GPT-5.1-Codex-Max从T2的85%降到T3的80%），说明扩大修改范围增加了回归风险。人机协作实验表明，计划注入将Claude-Opus-4.6的通过率从16.7%（基础）提升到58.3%，交互式指导进一步提升F2P Score，两者结合达到61.7%通过率和69.3% F2P Score，证明人机协作的巨大潜力。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| LongCLI-Bench 整体（20个长时程任务） | Pass Rate (%) | Claude-Opus-4.6: 16.7%, GPT-5.3-Codex: 15.0% | OpenHands + DeepSeek-V3.1: 5.0% | 商业系统比开源框架高约3倍 |
| F2P Step Score（需求完成度） | Step Score (%) | Claude-Opus-4.6: 50.7%, GPT-5.3-Codex: 44.1% | OpenHands + Qwen3-235B-A22B: 28.9% | 商业系统提升55%-75% |
| P2P Pass Rate（回归避免） | Pass Rate (%) | Claude-Opus-4.6: 78.3%, GPT-5.3-Codex: 86.7% | Claude-Sonnet-4.5: 70.0% | GPT-5.3-Codex提升23.9% |
| 人机协作（Plan + Interactive） | Pass Rate (%) | Claude-Opus-4.6: 61.7%, GPT-5.3-Codex: 50.0% | 基础模式：Claude-Opus-4.6: 16.7%, GPT-5.3-Codex: 15.0% | Claude-Opus-4.6提升270%, GPT-5.3-Codex提升233% |
局限与改进
作者坦诚地指出了多项局限性。首先，任务创建需要巨大的人工投入：每个任务平均需要40小时完成，包括编写需求文档、构建解答路径、设置测试环境和编写测试脚本。这导致数据集规模较小（仅20个任务），可能影响统计显著性和泛化性。其次，评估指标尚不全面：Step-level评分虽然提供了细粒度洞察，但未能全面评估代码质量或效率等维度。作者指出未来版本可加入更多指标。从个人观察来看，本文的实验设置存在一些值得注意的点：所有结果取三次运行的平均值，但对于通过率本身就很低的任务（<20%），三次运行的方差可能较大，统计可靠性需要审慎解读。此外，人机协作实验中的'人类'是论文作者本身，他们对任务有深入了解，这可能导致人机协作效果被高估——普通用户可能无法提供同样高质量的指导。评测框架目前仅支持Docker环境，对于某些特定的系统级任务可能存在环境限制。
独立分析的弱点
本文存在几个值得深入分析的弱点。第一，任务规模过小：仅20个任务虽然保证了质量，但统计上难以得出可靠结论，且任务的代表性可能不足——20个任务是否能充分覆盖6个领域和4个工程类别的各种组合？建议扩展到至少50-100个任务，并通过统计功效分析验证结论的可靠性。第二，自纠正实验的设计存在局限：当前实验仅进行3轮自纠正，且使用测试反馈作为信号。对于长时程任务，可能需要更复杂的反馈机制（如中间状态验证、部分结果缓存）才能有效提升性能。第三，人机协作实验中人类角色的标准化不足：不同人类指导者的水平差异可能很大，实验未控制这一变量。建议引入标准化的人类干预协议或使用多个独立人类指导者以提高结果的可靠性。第四，任务来源偏重CS课程作业（958个中筛选），真实工作流仅50个且完全手工构造，可能导致基准偏向学术场景而非工业实践。第五，Step-level评分虽然精细，但其可靠性依赖于需求分解的合理性——如何确保不同任务的需求分解粒度一致是一个未解决的问题。
未来方向
作者提出了明确的未来方向：与其单纯追求智能体的自主规划和执行能力，未来研究应重点关注协同人机工作流的开发。基于本文成果，可以延伸出多个研究方向：（1）自适应规划机制——根据Step-level反馈动态调整策略而非简单重试，避免重复循环这一主要失败模式；（2）环境感知验证——开发更强的环境状态验证能力，解决环境相关问题被误诊为代码逻辑缺陷的问题；（3）长时程上下文维护——研究如何在长执行链中保持一致性，避免后期遗忘早期约束；（4）渐进式人机协作——设计更智能的干预请求机制，让智能体在真正需要帮助时才请求人类介入，而非被动等待或盲目求助；（5）基准扩展——将LongCLI-Bench扩展到更多任务和领域，特别是工业级的真实工作流。此外，Step-level评分可以进一步发展为诊断性评估，不仅告诉你失败在哪里，还分析为什么失败（规划不足、执行错误、环境误判等）。
复现评估
本文在可复现性方面做得较好。代码和项目页面已在GitHub公开（https://github.com/finyorko/longcli-bench），包括评测框架的实现。任务的构造流程描述详细，包括数据来源、筛选标准和验证条件。评测在Docker隔离环境中执行，确保了环境一致性。但存在一些复现挑战：每个任务需要约40小时的人工投入来创建，完全复现基准的构造过程需要大量人力资源。商业智能体（Codex和Claude Code）的实验需要API访问权限和相应费用，开源框架OpenHands的实验则需要大量GPU算力来运行大模型。评测结果取三次运行平均值，原始运行数据是否公开未明确说明。建议作者发布每个任务的详细构造日志和所有运行的原始结果，以支持后续研究的完全复现。
论文图表