上週五 Andrej Karpathy 丟了一個新的開源專案到 GitHub，叫 autoresearch。三天內拿了 8,700 顆星。

這個專案做的事情很簡單：給 AI agent 一顆 GPU、一個小型 LLM 訓練環境，讓它自己跑實驗。你睡覺，它工作。醒來時桌上放著 100 個完成的實驗結果。

聽起來像科幻片？630 行 Python 就搞定了。

為什麼這件事值得注意

ML 研究有一個眾人皆知但很少人解決的問題：改一個超參數、跑一次訓練、看結果、再改、再跑。這個循環佔了研究者大量時間，而且大部分時間你就是在等 GPU 跑完。

Karpathy 的解法是把這個循環自動化。不是用複雜的 AutoML 框架，不是用分散式訓練叢集，而是用一個極簡的 agent loop：

  1. 讀取你寫的 Markdown 指令檔（program.md）
  2. 修改訓練程式碼（train.py）
  3. 跑 5 分鐘訓練
  4. 檢查驗證指標有沒有進步
  5. 有 → 保留修改。沒有 → 還原
  6. 回到步驟 2

每小時 12 個實驗。一晚大約 100 個。

設計哲學：一個檔案、一顆 GPU、一個指標

autoresearch 最吸引我的不是它能做什麼，而是它選擇不做什麼。

一個檔案。 agent 只能修改 train.py，裡面包含 GPT 模型架構、優化器、訓練迴圈。沒有複雜的多檔案專案結構。把改動限制在單一檔案，agent 比較不容易把事情搞砸。

一顆 GPU。 不搞分散式訓練。一張 H100（或其他 NVIDIA GPU）就夠了。這意味著你不需要一個研究實驗室的資源才能玩。

一個指標。 用 val_bpb（validation bits per byte）作為唯一的成功標準。這個指標跟 vocabulary size 無關，所以就算 agent 換了 tokenizer 或改了模型架構，實驗結果還是可以直接比較。

5 分鐘的固定訓練窗口也是巧思。不管你跑在什麼 GPU 上，每個實驗的訓練時間都一樣，結果之間的比較才公平。

用 Markdown 寫「程式」

傳統的 ML 實驗自動化，你要寫 Python 腳本來定義搜尋空間、設定排程器。autoresearch 完全不走這條路。

你寫的是一個 Markdown 檔案叫 program.md，用自然語言告訴 agent 你想探索什麼方向。像是：

  • 「試試不同的 learning rate schedule」
  • 「把 attention head 從 8 改到 16，看有沒有差」
  • 「探索不同的 weight initialization 方法」

agent 讀完指令，自己決定怎麼修改 train.py，執行訓練，評估結果。你不需要定義超參數的搜尋範圍，不需要寫 config 檔。

這跟我們日常寫程式的方式完全不同。你不是在寫程式告訴電腦「怎麼做」，而是用自然語言告訴 agent「做什麼」。

技術架構

底層用的是 nanochat 的單 GPU 簡化版。nanochat 是 Karpathy 之前的專案，又是從更早的 nanoGPT 演化來的。這條演化路徑很清楚：

1
nanoGPT（2023）→ nanochat（2025）→ autoresearch（2026）

訓練用的優化器是 Muon 和 AdamW 的組合，tokenization 用 BPE。模型本身是個小型 GPT，小到一顆 GPU 5 分鐘就能跑完一輪訓練。

整個 repo 大約 630 行 Python。沒有用什麼奇特的框架，就是 PyTorch 加幾個基本套件。Karpathy 一貫的風格：能不引入依賴就不引入。

這東西真的有用嗎？

Shopify 的 CEO Tobi Lütke 拿 autoresearch 框架改了一下用在內部專案，回報說讓 agent 跑了一晚之後，validation score 改善了 19%。

19% 是什麼概念？在 ML 研究裡，很多論文費盡心思提出新方法，改善幅度可能就是 1-3%。讓 agent 無腦跑一晚拿到 19%，這個效率差距相當驚人。

當然，這個數字要看具體場景。Lütke 用的是較小的模型架構，改善空間本來就比較大。但即使打個折，overnight 自動實驗的效率還是遠超人工。

Karpathy 的下一步：分散式 AI 研究

Karpathy 在 Twitter 上說，autoresearch 的下一步是做成 SETI@home 式的分散式系統。不是模擬一個 PhD 學生，而是模擬一整個研究社群。

想像一下：全世界數千台機器同時跑不同的實驗方向，結果自動匯總、互相參考。一個分散式的 AI 研究網路，24 小時不間斷運作。

這聽起來很遠，但 autoresearch 的極簡設計讓這條路變得可行。每個節點只需要一顆 GPU 和一個 program.md，協調的成本極低。

對開發者的意義

我認為 autoresearch 代表的趨勢比工具本身更重要：

AI 研究的民主化。 你不再需要一間有 100 顆 H100 的實驗室才能做有意義的 ML 研究。一顆 GPU 加一個好問題，agent 幫你跑實驗。

「寫指令」取代「寫程式碼」。 在 autoresearch 裡，你的生產力瓶頸不是寫 Python 的速度，而是你問的問題夠不夠好。program.md 裡的指令品質直接決定實驗結果。

overnight computing 的崛起。 人類睡覺的 8 小時，是白白浪費的算力。autoresearch 把這段時間變成生產力。Karpathy 之前就在推 overnight agent 的概念，現在他把它做出來了。

Karpathy 系列的一致性。 從 nanoGPT 到 nanochat 到 autoresearch，每個專案都是「用最少的程式碼做出最有教育價值的東西」。這個系列現在不只是教學工具了，它們開始產生實際的研究價值。

限制

說幾個目前的限制：

  • 只支援 NVIDIA GPU。 在 H100 上測試過，其他卡可能需要調整。沒有 AMD 或 Apple Silicon 支援。
  • 固定 5 分鐘窗口。 有些實驗可能需要更長的訓練時間才能看出差異。
  • 單一指標。 val_bpb 不能反映所有面向的進步，比如生成品質、推理能力。
  • 小模型限定。 要在 5 分鐘內跑完一輪訓練，模型不能太大。大規模模型的實驗需要不同的框架。

怎麼開始

如果你有一顆 NVIDIA GPU 想試試：

1
2
3
git clone https://github.com/karpathy/autoresearch
cd autoresearch
pip install -r requirements.txt

寫一個 program.md 描述你想探索的方向，然後讓 agent 跑。建議先從小的改動開始，比如 learning rate 的調整，感受一下系統的運作方式。

Karpathy 的 README 寫得很清楚，630 行程式碼也值得從頭到尾讀一遍。能從一個 single-file 專案學到的東西，往往比一個龐大的框架多。

我的觀察

我們正在經歷 ML 研究方式的轉變。以前是「人想方法 → 人跑實驗 → 人看結果」。現在變成「人想方向 → agent 跑 100 個實驗 → 人分析最好的幾個」。

人的角色從「執行者」變成「方向制定者」。你不需要手動調參數，但你需要知道什麼方向值得探索。這反而讓領域知識和直覺變得更重要，而不是更不重要。

Karpathy 用 630 行程式碼把這個轉變具體化了。下次有人問你 AI 會不會取代研究者，你可以說：不會取代，但會改變他們花時間的方式。最好的研究者不是調參數最快的人，而是問問題問得最好的人。

autoresearch 讓這件事變得非常清楚。