LoopsBench：当Coding Agent开始长期工作时，我们会重新评价它吗？

Coding Agent 正在进入一个新的阶段。 过去，我们通常让 Agent 修复一个 bug、完成一个 issue，或者实现一个相对独立的功能。围绕这类任务，SWE-bench 及其后续工作已经建立了相对成熟的评测范式：给定代码仓库和需求，让 Agent 修改代码，最终通过测试判断任务是否解决。 但随着 Coding Agent 开始支持持续执行、Goal Mode、动态工作流以及更复杂的任务编排，如何评测更长时间尺度上的 Agent 执行过程，也逐渐成为一个值得关注的问题： 当 Agent 不再只解决一个局部问题，而是要持续完成一组前后依赖的软件开发任务；当关注点从 Harness 内部的工具交互进一步扩展到外层的持续执行与任务编排，我们应该怎样评测它？ 近日， 微软、南京大学等机构的研究人员提出了 LoopsBench ，这是一个面向 long-horizon software engineering 的 Coding Agent Benchmark，关注 Agent 能否在长时间执行中持续维护计划、推进依赖任务、保留已经完成的工作，并控制后续修改产生的回归。 论文认为，随着 Coding Agent 从一次性的工具调用逐渐走向持续的软件开发系统，Agent 基础设施的研究重点也正在从 Harness Engineering 向 Loop Engineering 扩展。Harness 解决的是模型如何访问代码、Shell、编辑器和测试环境，而 Loop 进一步决定：Agent 如何跨越更长的时间尺度组织工作，如何维护状态，以及一次执行结束之后如何继续推进。 论文：https://arxiv.org/abs/2608.00267 代码：https://github.com/microsoft/Loopsbench 项目主页：https://loopsbench.ai 从最终结果评测，到持续执行评测 现有 Coding Agent Benchmark 的一个共同特点，是任务通常以一个相对完整的最终目标出现。 Agent 获得一个 issue 或 feature specification，随后自由探索仓库、修改代码，评测器最终查看测试是否通过。 这个范式对于衡量 issue resolution 能力非常有效，但对于越来越长的软件开发任务，仅观察最终结果可能不足以完整刻画执行过程。 考虑一个典型的软件开发过程： 一个功能可能首先依赖某个基础数据结构，随后需要建立接口，再由上层模块调用这个接口，最后才能完成 CLI、异常处理以及系统级集成。后面的任务不仅依赖前面的任务，而且 Agent 在修改后续模块时，还必须保证已经完成的功能没有被破坏。 如果只在最后运行一次测试，我们能够知道最终代码是否正确，却很难进一步了解： Agent 是否识别了任务之间的依赖关系？它是否沿着合理的软件开发顺序推进？它曾经完成过哪些功能？这些功能后来是否发生了 Regression？Agent 是持续稳定地向前推进，还是不断在不同子任务之间切换？ 这正是 LoopsBench 希望补充的评测维度： 对于长周期 Coding Agent，仅观察 terminal outcome 可能不足以完整刻画其执行过程，还需要进一步观察中间开发单元、持续累积的工程义务以及 Agent 的执行顺序。 LoopsBench 的核心抽象：把软件任务表示成 Dependency DAG LoopsBench 的一个核心设计，是改变软件任务在 Benchmark 中的表示方式。 传统 Benchmark 通常把一个任务表示成一个整体需求，而 LoopsBench 将一个长周期软件任务拆分成多个可以独立验证的 Development Unit ，再恢复这些 Development Unit 之间具有可验证证据支持的前置依赖关系。最终，一个任务被表示为一张 Dependency DAG 。 DAG 中的节点是来自原始开发过程的实际工程单元；边则表示后一个开发单元对前一个开发单元存在明确的前置依赖。 例如，一个后续模块调用了前一个单元中新增加的 API，那么两者之间存在明确的 producer-consumer dependency；如果后一个阶段扩展了此前定义的 schema、interface 或 subclass，也会形成相应的前置关系。 但是，这张 DAG 并不是在宣称 “真实的软件开发只有一种正确顺序”，更像是一个 evaluation contract 。 只要 Agent 采用的执行顺序符合依赖关系，LoopsBench 并不会要求它重现开发者历史上的完整顺序。Agent 可以并行完成相互独立的节点，也可以重新修改已经完成的实现。 从 LoopsBench 的评测定义来看，一个 Development Unit 在其前置条件满足之后，才进入可正常推进和评测的状态。 因此，Dependency DAG 给 LoopsBench 提供了一个过去 Benchmark 较难获得的参照系：我们不仅知道最终有多少功能完成，还能够进一步观察 Agent 究竟沿着软件依赖结构推进到了哪里，也就是在拓扑结构上走到了哪一层。 这些长周期任务从哪里来？ 为了让 Dependency DAG 尽可能对应真实的软件开发过程，而不是由模型主观生成，LoopsBench 从真实的软件演化材料中构造任务。 论文最终构建并发布 112 个 long-horizon tasks，包含超过 5,300 个 Development Units，覆盖 8 种编程语言和 9 个软件领域 ；在该 Benchmark 中，任务依赖深度的中位数为 6。 这些任务来自三类软件演化过程。 第一类 是大学课程中的大型编程实验。一个完整的课程 Project 通常天然包含多个阶段和模块，学生需要在数周甚至数月中逐步完成，因此能够提供相对清晰的长期开发结构。 第二类 来自真实开源项目中的连续 Pull Request。这里的重点并不是随机抽取几个 PR，而是重建一段连续的软件演化过程。当早期 PR 引入新的接口、模块或数据结构，而后续 PR 建立在这些修改之上时，它们便形成具有明确证据支持的工程依赖。 第三类 来自 Research Evolution。研究代码也经常沿着方法演化逐步发展：后续论文可能继承前一项工作的核心实现，再加入新的算法组件或系统设计。LoopsBench 通过具有实际方法继承关系的论文演化链，重建这类长期的软件变化过程。 最终的 112 个任务由 57 个 Course Labs、29 个 PR Sequences 和 26 个 Research Evolutions 构成。 从真实开发材料到可执行 Benchmark 论文的另一个关键部分，是如何把这些原始的软件开发材料转化成一个可复现、可执行的 Coding Agent Benchmark。 PR history 中包含大量和任务目标无关的修改；课程实验的要求可能分散在 handout、starter code 和测试中；研究代码的变化则可能同时涉及算法、实验和工程配置。 因此，LoopsBench 首先需要把