暴风中的代码舞蹈：代理能否完美交付？

在一个不平凡的时代，软件代理像是一位现代舞者，它们无所不能，轻盈地在代码森林中穿梭，召唤工具、调整文档、进行测试……但是，当面对一个复杂的大型软件系统时，这位舞者可就有点儿发愁了。想象一下，产品经理抛出了一份新需求，开发者们却发现手中的文档就像拼图的缺失部分，怎么也拼不出完整的画面。

在这个逻辑的迷宫里，开发者们可得先理解约束、追踪模块依赖，然后给出“改哪里、怎么改、怎样证明改对了”的一系列答案。这就像是在玩一个巨大的智力游戏，所有的分析都可能影响后续的交付——简直是极限挑战啊！

于是，复旦大学、香港城市大学以及香港中文大学等机构联手推出了LoLBench，决定把这些代理扔进一个包含约240万行源代码的迷宫中，看看它们能否从需求提案爬到交付的高地，评估一下这个庞大系统中的感知能力和跨模块的改动实战能力。这一过程就像将一位舞者放在未知的舞台上，看看他是否能完美舞动。 华体会

然而，实验揭示了关键的短板：虽然代理可能在局部做得不错，却往往漏掉了其他模块必需的同步改动。就算你给它写上详细的操作指南，绝大部分任务仍然面临大海捞针的困境，面对从理解需求到最终交付的鸿沟，它们依然显得力不从心。

那么，什么样的长程代码任务具有实际的工程价值呢？这里的“长程”可不是指简单的时间消耗或Token数量，想象让代理每分钟输出一个数字，从1数到1000，虽然这听起来像是一场无尽的耐力赛，但实际上它只需要简单的循环而已！而SWE-bench类的局部Bug修复任务，顾名思义，也不能涵盖从需求分析到模块交付的复杂挑战。

LoLBench真正关注的是，如何应对复杂系统中的模块开发。接到新需求后，开发者们如同侦探一般，必须不断分析：哪些行为必须实现？现有架构能不能扛得住？依赖关系会不会受到波及？通过怎样的方式来进行验证？LoLBench就是为了将这些藏在开发者脑子里的深邃分析也纳入评估，让代理们自己从用户意图推导出实现方案。 华体会

这种任务不仅充满了感知复杂性——即读懂提案、识别隐含约束、跨模块依赖，以及推导修改范围与实现规范（Specification）的难度；还蕴藏着实现复杂性——将规范转变为跨文件修改，并且在测试和修复中避免破坏已有功能的挑战。

为了让评估更全面，LoLBench从社区功能提案中选取了100项任务，覆盖29个系统、8种语言和5个领域。代理仅获得提案与实现前的代码仓库，但提案可不是低级文档，平均长度达到了5000个英文单词！而这次评测的舞台设置在断网的Docker环境，以防代理们像小偷一样，悄悄检索上游的实现。

例如，PEP 617提议用PEG替换CPython的LL(1)解析器，代理必须理清这一实施链路的每一个环节，简直就像解开一串复杂的项链。值得一提的是，在感知复杂性方面，LoLBench的目标类名在提案中的平均提及率仅7.3%，相较于其他评测的结果，这个数字似乎是不折不扣的“低级失误”。 华体会

在实现复杂性方面，LoLBench仓库的庞大程度简直可媲美图书馆，平均约240万行源代码，几乎是SWE-bench Verified的9.4倍，而实现的平均改动高达5499行，构成一座巨大的代码山。而每项任务平均需改动64.9个文件、40.1个类和195.9个函数，文件的数量则分别是后两者的25倍和4.2倍。想想看，要在这样巨大的架构中进行跨模块协同与验证，简直就是一场噩梦。

为了验证交付的正确性，LoLBench通过两类测试：新增功能测试（F2P）要求实现前失败、实现后通过；而回归测试（P2P）则要求前后均通过。研究团队还为了增加覆盖率，构造了各种可能的错误实现，用作测试用例识别漏检错误，提升了1688个变异体的检出率，从61%跃升至96%。F2P的行覆盖率也提到了79%——可喜的进展呀！

再谈谈28种Agent组合表现的尴尬现状吧：无论如何换模型或脚手架，最高的解决率也仅有14%！研究团队评估了6个前沿模型与5个脚手架的多达28个组合，但无论是Opus 5搭配Claude Code还是mini-SWE-agent，都难以突破这个数字的魔咒，解决率在所有组合中的中位数竟然只有2%！ 华体会

具体而言，同用Opus 5的mini-SWE-agent与Claude Code解决率相同，但前者耗时是后者的3.2倍，生成Token则是5倍，浪费的心力却换不来更高的解决率，真是让人哭笑不得。

在这些Agent的定位阶段，Token的消耗数据也很惊悚，平均定位阶段的Token占非缓存输入的52.4%、生成Token的45.4%。而在交互轮数方面，定位阶段的交互轮数也是其他阶段的几倍，简直就像是在进行一场冗长的对话，双方却始终无法达成一致。

所以说，让这些代理在复杂的代码世界中翩翩起舞，恐怕要有朝一日才会实现！ 华体会