EMNLP 2026 | 代码Agent会写不会跑？RAT让GitHub仓库自动跑起来
让你更懂AI的 2026-11-11 21:07 北京
代码Agent也会配环境了
有没有 clone 完 GitHub 项目，对着一堆报错怀疑人生的时刻？
依赖缺、版本冲突、Dockerfile 失踪、CI 脚本失效…… 你让 Agent 修一个 Bug，前提是它先能把项目环境配置好。
如果项目依赖缺失、版本冲突、CI 脚本失效、README 不完整，那么再强的代码能力也无从发挥。
对于代码 Agent 来说，环境配置（Environment Setup）其实是所有软件工程任务的第一步。而这一步，恰恰是目前最容易失败的地方。
项目主页：
论文地址：
https://arxiv.org/abs/2604.23190
代码地址：
https://github.com/gemelom/RunAnyThing
数据集地址：
https://huggingface.co/datasets/gemelom/RAT-bench
环境配置，为什么这么难？
很多人觉得环境配置无非就是：
➢ pip install -r requirements.txt
但真实世界远没有这么简单。一个 GitHub 仓库可能涉及：Python、Java、Rust 等不同语言；多种包管理器；Docker 环境；CI/CD 脚本；系统级依赖；外部服务依赖。
更麻烦的是，很多仓库可能压根没有完整配置文件。README 可能过期。Dockerfile 可能不存在。CI 脚本可能已经失效。甚至连测试程序都没有。
这意味着 Agent 必须像工程师一样需要理解仓库结构，推断运行环境，自动安装依赖，处理报错，包括验证最终是否运行成功。而不是简单执行一条安装命令。
RAT：让Agent学会“把仓库跑起来”
本工作提出了 RAT，其核心目标非常直接：给定任意 GitHub 仓库，自动完成环境配置，并最终得到可运行环境。
第一步：先识别语言生态，不搞 “一刀切”
环境配置最容易犯的错，就是拿同一套思路去处理所有语言。表面上都是跑代码，但 Python、Java、Rust、JS/Go 的依赖管理、构建流程、高频报错点完全不一样：
Python 常栽在系统依赖缺失、虚拟环境不兼容上
Java 多是 Maven/Gradle 构建冲突、多模块依赖版本打架
Rust 容易卡在工具链版本、原生库链接上
所以 RAT 先做语言感知抽象：先识别仓库的主编程语言，再给 Agent 匹配对应语言的专属配置逻辑 —— 包括依赖文件怎么找、包管理器怎么调、测试用例怎么跑、常见错误怎么排。
所有语言的能力都封装在统一的接口里，未来要加新语言（比如 C++），只需要新增一套适配模块，不用改动整个系统核心。
第二步：智能挑选基础镜像，开局就少踩一半坑
很多配置失败，其实从选基础镜像那一刻就注定了。
PyTorch 项目用了纯 Python 轻量镜像、CUDA 项目驱动版本对不上、低版本系统跑不了新语法…… 基础选错了，后面再怎么补都事倍功半。
RAT 专门使用 ImageRetriever 模块解决这个问题：先用大模型对仓库的 README、配置文件做语义分析，精准推断出项目需要的语言版本、操作系统、核心框架、关键依赖。
先从预定义的标准镜像池里挑最合适的打底；如果是复杂项目，还会自动生成检索词，去 Docker Hub 搜更有针对性的专用镜像，再通过打分选出最优的初始化环境。
第三步：迭代式排错，不是死跑脚本，是边错边改
传统的自动化配置，本质就是把一串安装命令按顺序跑一遍，错了就直接失败，不会自己调整。而人手动配环境，其实是个反复试错的过程：装依赖→看报错→查原因→改配置→再试一次。
RAT 将过程自动化了：它用 ReAct 框架把环境配置建模成持续交互的任务，还配了一套专门面向配置的工具集——切版本、装依赖、解析 CI/CD 脚本取官方步骤、搜历史 Issue 找现成解法、报错自动修复、项目没测试还能自己生成冒烟测试做验证。
它不会一条路走到黑，而是走一步看一步，根据实时的系统反馈动态调整策略，一步步逼近正确的可运行环境。
环境配置基准：RATBench
研究环境配置还有一个问题：缺少可信的评测数据。
很多已有的基准，要么就覆盖几十个仓库，样本少得可怜；要么只死磕 Python 一门语言，相当于考试只出课后题，分数看着高，一碰到真实项目就失灵。
但现实的软件生态根本不是标准化的：项目有大有小，配置有全有缺，语言五花八门，坑点千奇百怪。
因此本文构建了 RATBench。包含 2500 多个真实 GitHub 仓库。用分层抽样的方式，把不同项目规模、不同流行度、不同编程语言、不同配置完整度的场景都覆盖全了。
更关键的是，我们不搞 “静态扫代码就打分” 的纸面评测，是真刀真枪跑起来测能构建通过、能跑通测试才算配置成功，完全按真实开发的标准来衡量。
实验结果
本文使用 ESSR（Environment Setup Success Rate）衡量环境配置成功率。简单来说：只有真正把项目跑起来，且能运行测试程序或入口程序才算成功。
实验结果表明，RAT 在环境配置成功率上显著优于现有方法，平均提升约 36.1%。
在多种语言和不同配置难度场景下均表现稳定，即使在缺少文件的情况下，也能够有效推断执行环境并完成验证。相比于通用 Agent 如 Claude code 智能体，RAT 在特定领域任务上取得了更优的表现。
同时本文比较人类其表现甚至接近或超过资深工程师的手动配置能力，对于大规模代码 Agent、仓库挖掘以及软件工程自动化场景而言，自动化带来的规模优势往往比单次配置速度更加重要。
此外实验还发现有趣的结论: 随着计算预算增加，模型能力会持续提升类似于 scaling law。相比之下，基准几乎没有表现出类似规律。表明一个好的 agent 设计能保持较好的计算量—性能增长关系。
实际部署
下面是本文的可视化 Web 界面，RAT 的全流水线操作都浓缩在这一步：往输入框里填一个 GitHub 仓库地址就行。
结语
如果说过去的软件工程 Agent 解决的是“如何写代码”，那么 RAT 关注的则是如何让“代码跑起来”。
环境配置看似只是开发流程里的一小步，却是所有自动化软件工程任务的地基。
通过将静态代码仓库转化为可执行环境，RAT 可以为在真实世界代码上规模化开展代码智能体轨迹生成、数据合成、基于执行的评测以及代码领域强化学习奠定了可运行环境基础。
更多阅读
·
本文转载自微信公众号「PaperWeekly」，查看原文。版权归原作者所有，如有侵权请联系删除。