機器之心發(fā)布

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

但一個長期存在、卻始終沒有被系統(tǒng)性解決的事實是：絕大多數(shù)科學(xué)軟件，停留在 “被發(fā)布過”，而不是 “可以直接運行” 的狀態(tài)

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

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

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

這一問題在Agentic Science場景中表現(xiàn)得更加尖銳。如果工具依賴隱含環(huán)境、執(zhí)行高度脆弱，那么智能體的規(guī)劃將無法真正落地，執(zhí)行失敗也無法被結(jié)構(gòu)化分析，更不可能轉(zhuǎn)化為可學(xué)習(xí)的執(zhí)行軌跡。

從這個角度看，工具是否部署就緒，已經(jīng)成為制約 AI4S 與 Agentic Science 規(guī)模化發(fā)展的結(jié)構(gòu)性瓶頸。

基于這些觀察，我們逐漸形成了一個判斷：科學(xué)軟件的問題，并不在于工具不夠多，而在于缺乏一個能夠?qū)⒐ぞ呦到y(tǒng)性轉(zhuǎn)化為可執(zhí)行事實的共享基礎(chǔ)設(shè)施。Deploy-Master，正是在這一背景下被提出的。

在真實世界中，部署并不是一個孤立步驟，而是一條連續(xù)鏈路：工具能否被發(fā)現(xiàn)、是否被正確理解、能否構(gòu)建環(huán)境，以及是否真的可以被執(zhí)行。Deploy-Master 正是圍繞這條鏈路，被設(shè)計為一個以執(zhí)行為中心的一站式自動化工作流。

Search Agent

搜索科研錨點

在大規(guī)模場景下，部署的第一個難題并不在構(gòu)建，而在于發(fā)現(xiàn)。如果候選工具集合本身存在系統(tǒng)性偏差，后續(xù)所有自動化都會被放大為偏差。

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

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

雙模型博弈

實現(xiàn) 95% 成功率

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

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

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

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

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

這種差異并不會阻止整體流程的推進，但它決定了部署在規(guī)?；瘲l件下的成本結(jié)構(gòu)。

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

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

這進一步說明，在規(guī)?；渴鹬校〔粦?yīng)被視為異常，而應(yīng)被視為系統(tǒng)暴露問題、進而自我修正的信號。

通過統(tǒng)一的執(zhí)行基礎(chǔ)設(shè)施，我們得以系統(tǒng)性地觀察科學(xué)軟件在真實環(huán)境中的部署行為：哪些環(huán)節(jié)最容易失敗，哪些隱含假設(shè)最常被觸發(fā)，哪些工具鏈最容易放大不確定性。這種可觀測性本身，正是 Deploy-Master 希望建立的基礎(chǔ)之一。它讓 “科學(xué)軟件難以部署” 從一種經(jīng)驗判斷，轉(zhuǎn)化為可以被量化、被分析、被持續(xù)改進的工程對象。

為 Agentic Science 構(gòu)建行動基座

Deploy-Master 的直接產(chǎn)出，是一個由數(shù)萬條執(zhí)行驗證工具構(gòu)成的集合。但更重要的是，它為社區(qū) Agent 與各類 Master Agent 提供了一個長期缺失的基礎(chǔ)前提

對 Agent 而言，工具調(diào)用并不是抽象動作，而是必須在現(xiàn)實環(huán)境中成功落地的執(zhí)行過程。只有當(dāng)工具被統(tǒng)一構(gòu)建、驗證并注冊為可執(zhí)行能力，Agent 才真正擁有穩(wěn)定的 action space，規(guī)劃、執(zhí)行與學(xué)習(xí)之間的閉環(huán)才得以成立。這也使得不同來源的社區(qū) Agent，可以共享同一批經(jīng)過執(zhí)行驗證的工具能力，而不再各自維護脆弱、不可復(fù)現(xiàn)的運行環(huán)境。

這一方法論的意義，并不局限于科學(xué)計算?？茖W(xué)工具往往被視為自動化部署中最困難的一類：依賴復(fù)雜、系統(tǒng)耦合強、文檔不完整、對環(huán)境高度敏感。如果在這樣一個 “最難場景” 中，仍然可以通過以執(zhí)行為中心的設(shè)計，在萬級規(guī)模下穩(wěn)定地產(chǎn)生可運行工具，那么結(jié)論已經(jīng)非常清晰 ——問題不在工具類型，而在于是否建立了以執(zhí)行為核心的基礎(chǔ)設(shè)施

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

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

當(dāng) “工具能不能跑” 不再是一個默認假設(shè)，而成為一個被系統(tǒng)性驗證的事實，科學(xué)智能體才真正開始擁有與現(xiàn)實世界交互的基礎(chǔ)。而 Deploy-Master，正是邁向這一執(zhí)行現(xiàn)實的一次嘗試。