论文页面 - RepoRescue: 关于LLM代理在整库兼容性救援中的实证研究

来源：https://huggingface.co/papers/2607.01213

摘要

LLM代理能够通过兼容性救援成功将遗留软件仓库适配到现代环境，其中协作方法比单一系统取得更高的成功率。

开源库和工具被广泛复用，但兼容性维护成本高昂。一旦维护者离开，随着运行时和依赖项的演变，有用的仓库可能停止工作。我们研究了LLM代理（https://huggingface.co/papers?q=LLM%20agents）能否将旧仓库适配到现代环境——我们将这项任务称为兼容性救援（https://huggingface.co/papers?q=compatibility%20rescue）。与漏洞修复不同，兼容性救援（https://huggingface.co/papers?q=compatibility%20rescue）始于一个在原始环境中可工作、但因生态系统漂移（https://huggingface.co/papers?q=ecosystem%20drift）而失效的仓库。RepoRescue仅向代理提供仓库及其当前失败的现代环境；代理必须诊断失败原因、定位受影响代码，并生成一个源代码救援（https://huggingface.co/papers?q=source-code%20rescue），以恢复历史测试套件（https://huggingface.co/papers?q=test%20suite）。我们从193个Python和122个Java仓库构建了RepoRescue，每个仓库都经过验证，能在历史环境中通过测试而在现代化后失败。我们在Python上评估了五种部署的代理系统，在Java上评估了三种。除了完整补丁通过率外，我们还通过移除测试文件编辑后重新运行补丁来衡量纯源码修复（https://huggingface.co/papers?q=source-only%20repair），添加了一个运行时强制机制来阻止测试编辑，并验证了在救援后测试套件通过的仓库的实际可用性。我们发现Claude Code系统有时即使在被提示不要编辑时也会修改失败的测试；通过运行时阻塞，Kimi仍能救援41.5%的仓库。系统具有互补性：它们的联合覆盖率达到62.7%，超过最优单个系统10.9个百分点。难点集中在跨文件协调（https://huggingface.co/papers?q=cross-file%20coordination）上：在14个需要协调全代码库变更的仓库中，通过Codex的GPT-5.2通过了全部14个，而每个Claude Code系统最多仅通过两个。最后，测试套件通过只是一个初始信号：在34个测试套件在救援后通过的未维护Python候选者中，22个在现实场景中工作，12个通过漏洞猎杀补丁解决了兼容性失败。RepoRescue使用纯源码审计、运行时强制（https://huggingface.co/papers?q=runtime%20enforcement）、实际验证和推理标签对兼容性救援（https://huggingface.co/papers?q=compatibility%20rescue）进行基准测试。

查看arXiv页面（https://arxiv.org/abs/2607.01213）查看PDF（https://arxiv.org/pdf/2607.01213）添加到收藏（https://huggingface.co/login?next=%2Fpapers%2F2607.01213）

在你的代理中获取这篇论文：

hf papers read 2607.01213

没有最新的CLI？curl -LsSf https://hf.co/cli/install.sh | bash

引用此论文的模型0

没有模型与此论文链接

在模型README.md中引用arxiv.org/abs/2607.01213以从本页链接。

引用此论文的数据集0

没有数据集与此论文链接

在数据集README.md中引用arxiv.org/abs/2607.01213以从本页链接。

引用此论文的Space0

没有Space与此论文链接

在Space README.md中引用arxiv.org/abs/2607.01213以从本页链接。

包含此论文的收藏集0

没有包含此论文的收藏集

将此论文添加到收藏集（https://huggingface.co/new-collection）以从本页链接。