Karpathy 的 autoresearch：630 行程式碼如何讓一個人等於一間 AI 實驗室

摘要：2026 年 3 月 7 日，前 Tesla AI 總監、OpenAI 創始成員 Andrej Karpathy 在 GitHub 上釋出 autoresearch——一個僅由三個檔案組成的極簡框架，讓 AI agent 整夜自主執行 LLM 訓練實驗。發布 48 小時內獲得超過 9,600 顆 star 和 1,300 次 fork。其核心理念極為簡潔：人類寫方向（Markdown），agent 改程式碼（Python），5 分鐘跑一輪，一晚跑 100 次。社群實測已在 126 次實驗中將 val_bpb 從 0.9979 壓到 0.9697。但更深層的意義在於，Karpathy 正在為「一個人等於一間 AI 實驗室」的願景提供工程基礎設施——而他的下一步目標是 SETI@home 式的全球分散式 agent 協作網路。

核心數據一覽

從 nanoGPT 到 autoresearch：Karpathy 的極簡主義哲學

要理解 autoresearch 為何引起如此大的迴響，必須先回顧 Karpathy 過去三年建立的「極簡 AI 工具」譜系。

2023 年的 nanoGPT 用不到 600 行 Python 實現了一個完整的 GPT 模型訓練框架，讓全世界的學生和獨立研究者第一次可以在自己的筆電上從零訓練語言模型。2024 年的 llm.c 更進一步，用純 C 語言和 CUDA 寫了一套 LLM 訓練器，壓縮到極致的底層效能，讓人看見「沒有 PyTorch 也能訓練大模型」的可能性。

這兩個專案有一個共同的哲學主張：複雜性是 AI 研究的敵人。當一個訓練框架需要幾萬行程式碼、幾十個設定檔、半天的環境搭建時間，它實際上在說「只有大公司才配做 AI 研究」。Karpathy 的回應始終一致——把它壓縮到一個人能完整理解的規模。

autoresearch 是這條路線的邏輯延伸，但它跨出了關鍵的一步：不只是讓人類更容易做研究，而是讓 AI agent 自己做研究。

這三個專案構成了一條清晰的弧線：從「降低人類門檻」到「讓人類可以不在現場」。

三個檔案的精妙分工：人機介面的最小設計

autoresearch 的整體架構可以用一句話概括：人類迭代 prompt，agent 迭代程式碼。但要做到這一點，它的三個檔案必須各司其職，形成一個乾淨的「人類—agent—環境」三角關係。

prepare.py：不可變的實驗基礎

這是唯一一個 agent 不能碰 的 Python 檔案。它負責一次性的前置作業：

• 下載並預處理訓練資料集
• 訓練 BPE tokenizer
• 建立 dataloader 和評估工具

為什麼要把它鎖死？因為如果 agent 能修改資料處理流程，實驗結果就失去了可比性。這是一個刻意的工程約束——用不可變性換取可信度。

train.py：agent 的唯一「遊樂場」

這 630 行程式碼包含了一個完整的 GPT 模型定義、Muon + AdamW 優化器、以及訓練迴圈。agent 可以修改其中的任何東西——模型架構、超參數、batch size、學習率排程、正則化策略，甚至整個訓練邏輯。

但它受到一個硬性約束：每次實驗的 wall clock 時間固定為 5 分鐘（不含 Python 啟動和 CUDA 編譯時間）。這意味著 agent 不能靠「跑更久」來改善結果——它必須在相同的時間預算內找到更好的訓練方法。

這是 autoresearch 最聰明的設計決策之一。固定時間預算不只確保了實驗之間的公平比較，更意味著不同硬體上跑出來的結果可以直接對照。在一張 A100 上跑 5 分鐘和在一張 H100 上跑 5 分鐘，比較的是「誰在自己的硬體上優化得更好」——這本身就是一個有趣的研究問題。

program.md：人類的「方向盤」

這是整個系統中最精巧的部分。人類不直接寫程式碼、不調超參數、不看訓練曲線——人類只做一件事：用 Markdown 描述實驗方向。

# Program

You are an AI research agent. Your goal is to minimize val_bpb
on the validation set. You have full control over train.py.

## Current Strategy
- Focus on weight initialization and decay schemes
- Try different learning rate schedules
- Explore attention pattern modifications

## Constraints
- Never stop and never ask the human for permission to continue
- Each experiment must complete within the 5-minute budget
- If an experiment crashes, revert to the last working version

注意最後一條規則：「永遠不要停下來，永遠不要請求人類許可」。這不是一句隨意的指令——它定義了整個系統的運行哲學。人類在睡覺前寫好 program.md，按下啟動鍵，然後 離開。第二天早上回來看結果。

