科学软件的执行现实：Deploy-Master的突破

在过去的几十年里，科学计算领域积累了大量的开源软件工具，这些工具在生物信息学、化学模拟、材料计算、物理仿真与工程设计等多个学科方向都形成了自己的生态。

虽然GitHub等平台上成千上万的代码仓库声称可以被用于科研实践，但一个长期存在的问题是：绝大多数科学软件停留在“被发布过”的状态，而非“可以直接运行”。

高性能智能体的出现有望改善这一现状，帮助用户快速运行开源项目。

在真实的科研实践中，团队往往需要花费大量时间解决编译失败、依赖冲突、系统不兼容等问题，才能在本地“勉强跑通”一个工具。

这种运行环境高度依赖个人经验，往往是临时的、不可移植的，很难被他人复现或复用。每个研究者、每个实验室都在手工维护自己的运行环境，而不是在一个共享、可复现的执行基础设施上工作。

这种模式不仅效率低下，更在结构上限制了科学软件的三件大事：可复现性、大规模评估以及系统性集成。

随着AI for Science（AI4S）的兴起，这一问题被进一步放大。在新的科研范式中，AI系统需要与真实的科学工具紧密交互，调用求解器、执行模拟程序、运行分析管线、处理真实数据。

在此背景下，工具是否“真的能跑”，不再是工程细节，而是首要问题。

这一问题在Agentic Science场景中更加尖锐。如果工具依赖隐含环境、执行高度脆弱，那么智能体的规划将无法真正落地，执行失败也无法被结构化分析，更不可能转化为可学习的执行轨迹。

从这个角度看，工具是否部署就绪，已成为制约AI4S与Agentic Science规模化发展的结构性瓶颈。

研究团队逐渐形成了一个判断：科学软件的问题并不在于工具不够多，而在于缺乏一个能够将工具系统性转化为可执行事实的共享基础设施。

Deploy-Master正是在这一背景下被提出的。

在真实世界中，部署并非孤立步骤，而是一条连续链路：工具能否被发现、是否被正确理解、能否构建环境以及是否真的可以被执行。Deploy-Master正是围绕这条链路，设计为一个以执行为中心的一站式自动化工作流。

Search Agent：百万级仓库搜索

在大规模场景下，部署的第一个难题并不在构建，而在发现。如果候选工具集合存在系统性偏差，后续所有自动化都会放大偏差。

为此，团队从91个科学与工程领域出发，构建了一个覆盖AI4S实际应用场景的学科空间，并使用语言模型扩展搜索关键词，在GitHub与公共网络中进行大规模检索。

初始召回的仓库作为“锚点”，通过依赖关系、引用关系、共享贡献者和文档链接等信号进行迭代扩展，从而避免仅依赖关键词搜索带来的盲区。

随后，团队通过结构启发式规则剔除明显不可执行的仓库，并由Agent进行语义判断，确认其是否构成一个可执行的科学工具。

通过这一多阶段漏斗流程，团队将最初约50万个仓库收敛为52,550个进入自动部署流程的科学工具候选。这一步不仅筛选了工具，更首次以结构化方式刻画了真实科学工具世界的规模与边界。

Build Agent：双模型辩论

在构建阶段，团队面对的是一个“没有明确说明书”的世界。大量科学软件仓库的构建信息是零散的、不完整的，甚至相互矛盾的。

README文件可能早已过期，已有Dockerfile也未必反映当前代码状态，而关键依赖往往只存在于作者本地环境中。

Build Agent会系统性地遍历仓库中的构建线索，并在必要时进行补充信息检索，生成初始构建方案。

早期实验表明，仅依赖单一模型生成构建规格的成功率只有50%–60%，失败主要源于构建信息中大量隐含、未被显式表达的假设。

为此，Deploy-Master引入了双模型评审与辩论（debate）机制：一个模型提出构建规格，另一个模型独立审查并主动寻找潜在不一致、缺失依赖或环境假设，提出修正建议。

两者通过多轮交互不断修正方案，直到形成稳定、可执行的构建规格。这一机制将整体成功率提升到了95%以上。

每一个工具最终都会通过一个最小可执行命令进行验证。只有通过执行验证的工具才会被视为成功部署，并被进一步结构化、注册和发布到玻尔与SciencePedia上，使其可以被直接使用或被其他Agent（例如SciMaster）调用。