--- schemaVersion: 1 slug: mp-135-20260301-karpathy-multi-agent-research-org ticketId: MP-135 lang: zh-tw title: Karpathy 用 8 個 AI Agent 組了一個研究團隊 — 結果它們根本不會做研究 summary: Karpathy 花了一個週末，用 4 個 Claude + 4 個 Codex agent 組成 AI 研究團隊，讓它們在 GPU 上跑 nanochat 實驗。結論：Agents 執行力一流，但實驗設計能力是零分。「你現在是在寫一個組織的程式碼」— 這句話可能定義了 2026 年的 agentic engineering (╯°□°)╯ originalDate: 2026-02-27 translatedDate: 2026-03-01 source: Andrej Karpathy (@karpathy) sourceUrl: https://x.com/karpathy/status/2027521323275325622 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/mp-135-20260301-karpathy-multi-agent-research-org status: published replacementTicketId: null replacementUrl: null --- # Karpathy 用 8 個 AI Agent 組了一個研究團隊 — 結果它們根本不會做研究 > **來源:** [Andrej Karpathy (@karpathy)](https://x.com/karpathy/status/2027521323275325622) ## 當 Karpathy 說「不 work」，你要認真聽 想像一下這個場景：你是 [Andrej Karpathy](https://gu-log.vercel.app/glossary#andrej-karpathy)，前 Tesla AI 總監、OpenAI 創始成員，現在你坐在電腦前，盯著八個 terminal 視窗。每個視窗裡都有一個 AI agent 在跑實驗。螢幕很漂亮，像駭客電影。 然後你發現——它們全部都在做白工。 2026 年 2 月 27 日，Karpathy 在 X 上回覆了 Hugging Face 共同創辦人 Thomas Wolf 的一個問題：**「NanoGPT speedrun 怎麼還沒有被 AI 全自動化？」** 他的回答不是嘴砲，是他真的花了一個週末去實驗 (◍•ᴗ•◍) 8 個 AI agent — 4 個 Claude、4 個 [Codex](https://gu-log.vercel.app/glossary#codex) — 每個配一張 GPU，任務是跑 nanochat 的 ML 實驗（具體來說：嘗試移除 logit softcap 而不造成 regression）。 > The TLDR is that it doesn’t work and it’s a mess… but it’s still very pretty to look at :) 翻譯：**「結論是完全不行，一團亂⋯⋯但螢幕看起來真的很漂亮 :)」** > **Mogu 碎碎念：** > > Karpathy 說的「很漂亮」就是 8 個 tmux 視窗同時跑 agent，滿螢幕的 terminal output 像控制中心。工程師的浪漫就是這麼樸素——功能不 work 沒關係，畫面好看就值了 (⌐■\_■) ## 組一個 AI 研究團隊，像在排《復仇者聯盟》 Karpathy 試了好幾種組織架構。第一種是放養——8 個獨立研究員，各自為政，自己想題目自己做。結果就像你把 8 個博士生丟進同一間實驗室然後去度假，回來發現每個人都在做不同的事，而且沒有人建 baseline。 第二種是階層制——1 個首席科學家 agent 負責發指令，8 個 junior 研究員負責執行。這比較好一點，至少有人在管方向。 > **Mogu murmur：** > > 這兩種架構你應該很熟悉吧？第一種就是你那個「扁平化管理」的新創公司，大家都很自主但沒人對齊目標。第二種是傳統大公司的 top-down 管理。有趣的是，管 AI agent 跟管人遇到的問題居然一模一樣——自主性太高會失控，管太緊又缺乏創意。管理學教科書：1，AI 工程師：0 ┐(￣ヘ￣)┌ 技術上他的做法很有意思：每個研究項目是一個 git branch，每個 agent fork 出自己的 feature branch，用 git worktrees 做隔離。沒有 Docker，沒有 VM，他覺得靠 instructions 就能防止 agent 互相踩腳。[Agent](https://gu-log.vercel.app/glossary#agent) 之間靠簡單的檔案溝通，全部跑在 tmux window grids 裡，像視訊會議一樣排列，可以隨時「接管」任何一個 session。 他特別提到「no -p」——沒用 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 的 headless 模式，而是讓所有 agent 跑在互動式 session 裡。為什麼？因為他要能隨時看到每個 agent 在幹嘛，必要時直接介入。這不是不信任 AI，這是**實戰經驗**。 ## Agent 的致命弱點：執行滿分、思考零分 好，這是整篇最重要的部分。 Karpathy 給了一句話總結，簡單到讓人心痛： > They are very good at implementing any given well-scoped and described idea but they don’t creatively generate them. **Agent 的執行力是 S 級，但創意實驗設計能力是 F 級。** 講個具體的故事你就懂了。其中一個 agent，跑了一整天的實驗之後，興奮地回報：「我發現了！增加 hidden size 可以降低 validation loss！」 > **Mogu 畫重點：** > > 拜託。增加 hidden size 本來就會降低 validation loss 好嗎！在 infinite data regime 下，更大的網路本來就更好，而且這個 agent 還偷偷跑了更久。這根本不是發現，這是統計學第一堂課的內容。 > > Karpathy 說他不明白為什麼還需要自己出來指出這一點——是啊，你的 AI 研究員連「控制變因」這四個字都不會，這大概等於請了一個期末考統計學被當的實習生來幫你做研究 (╯°□°)╯ 除了這個笑話般的「發現」，agent 們還犯了一堆研究的基本錯誤。不建立 baseline——沒有對照組你怎麼知道改進是真的？不控制變因——runtime 和 FLOPs 都不管，那你比較的是什麼？隨便跑一些沒有邏輯的 variation——就像一個學生不看食譜，把冰箱裡所有東西都丟進鍋裡，然後問你「為什麼不好吃」。 這些不是什麼高深的方法論問題。這是你大學研究方法課第一章的內容。Agent 可以幫你寫出完美的 PyTorch training loop，但它不會問自己「等等，這個實驗的假設是什麼？」 ## 核心洞見：你的程式碼不再是程式碼 Karpathy 把這個慘痛教訓昇華成一個很猛的框架： > You are now programming an organization (e.g. a “research org”) and its individual agents, so the “source code” is the collection of prompts, skills, tools, etc. and processes that make it up. 翻譯：**你的 source code 不再是 Python 或 TypeScript。你的 source code 是一整套 prompts、skills、tools 和流程——它們定義了一個「組織」如何運作。** 他舉了一個讓我起雞皮疙瘩的例子： > E.g. a daily standup in the morning is now part of the “org code”. **「每天早上的 standup 會議」現在是你程式碼的一部分。** > **Mogu 歪樓一下：** > > 好，讓我消化一下。以前我們寫 `function doSomething()` 來讓電腦做事。現在 Karpathy 說，你在寫的是 `process.dailyStandup()` 和 `agent.researchProtocol()` — 你不是在寫演算法，你是在寫**管理手冊**。 > > 如果你是 Tech Lead，你其實早就在做這件事了——只是你的「agent」叫做同事，你的「prompt」叫做 code review guideline，你的「skill」叫做 onboarding doc。Karpathy 只是幫你的日常工作發了一張 AI 認證書而已 (￣▽￣)／ ## 不 work，但問題問對了 Karpathy 很坦白：**目前不 work。** 但他的重點不是在說「失敗了好可惜」，而是在定義正確的衡量指標。優化 nanochat pretraining 只是眾多任務之一，它本質上就是一個 eval。真正的問題是： > Given an arbitrary task, how quickly does your research org generate progress on it? 你的 AI 研究團隊面對任意任務時，能多快產出有意義的進展？ ## 延伸閱讀 - [MP-56: Karpathy 的誠實告白：AI Agent 還不能自動優化我的 Code（但我還沒放棄）](https://gu-log.vercel.app/posts/mp-56-20260210-karpathy-agents-cant-optimize-nanochat/) - [MP-82: GitHub Agent HQ：讓 Claude、Codex、Copilot 在同一個 PR 裡打群架 — 多 Agent 協作時代正式開打](https://gu-log.vercel.app/posts/mp-82-20260215-github-agent-hq-multi-agent/) - [GP-89: 從聊天室指揮 AI 大軍 — OpenClaw ACP 讓你在 Discord / Telegram 裡開 Codex、Claude Code、Gemini](https://gu-log.vercel.app/posts/gp-89-20260227-openclaw-acp-agents/) > **Mogu 畫重點：** > > 這跟他幾天前（02-25）那篇「Programming is becoming unrecognizable」的論述完美串接。02-25 他說：給 agent 一個明確任務（設定 DGX Spark + vLLM + dashboard），30 分鐘搞定，以前要花一整個週末。02-27 他說：給 agent 一個開放性任務（優化 nanochat pretraining），一團亂。 > > 兩天之內，他自己就做了完美的 A/B test——**明確任務 → agent 碾壓；模糊任務 → agent 崩盤。** 你的工作不是寫更好的 code，你的工作是把「模糊」翻譯成「明確」。而這個翻譯能力，才是 2026 年最值錢的技能 (๑•̀ㅂ•́)و✧ ## 回到那八個螢幕 所以讓我們回到開頭那個畫面：Karpathy 坐在電腦前，八個 terminal 視窗，八個 AI agent。螢幕很漂亮，像駭客電影。 但漂亮不等於有用。那八個 agent 可以在 30 分鐘內幫你架好一整套基礎建設，卻連「先跑一個 baseline」這種最基本的研究直覺都沒有。它們是你見過最會執行的實習生，同時也是你見過最不會思考的研究員。 Karpathy 用一個週末證明了一件事：2026 年的真正瓶頸不是 AI 的能力，而是我們還不會當 AI 的老闆。你在寫的不是 code，是組織架構。你在 debug 的不是 bug，是管理流程。 你的 standup 就是你的 source code。你的研究 SOP 就是你的演算法。 歡迎來到 agentic engineering 的世界——你以為你在寫程式，結果你在當主管 ┐(￣ヘ￣)┌ --- _原文來源：[Andrej Karpathy (@karpathy)](https://x.com/karpathy/status/2027521323275325622)，回覆 Thomas Wolf 關於 NanoGPT speedrun 為什麼還沒被 AI 全自動化的提問_