Andrej Karpathy 的 Loop / Agent Harness 實作深度解析

01 來源溯源與核心概念

近年在 AI Agent 社群廣為流傳的名言：「不要再直接 prompt coding agents，而要設計會去 prompt agents 的 loops」，經常被標註為 Andrej Karpathy 的發言。然而在進行事實查核後，需要先釐清精確的歷史出處。

來源查證（Provenance Check）：
該句名言的原始公開貼文來自 Peter Steinberger（OpenClaw 作者）於 2026 年 6 月在 X（前 Twitter）上的分享。與此同時，Boris Cherny（Anthropic Claude Code 負責人）在同期訪談中亦表達過高度一致的工作哲學。

然而，Andrej Karpathy（OpenAI 共同創辦人、前 Tesla AI 總監）在此方向上提供了更具體、具備完整可重現程式碼的開源實作：karpathy/autoresearch。在此之前，他更公開測試了一套由 4 個 Claude + 4 個 Codex、Git worktree 與 tmux 組成的「AI Research Organization」實驗。

一句話理解 Karpathy 做的事：
Karpathy 並非發明全新的龐大 Agent 框架，而是將 Prompt 的層級從「每次告訴 Agent 下一步做什麼（Task-level instructions）」，提升為「定義一個可以永久運轉的程式／制度（System-level control policy）」，讓 Agent 在 Eval → Feedback → Rollback → Retry 的閉環（Closed Loop）中自主工作。

02 範式轉移：從單輪對話到 Outer Loop

傳統使用 Coding Agent 的模式是「人類提出需求 → Agent 輸出代碼 → 人類人工審查 → 人類再次提示」。這種模式將人類置於每一個決策迴圈的中心，形成了嚴重的輸送量瓶頸。

傳統 Prompting 工作流（Human in the loop）

Human
  ↓ (Prompt)
Agent
  ↓ (Code)
Human Review
  ↓ (再 Prompt)
Agent
  ↓ (Code)

人類必須不斷監看輸出並給出下一步指令，Agent 缺乏自我修正的客觀邊界。

Karpathy 的 Harness 閉環架構（Outer Loop）

        Human
          │ (修改 program.md / 制度)
          ▼
   Claude Code / Codex
          │ (修改 train.py)
          ▼
      git commit
          │
          ▼
  immutable evaluator
     (prepare.py)
          │
          ▼
   val_bpb improved?
     ┌────┴────┐
    YES        NO
     │         │
   KEEP    git reset
     │         │
     └────┬────┘
          ▼
      NEXT LOOP ↺

人類負責編程研究制度（program.md），由客觀驗證器與 Git 狀態機接管每輪迴圈。

在這種架構下，人類工程師的工作不再是整天在終端機裡手打 Prompt，而是編寫「組織制度代碼（Programming the autonomous research org）」。

03 完整工具鏈與組件分工

在 karpathy/autoresearch 專案中，Karpathy 刻意使用極為精簡、標準的 UNIX 工具鏈，而非依賴龐大的外包第三方庫：

核心組件	技術實現	在 Harness 系統中的職責與角色
Agent Runtime	Claude Code / OpenAI Codex	可替換的推理與執行引擎（Execution Engine），負責閱讀指令並修改代碼。
Control Policy	`program.md`	核心營運程序（Standard Operating Procedure），定義目標、約束與無限迴圈策略。
Mutable Surface	`train.py`	Agent 唯一主要允許修改的檔案。模型架構、優化器、超參數皆在此調整。
Immutable Verifier	`prepare.py`	不可篡改的驗證器（Ground Truth）。嚴格禁止 Agent 修改，防止其「修改考卷讓自己考滿分」。
State & Rollback	Git (branch/commit/reset)	作為狀態機與檢查點機制。驗證通過保留 Commit，驗證失敗直接 `git reset`。
Persistent Memory	`results.tsv` + `run.log`	長期狀態持久化至磁碟，避免大量歷史數據淹沒 LLM 的 Context Window。
Hardware & Env	NVIDIA H100 GPU + `uv` + Python	單卡自包含運行環境。每次實驗固定約 5 分鐘，每小時約可執行 12 次實驗迭代。
Isolation & Multi-Agent	Git worktree + tmux	多 Agent 場景下的檔案系統隔離與可視化監控，刻意不引入 Docker/VM 容器開銷。

04 `program.md` 狀態機解析

