AI從論文走到實驗室：人大高瓴提出長程研究工程系統AiScientist

作者 | 論文團隊

編輯丨ScienceAI

如果說 AI for Science 的一個長期目標，是讓模型不只回答科學問題、解釋實驗現象，而是真正幫助研究者完成一整條研究流程，那么機器學習研究工程無疑是最具挑戰性的場景之一。

因為在這里，系統面對的并不是一道題、一次生成，或者某個孤立的編碼任務，而是一條跨越論文理解、環境搭建、資源獲取、代碼實現、實驗運行、結果診斷與反復修復的連續任務鏈。每個環節本身都很難，而把這些環節在數十小時的跨度中真正接起來、持續推進，則更難。

近日，中國人民大學高瓴人工智能學院提出了一個名為 AiScientist 的系統，嘗試解決這一設定：long-horizon ML research engineering。

論文地址：https://arxiv.org/pdf/2604.13018

代碼地址：https://github.com/AweAI-Team/AiScientist

它試圖回答一個更具體、也更接近真實科研的問題：如果給 AI 一篇論文或者一道科學任務、一個基礎環境和有限預算，它能否從頭開始，把研究工程一步一步做下去？

答案正在變得越來越清晰。

在 MLE-Bench Lite 的 Detecting Insults 任務上，AiScientist 在 23 小時內自主完成了 74 輪實驗循環，將 validation AUC 從 0.903 提升到 0.982。在更具挑戰性的 PaperBench 上，它相對最佳匹配基線平均提升 10.54 分；在 MLE-Bench Lite 上，系統達到 81.82% Any Medal。進一步的機制分析還表明，真正決定長程研究工程能否持續推進的，關鍵不只是單步推理夠不夠強，而是系統能否在跨階段迭代中維護、繼承并利用不斷演化的項目狀態。

為什么研究工程比「會寫代碼」更難？

過去一年，AI for Research 的進展非常快。從 idea generation、literature synthesis，到代碼實現、實驗輔助、科學寫作，越來越多系統已經展現出實用價值。

但研究工程和單點能力不同。它不是把幾個能力模塊簡單拼起來就能完成的任務，而是一種典型的「長程、延遲反饋、狀態敏感」問題。

論文把這種困難概括得很準確。首先，研究規格往往是不完備的。論文不會把所有實現細節都寫清楚，模型需要自己補足缺失決策。其次，系統 setup 本身就很重，環境、依賴、數據和模型資源都可能成為阻塞點。再次，真正有價值的反饋往往要等實驗跑起來之后才會出現，而且問題來源常常是混雜的：可能是理解偏差，也可能是代碼實現、數據處理、超參選擇，甚至是基礎設施配置。

更關鍵的是，項目狀態必須被持續保留。一輪實驗產出的日志、配置、結果和診斷，都會直接影響下一輪決策。如果這些狀態在多輪推進中丟失，系統就很難判斷「哪里出了問題」，更難真正進入后續 refinement。

也正因如此，ML research engineering 不只是很多 local problem 的疊加，它本身還是一個更難的 systems problem。

AiScientist 的核心，不僅僅是「更會分工」，而且是「更會把狀態存住」

AiScientist 的核心思路，可以用論文中的一句話概括：thin control over thick state。

直白來說，就是把「控制」和「狀態」拆開。

一方面，系統保留一個輕量的頂層 Orchestrator，負責階段級決策與流程推進；另一方面，真正承載項目記憶的，不是不斷膨脹的對話上下文，而是 workspace 中持續演化的分析、計劃、代碼、實驗日志和結果記錄。

這套設計包含兩個互相配合的關鍵部分。

第一，是層級化 orchestration。

AiScientist 并不是把所有事都交給同一個 agent 去完成，而是讓不同角色分別處理論文理解、任務規劃、代碼實現、實驗執行與診斷修復等環節。這樣做的目的，不只是「多幾個 agent」，而是讓每個角色都在更合適的局部上下文里工作。

第二，是 File-as-Bus。

