Karpathy 的 autoresearch 完整拆解 — 630 行 Python 的閉環機器
630 行 Python。三個檔案。無人值守兩天。700 次實驗。
Andrej Karpathy 的 autoresearch 在 2026 年 3 月釋出後，33.9k stars 的速度說明了一件事：很多人都在等一個工具，能讓 AI Agent 真正閉環運作，而不是永遠等待人類下一個指令。
autoresearch 就是這個工具的最小可行版本。
這篇是Beast Mode × autoresearch 完整指南 系列的子文章，專注 autoresearch 本身的架構解析。如果你想看 autoresearch 和 Beast Mode 如何搭配，讀總文或 Beast × autoresearch 合體 — 四個真實落地場景。
autoresearch 是什麼
核心概念一句話：讓 AI Agent 在無人監督下反覆跑 ML 實驗，直到找到改進為止。
Karpathy 自己描述得更直接：
「你不是在寫程式，你是在設計 Agent 的研究策略。」
這句話的重量超過它看起來的樣子。傳統 ML 實驗是「人類有想法 → 人類寫程式碼實驗 → 人類看結果 → 人類決定下一步」。autoresearch 把這個循環裡的「人類判斷」全部移除——除了最開始的目標設定和最後的結果審查。
三檔架構
autoresearch 的整個系統只有三個檔案：
| 檔案 | 角色 | 誰碰它 |
|---|---|---|
prepare.py | 資料準備、tokenizer、評估函數、常數 | 固定不動 |
train.py | 模型架構、optimizer、訓練 loop（~630 行） | Agent 唯一可改的檔案 |
program.md | Agent 的研究策略和行為規則 | 人類迭代 |
這個設計的關鍵是極度限制 Agent 的操作範圍。Agent 只能動 train.py，不會在整個 codebase 亂跑。範圍小 = 可控 = 可回退。
program.md 是人類跟 Agent 溝通的唯一介面：你在這裡告訴 Agent「你的目標是什麼」「你應該怎麼思考」「你不能碰什麼」。每輪迭代的研究策略改進，都是通過更新 program.md 實現的。
四個關鍵閉環設計
autoresearch 的閉環能力來自四個相互配合的設計決策：
設計一：單一可改檔案
Agent 只能修改 train.py。這不是限制，是設計。範圍越小，失敗的代價越低，Agent 能做的嘗試越多，人類回顧的成本越小。
設計二：固定時間預算（5 分鐘）
每次實驗固定跑 5 分鐘，無論 Agent 改了什麼——不管模型大小、batch size、或架構如何變化，時間預算不變。
這個設計讓所有實驗結果直接可比。如果時間預算不固定，一個跑了 30 分鐘的模型和一個跑了 5 分鐘的模型，你根本無法比較誰更好。固定時間 = 固定基準 = 可比較的指標。
實際效果：約 12 次實驗/小時，約 100 次/一整晚。
設計三：單一量化指標（val_bpb）
val_bpb = Validation bits per byte。衡量語言模型的壓縮效率：越低代表模型對語言的理解越好。
選擇 val_bpb 而不是 loss 的原因是：val_bpb 不依賴 vocab size，所以 Agent 可以自由改模型架構，包括改 tokenizer，結果仍然可比。這是一個非常精心設計的指標選擇，消除了一個可能讓 Agent 「作弊」的漏洞。
設計四：自動版本管理（git commit/checkout）
實驗結束後，Agent 讀取 val_bpb：
比上次好 → git commit —am "improvement: +X% val_bpb" // 保留
沒進步 → git checkout train.py // 丟棄回退Agent 自己判斷，不需要人類介入。這是整個系統最優雅的部分：版本控制從人類的職責變成 Agent 的自動行為。壞的改動永遠不會累積，好的改動永遠有記錄。
實戰成績
這不是論文裡的假設，是跑出來的數字：
Karpathy 自己的實驗（2 天）：
- 跑了約 700 次實驗
- 找到約 20 個有效改進
- 「Time to GPT-2」從 2.02 小時降到 1.80 小時
- 效率提升 11%
- 這些是他手動調了二十年都沒發現的改進
Shopify CEO Tobias Lütke 的複現：
- 一個晚上跑了 37 次實驗
- 效能提升 19%
「手動調了二十年都沒發現的改進」不是在說 Karpathy 不夠努力。這是在說：人類手動迭代的速度，結構性地低於 Agent 自動迭代的速度。當 Agent 可以在你睡覺時跑 100 次實驗，你醒來時面對的是一個完全不同的搜索空間。
autoresearch 缺什麼
autoresearch 的閉環設計非常精確，但這個精確本身就是它的限制：
- 沒有主動研究能力：Agent 在既有知識裡優化，不會主動上網研究最新技術
- 沒有遞迴資訊蒐集：不會自動去讀文件、爬 API 文檔、了解最新研究
- 適用範圍窄：需要有明確的單一可量化指標，不適合模糊目標（「讓用戶更滿意」不能直接用）
- 不會自己拆解複雜任務：只在一個指定檔案裡做局部優化，不適合需要跨多個系統改動的任務
這四個缺口，剛好是 Beast Mode 補上的。
SuperPortia 觀點：autoResearch Pattern 的對比
SuperPortia 有自己的 autoResearch Pattern（見 ADR-0002），是一個保護 Obsidian vault 的 guard pattern——防止 Agent 在沒有驗證的情況下寫入知識庫。
兩個「autoResearch」的對比：
| 面向 | Karpathy autoresearch | SuperPortia autoResearch Pattern |
|---|---|---|
| 目的 | ML 實驗閉環迭代 | 防止未驗證知識進入 vault |
| 量化指標 | val_bpb | 不適用（知識品質是判斷，非指標） |
| 版本管理 | git commit/checkout | Obsidian vault 變更記錄 |
| 人類角色 | HOTL（設定目標） | HOTL（設定驗證標準） |
| 適用範圍 | ML 訓練迴圈 | 知識管理寫入流程 |
兩者的共同哲學是一致的：讓 Agent 在明確定義的邊界內自主運作，而不是在每個步驟都等待人類確認。
Karpathy 的 autoresearch 更像是一個「完整的閉環系統」，而 SuperPortia 的 autoResearch Pattern 是一個「寫入保護機制」。如果要把 Karpathy 的模式完整引入 SuperPortia，需要的是一個能銜接兩者的 adapter——而這正是 text_batch_runner.py 要做的事（MTAAA TaskList #69）。
SuperPortia Intelligence Brief — 小西 整理，2026-03-20。返回總覽：Beast Mode × autoresearch 完整指南 | 延伸閱讀：Beast Mode 完整拆解 | Beast × autoresearch 合體 — 四個真實落地場景
...四篇系列文的 Hub 文章。要深入了解各個面向： - [[Beast Mode 完整拆解]] — VS Code Agent 的六大能力逐條解析 - [[Karpathy 的 autoresearch 完整拆解]] — 630 行 Python 的閉環機器 -...
...e × autoresearch 完整指南]] 系列的子文章，專注落地場景。如果你還沒讀兩個工具各自的拆解，先看：[[Beast Mode 完整拆解]] 和 [[Karpathy 的 autoresearch 完整拆解]]。 合體工作流 在看場景之前，先確認完整工作流的結構：...
...讓 Agent 真正自主，人類負責設計規則而不是盯著每個步驟。 SuperPortia Intelligence Brief — 小西 整理，2026-03-20。返回總覽：[[Beast Mode × autoresearch 完整指南]] | 延伸閱讀：[[Karpathy 的 autoresearch 完整拆解]] | [[[beast-autoresearch-integration|Beast ×]]