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 首先需要把不同来源的材料统一成 Development Units，然后恢复它们之间具有明确证据支持的 dependency relation。

在 DAG 构建中，论文采取了相对保守的策略：只有能够在原始软件材料中找到明确证据的依赖关系才进入图中。例如代码之间真实存在 symbol-level 的调用、导入和继承关系，或者两个开发阶段之间存在可以验证的结构复用。

这也是为什么论文将得到的 DAG 描述为真实 prerequisite structure 的一个lower bound—— 它宁可遗漏某些隐式依赖，也不希望仅凭语义猜测制造大量错误的依赖边。

完成 DAG 之后，每一个 Development Unit 都还必须被转化成真正可执行的评测义务。

LoopsBench 会为任务建立可复现运行环境，并将每个开发单元对应到一组 executable tests。测试并不是简单生成后直接加入 Benchmark，而需要通过基于 Gold Solution 的验证流程：正确实现必须能够让测试从失败变成通过，没有实现时测试不能自然通过，同时，仅完成当前节点的前置工作也不能提前满足这个节点的测试。

因此，论文最终评测的并不是抽象的文本 milestone，而是可以在代码上真实执行和验证的 Development Unit。

Flow-aware Runtime：让测试跟着软件进度向前移动

有了 Dependency DAG，接下来的问题是：

评测器应该什么时候检查哪些任务？

LoopsBench 为此设计了Flow-aware Evaluation Runtime。

假设开发单元 C 依赖 A 和 B。

在 A 和 B 尚未完成时，即使 C 的代码已经被 Agent 修改，评测器也不会把 C 当成当前正常推进的任务。

只有当 C 的所有 prerequisite 都已经完成，它才会进入当前的Ready Frontier。

也就是说，随着 Agent 不断完成 Development Unit，可评测的任务 frontier 会沿着 DAG 动态向前推进。

这使 LoopsBench 不仅能够统计有多少测试通过，还能够从 Dependency DAG 的角度刻画 Agent 推进到了哪一层。

传统 Test Pass Rate 主要告诉我们多少测试通过，而 Ready Frontier 可以进一步区分：Agent 是否真正打通了关键的前置节点，并进入更深的软件依赖层。

因此，LoopsBench 观察的是 Agent 自己能否发现合理的工程路线，而不是通过 Benchmark 把一条固定的正确路线直接提供给它。

已经完成的工作，会变成后续必须保护的 Regression Obligation

Flow-aware Runtime 还有另一个关键机制。

假设 Agent 已经完成了一个底层模块，它的测试全部通过。

随后 Agent 开始开发上层功能。在普通分阶段评测中，之前的阶段可能已经结束；但在真实软件工程里，这些已经完成的功能并不会消失，新代码仍然需要保证它们正常工作。

因此，在 LoopsBench 中，一个 Development Unit 一旦完成，它对应的测试就会继续留在后续执行过程中，成为Regression Obligation。

于是 Agent 每向前推进一步，实际上都承担越来越多的工程义务：它不仅需要让新的功能正确，还需要保证所有已经完成的功能继续正确。

这也构成了长周期 Coding Agent 需要面对的一类挑战：任务越往后推进，代码越来越复杂，同时 Agent 需要维护的正确状态也越来越多。

因此，LoopsBench 中的 Regression 并不是普通意义上 “最终测试失败了多少”，而是在观察：

Agent 曾经建立起来的正确状态，有多少在后续执行中重新丢失了。

为了捕获这种动态过程，LoopsBench 将 Agent 编辑环境与评测环境分离。Agent 在一个容器中持续工作，而 evaluator 在另一个容器中根据代码快照独立运行测试。Runtime 会在真实代码发生变化时记录新的状态，从而获得一条随时间演化的软件开发轨迹。

实验：今天的 Coding Agent 能把长周期任务推进多远？

在完成 Benchmark 构建后，论文并没有只给出一个排行榜，而是围绕三个 Research Questions 展开实验。

这三个问题对应 Long-horizon Agent 的三个层次：

它能走多远？它在执行过程中如何维护计划、代码和测试状态？哪些 Loop 设计会影响长期执行？

RQ1：当前 Coding Agent 究竟能持续推进多远？

第一个实验首先回答一个直接的问题：

当前具有代表性的模型与 Coding Agent，在 LoopsBench 上能够取得怎样的长期执行表现？

