讓兩個大模型在線吵架，跑通全網95%科研代碼｜深勢Deploy-Master

機器之心發布

科學計算領域已經積累了數量空前的開源軟件工具。從生物信息學、化學模擬，到材料計算、物理仿真與工程設計，幾乎每一個學科方向，都形成了自己的生態。在 GitHub 等平臺上，成千上萬個代碼倉庫聲稱可以被用于科研實踐。

但一個長期存在、卻始終沒有被系統性解決的事實是：絕大多數科學軟件，停留在 “被發布過”，而不是 “可以直接運行” 的狀態

在科研實踐中，我們往往需要花費數天甚至數周時間反復解決編譯失敗、依賴沖突、系統不兼容等問題，才能在本地 “勉強跑通” 一個工具。這樣的運行環境高度依賴個人經驗，往往是臨時的、不可移植的，也很難被他人復現或復用。每個研究者、每個實驗室，都在手工維護自己的運行環境，而不是在一個共享、可復現的執行基礎設施之上開展工作。

這種模式帶來的問題，并不只是效率低下。更關鍵的是，它在結構上限制了科學軟件的三件事情：可復現性、大規模評估，以及系統性集成。即便容器化、云計算和 HPC 平臺已經顯著降低了算力門檻，這一 “部署瓶頸” 依然真實存在，并且長期制約著科學軟件的可用性。

隨著AI for Science（AI4S）的興起，這一問題被進一步放大。在新的科研范式中，AI 系統不再只是輸出預測結果，而是需要與真實的科學工具發生緊密交互：調用求解器、執行模擬程序、運行分析管線、處理真實數據。在這樣的背景下，一個工具是否 “真的能跑”，不再是工程細節，而是第一性問題。

這一問題在Agentic Science場景中表現得更加尖銳。如果工具依賴隱含環境、執行高度脆弱，那么智能體的規劃將無法真正落地，執行失敗也無法被結構化分析，更不可能轉化為可學習的執行軌跡。

從這個角度看，工具是否部署就緒，已經成為制約 AI4S 與 Agentic Science 規模化發展的結構性瓶頸。

基于這些觀察，我們逐漸形成了一個判斷：科學軟件的問題，并不在于工具不夠多，而在于缺乏一個能夠將工具系統性轉化為可執行事實的共享基礎設施。Deploy-Master，正是在這一背景下被提出的。

在真實世界中，部署并不是一個孤立步驟，而是一條連續鏈路：工具能否被發現、是否被正確理解、能否構建環境，以及是否真的可以被執行。Deploy-Master 正是圍繞這條鏈路，被設計為一個以執行為中心的一站式自動化工作流。

Search Agent

搜索科研錨點

在大規模場景下，部署的第一個難題并不在構建，而在于發現。如果候選工具集合本身存在系統性偏差，后續所有自動化都會被放大為偏差。

為此，我們從91 個科學與工程領域出發，構建了一個覆蓋 AI4S 實際應用場景的學科空間，并使用語言模型擴展搜索關鍵詞，在 GitHub 與公共網絡中進行大規模檢索。初始召回得到的倉庫，會作為 “錨點”，通過依賴關系、引用關系、共享貢獻者和文檔鏈接等信號進行迭代擴展，從而避免僅依賴關鍵詞搜索帶來的盲區。

隨后，我們通過結構啟發式規則剔除明顯不可執行的倉庫，并由 Agent 進行語義判斷，確認其是否構成一個可執行科學工具。通過這一多階段漏斗流程，我們將最初約 50 萬個倉庫，收斂為 52550 個進入自動部署流程的科學工具候選。這一步的意義，不僅在于篩選工具，更在于第一次以結構化方式刻畫了真實科學工具世界的規模與邊界。

雙模型博弈

實現 95% 成功率

在構建階段，我們面對的并不是一個 “有明確說明書” 的世界。大量科學軟件倉庫的構建信息是零散的、不完整的，甚至相互矛盾的。README 文件可能早已過期，已有 Dockerfile 也未必反映當前代碼狀態，而關鍵依賴往往只存在于作者本地環境中。

Build Agent 會系統性地遍歷倉庫中的構建線索，并在必要時進行補充信息檢索，生成初始構建方案。早期實驗表明，僅依賴單一模型生成構建規格，成功率只有 50%–60%，失敗主要源于構建信息中大量隱含、未被顯式表達的假設。

為此，Deploy-Master 引入了雙模型評審與辯論（debate）機制：一個模型提出構建規格，另一個模型獨立審查并主動尋找潛在不一致、缺失依賴或環境假設，提出修正建議。兩者通過多輪交互，不斷修正方案，直到形成穩定、可執行的構建規格。這一機制將整體成功率提升到了 95% 以上

