新智元报道 如今Agent已经能熟练调用工具、修改文件、运行测试，但面对一个长期演进的大型软件系统，它能否从一份新需求出发，交付完整功能？ 产品经理提出新需求，开发者拿到的往往不是文件清单或函数签名。需要先理解约束，追踪模块依赖，再判断改哪里、怎么改、怎样证明改对了。这些分析影响后续交付。 复旦大学、香港城市大学、香港中文大学等机构提出LoLBench，把Agent放进平均约240万行源代码的软件
新智元报道 如今Agent已经能熟练调用工具、修改文件、运行测试，但面对一个长期演进的大型软件系统，它能否从一份新需求出发，交付完整功能？ 产品经理提出新需求，开发者拿到的往往不是文件清单或函数签名。需要先理解约束，追踪模块依赖，再判断改哪里、怎么改、怎样证明改对了。这些分析影响后续交付。 复旦大学、香港城市大学、香港中文大学等机构提出LoLBench，把Agent放进平均约240万行源代码的软件系统，评估从功能提案到模块交付的完整过程，检验 把需求落到系统中的感知能力，以及完成跨模块修改的实现能力 。 论文链接：https://arxiv.org/abs/2609.37143 数据集：https://huggingface.co/datasets/lolbench26/LoLBench 实验暴露出关键断点：Agent可能改对局部，却漏掉其他模块中必须同步的改动。即使补充实现指引，多数任务仍未解决， 从理解需求到完成交付仍有很长距离 。 重新定义长程代码任务 什么样的长程代码任务，才有实际工程价值？ 「长程」不能只看耗时、轮数或Token消耗。例如让Agent每分钟输出一个数字，从1数到1000，虽然耗时很久，却只需简单循环。SWE-bench类局部Bug修复的任务，也不能覆盖从需求分析到模块交付的挑战。 LoLBench关注的长程代码任务，是 面向复杂系统的模块开发 。接到新需求后，开发者会反复分析：哪些行为必须实现？已有架构能否支持？哪些依赖会受影响？怎样验证？LoLBench把这部分藏在开发者脑子里的分析也纳入评估，让Agent自行完成从用户意图到实现方案的推导。 这类任务同时具有 感知复杂性 和 实现复杂性 ：前者是读懂提案、识别隐含约束和跨模块依赖、推导修改范围与实现规范（specification）的难度；后者是将规范转成正确的跨文件修改，并通过测试和修复避免已有功能被破坏的难度。 图1 感知复杂性与实现复杂性的比较。 LoLBench如何同时评估两类复杂性 从功能提案推导实现规范 LoLBench从社区功能提案（Enhancement Proposal）及对应的已合并PR中选取100项任务，覆盖29个系统、8种语言和5个领域。 Agent仅获提案与实现前代码仓，提案平均约5000个英文单词。评测在断网的Docker环境中开展，防止Agent检索上游实现。 例如，PEP 617［1］提议用PEG替换CPython的LL(1)解析器，实现时需贯通语法定义、解析器生成、抽象语法树与错误报告。Agent必须识别整条实现链路。 感知复杂性方面 ，LoLBench参考实现的目标类名在提案中的平均提及率仅7.3%，不到SWE-bench Verified（15.9%）的一半，也不到FeatureBench（38.7%）的五分之一。Agent须自行推测需求与代码的联系。 把规范落实为工程交付 实现复杂性方面 ，LoLBench仓库平均约240万行源代码，约为SWE-bench Verified的9.4倍、FeatureBench的4.9倍；实现平均改动5499行，后两者分别为38行和2050行。每项任务平均改动64.9个文件、40.1个类和195.9个函数；文件数分别为两者的25倍和4.2倍。 跨模块协同与验证更难。 表1 LoLBench与现有代码任务评测集的对比。 LoLBench通过两类测试验证交付正确性：新增功能测试（F2P）要求实现前失败、实现后通过， F2P通过公开接口检验行为，允许不同内部实现。 回归测试（P2P）要求前后均通过。 在项目原有的测试基础上，研究团队构造遗漏功能、篡改需求等错误实现作为变异体，补充测试用例识别漏检错误，并提高参考补丁的测试覆盖率。 增强后，1688个变异体的检出率从约61%升至96%，F2P按任务平均的行覆盖率从约60%升至79%。 28种Agent组合的表现与瓶颈 换模型或脚手架，Agent最高解决率仅14% 研究团队评估6个前沿模型与5个脚手架的28个可用组合，单任务限时6小时。Opus 5搭配Claude Code或mini-SWE-agent均以14%的解决率并列最高，全部组合的中位数仅2%。 表2 论文中的主要实验结果 同用Opus 5，mini-SWE-agent与Claude Code解决率相同，前者耗时为后者的3.2倍、生成Token为5倍，更多消耗未换来更高解决率。 大量交互与Token花在代码定位上 从Token消耗来看，按Agent平均，定位阶段占非缓存输入Token的 52.4% 、生成Token的 45.4% 。从Agent交互轮数来看，定位阶段的交互轮数也显著多于其他阶段。 图2 各阶段的平均交互轮数。 对照参考实现修改的既有文件和函数，全部28组Agent