program.md 是整套系統的靈魂。它本質上是一個使用自然語言編寫的確定性狀態機（Natural Language State Machine）。

其核心運行邏輯可被精確抽象為以下虛擬代碼：

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, idea_description)
    
    # 閉環決策：指標進步則保留，退步則回滾
    if score < best_score:
        keep_commit()
    else:
        git_reset_to_previous_best()
    
    # 永久循環，永不自主停止

LOOP FOREVER 與 NEVER STOP 鐵律：
官方 program.md 中極其明確地寫下 LOOP FOREVER 與 NEVER STOP。系統嚴格禁止 Agent 詢問人類：

"Should I continue?"
"Is this a good stopping point?"

Agent 必須持續運行，直到人類手動中斷（Ctrl+C）。若單次實驗超過 10 分鐘，系統將直接終止進程並進行 Revert。遇到程式崩潰，能修復則修復，方向根本錯誤則直接 Discard。

05 Agent Harness 控制系統映射

從經典控制系統工程（Control Systems Engineering）與強化學習的視角拆解，Karpathy 的設計構建了一套完備的閉環回饋架構：

軟體工程與 AI 組件

LLM（Claude / Codex）
program.md
train.py
prepare.py
val_bpb（Validation loss）
Git Commit / Reset
results.tsv
run.log + grep

控制系統對應語義

Controller / Reasoner（控制器／推理機）
Control Policy（控制策略）
Plant / Mutable Env（受控對象／可變環境）
Ground Truth Verifier（客觀驗證器）
Reward Function（獎勵回饋函數）
State Checkpoint & Rollback（狀態存檔與回滾）
Persistent Memory（持久化記憶）
Observation Stream & Filter（觀測流與壓縮）

Prompt Engineering vs Harness Engineering 的分水嶺：
Agent 是否具備編寫代碼的能力已不再是核心瓶頸；Harness Engineering 的核心任務是決定：Agent 在什麼環境下編寫代碼、如何客觀判定成敗、失敗如何乾淨回滾、成功如何持久保留、每輪迭代應注入哪些精確觀測，以及何時終止。

06 上下文工程（Context Engineering）與日誌過濾

在長時間運行的 Agent 系統中，Context Window 溢出與雜訊干擾是造成 Agent 幻覺和退化的首要原因。Karpathy 在 program.md 中實踐了極具啟發性的上下文工程。

系統執行命令為：

uv run train.py > run.log 2>&1

關鍵規則：絕對不使用 tee 命令，禁止將完整的終端輸出直接刷入 Agent 的上下文。

資訊流壓縮機制：

當實驗成功完成時，Harness 僅透過 grep 抓取核心指標餵回 Agent：

grep "^val_bpb:\|^peak_vram_mb:" run.log

僅在程式發生崩潰（Crash）時，才透過 tail 提取最後 50 行追蹤堆疊：

tail -n 50 run.log

環境產生 50,000 Tokens 完整日誌
              ↓
Harness 進行精準觀測壓縮（Grep Filter）
              ↓
Agent 僅接收 20 Tokens 核心結果
              ↓
專注於下一輪假設推理（No Context Pollution）

上下文工程的核心不是強求模型「記住更多無效細節」，而是由外部 Harness 精準過濾雜訊，確保模型注意力集中於關鍵決策。

07 雙層迴圈架構：Inner Loop vs Outer Loop

當前如 Claude Code 與 OpenAI Codex 這類 Coding Agent 本身已內建一層工具調用迴圈（Inner Agent Loop）：

Inner Agent Loop（模型內部）

LLM 進行推理
   ↓
呼叫 Tool (Edit / Bash / Read)
   ↓
讀取 Tool 執行回傳
   ↓
再次思考推理
   ↓
呼叫下一個 Tool
   ↺ (直至單一任務完成)

Outer Harness Loop（外部框架）

        OUTER HARNESS LOOP
┌────────────────────────────────┐
│ 1. Propose Experiment (假設)    │
│       ↓                        │
│ 2. INNER AGENT LOOP (產出代碼) │
│       ↓                        │
│ 3. Run Verifier (獨立評測)      │
│       ↓                        │
│ 4. Compare Metric (指標比對)   │
│       ↓                        │
│ 5. Keep Commit / Git Reset     │
│       ↓                        │
│ 6. Next Iteration ─────────────┘