┌─────────────┐     指引方向      ┌──────────────┐
│  program.md │ ──────────────→  │   AI Agent    │
│ （人類撰寫）  │                  │（Claude/Codex）│
└─────────────┘                  └──────┬───────┘
                                        │ 修改
                                        ↓
                                 ┌──────────────┐
                                 │   train.py   │
                                 │  （630 行）    │
                                 └──────┬───────┘
                                        │ 訓練 5 min
                                        ↓
                                 ┌──────────────┐
                                 │  val_bpb 評估 │
                                 └──────┬───────┘
                                        │
                              ┌─────────┴─────────┐
                              ↓                   ↓
                         改善了？              沒改善？
                         保留修改              還原程式碼
                              │                   │
                              └─────────┬─────────┘
                                        ↓
                                   下一輪實驗
                                  （無限循環）

這個三檔案架構的精妙之處在於它創造了一個清晰的責任邊界：prepare.py 定義「遊戲規則」（不可變），train.py 定義「遊戲場地」（agent 可改），program.md 定義「遊戲策略」（人類可改）。任何更複雜的設計——多個可修改檔案、動態的評估指標、可變的時間預算——都會模糊這些邊界，讓系統更難理解、更難除錯。

val_bpb：為什麼選這個指標改變了一切

autoresearch 使用的指標叫做 val_bpb（validation bits per byte）。這不是一個隨便的技術選擇——它是整個系統能夠「自主運轉」的數學基礎。

傳統的語言模型評估通常用 perplexity 或 cross-entropy loss，但這些指標都跟 vocabulary size 有關。如果 agent 在某次實驗中修改了 tokenizer 的詞彙量（比如從 32K 改成 64K），loss 值的比較就失去意義。

val_bpb 解決了這個問題。它衡量的是「模型平均需要多少 bit 來編碼驗證集中的每個 byte」，跟詞彙量完全無關。這意味著：

1. Agent 可以自由修改 tokenizer 配置，結果仍然可比
2. 不同架構（Transformer、Mamba、混合模型）的結果可以直接比較
3. 不同硬體上的結果可以公平對照（因為時間預算也是固定的）

一個好的評估指標，應該讓實驗者在所有維度上都有自由度，同時確保結果的可比性。val_bpb 搭配固定時間預算，正好做到了這一點。

社群實戰：126 次實驗的真實成果與瓶頸

autoresearch 發布後 48 小時內最重要的社群產出，是 GitHub Discussion #43 中一位使用者分享的完整實驗報告。

這位使用者讓 agent 跑了整整一夜，完成 126 次連續實驗，將 val_bpb 從 0.9979 壓到 0.9697——改善幅度約 2.8%。在 LLM 訓練的語境中，這是一個非常可觀的進步，特別是考慮到整個過程完全無人值守。

從實驗日誌中可以看出 agent 的行為模式：

• 前 20 次：快速掃過常見的超參數空間（學習率、batch size、warmup steps），找到明顯的低掛果實
• 第 21-60 次：開始嘗試結構性修改，如調整 attention head 數量、改變 layer normalization 位置、嘗試不同的位置編碼
• 第 61-100 次：進入精細調整階段，主要是 weight decay 策略和初始化方案的排列組合
• 第 101-126 次：改善速度明顯放緩，agent 開始在相似的配置之間反覆

這正好引出了社群提出的最尖銳批評。GitHub Issue #22 指出了一個根本性問題：agent 的「創造力」有限。它擅長在已知的參數空間內做系統性搜索，但很少嘗試根本性的架構變革——比如把 Transformer 換成 SSM（State Space Model），或引入全新的訓練技巧。

這不是 autoresearch 本身的缺陷，而是當前 LLM agent 的普遍特性：它們是優秀的優化器，但不是好的發明家。它們能在已知的山上爬得更高，但不擅長跳到完全不同的山上。

這個現象其實是一個重要的研究問題：如何讓 agent 在「exploitation」（利用已知策略）和「exploration」（嘗試全新方向）之間取得平衡？Karpathy 的 program.md 設計暗示了一個答案——人類可以在 agent 陷入瓶頸時更新 Markdown 指令，「推」agent 去嘗試新方向。這是一種非同步的人機協作：agent 跑一整夜，人類早上看結果、調整策略、agent 再跑一整天。

SETI@home 的野心：從單機到全球 Agent 協作網路

如果 autoresearch 只是一個精巧的單機實驗工具，它不值得佔據 GitHub trending 榜首。Karpathy 在 X 上透露的下一步計畫，才是真正讓 AI 研究社群興奮的部分。

他寫道：

「The next step for autoresearch is that it has to be asynchronously massively collaborative for agents (think: SETI@home style).」

SETI@home 是 1999 年啟動的分散式運算專案，讓全球數百萬台個人電腦在閒置時分析外星信號。Karpathy 想做的事情結構上完全相同，但主角從「CPU 閒置週期」換成了「GPU + AI agent」。

這個願景的具體想像是這樣的：

1. 全球成千上萬的 agent 各自在不同的 GPU 上跑 autoresearch
2. 每個 agent 的實驗結果（程式碼修改 + val_bpb 分數）自動彙報到中央伺服器
3. 伺服器統整所有成功的修改，合併成一個不斷進化的 train.py
4. 新版本的 train.py 再分發給所有 agent，作為下一輪實驗的起點
5. 整個過程無需人類介入——它模擬的不是一個 PhD 學生，而是一整個研究社群

