前言
最近矽谷的 Agent 圈又冒出了一個新概念：Loopcraft。
第一次看到這個詞，我想這不就是給 Agent 套一個 while true 嗎？前幾年叫 Agent Loop，後來叫 Workflow、Harness Engineering，現在又發明了一個 Loopcraft，矽谷 AI 圈總是在不斷造詞……
不過順著最近 Peter Steinberger、Claude Code 負責人 Boris Cherny，以及 Andrej Karpathy 關於 Agent Loop 的討論看下去，我發現這次的變化還是有點不一樣的，所以來系統梳理一下。
Peter Steinberger 的說法是：
You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.
你不應該繼續親自 Prompt Coding Agent，而應該設計一個負責 Prompt Agent 的循環。
Boris Cherny 的說法是：
I don’t prompt Claude anymore. I write loops. The loops do the work.
我不再親自 Prompt Claude。我負責寫循環，循環負責幹活。
Karpathy 在介紹 Autoresearch 時也表達了類似的觀點：如果人還需要不斷查看結果、判斷下一步、再給 Agent 新指令，那麼人本身就成了整個系統的吞吐量瓶頸。
這幾句話放在一起，背後其實是一次抽象層上移：
以前：
人 → Prompt → Agent → 結果
現在：
人 → 設計 Loop
↓
任務發現 → Agent 執行 → 自動驗證 → 失敗重試 → 保存狀態 → 繼續運行
我目前對 Loopcraft 最簡潔的理解是：Prompt Engineering 優化一次互動，Loopcraft 優化整個反覆運行的系統。
它關注的不是這一個任務怎麼做好，而是：
- 下一次任務由誰發起；
- Agent 如何知道自己該做什麼；
- 輸出由誰檢查；
- 失敗後如何獲得回饋；
- 是否需要重試、換策略或者交給人；
- 狀態如何跨越不同會話保存；
- 多次運行累積下來的經驗，如何反過來改進系統。
這篇文章，我想具體拆三個問題：
- Loopcraft 到底是什麼，為什麼最近突然火了；
- 它與之前很火的 Agent Harness 有什麼區別；
- 普通開發者現在能不能搭一個簡單的 Loop 跑起來。
一、為什麼大家突然不談 Prompt，開始談 Loop 了
過去兩年，我們使用 Coding Agent 的典型方式，大致是這樣的：
告訴 Agent 要做什麼
→ 等它修改程式碼
→ 人檢查結果
→ 告訴它哪裡不對
→ Agent 繼續修改
→ 人再次檢查
模型已經在寫程式碼、搜尋檔案和運行測試，但整個過程仍然由人一步一步驅動。
Agent 每完成一輪，就停下來等下一條指令。
從表面上看，這是人在使用 Agent；換一個角度看，其實也是人充當了 Agent 系統的調度器、狀態機和驗證器。
所以模型雖然很快，人卻依然無法離開。各種 Agent 產品推出行動端非同步監管功能，也是為了緩解這個問題。
這正是最近 “Loop discourse” 提出的問題：不要只讓 Agent 自動執行其中一步，而是把任務發現、分配、驗證和繼續推進也設計成一個系統。
比如，以前修復一個 CI 問題可能是：
我看到 CI 失敗 → 打開 Codex → 複製錯誤日誌 → 讓它分析 → 看修改結果 → 讓它運行測試 → 檢查通過 → 手動建立 PR
放進 Loop 之後可以變成：
CI 失敗事件 → 自動讀取錯誤日誌 → 判斷是否屬於可自動處理的問題 → 在獨立 worktree 中啟動 Agent → 修改程式碼 → 運行測試和 lint → 第二個 Verifier 檢查 diff → 通過後建立 PR → 無法處理時通知人
這裡真正被自動化掉的，是修改程式碼周圍的整個閉環。
因此 Loopcraft 不是某個新的模型能力，也不是某個特定框架。
它更像是一種 Agent 系統設計方法：將任務執行、結果驗證、事件觸發、狀態保存和系統改進，組織成多個可以嵌套的循環。
二、Loopcraft 是新概念嗎？
Loopcraft 作為名字，確實非常新。但它背後的技術元素並不新。
我們早就有：
- Agent 的 Reason-Act-Observe 循環；
- Workflow 和狀態機；
- 自動測試和 CI/CD；
- 定時任務與事件驅動；
- 多 Agent 協作；
- LLM as a Judge；
- Reflexion 和 Self-Refine；
- 長期記憶；
- 自動實驗與爬山優化。
甚至最簡單的 Ralph Loop，本質上就是不斷重新呼叫 Coding Agent：
while true; do
claude "讀取任務和當前進度，繼續完成工作"
done
三、Agent Harness 和 Loopcraft 到底有什麼區別？
這是我覺得最容易混淆的地方。
過去一年，Agent Harness 已經是一個很熱門的概念。
Anthropic 對 Harness 的定義很清楚：它是讓模型能夠作為 Agent 工作的系統，包括上下文處理、工具呼叫、權限、環境、狀態管理和結果返回。
簡單說，Harness 解決的是：這個 Agent 在什麼樣的環境裡工作？
而 Loopcraft 解決的是另一個問題：這個 Agent 什麼時候被啟動，為什麼繼續運行，結果由誰檢查，下一輪做什麼？
用一組不完全嚴謹，但容易理解的比喻：
Model：工人的大腦
Tools：工人手中的工具
Harness：工人的工位和工作環境
Loop：工廠的生產節拍、質檢和任務調度
Loopcraft：如何設計並疊加整套生產循環
當然，我在真實實踐裡發現兩者邊界並不能完全絕對。
一個成熟的長任務 Harness，本身就包含重試、驗證和狀態交接；一個 Loop 也必然依賴 Harness 提供工具和環境。
我更願意把它們理解為關注點不同：
| 概念 | 主要關注的問題 |
|---|---|
| Prompt Engineering | 這一輪模型應該看到什麼指令 |
| Context Engineering | 模型此刻應該看到哪些資訊 |
| Tool Engineering | Agent 可以執行哪些動作 |
| Harness Engineering | 一次 Agent 運行如何可靠發生 |
| Loopcraft | 多次運行如何被觸發、驗證、連接和持續改進 |
所以 Loopcraft 並沒有取代 Harness。
恰恰相反，沒有穩定的 Harness，Loop 只是在自動、持續地製造錯誤。
四、Loopcraft 不是一個循環，而是多個循環的疊加
LangChain 後來把 Loopcraft 拆成了四個比較容易落地的層級。我覺得這個拆法很實用。
第一層：Agent Loop
最內層就是我們熟悉的 Agent：
模型思考
→ 呼叫工具
→ 讀取工具結果
→ 繼續思考
→ 直到認為任務完成
例如一個文件 Agent 可以：
讀取 Issue → 搜尋倉庫 → 修改 Markdown → 檢查連結 → 建立 PR
第二層：Verification Loop
Agent 說完成了，不代表任務真的完成了。因此，需要在 Agent 外面包一層驗證：
Agent 執行
→ Verifier 檢查
→ 不通過則返回具體回饋
→ Agent 再次執行
→ 直到通過或超過預算
Verifier 可以是單元測試、型別檢查、lint、Schema 校驗等等。
但這裡有一個很重要的原則：盡量不要讓做題的人，同時負責給自己判卷。
第三層：Event-driven Loop
有了執行和驗證，接下來是不再由人手動啟動。
任務可以由真實事件觸發，此時 Agent 不再只是一個聊天工具，而是業務系統中的後台元件。
事件
→ 確定性規則判斷是否需要處理
→ 啟動 Agent
→ 驗證結果
→ 更新真實系統
第四層：Hill-climbing Loop
前三層自動化的是工作。
第四層開始自動化如何把工作做得更好。
每次 Agent 運行都會留下 Trace：
- 收到了什麼任務；
- 呼叫了哪些工具；
- 在哪裡失敗；
- Verifier 為什麼拒絕；
- 消耗了多少 Token；
- 是否需要人工接管。
外層系統可以定期分析這些軌跡：
收集多次運行記錄
→ 找出高頻失敗模式
→ 調整 Prompt、Tool、Skill 或 Verifier
→ 在 Eval 集上重新測試
→ 通過後更新 Harness
這一層才是我認為 Loopcraft 最有價值的部分。
因為普通的循環只是重複工作，而 Hill-climbing Loop 會改變產生結果的系統。
普通 Loop：
失敗 → 再試一次
改進 Loop：
失敗 → 分析為什麼失敗
→ 修改 Prompt、工具或驗證規則
→ 讓未來的運行更可靠
外層循環的返回箭頭，不只是回到任務開頭，而是伸進了 Agent 內部，開始改造內層循環。
這時候，系統才真正出現了複利。
五、Karpathy 的 Autoresearch，是目前最標準的 Loopcraft 案例
要理解 Loopcraft，Karpathy 的 Autoresearch 是一個很好的實踐樣本。
這個專案做的事情並不複雜：
Agent 提出一個訓練改進
→ 修改 train.py
→ 運行固定五分鐘的訓練
→ 讀取 val_bpb 指標
→ 指標更好則保留
→ 指標變差則回滾
→ 開始下一次實驗
它能夠在無人干預時，每小時執行大約 12 次實驗，睡一覺可以完成接近 100 次實驗。
這裡真正聰明的不是 Agent Prompt 寫得多麼複雜，而是 Karpathy 把問題改造成了一個非常適合循環優化的環境：
- Agent 只能修改一個檔案；
- 評價指標固定；
- 每次實驗時間固定；
- 結果可以自動比較；
- 失敗可以回滾；
- Git 記錄完整實驗歷史；
- 驗證程式碼不能被 Agent 修改。
這就是 Loopcraft 的核心變化：人從直接完成任務，轉向設計一個能夠反覆完成、驗證和改進任務的系統。
六、自己怎麼搭一個最小 Loop？
Autoresearch 的環境比較特殊。普通開發者可以先從更簡單的場景入手：
自動接收一個小型 Issue，嘗試修復，通過測試後建立 PR，失敗則帶著回饋重試。
先別急著上多 Agent。一個最小 Loop 只需要六個部分：
- Trigger：什麼事件啟動任務，例如 CI 失敗、定時任務或帶有特定標籤的 Issue。
- Goal：明確什麼叫完成，最好能轉化為測試、lint、型別檢查等機器可驗證條件。
- State：把嘗試次數、失敗原因和當前進度寫進檔案或資料庫，不要只依賴聊天上下文。
- Worker：讓 Coding Agent 在獨立的 worktree 或容器中執行，避免污染主分支和其他任務。
- Verifier：優先使用測試、規則和靜態檢查，只有難以形式化的部分才交給 LLM Reviewer。
- Budget：限制嘗試次數、運行時間和成本，涉及高風險操作時及時交給人。
整個流程可以簡化成：
for attempt in range(3):
result = run_agent(goal, load_state())
verdict = verify(result)
save_state(result, verdict)
if verdict == "passed":
create_pull_request()
break
if verdict != "retryable":
notify_human()
break
具體使用 Claude Code、Codex、GitHub Actions，還是自己寫 Bash 或 Python 都不重要。
真正需要設計清楚的是這條鏈路：
觸發 → 執行 → 驗證 → 回饋 → 重試或退出
只要任務有明確目標、可靠回饋、可恢復狀態和停止條件，就已經具備了一個最小 Loop。
七、Loopcraft 最容易踩的幾個坑
第一個坑：把無限重試當作自主性
不斷運行不等於不斷進步。
如果 Agent 缺少新的回饋，重複十次通常只是用十倍 Token 犯相似的錯誤。
第二個坑：讓 Agent 修改自己的考試規則
執行 Agent 不應該隨意修改測試、評價指標、時間預算、權限邊界、Verifier Prompt。
否則它很可能不是把任務做得更好，而是把「通過」變得更容易。
第三個坑：一開始就上多 Agent
多個 Agent 不會自動產生智能，只會先產生更多 Token 消耗、檔案衝突、重複工作、狀態同步問題等。
先把一個 Worker、一個 Verifier、一個持久狀態跑通，再考慮並行。
第四個坑：只衡量 Agent 有多忙
Agent 數量、運行時長、Token 消耗和工具呼叫次數，都不是最終價值。
真正應該關注的是：單位成本下，經驗證的有效進展。
例如自動解決 Issue 的成功率、每個合格 PR 的平均成本、人工接管比例等。
第五個坑：Loop 越順，人越容易放棄理解
這是我覺得最值得警惕的一點。
當 Agent 可以自動寫程式碼、測試、修復並建立 PR，人很容易只看最終的綠色勾選。
但系統產出程式碼的速度越快，人對系統的理解可能下降得越快。
Loopcraft 不應該成為不再思考的藉口，而這需要人對自身有更高的要求。
寫在最後
我最近隱約感覺，Agent 工程正在經歷一次抽象層遷移。
最早我們在討論 Prompt，後來開始討論 Context、Tool、Memory 和 Harness。
現在，大家開始將關注點繼續向外移動，研究如何把一次 Agent 運行放進更大的任務、驗證和改進循環中。
我對「完全把人移出循環」仍然保留懷疑。
但有一點我基本認同：
不要只修復 Agent 當前產生的結果，也要開始修復那個不斷產生結果的系統。