8 月 23 日，微软、南京大学等机构的研究团队发布了 LoopsBench——一个专门评测「长周期 Coding Agent」的新基准。它的核心发现足够扎心：当前最强的 Agent 配置，跑长周期任务的成功率只有 25%。换句话说，四分之三的长任务，最强配置也完不成。
这篇资讯不是想说「Agent 不行」，恰恰相反：LoopsBench 告诉我们 Agent 真正的战场在哪——不是单点解题，而是长时间连续干活。这跟昨天 OpenAI 开源 Codex Harness（OpenAI 全面开源 Codex Harness）形成一条清晰的线索：Agent 的竞争，正在从「模型多聪明」转向「系统能不能让它稳定地干活」。
事实梳理：LoopsBench 是什么，怎么测的
过去的 Coding Agent 评测（比如 SWE-bench）都是「一锤子买卖」：给一个 issue，让 Agent 改，最后跑测试看通没通。但真实的软件工程不是这样——一个功能依赖底层数据结构，再建接口，再上层调用，最后才是 CLI 和集成。后面的任务依赖前面的，而且改后面的不能破坏前面的。
LoopsBench 就是冲着这个缺口去的。它把长周期软件任务拆成多个「可独立验证的开发单元（Development Unit）」，再恢复它们之间的前置依赖关系，最终把任务表示成一张依赖 DAG。评测时，Agent 在独立容器里持续工作，evaluator 在另一个容器里按代码快照独立跑测试，一路记录 Agent 的完整执行轨迹。
数据集规模不小：112 个长周期任务、超过 5300 个开发单元，覆盖 8 种编程语言和 9 个软件领域，任务依赖深度中位数 6。任务来源三类：大学课程的大型编程实验（57 个）、真实开源项目的连续 PR 序列（29 个）、研究代码的演化链（26 个）——都不是拍脑袋生成的，来自真实开发过程。
事实梳理：核心数据，最强配置只有 25%
在 LoopsBench 的设置下，表现最好的配置（最高配置 + 外部续跑）任务 Resolve Rate 是 25.00%，Test Pass Rate 是 53.05%。意思很直白：即使最好的配置，也还有约四分之三的任务没能完整解决。
实验还分别控制变量对比了模型和 Loop 的影响：固定 Loop 换模型，更强的模型通常推进得更远，但整体 Resolve Rate 仍然有限；固定模型换 Loop，性能差异同样明显。结论是：模型主要影响局部推理和代码能力，Loop 决定这些能力能不能在更长时间尺度上被组织和持续利用。
另一个关键发现来自「外部续跑（outer continuation）」实验：当一次执行主动停止后，外部 Loop 重新拉起 Agent 继续处理未完成的工作。引入续跑后，Resolve Rate 从 16.96% 提到 25.00%，另一组配置从 14.29% 提到 21.43%。这说明相当一部分失败，纯粹是「Agent 提前收工」造成的——但续跑只能缓解提前停止，解决不了更深层的状态维护问题。
事实梳理：Agent 到底丢掉了什么
LoopsBench 最有价值的部分，是它不只给了个分数，还分析了执行轨迹，回答「Agent 在长时间执行中丢掉了什么」：
一是计划覆盖不足：Agent 生成的计划只能恢复依赖 DAG 中的一部分前置关系，经常搞不清哪些任务有依赖、哪些能并行、哪个节点在阻塞后续推进。有些 Loop 把能并行的任务压成一条串行长链，有些则把有明确依赖的任务过早并行——两种都是错。
二是实现累积膨胀：即使只看最终完成的单元，Agent 写出的补丁也比参考答案更长，额外的修改在短任务里无所谓，任务一长就变成更大的状态空间和维护压力。
三是测试保护不足：Agent 普遍会跑已有测试，但很少随着开发进度持续补新测试，结果就是——已经完成的单元，在后续修改中仍然可能回归（Regression）。它在观察的多种 Loop 中都发现了回归事件。
影响分析：为什么说重心从 Harness 转向 Loop
LoopsBench 提出的核心观点是：Coding Agent 基础设施的研究重点，正在从 Harness Engineering 扩展（或说转移）到 Loop Engineering。
Harness 解决的是「模型怎么和软件环境交互」：更好的文件搜索、编辑工具、Shell、沙箱、更大的上下文窗口——这些过去几年给 Coding Agent 带来了大量提升，也确实是 Agent = Model + Harness 的由来。
但当 Agent 连续工作几十分钟、几小时甚至更久，另一个问题浮出水面：当前目标是什么？已经完成了什么？哪些状态必须跨上下文保留？什么时候该重新规划？一次上下文结束，剩余工作交给谁？新修改有没有破坏旧功能？这些问题不是加个工具、扩个上下文窗口能解决的，它们属于「Agent 怎么跨时间持续工作」——这就是 Loop Engineering 的领地。
这两天的新闻放在一起看特别有意思：昨天 OpenAI 用数据证明，同一模型换个 Harness（保留推理 + 上下文压缩），得分从 13.3% 涨到 38.3%（Codex Harness 开源）；今天 LoopsBench 用数据证明，Harness 之外还有一层 Loop——上下文再足、工具再全，Loop 不会组织长时工作，长任务照样完不成。执行层的每一层，都在被单独拆出来研究。
影响分析：对开发者和评测范式
对开发者，LoopsBench 最大的价值是给了三个可操作的信号。第一，跑长任务一定要设检查点和状态持久化，Agent 提前收工是真实的大问题——一个续跑机制就能把成功率拉高好几个点；第二，任务拆解要匹配真实依赖，别盲目并行也别一味串行；第三，每完成一个子任务就补上对应的验证，别让旧成果在后面的修改中悄悄坏掉。这些在 AI Agent 上下文管理 和长时任务设计的实操里反复强调过，现在有了基准数据的背书。
对评测范式，LoopsBench 把观察单位从「最终结果」扩展到「执行过程」：Dependency DAG 告诉你工作怎么关联，Ready Frontier 告诉你推进到哪一层，Regression Obligation 告诉你守住没守住成果，Loop Trace 让你看到计划、实现、测试如何共同影响结果。这和 AI Agent 评测怎么做 那篇说的方向一致——好评测不该只问「跑没跑完」，还要解释「为什么停在那里」。
老达点评
我的判断：LoopsBench 是「Agent 进入长时任务时代」的一个标志性基准。它用数据把一件大家早有体感的事说透了——Agent 从「能解题」到「能干活」，中间隔着的不是更聪明的模型，而是 Loop 这层工程系统。
对普通开发者和团队，别被 25% 吓到，也别指望换个更贵的模型就解决。真正该做的是把长任务的工程纪律补齐：拆解、检查点、状态持久化、回归保护、中断恢复。这些不依赖任何特定框架，OpenClaw、Codex、DeepSeek Harness 都能做——框架给的是能力，纪律得自己立。
另外提一句，从 DeepSeek Harness 到 Codex Harness 再到 LoopsBench，短短十天，执行层已经从「开源占位」卷到「评测定义」了。谁能定义长时任务的评测标准，谁就掌握了下一代 Agent 框架的话语权。这个观察值得所有做 Agent 基础设施的团队重视。
总结
微软联合南京大学发布的 LoopsBench，用 112 个真实演化长任务、5300+ 开发单元告诉我们：当前最强 Coding Agent 跑长周期任务的成功率只有 25%，四分之三的任务完不成；失败主要来自计划覆盖不足、实现膨胀、测试保护和回归失控；Agent 基础设施的研究重心，正在从 Harness Engineering 转向 Loop Engineering。模型决定起点，Loop 决定能走多远——这句话，正在成为 Agent 圈的共识。
