Loop Engineering 很好，但先想清楚一個問題

作者：Feisky

日期：2026年6月10日下午10:08

來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點高亮

Loop Engineering 嘅重點唔係點寫 loop，而係你講唔講得清「做完」嘅標準

整理版摘要

呢篇文章係 Feisky 對 Loop Engineering 呢個新 AI 編程範式嘅觀察同實戰心得。作者本身用過 Claude Code + Ralph loop，後來轉用 Codex /goal，對 loop 嘅演變同優缺點有好深體會。文章先交代 Loop Engineering 點樣由 Peter Steinberger 同 Boris Cherny 帶起熱潮，再追溯返去 ReAct 模式同 Ralph loop 嘅不足，然後聚焦 Codex /goal 嘅設計（狀態持久化+權限控制+強制自審），點解比以往方案穩定。

之後作者對比 Loop Engineering 同傳統定時任務嘅分別：定時任務只係定時觸發，Loop 係確保用正確方法完成目標，能夠自行判斷狀態同迭代。跟住畀出實用建議：目標要清楚、步驟有邊界、每步有檢查、有明確停止點，尤其係獨立驗證呢一步——因為模型自己話做完唔可信，要靠另一個子 agent 驗證。

最後作者點出最樸素嘅問題：你手頭嘅事，能唔能夠寫清楚「做完了」？如果可以，loop 幫你慳功夫；如果連完成標準都講唔清，就乖乖一步步嚟。另外仲提醒 token 燒得好快，要衡量自己係 token 富人定窮人，建議用訂閲制產品。整體結論係：Loop Engineering 係強大工具，但前提係你要有能力定義「完成」。

Loop Engineering 係設計一個自動循環系統，代替人類不斷 prompt agent，直至任務完成。
同定時任務嘅最大分別：Loop 關注係咪用正確方法完成目標，而唔係定時觸發。
Codex /goal 透過狀態持久化、權限控制同強制自審，解決咗 Ralph loop 嘅常見問題（假完成、狀態錯亂）。
成功 Loop 嘅關鍵唔係 prompt 寫得多靚，而係能否清晰定義「做完了」嘅標準。
獨立驗證（用另一個子 agent 評估）係防止 agent 偷懶或謊報嘅最重要機制。

值得記低

連結 addyosmani.com

Addy Osmani: Loop Engineering

Loop Engineering 概念出處

連結 x.com

Lance Martin: Designing loops with Fable 5

獨立驗證測試結果

連結 x.com

Boris Cherny 談自我驗證

Claude Code 負責人嘅建議

連結 mp.weixin.qq.com

Codex /goal 上線後，我把 Ralph loop 卸了

作者之前嘅詳細文章

整理重點

Loop Engineering 突然爆紅

呢兩日 Loop Engineering 呢個詞突然喺 AI 圈炸開。Peter Steinberger 發推話你唔應該再 prompt coding agent，而係要設計 prompt agent 嘅 loop，兩日衝到 800+ 萬閲讀。跟住 Claude Code 負責人 Boris Cherny 都附和，佢管嘅幾百個 agent 自己讀 GitHub 同 Slack、自己決定做咩，過去 30 日合併咗 250 幾個 PR，全部由 Claude Code 完成。

今日 Anthropic 仲發佈咗 Claude Fable 5 同 Mythos 5，話可以將幾個月嘅工作壓縮到幾日。作者話好有感觸，因為佢上個月已經開始用 Codex /goal，覺得呢個就係最好用嘅 Loop Engineering 實現，配合 GPT-5.5，完成度好過之前嘅 Claude Code + Ralph loop 組合。

整理重點

咩係 Loop Engineering？

Loop 簡單講就係一個替你去 prompt agent 嘅小系統：畀 agent 任務、讀結果、判斷做完未，未做完就繼續。以前你用 Claude Code 要自己入 prompt、睇輸出、中斷再入，你本身係個 loop。而家 Loop Engineering 就係將你從個循環入面抽走。

