深势科技Deploy-Master：自动化部署超5万科学工具，为Agentic Science铺平执行之路

过去几十年，科学计算领域涌现了无数开源工具，但能够真正“开箱即用”的却寥寥无几。深势科技推出的Deploy-Master以执行为核心，通过自动化工作流一次性部署验证超过5万个工具，为Agentic Science的落地奠定了坚实基础。

在过去的数十年间，科学计算领域积累了数量空前的开源软件资源。

从生物信息学、化学模拟，到材料计算、物理仿真与工程设计，几乎每一个细分学科都逐渐形成了自己独特的工具生态。在GitHub等代码托管平台上，成千上万个仓库声称可以直接用于科研实践。

然而，一个长期存在却始终未能被系统性解决的现实是：绝大多数科学软件仅仅停留在“被发布”的阶段，远未达到“可直接运行”的状态。

在真实的科研过程中，研究者往往需要耗费数天甚至数周时间，反复应对编译失败、依赖冲突、系统不兼容等棘手问题，才能勉强在本地环境中跑通一个工具。

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

这种模式带来的问题远不止效率低下。更重要的是，它在结构上限制了科学软件的三大核心能力：可复现性、大规模评估能力，以及系统性集成的可能性。

即便容器化、云计算和HPC平台已大幅降低算力门槛，这一“部署瓶颈”依然真实存在，并且长期制约着科学软件的广泛可用性。

随着AI for Science（AI4S）的兴起，这一问题被进一步放大。

在新的科研范式中，AI系统不再仅仅是输出预测结果，而是需要与真实的科学工具发生深度交互：

1. 调用求解器；

2. 执行模拟程序；

3. 运行分析管线；

4. 处理真实数据。

在这样的背景下，一个工具是否“真的能跑”，不再是工程细节，而是关乎研究可行性的第一性问题。

这一问题在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）调用。

从构建时间的分布来看，大规模部署并非一个“均匀”的过程。

尽管大多数工具可在7分钟左右完成构建，但整体分布呈现出明显的长尾特征。

一部分工具仅包含轻量级脚本或解释型代码，构建过程相对简单；

而另一部分工具则涉及复杂的编译流程、深层依赖以及系统级库配置，其构建时间显著更长。

这种差异并不会阻碍整体流程的推进，但它决定了部署在规模化条件下的成本结构。

在成功部署的50,112个工具中，我们观察到一种高度异构的语言分布。

工具覆盖了170多种编程语言，其中Python占据最大比例，其次是C/C++、Notebook形式的工具、R、Java等。

绝大部分语言的部署成功率都稳定维持在较高水平。

少数成功率相对较低的语言，主要集中在依赖复杂编译链或系统级库的场景，例如C/C++、Fortran以及部分R工具。

这并不意味着这些语言“天生更难部署”，而是反映了其工具链对底层环境的耦合程度更高，从而放大了构建规格中的不确定性。

从部署的角度看，语言本身并非决定性因素，环境耦合强度才是关键。在2,438次失败的构建尝试中，他们对失败原因进行了系统性统计。

结果显示，失败并非均匀分布，而是高度集中在少数几类问题上。最主要的失败来源是构建流程错误，包括构建步骤与仓库当前状态不一致、关键依赖缺失、编译器或系统库不匹配等。这类失败远多于资源不足、网络异常或权限问题。

与此同时，资源相关错误在高并发阶段也确实出现过，并直接推动了对调度策略和隔离机制的后续改进。这进一步说明，在规模化部署中，失败不应被视为异常，而应被视为系统暴露问题、进而自我修正的信号。

通过统一的执行基础设施，他们得以系统性地观察科学软件在真实环境中的部署行为：

哪些环节最容易失败，

哪些隐含假设最常被触发，

哪些工具链最容易放大不确定性。

这种可观测性本身，正是Deploy-Master希望建立的基础之一。

它让“科学软件难以部署”从一种经验判断，转化为可以被量化、被分析、被持续改进的工程对象。

从可运行工具，到Agentic Science的执行地基

Deploy-Master的直接产出，是一个由数万条执行验证工具构成的集合。但更重要的是，它为社区Agent与各类Master Agent提供了一个长期缺失的基础前提。

对Agent而言，工具调用并不是抽象动作，而是必须在现实环境中成功落地的执行过程。

只有当工具被统一构建、验证并注册为可执行能力，Agent才真正拥有稳定的action space，规划、执行与学习之间的闭环才得以成立。这也使得不同来源的社区Agent，可以共享同一批经过执行验证的工具能力，而不再各自维护脆弱、不可复现的运行环境。

这一方法论的意义，并不局限于科学计算。

科学工具往往被视为自动化部署中最困难的一类：

依赖复杂

系统耦合强

文档不完整

对环境高度敏感。

如果在这样一个“最难场景”中，仍然可以通过以执行为中心的设计，在万级规模下稳定地产生可运行工具，那么结论已经非常清晰——

问题不在于工具类型，而在于是否建立了以执行为核心的基础设施。

这一判断同样适用于更广泛的软件工具生态：工程工具、数据处理系统、专业软件乃至各类Agent Tooling。

只要工具最终需要被执行，其部署问题就无法绕开“不完美信息”这一现实前提。

Deploy-Master并未解决所有问题。异构硬件、分布式计算、语义级I/O接口以及与物理实验系统的闭环集成，仍然是未来需要面对的挑战。

但有一件事已经足够明确：在Agentic Science时代，执行不是推理之后的附属步骤，而是所有能力得以成立的前提。

当“工具能不能跑”不再是一个默认假设，而成为一个被系统性验证的事实，科学智能体才真正开始拥有与现实世界交互的基础。而Deploy-Master，正是迈向这一执行现实的一次重要尝试。