深势科技Deploy-Master：解锁科学计算的执行瓶颈

科学计算领域历经数十年发展，涌现出无数开源工具，然而真正能「开箱即用」的却寥寥无几。深势科技的Deploy-Master以执行为核心，通过自动化工作流一次性部署验证超过5万个工具，为Agentic Science的发展铺平道路。

在几十年的发展中，科学计算领域积累了海量的开源软件工具。从生物信息学、化学模拟到材料计算、物理仿真与工程设计，几乎每一个学科方向都形成了自己的工具生态。GitHub等平台上，成千上万的代码仓库宣称可用于科研实践。

然而，一个长期存在且未被系统性解决的问题是：绝大多数科学软件仅停留在「被发布」的状态，而非真正能够「直接运行」。在真实的科研实践中，研究人员往往需要花费数天甚至数周的时间，反复解决编译失败、依赖冲突、系统不兼容等问题，才能在本地「勉强跑通」一个工具。

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

这种模式不仅效率低下，更在结构上限制了科学软件的三件大事：可复现性、大规模评估以及系统性集成。即便容器化、云计算和HPC平台已经显著降低了算力门槛，这一「部署瓶颈」依然真实存在，并长期制约着科学软件的可用性。

随着AI for Science（AI4S）的兴起，这一问题被进一步放大。在新的科研范式中，AI系统不再只是输出预测结果，而是需要与真实的科学工具进行紧密交互。

在这样的背景下，深势科技逐渐意识到：科学软件的问题并不在于工具不够多，而在于缺乏一个能够将工具系统性转化为可执行事实的共享基础设施。于是，Deploy-Master应运而生。

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

Search Agent：百万级仓库搜索

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

为此，他们从91个科学与工程领域出发，构建了一个覆盖AI4S实际应用场景的学科空间，并使用语言模型扩展搜索关键词，在GitHub与公共网络中进行大规模检索。初始召回的仓库作为「锚点」，通过依赖关系、引用关系、共享贡献者和文档链接等信号进行迭代扩展，从而避免仅依赖关键词搜索带来的盲区。

随后，他们通过结构启发式规则剔除明显不可执行的仓库，并由agent进行语义判断，确认其是否构成一个可执行的科学工具。通过这一多阶段漏斗流程，他们将最初约50万个仓库收敛为52,550个进入自动部署流程的科学工具候选。

Build Agent：双模型辩论

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

Build Agent会系统性地遍历仓库中的构建线索，并在必要时进行补充信息检索，生成初始构建方案。早期实验表明，仅依赖单一模型生成构建规格的成功率只有50%–60%，失败主要源于构建信息中大量隐含、未被显式表达的假设。

为此，Deploy-Master引入了双模型评审与辩论（debate）机制：一个模型提出构建规格，另一个模型独立审查并主动寻找潜在不一致、缺失依赖或环境假设，提出修正建议。两者通过多轮交互，不断修正方案，直到形成稳定、可执行的构建规格。这一机制将整体成功率提升到了95%以上。

从构建时间的分布来看，大规模部署并非均匀过程。尽管大多数工具可以在7分钟左右完成构建，但整体分布呈现出明显的长尾特征。这种差异决定了部署在规模化条件下的成本结构。

在成功部署的50,112个工具中，观察到一个高度异构的语言分布。工具覆盖了170多种编程语言，其中Python占据最大比例，其次是C/C++、Notebook形式的工具、R、Java等。绝大部分语言部署成功率都稳定维持在较高水平。

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

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

对Agent而言，工具调用并非抽象动作，而是必须在现实环境中成功落地的执行过程。只有当工具被统一构建、验证并注册为可执行能力时，Agent才真正拥有稳定的action space。

这一方法论的意义并不仅限于科学计算。科学工具往往被视为自动化部署中最困难的一类：依赖复杂、系统耦合强、文档不完整、对环境高度敏感。如果在这样一个「最难场景」中仍然可以通过以执行为中心的设计在万级规模下稳定地产生可运行工具那么结论已经非常清晰：

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

这一判断同样适用于更广泛的软件工具生态：工程工具、数据处理系统、专业软件乃至各类Agent Tooling。只要工具最终需要被执行其部署问题就无法绕开「不完美信息」这一现实前提。