作者話最早可以追溯到 ReAct 模式</highlight>：提示詞之後模型推理、調工具、讀結果、重複直到冇工具調用。呢個 loop 係所有 Agent 嘅基礎。但得呢個唔夠，AI 成日停咗等輸入。之後有 Geoffrey Huntley 嘅 Ralph loop</highlight>：用一行 bash 不斷將同一個 prompt 檔案 send 畀 agent，直到佢話做完。但 Ralph loop 問題多：模型假完成、狀態錯亂、卡死。

後來 Codex 推出 /goal 功能</highlight>，用狀態持久化、權限控制同強制自審解決問題。作者仲提到自己之前寫嘅《Codex /goal 上線後，我把 Ralph loop 卸了》詳細講過。Claude Code 後期都加咗相同功能，但佢認為 Opus 模型比 GPT-5.5 差啲。

整理重點

同定時任務有咩分別？

驟眼睇 Loop Engineering 好似係將 timing task 改個名，底下一樣係不斷叫 AI 做嘢。但作者點出兩個本質分別：

定時任務</highlight>嘅目的係觸發執行，時間固定；到時執行咩取決於畀佢嘅指令，可以係腳本、提示詞甚至 Goal。
Loop Engineering</highlight>嘅目的係確保 AI 用正確方法完成目標，佢會自己睇狀態、決定下一步，循環直到完成。

實際使用可以結合：例如用 timing task 觸發 GitHub issue 排查，排查過程用 Loop 保證質量。

整理重點

點樣先用好 Loop Engineering？

作者建議四句口訣：目標寫清楚、步驟有邊界、每步有檢查、有明確停止點</highlight>，確保 agent 可以閉環迭代。Boris Cherny 都有畀建議：權限開 auto、讓 Claude 自己編排子 agent、用 /goal 模式、跑喺雲端，同埋自我驗證</highlight>。

作者翻過 Codex /goal 源碼，設計思路一致：模型可以話做完，但唔可以話預算就快冇所以要收工。每輪注入自審，強制逐項對照真實文件同測試結果。你可以逼模型繼續做，但你逼唔到佢承認做錯</highlight>，只有獨立驗證先戳穿佢。

整理重點

最後：你夠唔夠膽話「做完了」？

回到開頭個問題：你要唔要幫手頭嘅事上 loop？判斷標準好簡單：你能唔能夠寫清楚「做完了」</highlight>。寫得清，loop 真係幫你慳好多重複勞動。但如果連做完嘅標準都講唔清，不如一步步嚟。

另外仲要提醒：Loop Engineering 好燒 token</highlight>。自修正、驗證子 agent、重試，每一步都食 token。你係 token 富人定窮人，直接影響你對 loop 嘅態度。如果對消耗敏感，建議用訂閲制產品而唔直接 call API。

如果想深入研究，作者推薦咗 Addy Osmani、Lance Martin、Boris Cherny 嘅文章，同埋佢自己之前嗰篇 Codex /goal 拆解。

呢兩日有個新嘅 AI 編程範式 Loop Engineering 好紅。Peter Steinberger 出 tweet 話你唔應該再直接 prompt coding agent，而係要設計 prompt agent 嘅 loop，兩日就衝到 800 幾萬閲讀。之後 Claude Code 嘅負責人 Boris Cherny 都有類似講法，佢管理嘅幾百個 agent 自己識睇 GitHub 同 Slack、自己決定做咩，過去 30 日合併咗 250 幾個 PR，全部由 Claude Code 搞掂。

今日 Anthropic 啱啱發佈咗最新嘅 Claude Fable 5 同 Mythos 5 模型，仲可以將幾個月嘅工作壓縮到幾日內完成。

老實講幾有感觸。上個月 Codex 推出嘅 /goal 功能其實就係最好用嘅 Loop Engineering 實現，配合好多人讚嘅 GPT-5.5，工作完成度一下子同之前成日用嘅 Claude Code + Ralph loop 組合拉開咗距離，我自己大部分工作都轉咗去 Codex 上面。