实验结果显示，当前系统在这类长周期任务上仍有较大的提升空间。

在 LoopsBench 论文所采用的基准测试设置下，使用最高配置并结合 outer continuation 的方案表现最好，其任务 Resolve Rate 为25.00%，Test Pass Rate 为53.05%。

也就是说，即使是该实验中表现最好的配置，也仍有约四分之三的任务未能完整解决。

论文随后分别控制了 model 和 loop。

在固定 Coding Agent Loop、更换不同模型时，在论文比较的模型范围内，能力更强的基础模型通常取得了更好的长期进展；但即使模型能力提升，整体 Resolve Rate 仍然有限。

反过来，在固定模型后更换不同 Coding Agent Loop，也会产生明显的性能差异。

实验结果表明，Model 与 Loop 分别从不同层面影响长期执行：前者主要影响局部推理与代码能力，而后者影响这些能力如何在更长时间尺度上被组织和持续利用。

论文还进一步加入了outer continuation。当一次 Agent execution 主动停止之后，外部 Loop 会重新启动 Agent，让它继续处理尚未完成的工作。

在论文测试的多数配置中，Continuation 都带来了更好的任务进展。

例如，在其中一组高配置实验中，引入 continuation 后，Resolve Rate 从16.96%提高到25.00%；另一组配置则从14.29%提高到21.43%。这表明，一部分未完成任务与 Agent 的提前停止有关。

但实验也显示：

Continuation 可以缓解部分由提前停止带来的问题，却不能自动解决后续任务选择与推进路径的问题。

当任务进入更深的依赖层之后，Agent 仍然需要面对尚未完成的 prerequisite、不断累积的状态，以及越来越大的 Regression 压力。

RQ2：Agent 在长时间执行中，到底丢掉了什么？

如果第一组实验表明 Coding Agent 在 long-horizon task 中仍面临明显挑战，那么第二个研究问题开始进一步分析：

这些挑战可能与哪些执行过程因素有关？

LoopsBench 的优势在这里体现出来。因为任务拥有 Benchmark 构建得到的 Dependency DAG，同时 Runtime 记录 Agent 的真实执行轨迹，所以论文可以进一步分析 Agent 在Planning、Implementation 和 Testing三个层面的行为。

Planning

实验发现，目前 Agent 产生的计划只能恢复 Dependency DAG 中的一部分 prerequisite relation。

换句话说，Agent 的计划能够覆盖部分任务，但往往未能完整反映：

哪些任务具有前置依赖，哪些工作可以并行，以及哪一个节点正在阻塞后续工程推进。

这种差异在不同 Loop 中表现得并不相同。

部分 Coding Agent 已经开始显式使用 tree-shaped 或 concurrent execution structure，因此其计划宽度更接近参考 DAG；而在论文观察到的执行轨迹中，一些以线性执行为主的 Loop 更容易把本身具有并行结构的软件任务压成一条长链。

但并行并不天然意味着更好。

论文也观察到，有些 Loop 会走向另一个极端：把本来存在明确 prerequisite 的任务过早并行化。

因此，长周期 Planning 的核心并不是 “越并行越好”，也不是 “严格串行最安全”，而是：

并行结构需要尽可能与真实的软件依赖结构相匹配。

Implementation

论文发现，即使只观察最终成功完成的 Development Units，Agent 写出的 Patch 通常也比 Gold Reference 更长。

这一现象表明，在论文测试的任务中，Agent 除了任务路由之外，在实现过程中也可能逐渐累积额外修改。

这些修改未必立即造成错误，但随着任务越来越长，额外代码通常意味着更大的状态空间和更高的后续维护压力。

Testing

Testing 方面，论文观察到另一个值得关注的现象。

实验中的 Coding Agent 虽然普遍会运行已有测试，但较少随着开发过程持续建立足够的 Agent-authored tests。

这意味着在部分执行过程中，新功能的增加并未伴随同等程度的 regression protection。

结果是：已经完成的 Development Unit，在后续修改中仍然可能发生 Regression。

而且这种现象并不是某一个 Agent 的特殊情况。论文在不同 Loop profile 中都观察到了 Regression events。

从这个角度看，LoopsBench 提供的信息并不止于 “25% Resolve Rate” 这一最终指标。

对执行轨迹的进一步分析显示，计划对依赖关系的覆盖不足、实现过程中额外修改的累积、测试保护增长不足，以及后续修改引发的 Regression，都可能影响 Agent 在 long-horizon task 中的持续推进。