Karpathy 將 Prompt 從單一任務的指令（Task-level instruction），提升為整個系統的運行規範（System-level policy）；再透過確定性的驗證回饋迴圈接管日常演進。

08 4 Claude + 4 Codex 實驗與反思

2026 年 2 月底，Karpathy 公開分享了他建立的多 Agent 自主研究組織實驗。他配置了 4 個 Claude 與 4 個 Codex 分別掛載於獨立 GPU 上，並測試了兩種不同的組織拓撲：

拓撲 A：8 個獨立研究員（Independent Researchers）

8 個 Agent 各自擁有獨立的 GPU 與 Git 分支，各自提出假設並並行驗證。

拓撲 B：首席科學家 + 初階研究員階層

1 位 Chief Scientist Agent 負責制定全局研究方向與分解任務，指派給多位 Junior Researcher Agents 執行。

在此實驗中，每個研究項目對應一個 Git Branch，Agent 透過 Git worktree 實現檔案系統隔離，透過純文字檔案進行通訊，並在 tmux grid 中集中監控各 session。Karpathy 刻意未引入 Docker 或 VM。

關鍵實驗反思：「很亂，而且不太 work（Messy and didn't quite work）」
實驗失敗的原因不是 Agent 不會寫程式，而是 Agent 的代碼實作能力很強，但「實驗科學設計能力」嚴重不足：

產生大量缺乏統計意義的微小變異（Meaningless variations）。
未能建立嚴謹的基準對照組（Baseline）。
缺乏完整的消融實驗（Ablation studies）。
未控制運算複雜度與 FLOPs，甚至將「把網路參數量放大導致 Loss 下降」這類顯而易見的混淆結果誤認為突破性研究發現。

這證明了 Multi-Agent 並非「1 個不夠聰明就放 8 個（8 倍聰明）」。當 Agent 數量增加時，系統真正的瓶頸轉移至實驗設計、評估驗證、協調通訊、記憶管理與資源分配——也就是 Harness 本身。

09 Programming an Organization 與 Org Code

在多 Agent 實驗後，Karpathy 提出了一個極具前瞻性的概念：工程師未來的工作本質是「Programming an Organization（為組織編程）」。

未來的軟體源碼將不再僅由 .py、.ts 或 .go 組成，而是包含組織運行的全套規則：

Org Code 的範疇：

Prompts & Roles：各角色的思考邊界與責任範圍。
Skills & Tools：工具集與環境操作授權。
Processes & Evaluation：評測標準與驗收硬性指標。
Communication Protocol & Handoff：Agent 間的交接規格。
Daily Standup：將人類管理制度轉化為可執行的排程程式。
Git Rules & Resource Allocation：版本分支策略與 GPU/算力資源分配。

10 Codex 早退問題與 Supervisor Watchdog 迴圈

在 2026 年 3 月 8 日，Karpathy 於 autoresearch 倉庫提出了 Issue #57：他發現 Codex CLI 在執行數輪後會忽略 NEVER STOP 指令而自行退出，相比之下 Claude Code 對持續無限迴圈的支援較為穩定。

為了解決 Agent Runtime 自行退出的問題，社群提出的標準解決方案是在最外層封裝一個 Supervisor Watchdog Loop：

while true; do
  codex exec "Read program.md and run the next experiment"
  sleep 1
done

三層穩健 Harness 架構：

Supervisor / Watchdog Loop (最外層：崩潰重啟與監控)
        │
        ▼
Claude Code / Codex Session (中層：Inner Agent Loop 工具調用)
        │
        ▼
Deterministic Verifier & Git State (底層：客觀驗證與狀態回滾)

11 軟體工程實踐範式（General Software Engineering）

若將 Karpathy 的 autoresearch 設計模式推廣至日常軟體工程開發，標準專案架構與驗證機制如下：

my-project/
├── program.md          # Agent 的作業系統與運行策略
├── src/                # Agent 可自由修改的可變代碼區
├── eval/               # 嚴格禁止 Agent 修改的驗證器
│   ├── unit-tests/
│   ├── integration/
│   ├── playwright/     # E2E 瀏覽器驗證
│   ├── benchmark/      # 效能基準
│   └── score.py        # 評分腳本
├── state/              # 狀態記錄
│   ├── results.jsonl
│   ├── current-goal.md
│   └── best-commit.txt
├── logs/               # 完整日誌存檔
└── harness.sh          # 驅動腳本