這與當前 ML 研究的工作模式形成鮮明對比。在 Google DeepMind 或 Meta FAIR，一個研究專案通常需要 5-20 位研究員、幾百張 GPU、數月的時間。SETI@home 式的 autoresearch 提出了一個激進的替代方案：用大量低成本的分散式 agent 取代少量高薪的集中式研究團隊。

社群已經開始動手了。目前已出現的衍生版本包括：

• autoresearch-macos：支援 macOS 的移植版
• autoresearch-mlx：使用 Apple MLX 框架，讓 Mac 使用者也能參與
• TinyStories 資料集適配：Karpathy 推薦給硬體資源有限的使用者
• 多 agent 架構：一個 agent 負責生成假說、一個執行實驗、一個綜合評估

這些 fork 的爆發速度（48 小時內超過 1,300 個）本身就在驗證 Karpathy 的直覺——有大量擁有單張 GPU 的個人研究者渴望參與 AI 前沿研究，他們只是缺少一個框架。

企業啟示：Agentic 不再是概念，是生產模式

autoresearch 看起來像是一個學術玩具，但德國企業分析公司 LeapLytics 的深度解讀指出了它對企業的直接啟示。

LeapLytics 的核心論點是：autoresearch 的 「自主循環」模式（設定目標 → agent 執行 → 評估結果 → 自動迭代）已經準備好從研究領域擴展到企業生產環境。

「Agentic is no longer a research concept—it is a production pattern.」

他們提出了三個具體的企業意涵：

第一，角色重新分配。當 agent 能整夜自主執行實驗時，人類的角色從「做事的人」變成「審查的人」（from doing to reviewing）。這不是裁員的暗示——而是說工程師的價值不再是「會跑實驗」，而是「知道該跑什麼實驗」和「看得懂結果代表什麼」。

第二，成功指標的重要性。Karpathy 能讓 autoresearch 自主運轉，關鍵在於 val_bpb 是一個明確、可量化、自動計算的成功指標。LeapLytics 提醒企業：「If you cannot describe your workflow the way Karpathy describes his training loop, it is not ready for agent automation yet.」——如果你無法像 Karpathy 描述訓練迴圈那樣清晰地定義你的工作流程，那它還沒準備好被 agent 自動化。

第三，數據品質是前提。自主 agent 會放大它所接觸到的一切——好的數據產生好的結果，壞的數據產生壞的結果，而且速度比人類快 12 倍（每小時 12 次實驗）。

台灣觀點：一張 GPU 的研究民主化紅利

台灣的 AI 研究長期面臨結構性困境：學術界運算資源遠不及美國大廠，產業界的 AI 團隊規模通常在 5-15 人。autoresearch 改變了這個等式——1 張 GPU、1 個 AI agent、1 夜時間 = 100 次有意義的實驗。

• 學術研究：碩博士生用實驗室現有 GPU 讓 agent 整夜跑 100 次實驗，產出量相當於手動調參一週，釋放學生去做更高階的工作——設計問題、解讀結果、撰寫論文
• 新創團隊：一個工程師白天定義方向，agent 夜間執行，隔天分析結果——一個人同時扮演研究員和工程師
• 產業應用：製造業或金融業 AI 團隊可借鑑 autoresearch 的設計哲學（明確指標、固定預算、單一修改點、自動回滾）建立自己的 agentic automation
• 硬體生態：台灣擁有全球最強的 GPU 設計與製造能力，autoresearch 式工具的普及將推升中低階 GPU 的研究需求

Karpathy 的 autoresearch、Altman 的「one-person billion-dollar company」、Cognition 的 Devin，都指向同一趨勢：AI 正在壓縮做出世界級成果所需的最小團隊規模。對資源有限但人才密度高的台灣而言，這是近年最大的結構性機遇。

封面圖片來源：本文作者與 AI 協作繪製而成

參考資料來源：

1. Karpathy/autoresearch — GitHub
2. Session report: 0.9979→0.9697 in 126 experiments — GitHub Discussion #43
3. Low creativity · Issue #22 — GitHub
4. Karpathy: autoresearch release announcement — X
5. Karpathy: SETI@home vision — X
6. Karpathy Releases Minimal Autoresearch Repo — Blockchain News
7. Karpathy automates LLM training research — Pulse24
8. AutoResearch Wants to Turn AI Into a Fully Automated Scientist — WebProNews
9. Getting Started with autoresearch Full Guide — Medium
10. Autoresearch: Karpathy's Overnight AI Researcher — TopAIProduct
11. Autonomous AI Agents That Run Research Overnight — LeapLytics
12. Andrej Karpathy AI's Iterative Self-Improvement Of Code — Quantum Zeitgeist
13. Andrej Karpathy's AutoResearch: Bye Bye Researchers — Medium
14. AutoResearch — OpenFlows