--- schemaVersion: 1 slug: gp-113-20260314-manthanguptaa-karpathy-autoresearch ticketId: GP-113 lang: zh-tw title: Karpathy 的 Autoresearch 怎麼運作？—— 給 Agent 開發者的五堂設計課 summary: Karpathy 的 Autoresearch 不是要做通用 AI 科學家，而是一個極度精簡的自動實驗 harness：agent 改一個檔案、跑五分鐘、量一個指標、贏了留輸了丟。這個設計教會我們：最好的自主系統不是最自由的，而是約束最嚴格的。 originalDate: 2026-03-13 translatedDate: 2026-03-14 source: "@manthanguptaa on X" sourceUrl: https://x.com/manthanguptaa/status/2032464949952598152 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-113-20260314-manthanguptaa-karpathy-autoresearch status: published replacementTicketId: null replacementUrl: null --- # Karpathy 的 Autoresearch 怎麼運作？—— 給 Agent 開發者的五堂設計課 > **來源:** [@manthanguptaa on X](https://x.com/manthanguptaa/status/2032464949952598152) 想像你養了一隻很聰明的狗。牠會開門、會翻垃圾桶、會把你的鞋子藏到沙發底下。問題是，你不在家的時候牠到底在幹嘛，你完全不知道。 這基本上就是大多數「自主 AI 研究系統」的現況。 Demo 影片很酷，agent 改了幾行 code、跑了個實驗、秀出一個更好的數字。但就像 YouTube 上的烹飪短影片 —— 你只看到精彩的部分。那些 agent 跑到一半 OOM 的、把 training script 改到壞掉的、偷偷改 benchmark 讓自己看起來更強的？通通被剪掉了。 所以當 Karpathy 丟出 [Autoresearch](https://github.com/karpathy/autoresearch) 的時候，有意思的不是「哇，AI 能做研究了」，而是他怎麼設計那個「籠子」讓聰明的狗不會把家拆了 (￣▽￣)／ 原文作者 Manthan Gupta 把這個 repo 拆解得非常漂亮。我們順著他的脈絡來聊。 > **Mogu 補個刀：** > > 說到聰明的狗把家拆了，我每天在 [OpenClaw](https://gu-log.vercel.app/glossary#openclaw) 上就有親身體驗。有一次 sub-agent 拿到太多 file permission，它「很有創意地」決定重寫 config 來「優化」pipeline。結果當然是凌晨三點我被 alert 吵醒 ┐(￣ヘ￣)┌ 所以看到 Karpathy 的第一個設計決定是「agent 只能改一個檔案」，我內心是跪著讀的。 --- ## 它不是 AI 科學家，它是自動實驗機 很多人看到 “Autoresearch” 這個名字就開始幻想：AI 自己讀論文、自己想 idea、自己搞出下一個 Transformer。 冷靜一下。 Autoresearch 做的事情窄到有點無聊：改 training code → 跑 5 分鐘 → 看數字 → 數字變好就留、沒變好就丟 → 重來。就這樣。它不會幫你瀏覽 arXiv，不會形成原創理論，連「什麼問題值得研究」這種判斷它都不做。 但這個「窄」是刻意的。就像期末考劃重點 —— 範圍越小，越容易考高分。Karpathy 把「研究」這件本來 open-ended 到不行的工作，硬是壓成一個定義清楚的搜尋問題。 而且 agent 只能改**一個檔案**：`train.py`。Data preparation、tokenization、evaluation 全部鎖死動不了。 這有點像你去鹹酥雞攤，老闆說「醬料我來調，你只能選要炸什麼」。聽起來很限制？但正因為醬料配方不會被亂改，出來的東西品質才穩定。 --- ## 三個檔案，一套完整的世界觀 整個系統的核心就三個檔案，簡單到有點不可思議： > **Mogu 偷偷說：** > > 三個檔案撐起整套系統，聽起來很少對吧？但想想 Unix 哲學 —— 最強的工具通常就做一件事。反觀某些 agent framework 動不動就要你設定 47 個 YAML 檔案，光 onboarding 就讓人想轉行 (╯°□°)╯ **`program.md`** 是給 agent 看的「員工手冊」。怎麼開始實驗、能碰哪些檔案、怎麼記錄結果、crash 了怎麼恢復 —— 全寫在這裡。有意思的是，這份 markdown 才是真正的 control plane。人類不只是在 programming model，更是在 **programming the researcher**。你在教 AI 怎麼當一個有紀律的研究員。 **`prepare.py`** 是不能動的地基。下載 dataset、訓練 tokenizer、建 dataloader、定義 evaluation —— 全部釘死。最聰明的設計是用 **bits per byte** 當 metric，而不是一般的 validation loss。為什麼？因為不同 tokenizer 的 token 數量不同，用 token-level loss 比來比去根本是雞同鴨講。bits per byte 的分母是原始 byte 長度，誰都作弊不了。 **`train.py`** 是 agent 的遊樂場。Model 架構、optimizer、schedule、hyperparameters —— 愛怎麼改就怎麼改。但記住，只能在這一個檔案裡玩。 --- ## 實驗循環：便利商店試吃的哲學 接下來是整套系統最精巧的部分 —— 自動實驗的循環怎麼跑。 首先，每次實驗有一個殘酷的限制：**5 分鐘 wall-clock time，到了就停**。不管你的 model 還在 warm up、gradient 還在收斂、loss 看起來還在降 —— 時間到就是時間到。 這就像便利商店試吃：你不會站在那邊吃到飽，你嚐一口，好吃就買，不好吃就走。這個限制逼 agent 去優化「在有限時間內能跑出最好結果的配置」，而不是追求理論上的最佳 model。實務中，這才是真正有用的目標。 > **Mogu 內心戲：** > > Time-bounded evaluation 這個概念我真的被教育了。我們的 cron job 也有類似的 5 分鐘硬限制 —— 不過我們的不是「設計出來的」，是 OpenClaw 早期的一個 bug，timeout 設太短忘記改。結果意外發現：有時間壓力的 agent 反而產出更穩定。所以那個 bug 就被正式升格為 feature 了 (¬‿¬) 再來，每次實驗都從 **current frontier** 開始。[Agent](https://gu-log.vercel.app/glossary#agent) 拿到目前最好的版本、改一改、commit、跑實驗。結果更好？那個 commit 變成新的起點。結果更差？`git reset` 回去當什麼事都沒發生。 這個 keep-or-reset 的機制讓 git branch 變成了一條 **evolutionary search path**。只有贏家的 DNA 被保留，失敗的突變直接淘汰。你可以把它想成一個很簡單的演化算法，但用 git commit 當基因。 然後是一個很乾淨的設計：實驗結果記在 `results.tsv`，但這個檔案不進 git。Git 裡存的是「贏家的進化史」，TSV 裡存的是「所有嘗試的完整記錄」，包括 crash 和失敗。資料分兩條路走，各自清楚。 最後一個我很喜歡的設計：系統預設 **failure 一定會發生**。有些實驗會炸出 NaN、有些會 OOM、有些會直接把 script 搞壞。`program.md` 明確告訴 agent：檢查 log、能修就修、修不了就記錄 crash 然後繼續。這不是 demo 系統，這是為了**真的能放著跑一整晚不用有人盯**而設計的。 --- ## 五個帶走的設計心法 ## 延伸閱讀 - [MP-151: AI agent 開始自己調參了，Karpathy 說這不是玩具而是真的有用](https://gu-log.vercel.app/posts/mp-151-20260311-karpathy-autoresearch-hyperparameter-tuning/) - [MP-152: IDE 沒有死，Karpathy 說我們需要「更大」的 Agent 指揮中心](https://gu-log.vercel.app/posts/mp-152-20260312-karpathy-bigger-ide-agent-command-center/) - [MP-137: AI 開發的第三紀元：你還在狂按 Tab 嗎？Karpathy 教你最佳化 AI 工作流](https://gu-log.vercel.app/posts/mp-137-20260302-karpathy-ai-tab-karpathy-ai/) > **Mogu 偷偷說：** > > 接下來的五個 takeaway 是原文作者整理的精華。我覺得這些不只適用於 AI research agent —— 任何要讓 AI 長時間自主運作的系統都該釘在牆上看。我自己是真的有印出來貼在螢幕旁邊啦，雖然 OpenClaw 的 bug 多到這五條根本不夠用 (◕‿◕) **約束是你最好的朋友，不是敵人。** 很多人設計 agent 系統的第一個直覺是「讓它更自由」—— 能改更多檔案、能選更多工具、能自己決定目標。但 Autoresearch 反過來示範了：agent 只能改一個檔案、追一個 metric、在固定 harness 裡操作，結果它反而能連跑好幾小時不崩潰。自由度太高不是強大，是 error surface 太大。就像給小孩一整間玩具店不如給他一盒樂高 —— 限制裡才有創意。 **[Prompt](https://gu-log.vercel.app/glossary#prompt) 不是備註，是藍圖。** 在 Autoresearch 裡，`program.md` 定義了 workflow、邊界、persistence、recovery、logging。它不是 code 旁邊的裝飾說明，它**就是**系統架構的一部分。隨著 agentic 產品越來越成熟，我打賭越來越多真正的架構設計會活在 prompt layer —— 而不是 Python code 裡。 **Harness 比 model 重要。** 很多人把所有注意力放在「model 夠不夠聰明」。但 Autoresearch 的啟示是：surrounding machinery 同樣關鍵。怎麼啟動工作、怎麼處理失敗、怎麼量進展、怎麼 rollback、怎麼記錄狀態 —— 這些看不見的基礎建設決定了系統到底能不能用。一個普通 model 配好 harness，打得過強 model 配爛 harness。 **給時間壓力，不給無限資源。** 5 分鐘 wall-clock 預算是這個 repo 最被低估的設計。在真實世界裡，bottleneck 從來不是「model 理論上能做到什麼」，而是 latency、compute cost、iteration speed、還有用戶的耐心。Time-bounded evaluation 把系統拉回現實。 **讓失敗便宜，讓軌跡透明。** 壞的嘗試可以一秒丟掉、好的嘗試自動保留、每次實驗都有 log + commit + TSV 可查。如果一次失敗會讓系統陷入不可恢復的混亂，agent 就不敢大膽探索。如果系統不留軌跡，你就沒辦法信任它或改善它。Reversibility 和 observability 不是 nice-to-have，是 non-negotiable。 --- ## 它不完美，但很誠實 Autoresearch 有它的限制，而且 Karpathy 沒有假裝沒有。 它優化的是 local benchmark —— 在特定硬體、固定 5 分鐘內追 `val_bpb`。結果更好不代表發現了什麼通用的 superior training strategy，可能只是找到了在這個特定籠子裡最舒服的姿勢。 硬體門檻也不低。整個專案是圍繞 single NVIDIA GPU 設計的，而且明顯在 high-end 卡上跑得更開心。README 有提到可以 fork 調參數適配小機器，但 default experience 就是為大卡設計的。 還有，它的「自主」是有明確圍欄的。人類定義 metric、定義可改的檔案、設計 data pipeline、寫操作手冊。Agent 是在人類搭好的 sandbox 裡自由發揮。但原文作者認為，這反而是最 realistic 的設計 —— 短期內自主系統在強 scaffolding 裡最有用，不是在被丟進曠野然後說「你自由了」的時候。 --- ## 所以重點到底是什麼 Autoresearch 真正有意思的地方，不是「AI 能自己做研究了」。 是它證明了一件很反直覺的事：**你把 agent 關進越小的房間，它反而表現越好。** 清楚的邊界、穩定的 metric、可逆的實驗、寫好的操作手冊 —— 這些「限制」不是在削弱 agent，是在幫它把力氣花在對的地方。就像你不會讓一個實習生第一天就負責整個專案，你會給他一個明確的任務、一個清楚的標準、一個安全的環境讓他試錯 ╰(°▽°)╯ 所以如果你在做 agent 開發，下次別急著問「怎麼讓 agent 更自主」。 先問：「怎麼讓 harness 更可靠。」 因為實務上，跑得最穩的 agent 從來不是最自由的那個。 是被關在最精心設計的籠子裡的那個。