事實
術語 · LLM 工程 · 來源查證 · AI 人工智慧 · 名詞解析Tratopedia · 2026 年 8 月 16 日
五篇之四 · 始終沒有定下來的那一個
大家都說你該去寫迴圈，卻沒有人同意迴圈是什麼
2026 年 6 月的第一週，兩位知名工程師相隔四天說了同一件事：別再對程式代理下提示了，去寫迴圈。兩個人都沒有說迴圈是什麼。接下來的三週裡，有六個人回答了這個問題 —— 而他們回答的是五種不同的東西：一個人的工作習慣、一個遞迴目標、一支小程式、兩層彼此嵌套的機器、一套依觸發方式分類的體系，以及一個長達數週、把使用者也算進去的產品循環。Anthropic 自己的說明文章開頭就承認了：如果你花點時間在 X 上想弄清楚迴圈到底是什麼，你會看到好幾種不同的答案。本系列前面三個詞，各自都動到了某個地方。這一個從來沒有抵達。
四個星期，始終沒有收斂 兩句指示、一次坦承，以及一個能解開大半困惑的說法。
- 6在這個說法傳開後的 29 天內，關於「迴圈是什麼」而發表的答案數
- 5那六個答案談的其實是五種不同類別的東西 —— 習慣、目標、程式、兩台機器、一個組織
- 4迴圈本身存在的年數。ReAct 是 2022 年的東西；新的是「由誰下提示」
- 0找不到任何在固定代理的條件下、把迴圈與人工提示相比的量測
Boris Cherny · 2026 年 6 月 2 日
「我的工作就是寫迴圈」
- 完整說法是：我已經不對 Claude 下提示了。我有一些迴圈在跑，是它們在對 Claude 下提示、決定要做什麼。說話的是 Claude Code 的創造者，在 WorkOS 的活動台上。
- 他攤開來講的是職涯的三個階段：先是用自動補全手寫程式，然後是同時開五到十個 Claude 工作階段、逐一手動下提示，再來就是改成寫迴圈。
- 本專案沒有聽過這場談話。這段文字是透過一篇整理文章傳過來的，另外兩份資料也照抄 —— 這佐證的是字句，不是字句周圍的脈絡。
Peter Steinberger · 2026 年 6 月 7 日
「你該做的是設計會對代理下提示的迴圈」
- 開頭是「這是給你的每月提醒」 —— 所以這不是他第一次講，只是這次傳開了。查閱的資料沒有一份能給出更早那幾次的日期。
- 四天前他才在 Microsoft Build 上講過同一個想法：做出那個會做出東西的東西。而 Cherny 的發言又在那之前一天。
- 這是一句指示，不是一個定義。它說了不要再做什麼、改做什麼，卻始終沒說那個東西是什麼。
Claude Code 團隊 · 2026 年 6 月 30 日
「你會看到好幾種不同的答案」
- 完整說法是：如果你花點時間在 X 上想弄清楚迴圈到底是什麼，你會看到好幾種不同的答案。說這話的是 Anthropic —— 而這個說法之所以存在，有一半是因為他們自家的產品負責人。
- 他們自己的定義是：代理不斷重複執行工作循環，直到滿足停止條件為止，並依「如何被觸發」與「如何停止」分成四類。
- 他們把這種分歧當成 X 上待澄清的雜訊。本頁則把它視為這個詞本身的性質 —— 因為那些答案並不是在描述同一件東西。
Armin Ronacher · 2026 年 6 月 23 日
其實有兩個迴圈
- 每一個程式代理裡面，本來就已經有一個代理迴圈 —— 模型呼叫工具、讀取結果、修改檔案、跑測試。另一個迴圈是機具層級的迴圈：在代理迴圈之外的那一圈。
- 而且他直說：那個迴圈也不是新東西。他把外層迴圈追溯到「Claude Code 早期」。
- 他對「迴圈到底在做什麼」的描述是本文找到最好的一句：這項任務會一直活著，超過模型原本會說「我做完了」的那個時間點。
以上每一項有多確定？ 這是本系列裡來源最薄的一篇，這張表說明薄在哪裡。
| 確信程度 | 內容 | 依據 |
|---|---|---|
| 已讀原始出處 | 「好幾種不同的答案」；四種迴圈類型；不是每項任務都需要複雜的迴圈 | Claude Code 團隊，claude.com，2026 年 6 月 30 日 |
| 已讀原始出處 | 內外兩層迴圈的區分，以及「那個迴圈也不是新東西」 | Armin Ronacher，lucumr.pocoo.org，2026 年 6 月 23 日 |
| 已讀原始出處 | Osmani 的定義 —— 以及他在同一段裡表達的懷疑 | addyosmani.com，2026 年 6 月 7 日，就在它所回應的那則貼文數小時後 |
| 由他人提供，非自行擷取 | 內層迴圈的第一手拆解，比這個說法早五個月 | OpenAI 的 Michael Bolin，2026 年 1 月 23 日。PDF 由 djTratoh 提供；openai.com 回傳 403 |
| 轉述而來 | Cherny 的原話。本文沒有聽過那場談話；引文透過一篇整理文章傳來，另有兩份資料照抄 | Ezekiel Njuguna 於 Medium，2026 年 6 月 8 日。PDF 由 djTratoh 提供；medium.com 回傳 403 |
| 轉述而來 | Ng 的三個迴圈，包括「脈絡優勢」這個說法 | 產業媒體引用他在 X 上的貼文。那些貼文本身沒有讀到 |
| 未能讀取 | Steinberger 那場 Build 演講的實際內容。只擷取到議程頁 —— 而頁面正文是機器產生的摘要 | 該頁面同時提供影片與逐字稿，兩者都沒有取得 |
| 本頁的判讀 | 那六個答案描述的是五種不同類別的東西，而這是這個詞本身的性質，不是一時的混亂 | 由以上所有資料拼出。沒有任何一份資料這樣說；最接近的一份只承認答案不一致 |
時序
迴圈存在四年，爭論只有四週 機制是舊的。這裡有爭議的一切，全發生在 2026 年 6 月。
- 2022 年 10 月內層迴圈，先以論文形式出現。ReAct 讓模型在推理與行動之間交替：推理、行動、觀察、再重複。此後每一個程式代理跑的都是這個循環；本系列上一篇也查到維基百科與 Databricks 都把這個模式追溯到這裡。
- 2025 年底「把迴圈閉合起來」開始流行。Andrew Ng 把時間點放在這裡：給代理一份規格與一組評測，讓它反覆修改直到程式通過。這件事徹底改變了局面，讓程式代理能在無人介入的情況下，有效工作更長的時間。
- 2026 年 1 月 23 日內層迴圈，由真正在做這東西的人拆開來講。OpenAI 的 Michael Bolin 發表〈Unrolling the Codex agent loop〉—— 也就是協調使用者、模型與工具的核心邏輯。比任何人把這一切叫做「迴圈工程」早了五個月，而且它把迴圈放在機具裡面。
- 2026 年 6 月 2 日第一次發言。創造 Claude Code 的 Boris Cherny 在 WorkOS 的活動上說，他已經完全不對 Claude 下提示了：我有一些迴圈在跑，是它們在對 Claude 下提示……我的工作就是寫迴圈。他描述的是自己的工作日常，並沒有為這個詞下定義。
- 2026 年 6 月 3 日隔天，在更大的舞台上。Peter Steinberger 在 Microsoft Build 做了一場名為〈做出那個會做出東西的東西〉的分場演講，主張現在的問題不再是自己怎麼變快，而是怎麼幫你的代理更有效率地把回饋迴圈閉合起來。他同樣沒有用「迴圈工程」這個說法。
- 2026 年 6 月 7 日傳開的那則貼文。Steinberger 在 X 上寫道：這是給你的每月提醒：別再對程式代理下提示了。你該做的是設計會對代理下提示的迴圈。八百五十萬次瀏覽。「每月提醒」—— 所以這不是第一次，只是這次傳開了。
- 2026 年 6 月 7 日幾小時後，名字出現了。Addy Osmani 把它寫成文章：迴圈工程，就是把「對代理下提示的那個人」從你自己換掉。同一段裡他還補上現在還很早，我是抱持懷疑的，並提醒要注意 token 成本。和上一篇文章裡的命名一樣，這個詞也是由一個心存保留的人取的。
- 2026 年 6 月 8 日有人把它的意思寫了下來。一篇整理 Cherny 發言的 Medium 文章，給出本文收集到最白話的說法：一支你自己寫的小程式，代替你對程式代理下提示、讀取代理產出的東西、判斷任務完成了沒有，如果沒有就再下一次提示。模型變成了被你的程式呼叫的一個副程式。
- 2026 年 6 月 23 日沒有別人畫出來的那條界線。Armin Ronacher 指出這裡有兩個迴圈，不是一個 —— 每個程式代理裡面那個代理迴圈，以及在它外面的機具迴圈 —— 而且兩個都不是新東西。這個月大半的混亂，就是不同的人在指不同的那一個。
- 2026 年 6 月 30 日廠商試著把事情定下來，但先坦承了問題。Claude Code 團隊把迴圈定義為代理不斷重複執行工作循環，直到滿足停止條件為止，並分成四類 —— 依回合、依目標、依時間、主動式 —— 而在此之前，他們先承認了 X 上有好幾種不同的答案。他們還說：不是每項任務都需要複雜的迴圈。
- 2026 年 7 月 1 日還有一個根本不在談機器的說法。產業媒體轉述 Andrew Ng 的三個迴圈：代理式編碼、開發者回饋、外部回饋 —— 最後一個要跑上數天或數週，裡面包含朋友、早期測試者與 A/B 測試。他對「人扮演什麼角色」的說法是這個月最銳利的一句：那不是「品味」，而是脈絡上的優勢。
論點
六個答案，五個不同的問題 它們並不是在描述同一件東西。
把這六種說法並排放好，麻煩並不在於它們互相牴觸，而在於它們回答的是不同的問題。
Cherny 的迴圈是關於一個人的事實：他自己工作生涯的三個階段，最後停在「他改成寫迴圈而不是寫提示」。Osmani 的是一個目標 ——「一個遞迴的目標，你定義出目的，AI 就一直迭代到完成為止」。那篇 Medium 整理文章講的是一支程式，也是其中最具體的：一支你寫的東西，會下提示、讀結果、做判斷、再下提示，直到模型變成你的程式碼呼叫的副程式。Ronacher 的是兩台機器，一台套在另一台裡面。Anthropic 的是一套分類體系，按迴圈怎麼開始、怎麼停止來歸類。而 Ng 的是一個組織：三個迴圈，最外面那個要跑上數週，裡面還有客戶。
把兩個極端擺在一起看。Anthropic 的「依回合迴圈」是一次提示、一次回覆 —— 你送出的每一則提示，都啟動了一個由你逐回合指揮的手動迴圈。Ng 的第三個迴圈，則是一場歷時兩週、會重塑產品方向的 A/B 測試。在 2026 年 6 月，兩者都叫「迴圈」。再怎麼細心閱讀，也沒辦法把它們調和成同一個東西，而本頁不會去寫那句假裝可以的句子。那句話很好寫 ——迴圈是一支會反覆對代理下提示、直到滿足停止條件的程式—— 但它會是本頁的發明，而不是任何人發表過的立場。
真正能解開困惑的那個說法，反而是最少人重複的。Ronacher 指出：一個程式代理裡面本來就有一個迴圈 —— 模型呼叫工具、讀結果、改檔案、跑測試。那個內層迴圈已經四歲了，而 OpenAI 一月就把它拆解過。六月大家開始談的，是那一圈外面的迴圈 —— 在代理停下來的時候接住它、並判定工作還沒完的那個東西。這個月大半的爭論，其實是不同的人在指不同的迴圈，卻以為在指同一個。
這也指向了這個詞真正的內容。這裡沒有任何技術是新的，而且每一份資料都這麼說：Ronacher 說「那個迴圈也不是新東西」；Ng 把閉合迴圈追溯到 2025 年底；Bolin 一月就發表了拆解；ReAct 更是 2022 年的事。改變的是「由誰下提示」。那是一份工作的改變，不是一項技術的改變 —— 而這正是定義會四散的原因：每個人描述的是自己看得見的那一塊工作，而一位 Claude Code 負責人、一位框架作者與一位課程創辦人，看見的並不是同一塊。
還有一件事值得注意，因為這已經是本系列第二次了。Osmani 替迴圈工程命名，同一段裡就說自己對它抱持懷疑。Mitchell Hashimoto 造出「機具工程」時說，如果已經有別人的說法，他寧可跟著用。本系列最後這兩個詞，都不是由信徒推出來的 —— 但三個星期之後，圍繞它們的討論讀起來完全不是這樣。
補充
迴圈實際上在做什麼 在機制上，各方倒是一致 —— 和定義不同。
- 1把工作放進佇列不是你敲進去的提示，而是一份由別的東西來取件的清單。Cherny 的版本會去讀他的 GitHub、Slack 與 Twitter，決定什麼該進清單；Steinberger 的則是讀一個已經長到超過一萬筆的議題追蹤系統。
- 2讓代理去做，然後停下來這就是內層迴圈，它不需要幫忙：模型呼叫工具、讀結果、改檔案、跑測試，最後說它做完了。所有有意思的事，都發生在那句話之後。
- 3對「我做完了」表示異議由機具來判定那是不是真的結束。Ronacher 列出的下一步選項就是全部的訣竅：延續同一個工作階段、注入另一則訊息、用改過的脈絡開一個全新的工作階段，或是把任務丟給另一台機器。任務會一直活著，越過模型原本會終止它的那個點。
- 4讓檢查變成可量化的這是整件事的承重點，而每一份資料都這麼說。Anthropic 的原則是：檢查愈能量化，Claude 就愈容易自我驗證。他們給的實例明確拒絕「編輯成功就算改完」：要啟動伺服器、實際點下去、前後各截一張圖，並要求主控台不能有任何新的錯誤。
- 5然後，用能work的最小迴圈這句話出自最有理由勸你反著做的那家廠商：不是每項任務都需要複雜的迴圈；先從最簡單的做法開始，這些模式要有選擇地用。Osmani 的提醒則是同一件事的金錢版本 —— token 成本落差極大，而一個沒人看著的迴圈，不管有沒有在前進，都照樣在花錢。
唯一有人公開的數字 只有兩個，而且都沒有量到這個領域宣稱的那件事。
| 說法 | 它算的是什麼 | 它沒有證明的是什麼 |
|---|---|---|
| Close Reaper | Steinberger 的議題分類迴圈自動關閉了約 15,000 個 GitHub 議題，而積壓量報導為「超過 10,000」 | 算的是「做了多少動作」，不是「做對多少」。沒有任何依據能說明那些議題就該被關掉。而且這兩個數字只有在「它跑的時候積壓還在增加」的前提下才對得起來，來源並沒有這樣說 |
| 「幾百個代理」 | Cherny 對自己那套配置的描述 —— 由代理去讀 GitHub、Slack 與 Twitter，決定接下來要做什麼 | 這是規模，不是成果。它說明了跑了多少東西，卻沒說產出的東西是否勝過一個人工提示的工作階段 |
| 再無其他 | 找不到任何「固定代理、只改迴圈」的比較。 | 本系列上一篇有這樣的比較 —— 同一個模型、不同機具、公開排行榜。這個題目找不到對應的東西，在你照著它重建工作流程之前，這件事值得先知道 |
有必要把「證據有多薄」講精確，因為這股熱情一點都不薄。
本系列上一篇是以一個真實的量測收尾的：同一個模型 Opus 4.6，在不同機具裡於一個不屬於任何一方的公開排行榜上分數相差甚遠。那才是一個關於工程的主張該有的形狀 —— 把你沒有在測的東西固定住。迴圈這個題目上，找不到任何這種形狀的東西。有的是一個「關掉了幾個議題」的計數、一段對個人配置的描述，以及大量自信的建議。
這不代表那些建議是錯的。機制顯然是真的，提出建議的人做的東西規模大到不值得造假，而論證表面上也站得住：一個「自認為做完了就會停」的代理必然會太早停下來，總得有東西去反對它。但是，「表面上站得住」正是這個題目目前所在的位置，而且廠商與命名者本人都用自己的話這樣說過 —— 先從最簡單的開始、注意 token 成本、現在還很早。
還有一個不對稱值得點名。一個出錯的迴圈，失敗的方式和一個爛提示不一樣。爛提示浪費你一分鐘，而且你看得見結果。一個沒人看著、對著一萬筆積壓議題跑的迴圈，會趁你睡覺的時候做一萬五千件事，而它回報的數字是「它做了幾件」—— 不是「它該做幾件」。每一份談驗證的資料，談的其實都是這個落差。
結論
可以帶走的幾件事 四件事，依重要性排列。
先問是哪一個迴圈，你就懂了一大半
一個程式代理裡面本來就有一個迴圈 —— 推理、行動、觀察 —— 而且已經四歲了。2026 年 6 月談的是那一圈外面的迴圈：在代理說「我做完了」的時候接住它、並判定還沒完的那個東西。只有 Ronacher 一個人畫出了這條界線，而這個題目上幾乎每一場糊塗的對話，都是兩個人各自在指不同的迴圈。
這個詞命名的是一份工作的改變，不是一項技術
每一份資料都同意，這裡沒有任何技術是新的 —— ReAct 是 2022 年，OpenAI 一月就拆解過內層迴圈，Ronacher 也說外層那個同樣不新。改變的是：人不再是那個寫提示的人。定義之所以四散，原因就在這裡 —— 每個人描述的是自己看得見的那一塊工作，而一位產品負責人、一位框架作者與一位課程創辦人，看見的並不是同一塊。
沒有人量測過它
沒有任何「固定代理、只改迴圈」的比較 —— 上一篇文章賴以成立的那種「同模型、不同機具」的結果，這裡沒有對應物。流傳的兩個數字，一個算的是做了幾個動作，一個算的是跑了幾個代理，兩者都不是成果。這些建議很可能是對的；但它目前未經檢驗，而廠商與命名者本人都說要從小處開始。
已經兩次了：命名的人，正是那個保留的人
Osmani 在同一段裡寫下了「迴圈工程」與「我抱持懷疑」。Mitchell Hashimoto 造出「機具工程」時說，如果已經有別人的說法，他寧可用別人的。三個星期後，這兩層保留在人們轉述這些詞的時候都不見了 —— 這是一個關於「詞彙如何傳播」的事實，值得帶著它去看第五個詞會是什麼樣子。