Claude写5000词需求只交付14%，28种Agent组合实测暴露断点

工具调用、文件修改、测试运行，这些事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如何同时评估两类复杂性

从功能提案推导实现规范

社区功能提案（Enhancement Proposal）加上对应的已合并PR，LoLBench从中挑了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）要求实现前失败、实现后通过，它走公开接口查行为，内部怎么实现不限；回归测试（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%。看交互轮数：定位阶段也明显比别的阶段多。

图2 各阶段的平均交互轮数。

对照参考实现去改已有的文件和函数，28组Agent的文件修改精确率落在38.0%到80.4%之间，召回率30.3%至65.0%；函数修改精确率54.2%至65.6%，召回率20.8%至53.4%。定位不够准，覆盖也不全。

补充修改指引后，Agent仍难以完整交付

团队没有动原功能提案，只额外给出从参考实现导出的修改文件树和API实现规范，帮Agent圈定改动范围。Opus 5+Claude Code的解决率从14%升到34%，GPT-5.6 Sol+Codex从3%升到25%，DeepSeek V4 Flash+OpenCode从1%升到17%。

表3 补充修改文件树与API实现规范后的实验结果

指引确实减轻了感知负担，可最好的组合仍有66%的任务没解决。模块要协调、接口要实现、还得过验证，这说明大系统的实现复杂度本身就高。

从代码生成走向大型软件系统演进

这些结果给Agent研发指了几个可检验的方向：仓库检索能不能覆盖关键依赖，动手编码前的实现规范够不够完整，验证环节能否及时揪出跨模块的遗漏。

软件工程的价值，说到底在于用户需求能不能被可靠兑现。Agent得弄明白变更为何发生、会怎样影响系统，再把变化完整落地。LoLBench想推动Agent能力评估从生成代码转向支持软件持续演进，让交付结果成为检验Agent能力的尺度。

参考资料：PEP 617：https://peps.python.org/pep-0617/