這項由卡內基梅隆大學電腦科學學院主導的研究發表於2026年5月，以預印本形式在arXiv上公開，編號為arXiv:2605.05724v1，有興趣深入了解的讀者可以通過該編號查詢完整論文。
研究本身要解決的問題，其實是機器學習領域裡一個看起來平常卻相當棘手的挑戰：一個新模型能不能自己做研究？不是泛泛地寫出一篇論文，而是真正地在電腦上動手改代碼、跑實驗、看結果、再改、再跑——就像人類研究員每天在實驗室里做的事情一樣。
以往的人工智慧研究輔助工具，要麼只會幫你寫文章，要麼只會調調參數，要麼只會建議下一步怎麼做，但它們很少能把"提出想法→改寫代碼→運行實驗→看懂反饋→再次改進"這整個閉環自動化地轉起來，更別說在這個過程中遇到錯誤、超出限制、結果不好之後，還能從中學習並調整方向。卡內基梅隆大學的這支團隊，正是把目標鎖定在這個完整的閉環上。
他們構建了一套"自動研究"系統，核心設計是讓多個專門負責不同方向的AI代理（就像一組分工協作的研究小助手）輪流提出假設、修改代碼、提交實驗、讀懂外部評測系統返回的結果，然後把這些經驗記錄下來，傳給下一輪繼續用。整個過程一旦啟動，人類不需要介入——不需要挑選哪個想法值得試，不需要修復崩掉的實驗，也不需要判斷某次失敗是否有價值。機器自己摸索，自己總結，自己繼續。
在實驗中，這套系統跑了三個不同的機器學習任務，合計提交了1197次正式實驗加上600次對照實驗。在"參數高爾夫"這個任務上，它把模型壓縮效率提升了0.81%；在"NanoChat-D12"語言模型預訓練任務上，它把核心評估分數從0.1618提升到0.2244，提升幅度高達38.7%；在CIFAR-10圖像分類速度任務上，它在滿足精度要求的前提下把訓練時間壓縮了4.59%。每一項結果都由獨立的外部評測系統驗證，研究團隊沒有在中途干預或修改規則。
---
一、這套系統到底在做什麼：一次實驗就是一次"提案+動手+看反饋"
要理解這套系統的工作方式，可以把它比作一個認真負責的實習研究員團隊正在廚房裡改進一道菜譜。每個人負責不同的方向——有人專門研究食材搭配，有人專門負責火候控制，有人專門琢磨調味，還有人專門分析之前每次嘗試的記錄。每次有人提出"我覺得改用這個食材會更好"，就真的去做一道菜，然後讓一個獨立的美食評委評分。評委的評分結果會被完整記錄下來：這次多少分、花了多長時間、有沒有超出食材預算、失敗原因是什麼。這些記錄會被傳給整個團隊，下次有人提新想法時，可以先看看之前哪些方向試過了、哪些超預算了、哪些方向雖然沒提升但離目標最近。
這套系統中，每一次"實驗"被稱為一個"trial"（試次）。每個試次包含四個要素：一個關於"這次改動為什麼有用"的假設、對訓練代碼的實際修改、外部評測系統給出的結果分數、以及被記錄下來供後續參考的反饋資訊。這四個要素構成了一次完整的研究動作，就像一次菜譜改進實驗從設想到上桌再到記錄結論的完整過程。
系統里有一個叫做"lineage"（血緣記錄）的核心機制，可以理解為那本越來越厚的"改良菜譜日誌"。每次實驗結束後，不論成功還是失敗，結果都會被追加進這本日誌。下一輪的AI代理在開始工作前，會先翻閱這本日誌，了解當前最好的結果是什麼、哪些方向試過了但沒用、哪些方向因為超出限制而被淘汰、最近有沒有什麼新思路值得借鑑。正是這本日誌，讓整個系統不會每次都從零開始亂撞，而是能夠沿著已有的經驗線索繼續往前推進。
---
二、三個不同的"競技場"：不同的限制條件，不同的反饋信號
為了驗證這套閉環系統是否真的有效，研究團隊選擇了三個截然不同的任務環境，每個環境都有自己獨特的"遊戲規則"和"得分方式"，就像用不同難度的關卡來測試同一套攻略是否通用。
第一個任務叫"參數高爾夫"。這個名字來自OpenAI發布的一個公開挑戰，規則很像真實的高爾夫球——分數越低越好，但還有嚴格的場地限制。具體來說，選手需要訓練一個語言模型，讓它在一個固定的文本數據集上達到儘量低的"驗證損失"（可以理解為模型讀文本時"猜詞"的錯誤率，越低表示模型越聰明）。但關鍵在於，整個程序打包後的文件大小不能超過16兆字節，訓練過程不能超過10分鐘，全程使用8塊高端顯卡（H100）。這意味著每個想法都要在"效果更好"和"體積更小"之間精準拿捏，稍微貪心一點就會因為文件超大而直接被淘汰。這個任務的主要反饋信號，就是文件大小和時間預算——每次超出限制，系統都會返回精確的"超出了多少字節"或"超時了多少秒"，這些資訊被直接傳回給下一輪的AI代理。
第二個任務叫"NanoChat-D12"。這是由著名AI研究者Andrej Karpathy開源的一套小型語言模型預訓練框架，任務目標是在固定的90分鐘計算時間內，儘可能提高模型在多個評估基準上的綜合分數（稱為CORE分數）。這個任務的獨特之處在於，它的反饋信號主要是"運行效率"——如果一個代碼改動讓訓練變快了，那省下來的時間就可以用來訓練更多輪次，相當於間接提升了最終分數。這就像給賽車手一個固定油量，跑完比賽你的排名取決於終點速度，所以提升引擎效率和降低輪胎磨損都能讓你跑得更遠。在這個任務中，AI代理最大的收穫之一，正是發現了訓練代碼中存在一個注意力計算模組效率低下的瓶頸，替換後省出了大量計算時間，這些時間隨即被用於訓練更多數據，分數因此大幅提升。
第三個任務叫"CIFAR-10 Airbench96"。CIFAR-10是一個經典的圖像分類數據集，裡面有飛機、汽車、鳥、貓等十類圖片，任務是訓練一個模型來準確區分它們。Airbench96在這基礎上加了一個頗具挑戰性的規則：模型在測試集上的平均準確率必須達到96%以上，然後在滿足這個精度門檻的前提下，誰的訓練時間越短誰就贏。這個"精度門檻"就像一道關卡，沒有達到它，再快也沒用。於是AI代理每次提出"加速訓練"的想法，都要先過一關"精度檢驗"——失敗了不會只收到一個籠統的"錯誤"提示，而是會得到詳細的"這次速度是多少、精度是多少、差了多少"，這些精確的失敗資訊同樣會被記入日誌，供後續改進參考。
---
三、分工協作的專家團隊：為什麼要有"專家"而不是一個全能代理
這套系統里有一個設計選擇，乍看之下不那麼顯眼，但實驗結果表明它相當關鍵：系統里不只有一個AI代理在工作，而是一群分工明確的"專家代理"，每個人只負責訓練流程的某一個方面。
以"參數高爾夫"任務為例，這裡一共有十個專家角色，分別負責模型架構設計、優化器調參、量化壓縮、正則化方法、損失函數設計、評估策略、課程學習、分詞方式、測試時訓練，以及一個專門負責綜合分析已有結果的"元搜索分析師"角色。每個專家有自己的工作目錄，有自己的提示詞說明自己該負責什麼、不該碰什麼，還有明確的"改動力度"指導——比如架構專家被告知，如果當前最好的版本已經在小參數上調來調去了，那就應該考慮更大幅度的結構性改動，而不是繼續微調同一個數字。
NanoChat-D12任務有五個專家，分別負責模型架構、優化策略、數據處理、訓練調度和系統級優化。CIFAR-10任務同樣有五個專家，覆蓋架構、優化、數據增強、損失函數和正則化。
每個專家都能看到同一份"日誌賬本"——所有人的實驗記錄都被匯總在共享的血緣記錄里。這意味著，當系統專家發現了訓練效率問題並修復了它，架構專家在下一輪工作時就能看到"系統專家剛剛省下了一批時間"這條資訊，並據此決定是否值得在這段時間裡嘗試更複雜的架構。資訊在不同專家之間流通，想法可以跨越角色邊界相互激發。
研究團隊在論文中做了一組對照實驗，把這種"分工專家+共享日誌"的設計和其他幾種方案做了比較。對照方案包括：只有一個全能代理獨自工作（單一通才），十個不分專業方向的普通代理同時工作（通用多代理），以及和標準系統完全相同但去掉了歷史記錄共享機制的版本（無血緣記錄）。
實驗結果用一個數字來概括就很清楚了：在同樣的200次實驗預算內，分工專家+共享日誌的版本找到了16次有效提升，無血緣記錄版本只找到了3次，然後之後跑了125次實驗都沒有再找到任何新的提升。沒有歷史記錄的系統，就像一個每天早上都失憶的研究員，每次都要從頭開始摸索，碰壁了也不知道上次是為什麼碰壁的。通用多代理版本雖然也有10個代理同時工作，但因為它們提出的想法高度重疊（最大的一個"想法類別"占了12%的提案，而分工專家版本只有3.5%），實際有效提升反而比分工專家版少。
衡量"提案多樣性"的方式也很有意思。研究團隊把每次實驗的假設文本用一種叫TF-IDF的算法轉換成向量，然後統計這些向量聚集成多少個真正不同的"想法簇"。分工專家版本在200次實驗中形成了134.8個有效想法簇，通用多代理只有41.1個，單一通才只有61.9個，而且單一通才有10.1%的提案幾乎是重複的（分工專家版本只有2%）。這說明，專業分工確實在幫助系統把注意力分散到更多不同的方向上。
---
四、失敗也是資訊：崩潰、超時、不達標都是有價值的反饋
在這套系統里，一次實驗"失敗"並不意味著這次嘗試毫無意義。研究團隊把每種失敗都仔細分類，並將失敗的具體資訊原封不動地傳遞給下一輪代理。
實驗狀態被劃分為九種。"keep"表示這次結果比之前最好的記錄更好，被正式保留。"discard"表示結果有效但沒有改善。"crash"表示訓練代碼運行出錯了，並沒有產生有效的評分。"preflight_crash"表示代碼在連GPU時間都沒用上之前就在本地檢查階段出錯了。"size_blocked"表示打包後文件超過了16兆的上限，直接被攔截。"train_budget_overrun"表示訓練階段超時了。"eval_budget_overrun"表示評估階段超時了。"disqualified"是專門給CIFAR任務用的，表示速度夠快但準確率沒達到96%的門檻。還有一種"harness_abort"，表示系統調度層面出了問題，這類失敗被標記為非實質性信號，不會傳遞給下一輪代理。
這種精細化的失敗分類，在實踐中起到了非常具體的作用。以參數高爾夫任務中的一個真實案例為例：第587次實驗提出了一個叫做"TTT-only z-loss"的技術改動（簡單說就是在測試時自適應階段引入一種額外的訓練目標），這個改動確實讓模型的驗證損失從1.0810下降到了1.072431，效果是好的——但文件打包後超出了16兆的上限2056個字節，被判為不合格。這個結果被完整記錄：分數是多少、超出了多少字節。下一輪的代理讀到這條記錄，知道"這個想法本身有效，只是體積太大"，於是專門針對壓縮部分進行優化，在保留同樣技術思路的前提下，從源代碼層面回收了足夠的字節空間，最終讓第596次實驗在15,995,930字節的合法範圍內實現了1.072251的分數，把這個原本"超限的好想法"變成了一個真正合格的提升。
CIFAR-10任務里有一個更生動的例子。第60次實驗跑完之後，時間只用了25.165秒（已經比起始點快了），但準確率只有0.9596，差了0.0004沒過96%的門檻，被判為"disqualified"（不達標）。這條記錄被傳給後續代理：速度已經夠快了，差的只是那一點點準確率。於是第70次實驗保留了所有加速改動，只把預熱階段的比例從10%調短到5%，結果準確率恢復到0.96008，時間保持在25.1464秒，成功通過了精度門檻。一次"差一點點"的不達標，直接告訴了系統應該調整哪個旋鈕。
---
五、NanoChat的故事：一個運行速度的發現如何滾雪球式地變成38.7%的提升
NanoChat-D12的實驗軌跡是這篇論文裡最完整的一個"故事弧"，值得詳細講一講，因為它清晰地展示了這套閉環系統是如何把一個系統層面的發現轉變成一系列連鎖的研究行動的。
故事從第7次實驗開始。系統專家代理在分析NanoChat-D12的訓練代碼時，發現了一個效率問題：原始代碼里，12層Transformer注意力模組中的部分層使用了一種叫做"masked SDPA"的計算路徑，這種路徑在當前GPU上運行時比另一種叫做"Flash SDPA"的計算路徑要慢。這就像一條雙車道高速公路里，有幾段路莫名其妙地縮窄成了單車道——整體速度被瓶頸拖慢了。代理把這幾層全部切換到Flash SDPA路徑，代碼改動本身並不複雜，但效果是可測量的：訓練速度加快了，在固定的90分鐘預算內可以訓練更多的數據。CORE分數從基準的0.1618上升到了0.1695，這是第一次有效提升。
這條記錄進入了血緣日誌。關鍵在於，它記錄的不只是"CORE提升了"，還記錄了"為什麼提升"——因為運行時間省下來了，所以可以多跑一些訓練步驟。後續的數據專家和調度專家讀到這條記錄，意識到時間預算現在有了富餘，可以擴大訓練數據的量。第20次實驗把訓練數據的比例從原始設置大幅擴展，這一步帶來了最大幅度的單次提升：CORE分數跳到了0.2029，單次提升0.0334。
接下來，第24次實驗進一步調整了不同訓練階段的數據混合比例（預訓練階段約12份、中間訓練階段約100份、最後階段約130份），第25次實驗在這個方向上進一步細化，把CORE分數推到了0.2241，形成了一個相對穩定的高點。最後，第156次實驗由另一個方向的代理提出了一個細小但有效的改動：在語言模型輸出頭之後添加一個零初始化的可學習偏置向量，這個向量可以讓模型學到詞彙層面的先驗分布，最終把CORE分數推到了0.2244。
整個過程，一個系統層面的運行效率發現，經過血緣記錄的傳遞，變成了數據預算的擴展決策，又變成了訓練階段配比的調整，最終在一個小型的模型結構改動上收尾。這條鏈條里的每一步，都是前一步的觀察結果催生的下一步假設。
---
六、實驗的嚴謹性：如何防止AI"作弊"
這套系統在設計上有一個貫穿始終的原則：評測必須由獨立於訓練代碼的外部機制來完成，不能讓代理自己報告自己的成績。這個原則看起來簡單，但實現起來需要在多處精心設計。
在參數高爾夫任務中，分數由官方評測路徑計算，代理提交的代碼無法接觸評測邏輯。在NanoChat-D12任務中，CORE分數由一個"受保護的解析器"從訓練日誌中提取，代理不能修改這個解析器，系統還會自動審計每次提交是否有代理嘗試碰觸解析器或評估器的文件，發現則直接標記為無效。在CIFAR-10任務中，訓練時間由外部Shell命令測量並寫入獨立的時間記錄文件，訓練腳本本身不能報告自己的運行時間，準確率評測也由外部分類器執行。
這種設計的意義在於，它在源頭上關閉了一種常見的"獎勵黑客"風險——如果允許AI代理修改評測代碼，那最簡單的"提升"方式就是讓代碼直接輸出一個更好看的假分數，而不是真正改進模型。外部評測機制確保了每一個記錄在案的分數都對應著真實的訓練效果。
每次提交前，系統還會先在本地做一次"預檢查"：語法檢查（用Python的編譯器確認代碼沒有語法錯誤）、大小檢查（用真實的壓縮算法模擬打包，提前判斷是否會超出16兆限制）。這兩步檢查不消耗GPU資源，可以快速過濾掉明顯不合格的提交，把寶貴的GPU時間留給真正有機會的實驗。
研究團隊還為系統設置了明確的終止條件：超過48小時的運行上限，或者超過4小時沒有找到任何新的有效改善就會停止。每次有新的有效提升出現，4小時的倒計時就會重置。
---
七、並行運行與效率：十個專家同時工作能快多少
在計算資源的使用上，研究團隊也做了一次有意思的測量。他們定義了一個"並行效率"指標，衡量多代理同時工作相比單代理串行工作能快多少倍。理論上，十個代理同時工作應該快十倍，但實際上因為所有代理共享同一個GPU資源池、共享日誌文件的讀寫鎖，效率會有所損耗。
測量結果是：單一通才代理每小時可以完成2.26次實驗；分工專家的十代理版本每小時完成18.15次，並行效率約為80%（理論最高值是十倍，實際達到了八倍左右）；通用十代理版本每小時完成16.79次，並行效率約為74%。這意味著，分工專家版本相比通用多代理版本不只是提案更多樣，連實際執行效率也略高——因為專家分工減少了代理之間對同一資源的爭搶。
這個效率數字在實踐中非常重要：如果反饋結果返回得太慢，後續代理在制定新提案時就用不上這些反饋，閉環的價值就會大打折扣。對於一個每次實驗本身就需要10分鐘到90分鐘的任務，保證足夠的並行吞吐量，是整套系統能在有限時間內完成大量探索的前提。
---
八、系統的邊界與局限：哪些事情它還做不到
研究團隊對這套系統的能力邊界有非常坦誠的描述。在整個1197次實驗中，AI代理提出的改動，本質上都屬於"組合已知技術"的範疇——把現有的高效注意力核、現有的正則化方法、現有的量化策略，以各種方式組合、遷移、適配到當前的任務環境中。
系統提出過的改動包括：把不同類型的注意力機制混合使用（如差分注意力、多頭潛在注意力）、在Transformer塊內部引入循環結構（類似狀態空間模型的思路）、修改學習率調度的形狀（從餘弦切換到WSD等）、引入GQA（分組查詢注意力，一種減少鍵值緩存體積的技術）、使用哈希嵌入替代標準詞嵌入、添加多任務預測目標、調整卷積深度和寬度的比例，以及嘗試自定步調的損失緩存策略。這些都是機器學習領域中存在的已知技術方向，系統的貢獻在於在特定約束條件下將它們有效組合。
然而，系統在整個過程中沒有提出任何可以被稱為"範式級創新"的想法——比如提出一種全新的神經網路基本操作，或者打破現有架構假設的根本性結構設計。論文作者明確寫道，這套系統在當前階段的觀察範圍內，無法做出類似"發明Transformer"這樣的結構性突破。這是一個誠實的自我定位，而非缺陷的掩蓋。
系統同樣不適合那些反饋模糊、無法自動驗證的任務場景。如果一個研究問題的評估需要人工判斷、或者實驗周期過長導致反饋無法及時返回，這套閉環就難以轉起來。它最適合的環境是：有明確的可量化目標、失敗可以被精確描述、每次實驗的時間成本在可接受範圍內、評測邏輯獨立於訓練代碼。
---
歸根結底，這項研究要說明的是：AI輔助研究不應該被定義為"AI生成一篇論文"或"AI提出一個大想法"，而應該被理解為"AI真正參與那個每天都在發生的改代碼-跑實驗-看結果-再改-再跑的循環"。當這個循環被忠實地自動化之後，它產生的不是一個漂亮的結論，而是一份可供檢查的軌跡——每次提案是什麼、代碼怎麼改的、評測系統怎麼說的、失敗原因是什麼、下一步怎麼變了。這份軌跡本身，就是研究過程的證據，而不只是研究結論的展示。
如果有一天AI系統真的能在這個閉環里提出範式級的新想法，那麼同一套評測機制就可以立刻檢驗那個想法是否真的成立——因為評測標準並不隨著想法的大小而改變。那時候，這套系統的價值會比現在更加凸顯。目前的成果已經說明，在"組合與改進"這個維度上，機器已經可以做得相當紮實；至於"發明"這個維度，暫時還是留給人類和未來更強大的模型去探索吧。有興趣深入了解技術細節的讀者，可以通過arXiv:2605.05724v1查閱完整論文，代碼和實驗軌跡也在論文中提到的GitHub倉庫公開。
---
Q&A
Q1：自動研究系統中的"血緣記錄"（lineage）是什麼，它有什麼用？
A：血緣記錄是系統在每次實驗結束後自動追加的一份歷史日誌，記錄了每次提案的假設內容、代碼改動、得分結果、失敗原因和耗時等資訊。下一輪AI代理在提新想法前會先翻閱這份日誌，避免重複踩已知的坑，也能基於之前成功的方向繼續深入。沒有這份記錄的對照實驗裡，系統在找到3次有效改進後就陷入了125次連續無效探索，說明歷史記錄對維持研究方向至關重要。
Q2：參數高爾夫任務里的文件大小限制為什麼那麼重要？
A：參數高爾夫要求整個程序（包括模型權重）打包後不超過16兆字節。這個限制直接影響模型複雜度，每次提出新架構或添加新功能，都必須同時考慮是否會撐破這個體積上限。論文中有個典型案例：第587次實驗找到了一個有效的技術改動，模型性能確實提升了，但文件超出上限2056字節被判無效。系統讀到這個精確的超出量，專門做了壓縮優化，最終在合規體積內復現了同樣效果。
Q3：NanoChat-D12任務的CORE分數從0.1618提升到0.2244，這個38.7%的提升是怎麼來的？
A：提升主要由三個疊加改動構成。第一步是系統專家發現訓練代碼中部分注意力層使用了低效的計算路徑，替換為更快的Flash SDPA後節省了訓練時間；第二步是把省下來的時間用於擴大訓練數據量，數據預訓練、中間訓練和最終訓練階段的比例從原始值調整為約12:100:130；第三步是在模型輸出層後添加了一個零初始化的可學習偏置向量。三步改動先後落地，CORE分數依次經過0.1695、0.2029、0.2241，最終穩定在0.2244。