這是 AiScientist 更有辨識度的一點。它把共享工作區視為系統的「外部記憶」。論文分析、任務計劃、實現代碼、實驗日志、錯誤記錄等，都被持續寫回文件系統，成為后續階段可以重新讀取和利用的 durable artifacts。系統因此不需要每一輪都把歷史重新塞回 prompt，而是可以圍繞真實存在的項目證據繼續推進。

換句話說，AiScientist 的關鍵，不只是多智能體組織形式本身，而是它把狀態連續性做成了系統能力。

結果之外，更值得注意的是什么？

在 PaperBench 上，AiScientist 相對最佳匹配基線平均提升約 10.54 分。這意味著，它并不是只在個別 case 上有效，而是在從論文復現到完整工程實現的高難度任務中，穩定拉開了與現有方法的差距。

在 MLE-Bench Lite 上，AiScientist 達到了 81.82% Any Medal，說明它不只擅長「先跑出一個版本」，也能在更接近真實實驗優化的場景中持續改進結果。

但論文里最值得注意的，其實不只是這些數字，還有一個很重要的判斷：More interaction alone is not enough.

這句話背后對應的是一個常見誤解：很多人會自然地以為，只要讓系統多試幾次、多跑幾輪，就能自動獲得更強的長程能力。但論文的結論恰恰相反。額外的輪次只有建立在前面正確積累的狀態之上，才會真正轉化為有效進步；否則，更多交互反而可能意味著更高成本和更多噪聲。

File-as-Bus 為什么值得單獨看？

論文的消融實驗給出了一個非常清晰的信號。

移除 File-as-Bus 后，AiScientist 在 PaperBench 上下降 6.41 分，在 MLE-Bench Lite 上 Any Medal 下降 31.82 個百分點。這說明，狀態連續性并不是一個「有更好、沒有也行」的輔助設計，而是長程研究工程里真正決定系統能否持續推進的重要機制。

更有意思的是，這種退化并不是平均落在所有階段上。論文顯示，去掉 File-as-Bus 后，系統未必立刻連基礎可運行性都失去，但在更依賴后期 refinement 的指標上，退化會更明顯。

這意味著，File-as-Bus 的價值不只是幫助系統先搭一個能跑的腳手架，更重要的是讓系統在后續的診斷、修補、結果對齊與迭代優化中，真正把每一輪試錯都建立在前一輪留下的有效證據之上。

從這個角度看，它解決的并不只是 executability，更是 fidelity。

這項工作對 AI for Science 意味著什么？

AiScientist 之所以值得 AI for Science 社區關注，并不只是因為它在某個 benchmark 上拿到了更高分數，而是因為它觸及了一個更深層的問題：

如果 AI 想真正進入科學研究流程，它需要的不只是更強的單步能力，還需要在長程任務中維持項目狀態、銜接異構階段、持續吸收實驗反饋。

對于科學研究而言，這一點非常關鍵。因為真正高價值的科研任務，很少是一次生成就結束的。無論是算法復現、實驗設計、參數迭代，還是結果分析與修正，研究者都在和一種「不斷演化的項目狀態」打交道。

也正因為如此，AiScientist 給出的啟示并不局限于機器學習研究工程本身。它更像是在提醒整個 AI for Science 社區：未來更強的科學智能體，也許不僅要「會推理、會生成、會調用工具」，還要學會在長時間跨度里記住什么、保留什么、繼承什么、繼續推進什么。

從 benchmark 走向研究工具

論文還有一點值得注意：團隊并沒有把 AiScientist 停留在 benchmark 評測對象上，而是在繼續把它推進為真實可用的軟件系統。

這件事很重要。因為 benchmark 回答的是「能不能做」，而工具真正回答的是「能不能被用起來」。

如果 AI 研究系統未來真的要進入實驗、復現、調參與迭代的日常流程，那么它最終必須以工具形態存在，成為研究者工作流的一部分，而不只是論文中的一個分數。

小結

AiScientist 試圖推動的，并不只是一個更強的科研 agent，而是一種對長程研究工程的新理解：在真實科研任務中，真正重要的往往不是單次生成得多漂亮，而是系統能否在跨階段、跨輪次、跨文件的任務鏈中，把項目狀態穩定存住，并據此持續推進。

如果這一點成立，那么 AI 進入科研流程的方式，也將從「輔助某一步」逐漸走向「接手整條鏈路」。