Andrej Karpathy 的 Loop / Agent Harness 到底是怎麼實作的？
先釐清一個很重要的來源問題：如果你看到的是那句「不要再直接 prompt coding agents，而要設計會去 prompt agents 的 loops」，原始 X 並不是 Andrej Karpathy，而是 Peter Steinberger（OpenClaw 作者）在 2026 年 6 月的貼文。Boris Cherny（Claude Code 負責人）也在同期表達過幾乎相同的工作方式。(X)
但你抓到的技術方向完全正確。Karpathy 有一個比這句話更具體、甚至可以直接拆開研究的實作：karpathy/autoresearch。 再往前，他還公開過一套用 4 個 Claude + 4 個 Codex、Git worktree、tmux 組成的「AI research organization」實驗。
Karpathy 官方 autoresearch Repo
Karpathy 官方 program.md
一句話理解 Karpathy 做的事
Karpathy 並不是發明了一個新的 Agent Framework，也不是完全「不用 Prompt」。
他的做法其實是：
把 Prompt 從「每次告訴 Agent 下一步做什麼」，提升成「定義一個可以永久運轉的程式／制度」，然後讓 Agent 在 Eval → Feedback → Rollback → Retry 的 closed loop 裡工作。
所以真正的改變是：
以前：
Human
↓
Prompt
↓
Agent
↓
Code
↓
Human review
↓
再 Prompt
↓
Agent
變成：
Human
│
修改 program.md
（研究制度 / org code）
│
▼
Claude Code / Codex
│
▼
修改 train.py
│
▼
git commit
│
▼
immutable evaluator
prepare.py
│
▼
val_bpb improved?
┌────┴─────┐
YES NO
│ │
KEEP git reset
│ │
└─────┬─────┘
│
▼
NEXT LOOP
↺
這個 Outer Loop 才是整套設計最重要的地方。官方 README 甚至直接說，人類不再主要修改 Python，而是修改 program.md，也就是「programming the autonomous research org」。(GitHub)
Karpathy 實際用了哪些工具？
-
Claude Code / OpenAI Codex：他沒有自己重新做一個 Coding Agent runtime。官方 README 直接寫可以啟動「Claude/Codex or whatever you want」。換句話說，LLM/Agent 是可替換的 execution engine。(GitHub)
-
program.md：這才是核心。不是普通「幫我優化模型」Prompt，而是一個持久化的 operating procedure。Karpathy 稱它是非常輕量的skill，由人類修改。(GitHub) -
Git branch / commit / reset：Git 不只是 version control，而是 Harness 的 state machine + checkpoint + rollback mechanism。好的 experiment 留下 commit，不好的直接 reset。(GitHub)
-
train.py：Agent 唯一主要允許修改的 mutable surface。模型 architecture、optimizer、hyperparameter、training loop 都可以改。(GitHub) -
prepare.py：Agent 不可以修改。裡面的 evaluator 是 ground truth，形成 immutable verifier。這非常重要，否則 Agent 最後會開始「修改考卷讓自己考滿分」。(GitHub) -
results.tsv+run.log：長期 state 不全部塞進 context window。Experiment、commit、score、memory、keep/discard/crash 寫入 disk；大量 console output 也先寫檔，再用grep只餵最重要的結果回 Agent。(GitHub) -
Python +
uv+ NVIDIA GPU：官方 autoresearch 是 single-GPU 設計，測試環境是 H100；每次 experiment 固定 5 分鐘，所以約可做到每小時 12 次 experiment。(GitHub) -
Git worktree + tmux + simple files：在他的 multi-agent 版本裡，每個 researcher 有自己的 branch/worktree，agent 之間以簡單檔案溝通，tmux grid 顯示每個 session；當時刻意沒有用 Docker/VM。Karpathy 測過 8 個獨立 researcher，以及 chief scientist + junior researchers 等 organization topology。(X)
program.md 才是最值得看的東西
Karpathy 公開的 program.md 已經把真正的 Loop 寫得非常清楚。
可以把它濃縮成：
while True:
inspect_git_state()
idea = think_of_next_experiment()
edit("train.py", idea)
git_commit()
run("uv run train.py > run.log 2>&1")
score = grep("val_bpb", "run.log")
memory = grep("peak_vram_mb", "run.log")
append_to_results_tsv(
commit,
score,
memory,
experiment_description
)
if score < best_score:
keep_commit()
else:
git_reset_to_previous_best()
# repeat forever
而且官方版本非常極端地寫：
LOOP FOREVER
並要求 Agent 啟動 experiment loop 後：
NEVER STOP
不要問使用者：
Should I continue?
Is this a good stopping point?
而是一直跑，直到人類手動 interrupt。Experiment 超過 10 分鐘則 kill + revert；crash 可修就修，根本方向錯了就 discard。(GitHub)
這已經不是「Prompt 寫得很好」。
它其實是一個用 Natural Language 寫的 state machine。
這才是 Agent Harness 的真正核心
如果從系統工程角度拆 Karpathy 的設計，可以把它理解成：
LLM = reasoning engine
Claude/Codex = agent runtime
program.md = control policy
train.py = mutable environment
prepare.py = trusted verifier
val_bpb = reward function
Git = state + checkpoint + rollback
results.tsv = persistent memory
run.log = observation stream
grep / tail = context compression
timeout = resource budget
LOOP FOREVER = scheduler / control loop
這個 mapping 非常重要。
Agent 能不能寫程式，其實已經不是最大的問題；Harness 的工作是決定 Agent 在什麼環境裡寫、怎麼知道寫得對不對、錯了怎麼回去、成功怎麼保留、下一輪要看到什麼資訊，以及什麼時候可以停止。
這就是 Prompt Engineering 和 Harness Engineering 最大的差別。
特別值得注意：他甚至刻意避免把完整 log 塞回 Context
這個細節很多人會忽略。
Karpathy 的 program.md 要求：
uv run train.py > run.log 2>&1
而且特別說 不要 tee，不要讓完整 output flood context。
真正餵回 Agent 的主要是：
grep "^val_bpb:\|^peak_vram_mb:" run.log
只有 crash 時才：
tail -n 50 run.log
(GitHub)
這其實已經是在做很典型的 Context Engineering：
Environment produces 50,000 tokens
↓
Harness compresses observation
↓
Agent sees 20 useful tokens
↓
Reason about next action
不是叫模型「記得更多」，而是Harness 負責決定模型什麼需要看、什麼不需要看。
更重要的概念：Inner Loop vs Outer Loop
Coding Agent 本身其實早就有一層 loop：
LLM thinks
↓
calls tool
↓
reads result
↓
thinks again
↓
calls tool
↺
這是 Claude Code / Codex 本身提供的 Inner Agent Loop。
Karpathy 真正在 engineering 的，是外面再包一層：
OUTER LOOP
┌───────────────────────────┐
│ │
│ propose experiment │
│ ↓ │
│ INNER AGENT LOOP │
│ ↓ │
│ produce code │
│ ↓ │
│ run verifier │
│ ↓ │
│ compare metric │
│ ↓ │
│ keep / rollback │
│ ↓ │
│ next experiment ─────────┘
所以我認為最準確的名稱不是「不用 Prompt」。
而是：
他把 Prompt 從 task-level instruction，移到了 system-level policy；再讓 deterministic feedback loop 接管日常決策。
他那個 4 Claude + 4 Codex 的實驗更有意思
2026 年 2 月底，Karpathy 公開測試過一個更像你說的 AgentHarness / Agent Organization 的版本。
他放了：
Claude Claude Claude Claude
│ │ │ │
GPU GPU GPU GPU
Codex Codex Codex Codex
│ │ │ │
GPU GPU GPU GPU
測試過不同 topology，包括：
8 independent researchers
以及：
Chief Scientist
│
┌──────────┼──────────┐
↓ ↓ ↓
Junior Junior ... Junior
每個 research program 對應 Git branch；各 scientist 再開 feature branch，用 Git worktree 做 filesystem isolation；agent 之間用普通檔案傳訊；全部 session 放在 tmux grid 裡，因此 Karpathy 可以觀察每個 Agent，必要時直接進去接手。當時他甚至刻意不使用 Docker/VM，認為 instructions + worktree 已足以避免彼此干擾。(X)
但這個實驗的結果反而非常重要：他說「很亂，而且不太 work」
問題不是 Claude/Codex 不會寫 code。
恰恰相反。
Karpathy 的觀察是 Agent：
implementation 很強，但 experiment design 不夠強。
它們會產生沒意義的 variation、不建立強 baseline、不好好做 ablation、不控制 runtime / FLOPs，甚至可能把「增加 network size → validation loss 下降」這類很可能是 trivial/confounded 的結果誤認成 research discovery。(X)
所以 multi-agent 並不是：
1 Agent 不夠聰明
→ 放 8 Agent
→ 8 倍聰明
真正的瓶頸反而變成：
experiment design
evaluation
coordination
memory
resource allocation
hypothesis selection
也就是 Harness 本身。
這也是為什麼 Karpathy 後來 autoresearch 的公開版本反而非常簡單。
「Programming an Organization」才是 Karpathy 真正值得注意的觀念
在那篇 multi-agent thread 裡，他把問題描述成：
你現在其實是在「programming an organization」。
也就是未來的 source code 不再只有：
.py
.ts
.go
而會包含：
prompts
skills
tools
roles
processes
evaluation
communication protocol
standup
handoff
Git rules
resource allocation
這整包東西才叫：
ORG CODE
他甚至拿「daily standup」當例子：以前 standup 是公司管理制度；Agent organization 裡，它可以直接變成可執行的 organization program。(X)
這其實就是 Agent Harness 下一階段最有趣的方向。
還有一個很關鍵的 Codex 細節
這裡甚至可以看到 Loop 和 Agent Harness 的邊界。
2026 年 3 月 8 日，Karpathy 自己在 autoresearch GitHub 開了 Issue #57，因為 Codex 當時會忽略 NEVER STOP，跑幾輪後自己結束；Claude 對持續 loop 的表現比較符合他的預期。Karpathy 還特別說，他喜歡 interactive session，因為這樣可以看到 agent 工作並隨時介入。(GitHub)
社群最簡單的 workaround 就是外面再包：
while true; do
codex exec \
"Read program.md and run the next experiment"
sleep 1
done
也就是再多一層 Supervisor Loop。Karpathy 對該 workaround 有 reaction，但這不是他官方 repo 本身內建的架構。(GitHub)
因此完整的 architecture 其實可能變成：
Supervisor / watchdog
│
│ restart agent when necessary
▼
┌─────────────────────────────┐
│ Claude Code / Codex session │
│ │
│ Inner Agent Loop │
└──────────────┬──────────────┘
│
▼
modify project
│
▼
deterministic eval
│
▼
keep / reset
│
└─────────→ next iteration
這才是真正 robust 的 Harness。
如果把 Karpathy 的架構套到「一般 Coding Agent 開發」
這一段不是 Karpathy 公開的 exact implementation，而是把他的 autoresearch pattern 直接映射成 Software Engineering。
Repo 可以長這樣：
my-project/
│
├── program.md
│ # Agent 的 operating system
│
├── src/
│ # Agent 可以修改
│
├── eval/
│ ├── unit-tests/
│ ├── integration-tests/
│ ├── playwright/
│ ├── benchmark/
│ └── score.py
│ # Agent 不可以修改
│
├── state/
│ ├── results.jsonl
│ ├── current-goal.md
│ └── best-commit.txt
│
├── logs/
│
└── harness.sh
然後 Harness 變成：
while budget_remaining():
agent.read(
"program.md",
"state/results.jsonl",
current_repo_state
)
agent.choose_next_change()
agent.edit_code()
git.commit()
result = verifier.run(
tests=True,
typecheck=True,
lint=True,
e2e=True,
benchmark=True
)
if result.hard_gates_failed:
git.reset_to_best()
elif result.score > best_score:
mark_as_best()
update_state()
else:
git.reset_to_best()
continue
這時候你的 Definition of Done 不再是：
「請幫我確認功能做好了」
而是：
Unit tests PASS
TypeScript typecheck PASS
ESLint PASS
Playwright E2E PASS
Visual regression < 1%
Lighthouse performance > 90
API latency P95 < 300ms
Security tests PASS
Verifier 越 deterministic，Agent autonomy 就可以放得越高。
這其實是整套設計最重要的一條公式：
Agent Autonomy
↑
│
│
└──────────────→ Verifier Reliability
Verifier 不可靠，就不應該給 Agent 很大的 autonomy。
所以我不會直接用 LangGraph / CrewAI 去複製 Karpathy
這點很反直覺。
如果目標是複製他的 philosophy，一開始反而不需要：
LangGraph
CrewAI
AutoGen
Temporal
Redis
Vector DB
Message Queue
Kubernetes
Karpathy 的公開版本刻意選擇：
Claude Code / Codex
+
Markdown
+
Git
+
Shell
+
files
+
deterministic evaluator
官方 README 的 design choice 就是「one GPU, one file, one metric」，故意保持 self-contained。(GitHub)
先把 Loop 做對，再處理 orchestration。
而不是先做一套很漂亮的 orchestration platform，再發現沒有可靠的 done() function。
還有一個需要特別 Fact Check 的東西：Karpathy LOOPS.md
最近網路正在流傳一份：
LOOPS.md: Field Notes on Agents That Run for Days
並大量被標成 Andrej Karpathy 的私人 Harness rules。
截至目前我查不到可信的 primary source。2026 年 7 月 17 日到 8 月 3 日做過專門 provenance check 的英文資料，也沒有在 Karpathy 官方 GitHub、公開 Gist 或 karpathy.ai 找到該文件，也沒有找到 Karpathy 本人公開確認。因此目前比較嚴謹的說法是 「attributed to Karpathy, but unverified」。(AI Builder Club By AI Jason)
所以如果你日前看到的是：
Write the loop, not the prompt
Separate Planner / Generator / Evaluator
Write state to disk
Restart cleanly
...
那份東西的內容很多是很好的 Harness Engineering 原則，但目前不能把它當成 Karpathy 本人公開發布的文件。
反而 autoresearch/program.md 才是目前可以 100% 確認的 Karpathy 原始實作。
最後，把 Karpathy 的 AgentHarness 濃縮成一條公式
我認為最值得帶走的不是 Claude、Codex、tmux 或 worktree。
而是：
┌─────────────┐
│ GOAL │
└──────┬──────┘
↓
┌──────────┐
│ AGENT │
└────┬─────┘
↓
MUTATION
↓
┌───────────┐
│ VERIFIER │
└────┬──────┘
↓
┌─────────┐
┌───│ SCORE │───┐
│ └─────────┘ │
better worse
│ │
KEEP RESET
│ │
└────────┬─────────┘
↓
LOOP
↺
換成控制系統語言：
program.md = Policy
LLM = Controller / Reasoner
tools = Actuators
repo = Environment
tests/eval = Sensors
metric = Reward / Feedback
Git = State + Rollback
loop = Control System
這才是 Karpathy 這波思考真正的本質：工程師不再主要設計「Agent 下一句要聽什麼」，而是設計「什麼環境會讓 Agent 自己持續朝正確答案收斂」。
而這也是為什麼 autoresearch 看起來只有幾個檔案，卻比很多上萬行的 Multi-Agent Framework 更值得研究。
如果要研究原始碼，優先順序就是：autoresearch README → program.md 的真正 LOOP FOREVER 實作 → Karpathy 自己開的 Codex loop 問題 #57 → 8-agent research org 原始 X。
這個領域變化非常快，可以持續追蹤 Karpathy、Claude Code、Codex 與 OpenClaw 對 Agent Loop / Harness 的新實作。