但用咗一段時間之後，我發現 loop 好唔好用，其實取決於一個好簡單嘅問題。呢個問題後面會再講，先講下 Loop Engineering 究竟係咩。

Loop 講白咗就係一個幫你 prompt agent 嘅小系統：俾 agent 發任務，讀結果，判斷做完未，未做完就繼續執行。以前我哋用 Claude Code，要靠自己輸入 prompt、睇住輸出、中斷之後再輸入，咁樣循環往復，你就係嗰個循環。Loop Engineering 就係將你從循環度抽走，但點樣抽走就係一個問題。

咩係 Loop Engineering

講到 Loop Engineering，我覺得最早可以追溯到 ReAct 模式：你輸入提示詞之後，模型推理、叫工具、讀結果、循環重複直到冇工具再叫就結束。呢個循環後來演變咗做 AI Agent 最基本嘅執行過程，係所有 Agent 必備嘅基礎模塊。

不過得呢個循環明顯仲唔夠，AI 成日都會喺執行完一堆工具調用之後停低等你輸入。所以後來就有咗 Geoffrey Huntley 嘅 Ralph loop 模式：透過一行 bash，將同一個 prompt 文件不停咁發送俾 agent 執行，直到模型話做曬工作先停。

Ralph loop 出咗之後的確解決咗好多長程任務嘅執行問題，但問題都唔少：模型跑嚇跑嚇自己宣佈勝利，任務清單仲剩低大半；狀態文件越寫越離譜，跨 session 之後新 agent 見到嘅進度同實際對唔上；有時成個循環會直接 hang 死。

後來，Codex 推出咗第一個真係可以穩定執行長程任務嘅功能 /goal，透過狀態持久化 + 權限控制 + 強制自審三層機制解決咗呢啲問題。詳細嘅實現原理同使用方法可以參考我之前寫嘅《Codex /goal 上線之後，我將 Ralph loop 剷咗》，呢度就唔展開了。

Claude Code 喺之後嘅版本都有加入相同嘅 Goal 功能，不過要注意 Opus 模型同 GPT-5.5 相比仲有差距，效果差少少（Claude Fable 就會好啲）。

同定時任務有咩分別

表面睇，Loop Engineering 就好似將之前嘅定時任務改咗個名，底層都係叫 AI 大模型不停咁執行任務。

但兩者有幾大分別：

• 定時任務嘅目的係觸發任務嘅執行，執行時間係固定嘅。至於到時執行啲咩取決於你俾佢嘅指令，可以係腳本、提示詞甚至係 Goal 呢啲複雜嘅任務目標；
• Loop Engineering 嘅目的係確保 AI 大模型可以用正確嘅方法完成你嘅任務目標，佢可以自己睇狀態、決定係咪執行下一步，循環往復直到目標完成。

喺實際使用上，你可以將佢哋混合使用。例如，用定時任務去觸發 Github issue 嘅排查，而喺排查每個 issue 時用 Loop 去確保任務執行嘅質素。

點樣先用好 Loop Engineering

咁點樣先用好 Loop Engineering？

我嘅建議係，目標寫清楚、步驟有界限、每步有檢查、有明確嘅停止點，確保 Agent 可以閉環迭代就夠。

Cherny 都俾過幾條建議，可以參考：權限開 auto 模式、等 Claude 自己編排子 agent、用 /goal 模式、跑喺雲端，同埋自我驗證。前四條大家都用緊，但最重要其實係最後一條：驗證。產出冇人 check，方向遲早會走歪。

點解驗證咁重要？大模型俾自己嘅產出打分好唔可靠，但如果換一個獨立上下文嘅子 agent 去評估，效果就穩定好多。Lance Martin 嘅測試入面（連結見最後），Fable 5 最好嘅運行有 73% 嘅結論經過獨立驗證，Opus 4.7 中位數得 17%，差距主要喺呢度。