这些现象也指向了 Loop-level design 中值得进一步研究的问题。

RQ3：不同 Loop 机制如何影响 Long-horizon Execution？

论文的第三个 Research Question 进一步比较了多种长周期 Loop 设计，包括 Goal Mode、dynamic workflows 以及基于 fresh invocation 的循环机制。

这里论文关注的不再是某个 Agent 最终谁赢，而是不同 Loop 如何处理三个关键问题：

Objective persistence、Context renewal 和 Residual work。

Goal Mode 的核心思想，是让目标在一次较长的执行周期中持续存在。

Dynamic Workflow 则进一步把工作拆分给多个具有更窄上下文的 worker。

另一类循环机制采取不同路线：结束当前 invocation 后重新启动新的 invocation，让新的 Context 接管剩余任务。

这些机制代表了几种不同的 Long-horizon System Design。

实验发现，它们之间确实存在明显差异。

例如，采用 dynamic workflows 的设计可以产生更多独立的 context rounds，并取得较高的 Resolve Rate；Goal Mode 则通过长期维护目标来持续推进。

相比之下，在 LoopsBench 的相关实验设置下，单纯依赖 fresh invocation 重新接管 residual work 的循环机制，在更复杂任务上的表现相对较弱。

但在论文测试的这些机制中，没有一种能够完全消除 Regression。

这一结果表明，仅增加或刷新 Context 本身，可能还不足以解决 long-horizon execution 中的状态维护问题。

即使系统能够通过多次 continuation 持续执行，如果新的 Context 无法准确恢复 “哪些工作已经完成、当前为什么停在这里、哪些 invariant 必须继续保持”，它仍然可能重复工作、错误路由或者破坏已有结果。

因此，论文进一步将state retention、residual routing 和 regression obligation retention视为 Long-horizon Loop Engineering 中值得重点研究的问题。

为什么是从 Harness Engineering 扩展到 Loop Engineering？

这也是整篇论文希望提出的核心观点之一。

过去，Coding Agent 的不少系统能力提升都与Harness Engineering的发展密切相关。

我们不断改进模型与代码环境之间的接口：更好的文件搜索、更好的编辑工具、更好的 Shell、更好的 Sandbox、更大的 Context，以及更清晰的 Agent-Computer Interface。

这些工作回答的是：

How should the model interact with the software environment?

但当 Coding Agent 开始连续工作几十分钟、几小时，甚至更长时间时，另一个系统层开始变得重要：

当前目标是什么？已经完成了什么？真正阻塞工程的任务是什么？

哪些任务可以同时推进？哪些状态必须跨 Context 保留？什么时候应该运行测试？

什么时候需要重新规划？一次 Context 结束后，剩余工作应该交给谁？新的修改是否破坏了以前已经完成的功能？

这些问题已经很难单纯通过增加一个 Tool 或扩大 Context Window 来解决。

它们属于：

How should the agent continue working over time?

也就是Loop Engineering。

Harness 是模型与环境之间的接口；Loop 则是跨时间组织 Agent 行为的控制系统。

因此，LoopsBench 的目的并不是宣称 Harness Engineering 已经不重要，而是强调：随着任务进入更长时间尺度，Harness 之上的 Loop 设计开始成为另一个值得独立观察的系统层，而现有 Benchmark 对这一层的直接测量仍然有限。

LoopsBench 希望改变测评范式

从论文角度看，LoopsBench 的核心变化之一，是将 Coding Agent Benchmark 的观察单位从最终结果进一步扩展到执行过程。

现有的一类主流 Coding Agent 评测主要关注一个任务最终是否 Resolve。

LoopsBench 则把一次软件开发过程展开成一条随时间变化的执行轨迹：

• Dependency DAG 告诉我们工作之间如何关联；
• Ready Frontier 告诉我们 Agent 实际推进到了哪里；
• Regression Obligation 告诉我们它能不能守住已经完成的成果；
• Loop Trace 则让我们进一步观察 Planning、Implementation、Testing、Routing 和 Context Renewal 如何共同影响最终结果。

从这一角度看，这提供了一种值得进一步探索的 Long-horizon Coding Agent Evaluation 思路：

Benchmark 不仅应该衡量 Agent 最终到达了哪里，也应该帮助我们理解它为什么停在那里。