軟體工程的 Definition of Done（完成定義）：
不再是模糊的「請幫我確認功能做好了」，而是由確定性硬性閘門構成：

Unit & Integration Tests: PASS
TypeScript Typecheck: PASS
ESLint / Linter: PASS
Playwright E2E: PASS
Visual Regression: < 1%
Lighthouse Performance: > 90
API Latency P95: < 300ms
Security SAST: PASS

黃金公式：
$$\text{Agent Autonomy} \propto \text{Verifier Reliability}$$ 驗證器越客觀、越確定，給予 Agent 的自主運行權限才能越高；反之，若缺乏可靠驗證器，盲目放開自主權只會導致代碼品質快速退化。

12 為什麼初期不需盲目套用複雜框架

許多團隊在嘗試建立 Agent 系統時，一開始便引入 LangGraph、CrewAI、Temporal、Redis、Vector DB、Kafka 與 Kubernetes，然而最終往往陷入「框架複雜度極高，卻無法穩定產出」的困境。

Karpathy 的極簡工程哲學：
autoresearch 專案刻意採用「One GPU, One File, One Metric」的設計原則。整個閉環僅依賴：

Claude Code / Codex + Markdown + Git + Shell + Files + Deterministic Evaluator

先將 Loop 與 Verifier 做好，再考慮 Orchestration。
如果連最基本的 done() 驗收函數與回滾機制都尚未穩定，構建再華麗的多 Agent 調度平台也無法解決收斂問題。

13 關於網路流傳 `LOOPS.md` 的事實查核

近期社群流傳一份名為 LOOPS.md: Field Notes on Agents That Run for Days 的文件，並廣泛被標註為 Andrej Karpathy 的私人開發規範。

Fact-Check 結論（Attributed to Karpathy, but unverified）：
經過多方檢索與溯源比對，在 Karpathy 的官方 GitHub、公開 Gist 以及個人網站中，皆無發布該文件的紀錄，亦無本人公開證實。該文件彙整了許多優秀的 Harness Engineering 原則，但在文獻引用上不可視為 Karpathy 本人的正式著作。

當前唯一具備 100% 權威性、由 Karpathy 本人編寫並開源的實作基準，依然是 karpathy/autoresearch 及其中的 program.md。

14 控制系統哲學與延伸資源

Karpathy 的 Loop / Harness 實作展示了 AI 軟體工程的根本性典範轉移：工程師的核心職責不再是教導模型如何寫代碼，而是為模型設計一個具備自我修正、能夠朝全域最佳解自動收斂的封閉環境。

「把 Prompt 從任務層級的指令，提升為系統層級的控制策略；再由確定性的回饋迴圈接管日常演化。」 — Agent Harness Engineering 核心思想

Andrej Karpathy 的 Loop / Agent Harness 到底是怎麼實作的？

01 來源溯源與核心概念

02 範式轉移：從單輪對話到 Outer Loop

03 完整工具鏈與組件分工

04 `program.md` 狀態機解析

05 Agent Harness 控制系統映射

06 上下文工程（Context Engineering）與日誌過濾

07 雙層迴圈架構：Inner Loop vs Outer Loop

08 4 Claude + 4 Codex 實驗與反思

09 Programming an Organization 與 Org Code

10 Codex 早退問題與 Supervisor Watchdog 迴圈

11 軟體工程實踐範式（General Software Engineering）

12 為什麼初期不需盲目套用複雜框架

13 關於網路流傳 `LOOPS.md` 的事實查核

14 控制系統哲學與延伸資源

權威參考資料與原始代碼鏈接

01 來源溯源與核心概念

02 範式轉移：從單輪對話到 Outer Loop

03 完整工具鏈與組件分工

04 program.md 狀態機解析

05 Agent Harness 控制系統映射

06 上下文工程（Context Engineering）與日誌過濾

07 雙層迴圈架構：Inner Loop vs Outer Loop

08 4 Claude + 4 Codex 實驗與反思

09 Programming an Organization 與 Org Code

10 Codex 早退問題與 Supervisor Watchdog 迴圈

11 軟體工程實踐範式（General Software Engineering）

12 為什麼初期不需盲目套用複雜框架

13 關於網路流傳 LOOPS.md 的事實查核

14 控制系統哲學與延伸資源

權威參考資料與原始代碼鏈接

04 `program.md` 狀態機解析

13 關於網路流傳 `LOOPS.md` 的事實查核