微软、南京大学等机构的研究人员提出了 LoopsBench，这是一个面向 long-horizon software engineering 的 Coding Agent Benchmark。该基准将软件任务表示为依赖 DAG，以评估 Agent 在长时间执行中维护计划、推进依赖任务、保留已完成工作并控制回归的能力。这一基准的提出反映了 Coding Agent 从一次性工具调用向持续软件开发系统演进的趋势。
SynthePulse Insight · AI 深度解读
版本 1 · 1 个来源
微软与南京大学等机构提出LoopsBench，将长周期软件任务表示为依赖DAG，并引入Flow-aware Runtime，以评测Coding Agent在长时间执行中的规划、推进与回归控制能力。
现有Coding Agent Benchmark（如SWE-bench）通常以最终测试是否通过来评判，但面对持续执行、Goal Mode等新能力，仅看最终结果不足以刻画执行过程。LoopsBench提出，长周期任务中Agent需要识别依赖、沿合理顺序推进，并防止已完功能回归。
LoopsBench将任务表示为Dependency DAG：节点是实际工程单元，边表示有证据支持的前置依赖。该DAG并非唯一正确顺序，而是评估契约，允许并行或重做，只要符合依赖关系。
任务来源包括大学课程实验、开源项目连续PR和研究代码演化，共112个任务，其中57个Course Labs、29个PR Sequences、26个Research Evolutions。
LoopsBench设计Flow-aware Evaluation Runtime：只有当前置条件满足，Development Unit才进入Ready Frontier，测试随进度沿DAG推进。这能观察Agent推进到哪一层，而非仅统计通过率。
一旦单元完成，其测试继续保留，成为Regression Obligation。Agent每前进一步，需维护更多已完功能，回归压力累积。
Runtime将编辑与评测环境分离，在代码变化时记录状态，生成随时间演化的轨迹，以捕获回归动态。
在基准测试中，最佳配置（最高配置+outer continuation）的Resolve Rate为25.00%，Test Pass Rate为53.05%，即约四分之三任务未完整解决。固定Loop换模型或固定模型换Loop均产生差异，说明Model与Loop分别影响局部推理与长期组织。
引入continuation可提升表现：一组配置Resolve Rate从16.96%提高到25.00%，另一组从14.29%提高到21.43%，但无法自动解决后续任务选择与推进路径问题。
分析显示，Agent计划仅覆盖部分依赖关系，Patch通常比Gold Reference更长，且较少建立Agent-authored tests，导致已完单元在后续修改中发生Regression。
论文比较了Goal Mode、Dynamic Workflows和基于fresh invocation的循环机制。Dynamic Workflows产生更多独立context rounds并取得较高Resolve Rate；Goal Mode通过长期维护目标推进；fresh invocation在复杂任务上表现相对较弱。
然而，没有一种机制能完全消除Regression，表明仅增加或刷新Context不足以解决长期执行中的全部问题。
本文基于机器之心对LoopsBench论文的报道，所有数据与结论均来自该报道，未核实原始论文。部分实验细节（如具体模型名称）未在报道中提及，故未包含。
LoopsBench提供了一种评测长周期Coding Agent的新范式，强调过程而非仅结果。当前Agent在长期任务中仍面临规划、回归控制等挑战，Loop设计需与真实依赖结构匹配。
主报道
主报道来源