ToolRosetta：通过自动工具标准化连接开源仓库与大语言模型智能体 ToolRosetta: Bridging Open-Source Repositories and Large Language Model Agents through Automated Tool Standardization
自动将科学代码仓库标准化为LLM智能体可调用工具，覆盖六大领域122个仓库，转换成功率61.5%
前置知识
Model Context Protocol (MCP)
MCP是一种标准化的工具接口协议，用于统一不同软件服务的调用方式。它定义了统一的输入输出格式、错误处理机制和通信协议，使得异构的工具可以以一致的方式被语言模型调用。MCP将各种科学计算功能封装为标准化的服务端点，支持异步调用和并发执行，为智能体提供可靠的工具调用基础设施。
理解MCP是理解ToolRosetta如何实现工具标准化的基础，因为整个系统的目标就是将异构仓库转换为MCP兼容的服务，这是实现工具可重用性的关键技术。
LLM智能体
基于大语言模型的智能体是一种能够自主感知环境、推理规划并执行动作的系统。它通常采用ReAct推理-行动范式，通过迭代地解释任务、选择工具和基于中间结果更新行动来完成复杂任务。智能体的核心能力在于理解任务意图、规划执行步骤和调用外部工具，这是实现科学工作自动化的关键。
ToolRosetta的目标就是为LLM智能体提供可用的科学计算工具，理解智能体的工作原理有助于理解为什么工具标准化如此重要，以及标准化工具如何增强智能体的实际能力。
依赖解析
依赖解析是指确定软件项目所需的所有外部库、框架和运行时环境，并确保它们能够正确安装和配置的过程。在Python中，这通常涉及解析requirements.txt、setup.py或pyproject.toml文件，处理版本兼容性问题，并处理系统级依赖和隐式依赖。依赖解析的复杂性在于依赖之间的冲突、版本不兼容以及平台差异等问题。
依赖解析是ToolRosetta面临的主要挑战之一，论文中75.3%的失败都是由于依赖和环境问题导致的，理解这个概念有助于认识到工具标准化的技术难点。
迭代修复
迭代修复是一种通过循环执行诊断、修正、验证的流程来逐步解决问题的方法。在ToolRosetta中，Review-Revise-Fix机制会分析运行失败的原因，识别错误来源，制定修复计划，重新生成代码，然后再次测试，直到成功达到修复次数上限。这种方法能够处理代码生成和环境配置中的不确定性，提高自动化成功率。
迭代修复是ToolRosetta实现高转换成功率的关键机制，论文中通过RRF机制将首次通过成功率从33.6%提升到61.5%，理解这个机制有助于理解系统的核心技术优势。
异构仓库
异构仓库是指具有不同接口设计、依赖结构、编码风格和执行逻辑的代码仓库。这些仓库可能由不同的开发者独立开发，遵循不同的组织结构和约定，使用不同的包管理工具，并且缺乏统一的API接口标准，使得难以被自动化系统直接使用。科学计算领域的异构性尤为突出，因为不同学科有不同的工具生态和编码习惯。
异构性是科学代码仓库难以被智能体使用的根本问题，也是ToolRosetta要解决的核心挑战。理解这个概念有助于认识到为什么需要专门的标准化框架，以及这个问题的复杂性和重要性。
研究动机
现有科学工具调用方法存在根本性局限。一方面，基于人工精心设计工具库的方法虽然可靠性高，但能力空间固定且有限，无法覆盖不断发展的科学计算需求。例如SciToolAgent使用500多个工具，SciSciGPT使用11个工具，CRISPR-GPT使用4个基于搜索的工具，这些系统表现良好但受限于预编译的能力空间。另一方面，试图直接利用更大规模开源生态的方法虽然工具覆盖范围广，但由于仓库异构性高，包括不同的接口设计、环境配置、调用约定，导致调用可靠性大幅下降。在实际科学任务中，大量计算功能已经存在于开源代码仓库中，但由于接口不一致、依赖环境脆弱、执行规范不完整、实现风格变化极大等问题，这些资源很少能以可直接使用的形式供智能体使用。结果是，大量科学工具被实际上锁定在LLM智能体之外，即使底层代码已经包含完成给定任务所需的计算能力，这成为科学智能体发展的主要瓶颈。
本文的目标是ToolRosetta的具体目标是建立一个自动化的仓库到工具标准化框架，能够将异构的科学代码仓库可靠地转换为标准化、可被LLM智能体调用的工具。量化的目标包括在覆盖多个科学领域的大规模仓库集合上实现较高的转换成功率，相比人工工程师显著减少标准化时间，转换后的工具能够在下游科学任务中提供可靠的执行能力，生成的工具层能够被不同的智能体框架重用从而扩大智能体可使用的计算能力空间。具体而言，系统需要在122个GitHub仓库上验证有效性，这些仓库涵盖35个子学科和六个领域，同时保持合理的转换效率和质量标准。
与已有工作不同的是，本文的独特切入角度是专注于仓库到工具标准化的上游问题，而不是下游的工具编排和任务规划。大多数现有工作假设工具已经可用，专注于如何更好地选择、组合和调用工具。而ToolRosetta抓住了被忽视的关键问题：如何自动将非标准化的、异构的科学代码仓库转换为可直接调用的工具。这一角度的独特性在于，它试图在固定的人工工具库和不可靠的直接仓库执行之间建立一个标准化层，既保持了工具覆盖的广度，又确保了调用的可靠性，从而为科学智能体提供一个可复用的计算能力层。这种标准化层一旦建立，就可以服务于不同的智能体框架，成为科学计算基础设施的重要组成部分。
核心方法
ToolRosetta的直觉就像一个智能的翻译官和标准化工程师，它理解不同科学仓库的方言，这些方言包括不同的代码组织方式、接口设计模式、依赖环境配置，然后将它们统一翻译成LLM智能体能听懂的标准语言，即MCP协议，并确保翻译后的代码能够正确运行。技术路线上，ToolRosetta采用分层多智能体架构，包含三个核心组件：Tool-search Agent负责从开源生态中检索和评估与任务相关的仓库，通过LLM驱动的语义解析、GitHub API检索和代码完整性评估来选择最佳候选；MCP-construction Agent通过八阶段自动化管道将符合条件的仓库转换为MCP兼容服务，这些阶段包括下载、分析、环境准备、代码生成、代码检查、运行测试、审查修正和最终完成；Planning Agent在工具注册后负责解释用户查询、规划执行步骤并调用合适的工具生成最终答案。整个pipeline通过多轮迭代修复来应对代码生成和环境配置中的不确定性，确保生成的工具既高效又可靠。
ToolRosetta的核心创新在于将仓库到工具的标准化视为一个可自动化的系统工程问题，而不是一次性的代码生成任务。这与已有方法有本质区别。SciToolAgent等系统假设工具已经手动准备好，专注于下游工具编排；RepoMaster等系统直接理解仓库内容而不建立标准化层。ToolRosetta的独特性体现在三个方面。首先，建立了完整的八阶段标准化pipeline，从仓库分析、环境准备、代码生成到验证修复，每个阶段都有明确的输入输出和质量控制点，这种结构化设计使得系统能够处理复杂的多步骤转换过程。其次，引入Review-Revise-Fix迭代修复机制，通过诊断、修正、验证的循环逐步解决代码和环境问题，这比单次生成方法大大提高了成功率。最后，生成的工具遵循MCP协议，成为可被不同智能体框架重用的标准化能力层，而不绑定到特定的智能体架构，这种设计使得工具的标准化过程既保持了自动化效率，又通过迭代机制保证了可靠性。
方法步骤详情
ToolRosetta的标准化流程包含八个明确的阶段。第一阶段是下载，将选定的GitHub仓库克隆到本地工作空间，为后续解析、测试和服务构建提供基础。第二阶段是分析，使用DeepWiki等工具解析仓库源代码和文档，识别可复用的功能组件，推断可调用接口，恢复内部依赖关系，生成结构化的能力报告。第三阶段是环境准备，初始化Python环境，默认使用3.10版本，解析依赖规范文件，识别所需包和环境配置，自动安装依赖以构建可复现的执行环境。第四阶段是生成，基于能力报告使用LLM合成MCP兼容服务层，将仓库功能封装为标准化的异步执行接口，包含参数转换、异常处理和依赖管理规则。第五阶段是代码检查，扫描源模块提取可用符号字典，验证生成的MCP服务中的import语句和符号引用是否有效，检测到不一致时启动自动修复循环。第六阶段是运行，在准备好的执行环境中运行生成的MCP服务，通过自动验证套件测试初始化和核心工具接口行为。第七阶段是审查，当验证失败时，分析执行错误、失败测试用例、生成的包装代码和仓库结构信息，识别可能的失败源并制定结构化修复计划。第八阶段是完成，组织最终版本的MCP服务文件、依赖列表、使用说明和示例调用到标准化目录结构中，生成可部署的MCP包。在运行阶段失败时，系统会进入审查、生成、代码检查、运行的循环，最多执行三轮迭代修复。
技术新颖性
ToolRosetta的技术新颖性体现在多个方面。首先，在架构设计上，它将仓库到工具的标准化分解为八个明确的功能节点，每个节点专注于特定子问题，包括代码理解、环境构建、接口生成、验证修复，这种模块化设计使得系统既能处理异构仓库的复杂性，又能保持pipeline的可维护性和可扩展性。其次，在质量控制上，引入了结构化的验证和迭代修复机制。代码检查节点通过符号表分析验证接口一致性，审查节点通过多源信息融合诊断问题，RRF循环通过渐进式修正提高成功率，这与LLM-only单次生成方法有本质区别。第三，在接口标准化上，采用MCP协议作为统一工具接口，生成的服务支持异步调用和并发执行，这种标准化使得工具层可以在不同智能体框架间无缝迁移。第四，在检索策略上，Tool-search Agent结合了LLM语义解析、GitHub API检索和代码完整性评估，这种混合检索策略既考虑了语义相关性，又考虑了仓库的社区采用度和代码质量。最后，在安全性考虑上，论文系统讨论了wrapper级别和action级别的安全控制，包括路径白名单、隔离执行、参数化命令、资源配额等，这在工具标准化工作中往往是被忽视的重要方面。
实验结果
ToolRosetta在仓库标准化效率和下游任务执行方面都取得了显著成果。在效率方面，ToolRosetta平均每仓库完成时间为7.2分钟，相比Codex辅助人类工程师的31.6分钟减少了77.2%，实现了4.4倍加速。首次通过成功率为33.6%，即41个仓库，经过三轮迭代修复后提升至61.5%，即75个仓库，相比LLM-only基准的8.2%，即10个仓库，有大幅提升，虽然仍低于人类专家的90.2%，即110个仓库，但考虑时间成本后具有明显优势。成功率在各领域表现不同，地球与环境科学为50.0%，健康科学为37.5%，物理科学为35.7%，生物科学为29.4%，科学社区与社会为28.6%，计算机科学为25.0%。在下游任务执行方面，使用所有122个仓库构建的完整工具池，ToolRosetta在六大科学领域的平均验证成功率达到84.0%，其中物理科学为81%，地球与环境科学为79%，生物科学为84%，健康科学为79%，科学社区与社会和计算机科学均为100%。在23个被固定工具库覆盖范围之外的子学科中，ToolRosetta的平均验证成功率为82.5%，远高于SciToolAgent和ChemCrow的0.0%、RepoMaster的21.3%、OpenAgents的16.1%、OpenClaw的1.0%。工具增强实验显示，将ToolRosetta转换的工具注入到其他智能体框架中，所有系统都有显著提升，RepoMaster从16.3%提升到81.5%，OpenAgents从22.0%提升到82.0%，OpenClaw从1.3%提升到77.9%。失败分析显示，首次失败的81个仓库中，34个经过三轮RRF修复后被恢复，47个仍未解决。失败的两大主要类别是依赖和环境问题以及运行时代码生成错误。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 仓库转换成功率 | 成功转换仓库数除以总仓库数 | 61.5%即75个仓库，经过三轮RRF修复后 | LLM-only为8.2%即10个仓库，人类专家为90.2%即110个仓库 | 相比LLM-only提升53.3个百分点，相比人类专家低28.7个百分点但时间成本降低77.2% |
| 仓库转换平均时间 | 每仓库标准化时间，单位分钟 | 7.2分钟 | Codex辅助人类工程师为31.6分钟，LLM-only约为7分钟 | 相比人类工程师提升4.4倍 |
| 下游任务验证成功率六领域平均 | 验证成功的任务数除以总任务数 | 84.0% | RepoMaster在分布外子学科为21.3%，OpenAgents在分布外子学科为16.1%，OpenClaw在分布外子学科为1.0% | 在分布外子学科上远超所有基线，提升幅度超过60个百分点 |
| 工具增强效果 | 注入ToolRosetta工具后的成功率提升 | 工具可重用于多框架 | RepoMaster从16.3%提升到81.5%，OpenAgents从22.0%提升到82.0%，OpenClaw从1.3%提升到77.9% | 所有框架均有显著提升，平均提升约67个百分点 |
局限与改进
作者承认的主要局限性包括自动转换与人类专家完成之间仍存在差距，61.5%的成功率低于人类的90.2%。迭代自纠无法完全解决两大转换失败来源，环境重建包括损坏的远程依赖、平台特定配置、隐式系统状态假设，以及代码结构异构性，特别是为交互式探索设计的仓库，如GUI应用或基于notebook的工作流。当前实现仅针对Python仓库，大量R和C++等语言的科学代码未被覆盖。存在治理和安全挑战，因为从外部仓库转换工具会改变信任边界，从预先审查的封闭工具库转向未单独审查的外部代码。我的独立观察包括系统在健康科学和科学社区与社会等依赖配置复杂的领域初始成功率较低，首次通过均低于30%，虽然通过迭代修复有较大提升，但仍表明这些领域的仓库标准化难度更大。LLM-only基准的极低成功率表明单次生成无法处理端到端仓库标准化，证实了迭代修复机制的必要性。系统对仓库星数的依赖可能导致新兴但高质量的小众仓库被忽视。安全性讨论虽然全面，但缺乏系统性的风险评估和实证验证。
独立分析的弱点
ToolRosetta在依赖和环境重建方面存在明显弱点，75.3%的失败都归因于此。具体场景包括当仓库依赖的远程包已经失效或版本不兼容时，系统无法智能选择替代方案；当仓库依赖平台特定的系统库或硬件加速时，容器隔离环境可能无法提供这些资源；当仓库隐式依赖特定的系统状态或环境变量时，代码级修复无法解决问题。改进方向包括建立依赖健康度数据库和版本兼容性图谱，实现智能依赖替换；增强环境重建能力，支持多平台虚拟化和资源代理；开发系统依赖检测和配置规范化工具。在代码结构异构性方面，GUI应用和notebook工作流等交互式仓库缺乏程序化接口，改进方向包括开发交互模式到程序模式的转换模板；识别仓库中的核心计算模块并封装为可调用函数。在检索策略方面，过度依赖星数可能导致偏见，改进方向包括引入代码质量指标如测试覆盖率、文档完整性作为补充排序信号；支持用户明确指定仓库以绕过检索阶段。在安全性方面，缺乏自动化安全审计，改进方向包括集成静态代码分析工具检测常见漏洞；建立工具风险评估和分级执行机制；提供沙箱执行和资源监控功能。
未来方向
作者提出的未来工作方向包括将框架扩展到其他编程语言，如R、C加加、Java等。具体实现方式是为每种语言开发适配器，将原生入口点转换为MCP兼容工具。对于R包解析DESCRIPTION和NAMESPACE文件，对于C加加项目解析Makefile或CMake配置，对于Java项目解析Maven或Gradle构建文件。在安全治理方面，需要在包装级别和action级别实施更完善的安全控制，包括路径白名单、容器隔离、参数化执行、资源配额管理等。基于论文成果可延伸的方向包括增强检索能力，超越简单的星数排序，引入代码质量、社区活跃度、维护状态等多维信号；扩展修复能力，引入更智能的依赖解析和版本管理，处理复杂的依赖冲突；支持增量更新，当仓库更新时能够自动检测变化并更新标准化工具；建立工具质量评估和推荐系统，帮助用户选择最可靠的工具；支持跨仓库工具组合，自动检测不同仓库之间的兼容性并构建复合工具链；开发工具使用分析和优化机制，基于实际使用情况优化接口设计和性能表现。
复现评估
ToolRosetta的复现条件相对友好。数据和代码已开源，标准化的仓库数据和下游任务评估数据集可通过HuggingFace获取，源代码可在GitHub获取。实验基于122个真实的GitHub仓库，涵盖35个子学科和六个领域，这些仓库都是公开可访问的开源项目。算力需求方面，仓库标准化过程主要依赖LLM API调用和本地代码执行，不需要大规模GPU集群，但需要稳定的网络连接来下载仓库和依赖包。复现难度中等，主要挑战包括LLM API的配置和调用需要相应的API密钥；部分仓库的依赖可能在特定操作系统或Python版本下存在兼容性问题；实验结果可能因LLM模型版本和API服务的变化而有所波动。建议复现者按照论文中提供的参数设置进行实验，如检索50个仓库数、生成5个主题描述符数、最多三轮RRF修复，并注意记录LLM模型版本和执行环境配置以促进结果对比。
论文图表
这张图对比了脆弱流程和安全流程，用三个代表性案例说明了安全风险和防护措施。第一个案例展示了生物医学管道中的数据泄露风险，脆弱流程允许路径遍历攻击导致机密性违规，而安全流程通过路径护栏和容器隔离实现机密性防御。第二个案例展示了传统工具调用中的命令注入风险，脆弱流程直接执行shell命令导致完整性违规，而安全流程通过命令护栏和参数化执行实现完整性防御。第三个案例展示了高性能计算环境中的资源耗尽风险，脆弱流程无限制执行导致可用性违规，而安全流程通过资源护栏和配额执行实现可用性防御。
这张图对理解论文很重要，因为它直观展示了从开源仓库转换工具带来的安全风险以及相应的防护措施，这是论文中讨论的安全治理部分的核心内容，帮助读者理解为什么需要wrapper级别和action级别的安全控制以及这些控制如何工作。