CompileAgent: Automated Real-World Repo-Level Compilation with Tool-Integrated LLM-based Agent System¶

会议: ACL 2025
arXiv: 2505.04254
代码: 无
领域: LLM Agent / 软件工程
关键词: 自动编译, LLM Agent, 仓库级编译, 工具集成, 多Agent讨论

一句话总结¶

提出 CompileAgent，首个面向仓库级代码编译的 LLM Agent 框架，集成五种专用工具和流程化 Agent 策略，在 100 个 C/C++ 真实项目的 CompileAgentBench 上将编译成功率最高提升 71%，平均每个项目仅需 $0.22。

研究背景与动机¶

领域现状¶

开源项目日益复杂，从源码编译到可执行文件或库是软件开发中的常见需求。编译产物不仅可直接使用，还支持后续工作如数据集构建、性能测试、安全漏洞分析等。然而，仓库级编译远比单文件编译复杂，涉及环境适配、依赖管理、构建配置等多方面挑战。

现有痛点¶

编译指令分散难找：编译指南可能藏在 README、doc.html、install.txt 等不同文档中，甚至在外部网站上，开发者需要大量时间定位。

编译错误难解：依赖冲突、环境不匹配、代码兼容性等问题需要丰富经验和反复调试。

现有工具能力有限：Oss-Fuzz-Gen 仅基于特定文件名执行预定义编译命令，对文件名不符的项目束手无策，也无法适应动态变化的环境。

核心矛盾¶

仓库级编译需要理解整个代码库结构、文档、依赖关系并与交互式环境动态交互，这超出了传统规则方法的能力范围，但完全契合 LLM Agent 的优势。

本文切入角度¶

将 LLM Agent 引入仓库级编译这一此前无人涉足的领域，设计专门的工具集和流程化策略，模拟开发者的真实编译过程。

方法详解¶

整体框架¶

CompileAgent 包含两大核心模块：CompileNavigator（搜索编译指令）和 ErrorSolver（解决编译错误），共集成五种工具，由 MasterAgent 按流程化策略调度。

整体编译流程： 1. 下载代码仓库并挂载到 Docker 容器中 2. 获取仓库结构（tree 命令） 3. 用 FileNavigator 定位编译指令文件 4. 用 InstructionExtractor 提取编译指令并执行 5. 编译成功则结束；出错则先自行尝试，失败后调用 ErrorSolver

关键设计¶

1. CompileNavigator 模块 — 寻找编译指令¶

功能：从复杂的仓库结构中定位并提取编译指令。

包含三个工具： - Shell：通过 Docker 容器隔离编译环境（Ubuntu 22.04），保护物理机安全，LLM 可通过 SSH 执行任意命令 - File Navigator：设计两个协作 Agent（SearchAgent I 和 II），输入仓库结构信息，通过讨论确定最可能包含编译指令的文件 - Instruction Extractor：SummarizeAgent 读取指定文件内容，搜索文件中与编译相关的 URL，必要时爬取网页内容，最终总结输出编译指令

设计动机：模拟开发者查找编译指南的流程——先看结构、再找文件、最后提取指令。双 Agent 协作讨论可提高文件定位准确率。

2. ErrorSolver 模块 — 解决编译错误¶

功能：当编译过程中出现错误时，自动分析错误原因并修复。

包含两个工具： - Website Search：封装 Google 搜索，优先查找 GitHub 和 StackOverflow 等可靠开源网站上的解决方案，聚合相关信息 - Multi-Agent Discussion：三个 Agent 分析编译错误，各自生成初始解决方案，然后进行最多 3 轮讨论。每轮结束后对命令行解决方案进行分段计数，若重复项超过阈值则达成共识并生成最终方案

设计动机：编译错误通常有明确的错误信息（路径问题、环境配置、兼容性问题等），不需要复杂推理，但多 Agent 讨论可以综合不同视角提高解决方案质量。

3. 流程化 Agent 策略（Flow-based Strategy）¶

核心思路：定义工具使用的固定顺序，通过 prompt 无缝串联各工具。

与 ReAct（每步推理+行动）和 Plan-and-Execute（先规划后执行）不同，流程化策略模拟了开发者编译项目的真实流程：先找编译指南→执行编译命令→遇到错误先自己尝试→不行就查资料和讨论。这种结构化流程减少了 LLM 在编译任务中的决策负担。

损失函数 / 训练策略¶

本工作不涉及模型训练。CompileAgent 是一个推理时的 Agent 框架，所有 Agent 使用现有 LLM（如 GPT-4o、Claude-3.5-sonnet 等）驱动，通过 prompt engineering 和工具调用完成任务。

实验关键数据¶