每一個工具最終都會通過一個最小可執行命令進行驗證。只有通過執行驗證的工具，才會被視為成功部署，并被進一步結構化、注冊和發布到玻爾與 SciencePedia 上，使其可以被直接使用，或被其他 Agent（例如 SciMaster）調用。

從構建時間的分布來看，大規模部署并不是一個 “均勻” 的過程。盡管大多數工具可以在 7 分鐘左右完成構建，但整體分布呈現出明顯的長尾特征。一部分工具僅包含輕量級腳本或解釋型代碼，構建過程相對簡單；而另一部分工具則涉及復雜的編譯流程、深層依賴以及系統級庫配置，其構建時間顯著更長。

這種差異并不會阻止整體流程的推進，但它決定了部署在規模化條件下的成本結構。

在成功部署的 50112 個工具中，我們觀察到一個高度異構的語言分布。工具覆蓋了 170 多種編程語言，其中 Python 占據了最大比例，其次是 C/C++、Notebook 形式的工具、R、Java 等。絕大部分語言部署成功率都穩定維持在較高水平。少數成功率相對較低的語言，主要集中在依賴復雜編譯鏈或系統級庫的場景，例如 C/C++、Fortran 以及部分 R 工具。

這并不意味著這些語言 “天生更難部署”，而是反映了其工具鏈對底層環境的耦合程度更高，從而放大了構建規格中的不確定性。從部署的角度看，語言本身并不是決定性因素，環境耦合強度才是。在 2438 次失敗的構建嘗試中，我們對失敗原因進行了系統性統計。結果顯示，失敗并非均勻分布，而是高度集中在少數幾類問題上。最主要的失敗來源是構建流程錯誤，包括構建步驟與倉庫當前狀態不一致、關鍵依賴缺失、編譯器或系統庫不匹配等。這類失敗遠遠多于資源不足、網絡異常或權限問題。與此同時，資源相關錯誤在高并發階段也確實出現過，并直接推動了我們對調度策略和隔離機制的后續改進。

這進一步說明，在規模化部署中，失敗不應被視為異常，而應被視為系統暴露問題、進而自我修正的信號。

通過統一的執行基礎設施，我們得以系統性地觀察科學軟件在真實環境中的部署行為：哪些環節最容易失敗，哪些隱含假設最常被觸發，哪些工具鏈最容易放大不確定性。這種可觀測性本身，正是 Deploy-Master 希望建立的基礎之一。它讓 “科學軟件難以部署” 從一種經驗判斷，轉化為可以被量化、被分析、被持續改進的工程對象。

為 Agentic Science 構建行動基座

Deploy-Master 的直接產出，是一個由數萬條執行驗證工具構成的集合。但更重要的是，它為社區 Agent 與各類 Master Agent 提供了一個長期缺失的基礎前提

對 Agent 而言，工具調用并不是抽象動作，而是必須在現實環境中成功落地的執行過程。只有當工具被統一構建、驗證并注冊為可執行能力，Agent 才真正擁有穩定的 action space，規劃、執行與學習之間的閉環才得以成立。這也使得不同來源的社區 Agent，可以共享同一批經過執行驗證的工具能力，而不再各自維護脆弱、不可復現的運行環境。

這一方法論的意義，并不局限于科學計算。科學工具往往被視為自動化部署中最困難的一類：依賴復雜、系統耦合強、文檔不完整、對環境高度敏感。如果在這樣一個 “最難場景” 中，仍然可以通過以執行為中心的設計，在萬級規模下穩定地產生可運行工具，那么結論已經非常清晰 ——問題不在工具類型，而在于是否建立了以執行為核心的基礎設施

這一判斷同樣適用于更廣泛的軟件工具生態：工程工具、數據處理系統、專業軟件乃至各類 Agent Tooling。只要工具最終需要被執行，其部署問題就無法繞開 “不完美信息” 這一現實前提。

Deploy-Master 并未解決所有問題。異構硬件、分布式計算、語義級 I/O 接口以及與物理實驗系統的閉環集成，仍然是未來需要面對的挑戰。但有一件事情已經足夠清楚：在 Agentic Science 時代，執行不是推理之后的附屬步驟，而是所有能力得以成立的前提。

當 “工具能不能跑” 不再是一個默認假設，而成為一個被系統性驗證的事實，科學智能體才真正開始擁有與現實世界交互的基礎。而 Deploy-Master，正是邁向這一執行現實的一次嘗試。