呢個同我翻 Codex /goal 源碼見到嘅設計思路一致。模型可以宣佈做完，但唔可以話預算就快冇所以要走人。再配上每輪注入嘅自審，強制逐項對照真實文件同測試結果。簡單嚟講，你可以逼模型繼續做嘢，但你逼唔到佢承認自己做得差，可以揭穿佢嘅只有獨立驗證。

寫喺最後

返到開頭講嗰個簡單問題：你要唔要幫手頭上嘅嘢加 loop？判斷標準同我喺 /goal 嗰篇講嘅一樣：你可唔可以將「做曬」寫清楚。寫得清楚，loop 真係可以幫你慳返大量重複勞動。但如果連做完嘅標準都講唔清，咁就乖乖地一步步做啦。

另外仲要提醒一點，Loop Engineering 避唔開一個現實問題：燒 token。跑起上嚟燒錢比你諗嘅快，自修正、驗證子 agent、重試，每一步都係消耗 token。講白咗，你係 token 富人定 token 窮人，直接決定你對 loop 嘅態度。如果你對 token 消耗比較敏感，建議優先使用訂閲制嘅產品而唔係直接 Call API，可以慳返唔少錢。

如果你想了解多啲 Loop Engineering，推薦睇：

• Addy Osmani: Loop Engineering：https://addyosmani.com/blog/loop-engineering/
• Lance Martin: Designing loops with Fable 5：https://x.com/RLanceMartin/status/2064397389189071163
• Boris Cherny 談自我驗證：https://x.com/bcherny/status/2064426115255730578
• Codex /goal 上線之後，我將 Ralph loop 剷咗：https://mp.weixin.qq.com/s/qwjxsGpMacLNy93g6dz4Aw

如果你都喺探索 AI 編程工具，歡迎關注 Feisky，我會持續分享實踐入面嘅發現同踩過嘅坑。

這兩天一個新的 AI 編程範式 Loop Engineering 火了。Peter Steinberger 發推說你不應該再 prompt coding agent，應該去設計 prompt agent 的 loop，兩天衝到 800+ 萬閲讀。隨後 Claude Code 負責人 Boris Cherny 也表達了類似的觀點，他管理的幾百個 agent 自己讀 GitHub 和 Slack、自己決定幹什麼，過去 30 天合併了 250 多個 PR，全部由 Claude Code 完成。

今天 Anthropic 剛剛發佈了最新的 Claude Fable 5 和 Mythos 5 模型，甚至能夠把數月的工作壓縮至幾天內完成。

說實話挺有感觸的。上個月 Codex 推出的 /goal 功能其實就是最好用的 Loop Engineering 實現，配合廣受好評的 GPT-5.5，工作完成度一下子就把之前經常使用的 Claude Code + Ralph loop 組合拉開了，我自己的大部分工作也都切換到了 Codex 上面來。

但用了一段時間之後，我發現 loop 好不好用，其實取決於一個很樸素的問題。這個問題後面會展開，先說說 Loop Engineering 到底是什麼。

Loop 說白了就是一個替你 prompt agent 的小系統：給 agent 發任務，讀結果，判斷做完沒有，沒做完就繼續執行。以前我們用 Claude Code，要靠你自己輸入 prompt、盯着輸出、中斷後再輸入，如此循環往復，你就是那個循環。Loop Engineering 則是把你從循環裏摘出來，但如何摘出來是個問題。

什麼是 Loop Engineering

說到 Loop Engineering，我覺得最早可以追溯到 ReAct 模式：你輸入提示詞後，模型推理、調工具、讀結果、循環重複直到沒有工具調用時結束。這個循環後面演變成了 AI Agent 最基本的執行過程，是所有 Agent 都必備的基礎模塊。

不過只有這個循環明顯還不夠，AI 經常會在執行完一些工具調用後停下來等待你的輸入。所以後來就有了 Geoffrey Huntley 的 Ralph loop 模式：通過一行 bash，把同一個 prompt 文件反覆發送給 agent 執行，直到模型說工作完成了才停止。

Ralph loop 推出後的確解決了很多長程任務的執行問題，但問題也不少：模型跑着跑着自己宣佈勝利，任務清單還剩大半；狀態文件越寫越離譜，跨會話之後新 agent 看到的進度跟實際對不上；偶爾整個循環還會直接卡死。