CompileAgentBench 基准¶

100 个 GitHub C/C++ 真实项目
覆盖 14 个不同领域（加密、音频、神经网络等）
三名有 3-4 年经验的开发者手动编译验证，共耗时 46 人时
按编译指令获取难度分级

主实验：编译成功率对比¶

模型	Oss-Fuzz-Gen	Readme-AI	RAG	CompileAgent	提升幅度
GPT-4o	25%	70%	71%	89%	+18~64%
Claude-3.5-sonnet	25%	74%	73%	91%	+17~66%
Gemini-1.5-flash	25%	56%	57%	77%	+20~52%
Qwen2.5-32B	25%	57%	55%	72%	+15~47%
Mixtral-8×7B	25%	35%	37%	47%	+10~22%
LLaMA3.1-70B	25%	52%	61%	71%	+10~46%
DeepSeek-v2.5	25%	56%	59%	80%	+21~55%

CompileAgent 在所有 7 个 LLM 上均大幅超越基线。Claude-3.5-sonnet 达到最高 91% 成功率，比 Oss-Fuzz-Gen 提升 66%。平均每个项目成本仅 $0.22。

消融实验¶

配置	成功率	时间 (h)	费用 ($)	说明
CompileAgent（完整）	89%	8.38	16.53	基于 GPT-4o
- File Navigator	81%	6.93	17.32	下降 8%，无法精确定位编译指令文件
- Instruction Extractor	77%	7.18	18.26	下降 12%，无法从文件中提取编译指令
- Website Search	84%	7.25	16.53	下降 5%，无法利用网络搜索错误解决方案
- Multi-Agent Discussion	71%	8.77	18.89	下降 18%，最关键组件，处理复杂错误能力大幅削弱

Multi-Agent Discussion 是平均调用频率最高（1.87 次/项目）且最关键的工具，移除后成功率下降最大。

Agent 策略对比¶

策略	Claude-3.5-sonnet	GPT-4o	Qwen2.5-32B
ReAct	约 60%	约 55%	约 40%
Plan-and-Execute	最低	最低	最低
OpenAIFunc	-	中等	-
Flow-based（本文）	91%	89%	72%

流程化策略在所有模型上均显著优于其他策略，保持 30-53% 的优势。

关键发现¶

更强的 LLM 带来更好的编译效果：模型能力与编译成功率正相关，但 Mixtral-8×7B 可能因架构设计表现较差
Multi-Agent Discussion 是核心：编译错误解决严重依赖多 Agent 协作讨论，单 Agent 难以应对复杂依赖问题
流程化策略优于灵活策略：对于编译这种有明确工作流的任务，固定流程比自由决策更有效
成本极低：平均每个项目 $0.22，远低于人工编译的时间成本（46 人时/100 项目）
常见失败原因：复杂构建依赖链（特定库版本）、工具链版本不匹配、复杂配置设置

亮点与洞察¶

首个将 LLM Agent 应用于仓库级编译的工作，填补了自动化编译研究的空白
工具设计高度贴合实际开发者工作流：找文档→提取指令→执行→遇错查网页→讨论解决，体现了对真实编译场景的深入理解
Docker 隔离环境设计既保证了安全性又提供了独立构建环境，是工程上的合理选择
Multi-Agent Discussion 的共识机制（命令行分段+重复计数）简单但有效，避免了复杂推理框架的开销
成本效益极高：$0.22/项目 vs 约 0.46 人时/项目的人工成本

局限与展望¶

依赖 LLM 理解能力：Agent 可能误解 prompt 或指令导致重复/错误操作，需要探索微调以改善指令理解
工具集较基础：未利用更高级的编程和调试工具（如 GDB、Valgrind 等），扩展工具集可能提升复杂错误的解决能力
高度依赖 prompt 工程：系统性能与 prompt 质量密切相关，需要更自动化的 prompt 优化方法
仅支持 C/C++：虽然讨论了多语言扩展的可能性，但实际只在 C/C++ 上验证
基准规模有限：100 个项目可能不足以全面评估，应扩展到更大规模和更多样化的项目

评分¶

新颖性: ⭐⭐⭐⭐ 首次将 LLM Agent 引入仓库级编译是重要创新，但 Agent 框架设计本身较为标准
实验充分度: ⭐⭐⭐⭐ 7 个 LLM、3 个基线、4 种策略、完整消融，但基准仅 100 个 C/C++ 项目
写作质量: ⭐⭐⭐⭐ 问题定义清晰，方法描述详细，但部分段落重复冗长
价值: ⭐⭐⭐⭐ 对软件工程自动化有实际价值，$0.22/项目的低成本使其具备实用潜力