Enhancing Open-Domain Task-Solving Capability of LLMs via Autonomous Tool Integration from GitHub¶

会议: ACL 2025 Main
arXiv: 2312.17294
代码: https://github.com/OpenBMB/OpenAct
领域: LLM/NLP
关键词: 自主工具集成, GitHub, 分层Agent, 经验学习, 开放领域

一句话总结¶

提出OpenAgent系统，通过Search→Setup→Apply→Store四阶段流程自主从GitHub搜索、配置、使用和存储仓库作为工具，解决LLM在金融、化学、生物等专业领域的开放域任务，平均成功率69.4%。

研究背景与动机¶

领域现状：LLM-based Agent通过集成外部工具（搜索引擎、计算器、知识库等）来增强能力。然而现有Agent支持的工具集有限，无法覆盖用户在各专业领域的多样化需求。

现有痛点：(1) 工具集固定——现有Agent只支持预定义的有限工具集，面对专业领域（量化投资、分子逆合成等）束手无策；(2) 工具创建能力弱——虽有研究让LLM动态创建工具，但创建的工具功能简单，无法满足真实复杂需求；(3) 缺乏评估——没有评估LLM开放域任务解决能力的数据集。

核心矛盾：GitHub上存在大量专业工具仓库，但将它们自动集成到Agent中面临两大挑战：(a) 仓库质量参差不齐、文档不完整、代码可能有bug；(b) 仓库使用方式多样、缺乏标准化接口。

本文目标 (1) 构建OpenAct基准评估开放域任务解决能力；(2) 设计能自主从GitHub集成工具的Agent系统。

核心 idea：让LLM Agent自主搜索GitHub仓库并将其作为工具集成，通过学习GitHub Issues/PRs中的人类经验来克服仓库的非标准化问题。

方法详解¶

整体框架¶

OpenAgent（论文早期版本称GitAgent）采用分层任务分解策略，将工具集成过程分解为四个阶段：Search（搜索合适仓库）→ Setup（配置环境）→ Apply（应用仓库解决任务）→ Store（存储仓库供未来使用）。每个阶段进一步分解为多个子任务，每个子任务通过一系列动作（API调用、命令执行、文件I/O等）来完成。

数学形式化：\(Q \xrightarrow{\mathcal{M}} O_{\text{Search}} \rightarrow O_{\text{Setup}} \rightarrow O_{\text{Apply}} \rightarrow O_{\text{Store}} \rightarrow R\)

关键设计¶

Search阶段——自适应仓库搜索：
- 两种搜索策略：(a) 若用户指定仓库名，直接调用GitHub search_by_name API；(b) 若未指定，Agent从查询中提取GitHub topics列表，调用search_by_topic API搜索
- 仓库功能判断：Agent读取每个候选仓库的README，分析其功能并判断是否适用于当前任务
- 缓存检索：优先从之前存储的仓库中检索，Precision@1达到100%
双层经验学习机制（Human Experience Learning）：
- Issues学习：在Apply阶段遇到问题时，Agent将问题总结为查询\(Q_S\)，调用GitHub Issues API搜索相关Issue，逐一评估其适用性，提取解决方案
- PRs学习：在Setup阶段遇到环境配置问题或代码bug时，Agent搜索Pull Requests找到修复方案，通过File_Modification子任务修改源文件
- 数学形式化：\(A_{\text{search}}(Q_S) = \mathcal{M}_{P_{\text{abs}}}(Q, H)\)，其中\(H\)为累积历史信息
安全隔离执行：仓库克隆到Docker环境中，所有后续命令在隔离环境中执行，确保安全性

损失函数¶

本文为Agent系统设计，不涉及传统训练损失。基于GPT-4（gpt-4-32k）的Function Calling能力实现，temperature=0.6。

实验¶

主实验¶

仓库	领域	查询数	Search成功率	Setup成功率	Apply成功率	Store成功率
Qlib	金融	8	77.5	75.0	67.5	67.5
Bringing-Old-Photos	CV	12	100.0	85.0	63.3	63.3
Sniffles	生物	3	100.0	100.0	100.0	100.0
AiZynthFinder	化学	7	83.6	80.0	69.1	69.1

主要发现：平均69.4%成功率；不同仓库间成功率差异大（Sniffles 100% vs Bringing-Old-Photos 63.3%），反映了仓库非标准化的现实挑战。

消融实验——计算成本分析¶

仓库	平均API调用数	平均Token数
Qlib	32.8	199,388
Bringing-Old-Photos	28.9	80,286
Sniffles	16.3	47,440
AiZynthFinder	30.5	90,639

关键发现¶

Search阶段是主要瓶颈之一：需要Agent从用户查询中推断仓库功能/领域并生成相关GitHub topics，对抽象理解能力要求高
Apply阶段对成功率影响最大：不同仓库的使用方式差异大，需要深层理解
缓存检索100%准确：Store-and-Retrieve机制有效减少重复搜索开销
三类主要失败原因：仓库选择错误（README描述不清）、环境配置失败（Dockerfile过时）、执行配置错误（参数设置错误）

亮点¶

方向前瞻：将GitHub仓库视为工具资源池的思路具有极大的扩展性，理论上可覆盖任意专业领域
经验学习机制：利用GitHub Issues/PRs作为人类经验知识库，巧妙解决非标准化问题
分层架构设计：四阶段流程清晰，每阶段可独立优化
全开源：数据集OpenAct和代码均开源

局限性¶

评估规模较小：仅4个仓库、30个查询，统计显著性受限
高度依赖GPT-4的推理能力，开源模型表现未知
Docker隔离增加了部署复杂度
每个查询的token消耗巨大（平均约10万token），成本高
对README质量敏感，文档不清晰的仓库容易失败
结果不稳定——重复实验有较大方差，部分源于网络连接和LLM推理随机性

评分¶

创新性: ⭐⭐⭐⭐⭐ — 将GitHub作为动态工具库的思路非常新颖
实用性: ⭐⭐⭐⭐ — 对扩展Agent能力边界有重要价值，但token成本高
技术深度: ⭐⭐⭐⭐ — 分层架构和双层经验学习设计合理
实验充分度: ⭐⭐⭐ — 规模偏小，仅4个仓库30个查询
总体推荐: ⭐⭐⭐⭐ — 方向重要、系统设计完整，实验规模可以更大