後來，Codex 推出了第一個真正可以穩定執行長程任務的功能 /goal，通過狀態持久化+權限控制+強制自審三層機制解決了這些問題。詳細的實現原理和使用方法可以參考我之前寫的《Codex /goal 上線後，我把 Ralph loop 卸了》，這兒就不展開了。

Claude Code 在隨後的版本里也增加了相同的 Goal 功能，不過需要注意 Opus 模型相對 GPT-5.5 還是有差距，效果稍微差一些（Claude Fable 則會好一些）。

跟定時任務有什麼區別

乍看起來，Loop Engineering 就像是把之前的定時任務改了個名字，底下都是讓 AI 大模型不停地執行任務。

但這兩者有很大的區別：

• 定時任務的目的是觸發任務的執行，執行的時間是固定的。至於到了時間執行啥取決於你給它的指令，可以是腳本、提示詞甚至是 Goal 這種複雜的任務目標；
• Loop Engineering 的目的是確保 AI 大模型能夠以正確的方法完成你的任務目標，它能夠自己查看狀態、決定是否執行下一步，循環往復直到目標完成。

在實際使用中，你可以把它們結合在一起來使用。比如，使用定時任務來觸發 Github issue 的排查，而在排查每個 issue 時使用 Loop 來確保任務執行的質量。

怎麼用好 Loop Engineering

那怎麼用好 Loop Engineering？

我的建議是，目標寫清楚、步驟有邊界、每步有檢查、有明確的停止點，確保 Agent 能夠閉環迭代就可以了。

Cherny 也給過幾條建議，可以參考：權限開 auto 模式、讓 Claude 自己編排子 agent、用 /goal 模式、跑在雲端，以及自我驗證。前四條大家都在用，但最重要的其實是最後一條：驗證。產出沒人查，方向遲早跑偏。

為什麼驗證這麼重要？大模型給自己的產出打分很不可靠，但如果換一個獨立上下文的子 agent 來評估，效果就穩定得多。Lance Martin 的測試裏（連結見最後），Fable 5 最好的運行有 73% 的結論經過了獨立驗證，Opus 4.7 中位數只有 17%，差距主要就在這兒。

這跟我翻 Codex /goal 源碼看到的設計思路是一致的。模型能宣佈做完，但不能說預算快沒了先撤。再配上每輪注入的自審，強制逐項對照真實文件和測試結果。簡單來說，你可以逼模型繼續幹活，但你逼不了它承認自己沒幹好，能戳穿它的只有獨立的驗證。

寫在最後

回到開頭說的那個樸素問題：你要不要給手頭的事上 loop？判斷標準跟我在 /goal 那篇裏說的一樣：你能不能把“做完了”寫清楚。能寫清楚，loop 確實能幫你省掉大量重複勞動。但如果連做完的標準都說不清，那還是老老實實一步步來吧。

另外還要提醒一點，Loop Engineering 繞不開一個現實問題：燒 token。跑起來燒錢比你想的快，自修正、驗證子 agent、重試，每一步都在消耗 token。說白了，你是 token 富人還是 token 窮人，直接決定了你對 loop 的態度。如果你對 token 消耗比較敏感，建議優先使用訂閲制的產品而不是直接調 API，能省不少錢。

如果你想了解更多的 Loop Engineering，推薦閲讀：

• Addy Osmani: Loop Engineering：https://addyosmani.com/blog/loop-engineering/
• Lance Martin: Designing loops with Fable 5：https://x.com/RLanceMartin/status/2064397389189071163
• Boris Cherny 談自我驗證：https://x.com/bcherny/status/2064426115255730578
• Codex /goal 上線後，我把 Ralph loop 卸了：https://mp.weixin.qq.com/s/qwjxsGpMacLNy93g6dz4Aw

如果你也在探索 AI 編程工具，歡迎關注 Feisky，我會持續分享實踐中的發現和踩坑。