RepoRescue：LLM 代理对整个存储库兼容性救援的实证研究

开源库和工具被广泛重用，但兼容性维护成本高昂。一旦维护者离开，有用的存储库就会随着运行时和依赖项的发展而停止工作。我们研究 LLM 代理是否可以使旧存储库适应现代环境，我们称之为兼容性救援的任务。与错误修复不同，兼容性救援从在原始环境中工作但在生态系统漂移后失败的存储库开始。 RepoRescue 仅向代理提供存储库及其失败的现代环境；代理必须诊断故障，找到受影响的代码，并生成恢复历史测试套件的源代码救援。我们从 193 个 Python 和 122 个 Java 存储库构建 RepoRescue，每个存储库都经过历史验证，在现代化后会失败。我们评估了五个在 Python 上部署的代理系统和三个在 Java 上部署的代理系统。除了完整补丁通过率之外，我们在删除测试文件编辑后重新运行补丁以测量仅源修复，添加阻止测试编辑的运行时强制机制，并验证其套件在救援后通过的存储库的实际使用情况。我们发现克劳德代码系统有时会编辑失败的测试，即使提示不要这样做；在运行时阻塞的情况下，Kimi 仍然挽救了 41.5% 的存储库。系统具有互补性：它们的联合达到62.7%，比最好的单一系统高出10.9个百分点。困难集中在跨文件协调上：在需要协调整个代码库更改的 14 个存储库中，GPT-5.2 通过 Codex 通过了全部 14 个存储库，而每个 Claude Code 系统最多通过了两个存储库。最后，通过套件只是一个初始信号：在 34 个未维护的 Python 候选套件中，其套件在救援后通过，其中 22 个在现实场景中工作，12 个通过了解决兼容性故障的补丁的 bug 搜寻。 RepoRescue 通过纯源审计、运行时执行、实际验证和推理标签对兼容性救援进行基准测试。