代码智能体真的会修 Bug，还是只是认出了仓库？

导语

SWE-bench 等仓库级编程基准，已经成为衡量代码智能体能力的重要工具。它们要求模型阅读真实项目、定位问题、修改代码并通过测试，比单函数补全更接近实际开发。然而，这类基准也存在一个根本风险：测试所依赖的开源仓库可能早已出现在模型训练数据或公开解决方案中。模型取得高分，未必完全来自对代码逻辑的推理，也可能得益于对项目名称、目录结构、常见实现方式和历史修复模式的熟悉。

上海交通大学研究团队提出的 SchrodingerRepo，正是为了检验这种可能性。它把测试仓库视为一个只有在评测环境中才“实例化”的变量：智能体面对的仍是行为等价、可运行的项目，但项目外观会被改造成不熟悉的形式。这样既保留了原任务的功能目标，又尽量削弱模型依赖记忆线索的机会。

核心方法

SchrodingerRepo 设计了由浅入深的四类变换：

• 重构问题描述：重新组织任务表述，降低模型对原始 issue 文本或固定措辞的依赖。
• 命名空间映射：调整项目中的名称和标识符，让模型无法直接凭熟悉的类名、函数名或模块名定位代码。
• 文件内部布局重排：改变代码在文件中的组织顺序和布局，同时保持程序行为不变。
• 保持功能的代码重写：在不改变执行结果的情况下，改写实现模式，进一步减少与原始仓库的表面相似性。

研究在 SWE-bench Verified 和 SWE-QA 上评估多种流行大语言模型。摘要显示，当熟悉的仓库线索逐步被移除后，不同模型的完成表现都出现下降，同时交互成本明显增加。进一步分析认为，额外成本主要来自仓库探索和问题定位，而不是单纯的代码生成环节。

意义与影响

这项工作并不能简单证明现有模型“只是在背答案”，但它揭示了一个重要的评测盲点：基准分数可能混合了通用软件工程能力、对仓库风格的识别能力，以及对训练语料中既有项目的记忆。若评测环境长期固定，模型越熟悉某些项目线索，就越可能通过更短的路径找到解决方案。

对代码智能体而言，真正稳健的能力应包括理解陌生目录、建立代码索引、追踪跨文件依赖、验证行为变化，并在缺少先验提示时逐步缩小排查范围。对基准设计者而言，动态生成或多表示评测提供了一条可行方向：同一任务可以拥有多个行为等价但表面不同的仓库版本，从而把“记住项目”与“解决问题”区分开来。

当然，代码重写和布局变换也需要严格验证，确保没有引入新的难度来源或破坏原任务语义。SchrodingerRepo 的价值，正在于把数据泄漏问题从抽象担忧转化为可操作的实验框架，并提醒业界重新思考：一个智能体在熟悉代码库中表现出色，是否就意味着它能在真实、陌生的软件环境中工作。

来源：Hugging Face Daily Papers