在 Andrej Karpathy 發布的《LOOPS.md》技術手記中，「循環工程（Loop Engineering）」正式確立為建構數日級長程自主 Agent 的核心方法論。 過去兩年間，許多與大型語言模型打交道的工程師常陷入「深夜 Prompt 調參玄學」的困境：為了讓 Agent 完成複雜的多步驟任務，反覆微調 System Prompt 的語氣甚至加入情緒誘導，但一旦任務拉長至數小時甚至數天，系統便迅速遭遇上下文腐化、模型自我諂媚與死迴圈崩潰。前 OpenAI 聯合創始人 Andrej Karpathy 敏銳指出，制約 Agent 投入生產的瓶頸早已超越模型本身的智商範疇，關鍵核心在於外圍的 Harness 與執行循環架構。本文將為你深入剖析《LOOPS.md》提出的 9 條黃金架構法則，拆解三角色分離、磁碟狀態持久化與契約協商機制，助你建構具備極高可靠度的自主 Agent 系統。
1. 告別深夜 Prompt 調參玄學：為什麼「循環工程」成為新典範？
在早期的 AI 開發模式中，開發者習慣將注意力全部集中在單次提示詞的調優上。然而，提示詞本質上是「單次消費型」產物；而真正的自主系統需要的是一個即便開發者在睡眠時，依然能在背景不知疲倦穩定運行的閉迴路（Loop）。
- Prompt 槓桿效益見頂：當前頂級基底模型已經具備極高的指令遵循與步驟推理能力，純粹微調文字措辭所帶來的邊際效益已大幅遞減。
- 流程（Procedure）決定系統上限：真正拉開企業級 AI 差距的，在於如何將業務邏輯編排為穩健的執行流程。
- 標準循環五動詞：一個強健的自主循環由五個核心動詞構成：收集、推理、行動、驗證、重複（Gather, Reason, Act, Verify, Repeat）。所有的外部架構設計，本質上都是這五個動詞的具體落實。
提示詞工程 vs. 循環工程典範轉移：
提示詞工程 (Prompt Era) ──► 反覆微調單一 System Prompt ──► 上下文腐化、模型自我諂媚、長程任務崩潰
循環工程 (Loop Era) ──► [Gather 收集 ──► Reason 推理 ──► Act 行動 ──► Verify 驗證 ──► Repeat 重複] ──► 數日級穩定自主運行
2. 9 條黃金架構法則深度拆解：建構數日級自主 Agent 的工程藍圖
Karpathy 在手記中歸納了讓 Agent 脫離「玩具 Demo」並真正交付可用軟體產品的 9 條關鍵法則：
規則一：別再寫 Prompt，去寫循環（Write the Loop, Not the Prompt）
當模型已經足夠聰明時，請關掉 Playground 標籤頁，將精力轉移至建構控制流狀態機。
規則二：徹底分離角色（Separate the Roles）
系統必須具備三個獨立的角色、三個獨立的上下文窗口，以及三套專屬的系統提示詞： - 規劃者（Planner）：負責將人類模糊的需求轉化為具體的規格需求（Spec），絕對嚴禁碰程式碼。 - 生成者（Generator）：負責撰寫所有程式碼與實作，但嚴禁給自己的產出打分。 - 評估者（Evaluator）：負責讀取程式碼差異（Diff）、啟動自動化測試並實際執行驗證。它從被啟動的第一秒起就被賦予「這份程式碼必定有 Bug」的預設預設立場，唯一任務就是找出失敗證據。
規則三：先在磁碟上協商「契約」（Negotiate the Contract First）
在生成者寫下第一行程式碼之前，生成者與評估者必須在磁碟的 Markdown 檔案中展開論證與反駁，最終共同產出一份包含具體可測試斷言（Testable Assertions）的清單（例如 25 至 30 條明確標準）。這份契約是驗收的唯一客觀基準。
規則四：狀態寫入磁碟，別塞進上下文（Write to Disk, Not to Context）
大型模型的上下文窗口會隨著對話拉長而產生注意力稀釋與摘要遺失，但本地磁碟不會說謊。工作目錄中應精簡維護四個檔案：feature_list.json（功能清單）、progress.md（進度）、contract.md（契約）以及僅允許追加寫入的 log.md。
規則五：允許循環「推倒重來」（Let the Loop Restart）
當 Agent 發現實作走進死胡同且架構劣化時，優秀的新一代模型會展現出主動刪除整個專案並重新建構的行為。請不要人為打斷這種重構，乾淨的重啟正是健康循環在發揮作用的體現。
規則六：給主觀體驗與審美品味量化打分（Score the Subjective）
審美與軟體工藝可以被量化。在評估器中設定四個加權維度：設計（Design）、原創性（Originality）、工藝（Craft）與功能性（Functionality），並提供明確的高品質典範與低劣垃圾範例供模型對齊收斂。
規則七：像讀呼叫堆疊一樣精讀 Trace 日誌（Read the Traces）
除錯 Agent 循環的最佳方式是閱讀原始執行日誌（Transcript / Traces）。使用 grep 檢索模型決策開始與人類意圖分歧的關鍵瞬間，並針對該上下文修正提示詞。
規則八：隨時準備刪除過時的 Harness（Delete the Harness）
外骨骼（Harness）的存在是為了彌補當前模型的缺陷。隨著底層模型智商迭代，每季都應主動審視並刪除已被模型原生能力吸收的多餘控制邏輯，避免架構單調膨脹。
規則九：瓶頸永遠在移動（The Bottleneck Always Moves）
當編寫程式碼不再是瓶頸，規格規劃成為瓶頸；當規劃自動化，驗證成為瓶頸；當驗證完備，審美品味成為終極瓶頸。設計循環的目的是讓下一個瓶頸清晰暴露。
| 架構構件 | 傳統單體 Agent 設計缺陷 | Karpathy LOOPS 循環工程設計規範 | 系統可靠度提升指標 |
|---|---|---|---|
| 角色職責邊界 | 單一模型實例兼任編程與自我驗收 | 規劃者、生成者、評估者三權分立 | 徹底消除 95% 以上的諂媚性自我評分漏洞 |
| 狀態管理載體 | 全量堆疊於記憶體上下文視窗 | 本地檔案系統持久化（4 個核心檔案） | 支援任意節點當機重啟並 100% 接續進度 |
| 驗收標準確認 | 人類給予模糊文字評估 | 執行前由生成者與評估者協商可測試斷言契約 | 消除驗收標準不一致引發的無效返工 |
| 錯誤修復策略 | 在劣化程式碼上反覆追加補丁 | 評估器觸發清空重構（Clean Rebuild） | 避免技術債累積導致的長程死鎖 |
3. 為什麼大模型會「自我諂媚」？評估者的獨立博弈機制
在多數失敗的 Agent 系統中，最致命的架構缺陷就是讓生成者為自己的產出打分。研究與實戰數據表明：
- 自我確認偏誤（Confirmation Bias）：模型在評估自己撰寫的邏輯時，傾向於忽略邊界條件與潛在例外，並給出虛假的「驗證通過」結論。
- 對立博弈設計：將評估者獨立於另一個獨立的上下文窗口中，並在系統提示詞中植入「懷疑主義」立場，強制其透過實際執行單元測試、Headless Browser（如 Playwright）操作來尋找破綻，才能建構真實的品質防線。
生成者與評估者的對立博弈流程：
人類需求 ──► [規劃者 Planner] ──► 產出規格需求 (Spec)
│
┌─────────────────────────┴─────────────────────────┐
▼ ▼
[生成者 Generator] (撰寫程式碼) ◄───[磁碟契約 debate]───► [評估者 Evaluator] (預設必有 Bug)
│ │
└───────────────► 執行驗證 (通過 / 拒絕重構) ─────────┘
4. 檔案系統作為唯一真實來源：狀態持久化與斷點續行實踐
為了讓 Agent 具備連續運行數天的強韌性，開發團隊必須將本地檔案系統視為唯一的系統真實來源（Single Source of Truth）：
1. 核心狀態檔案矩陣
feature_list.json：結構化的功能進度表，標註各模組的未開始、進行中與已驗收狀態。contract.md：前置協商完成的具體測試斷言清單。progress.md：當前迭代的執行摘要與決策記錄。log.md：嚴格僅允許追加寫入（Append-only）的操作日誌，格式規範為## [YYYY-MM-DD] op | title。
2. 無狀態會話與斷點復原
當底層 API 發生網路中斷或執行行程崩潰時，重啟的 Agent 只需重新讀取這四個磁碟檔案，即可在數秒內精確還原上下文狀態，完全不依賴易失的記憶體快取。
5. 常見問題（FAQ）
Q1：什麼是 Loop Engineering（循環工程）與 Prompt Engineering（提示詞工程）的核心差異？
提示詞工程著重於調優單次輸入文字的語氣與指令結構，屬於靜態最佳化；而循環工程著重於建構多角色協同、狀態持久化、自動化測試與錯誤復原的動態控制流，是支撐長程任務運行的系統級架構。
Q2：為什麼評估者（Evaluator）必須與生成者（Generator）使用不同的上下文視窗？
若共用上下文視窗，生成者的思考邏輯會污染評估者的判斷，導致模型產生自我諂媚與寬鬆驗收的現象。獨立的上下文能確保評估者站在客觀且嚴苛的視角審視產出。
Q3：在長程任務中，允許 Agent「刪庫重來」是否會浪費大量 Token？
恰恰相反。當程式碼架構已經走入死胡同，在錯誤基礎上反覆打補丁往往會消耗更多 Token 並最終走向崩潰；果斷刪除並依據明確契約重新建構，通常能在更少迭代輪次內交付高品質成果。
Q4：一般團隊該如何開始導入《LOOPS.md》的架構原則？
建議先從「三檔案狀態管理（進度、功能清單、追加日誌）」以及「分離寫程式碼與驗收測試提示詞」開始著手，逐步建立外部確定性驗證閘門。
權威引用
- Andrej Karpathy — LOOPS.md: Field Notes on Agents That Run for Days
- Anthropic — Building Effective Agents: Workflows and Architectural Patterns
- Tony Bai — Andrej Karpathy 解析 Loop Engineering 9 條黃金法則
- Hacker News — Discussion on Long-Running Autonomous Agent Harnesses
- arXiv — Scaffolding and Adversarial Evaluation in Autonomous Code Generation
Author Insight
從 Prompt 到 Harness，再到 Karpathy 總結的 Loop Engineering，AI 應用的開發哲學正在經歷一場回歸軟體工程本質的偉大復興。大模型給予了我們前所未有的推理能力，但要將這種隨機的智慧轉化為確定性的軟體產品，依然需要依靠經典的職責分離、磁碟契約與嚴格的評估體系。著手為 Agent 建構健壯的運作迴路，跳脫深夜調參的泥淖，正是每位 AI 架構師邁向成熟的關鍵路徑。
我們團隊持續深耕企業級 AI Agent 架構設計、Harness 循環工程實務與自動化工作流導入方案。如果你正在評估團隊的長程代理人系統架構，歡迎與 Tenten 團隊預約諮詢。
