Tratopedia
側 NBM
設定

文字大小

語言

EN繁中BMES

佈景

高對比

中文排版

豎排會把內文排成由右至左的直行，如同台灣的實體書籍。

版本

v1.184.0

本頁建置時的版本編號，也是 service worker 快取所依據的版本。

事實

術語 · LLM 工程 · AI 代理 · 效能評測 · AI 人工智慧 · 說明這個名詞與這門功夫，2022 年 10 月至 2026 年 8 月

五篇之四 · 始終沒有定下來的那一個

大家都說你該去寫迴圈，卻沒有人同意迴圈是什麼

2026 年春天到初夏，幾位與程式代理打交道最知名的工程師說了同一件事：別再對代理下提示，改寫會替你下提示的迴圈。打造 Claude Code 的 Boris Cherny 在 4 月 15 日於舊金山的台上這麼說；Peter Steinberger 6 月 7 日的貼文讓這句話傳開，Addy Osmani 同一天替它取名為迴圈工程。接著出現了六種「迴圈是什麼」的說法，描述的迴圈大小天差地遠——小到一次提示，大到把顧客也包進去、一跑就是好幾週的產品週期。Anthropic 自己的說明文一開頭就承認，在 X 上會得到「好幾種不同的答案」。沒有人爭議的是機制：代理外面有個東西，不肯把「我做完了」當成答案。到了 8 月，第一個固定代理、只改變由誰來指揮的基準測試發現，最好的指揮只完成了 24.69% 的完整任務，完全沒人指揮時是 18.52%。

  • 53天：從 Cherny 2026 年 4 月 15 日在台上的發言，到讓這個想法傳開的 6 月 7 日貼文
  • 6種「迴圈是什麼」的說法，從 4 月的 Cherny 到 6 月 30 日的 Ng 與 Anthropic——大小從一次提示到好幾週
  • 24.69%的完整程式任務，由第一個固定代理的基準測試中最好的迴圈控制者完成；沒有控制者時是 18.52%
  • 9.4×倍：那個控制者每次執行的估計成本，相對於讓代理自己做

兩句話、一次坦承、一個區分 四者沒有一個是定義，這正是重點。

  • Boris Cherny · 2026 年 4 月 15 日

    「我的工作就是寫迴圈」

    這是在描述他自己的做法，不是一個定義。

    • 這是他在 WorkOS 於舊金山舉辦的晚間活動上所說，6 月 2 日才以影片公開。最完整的引文是：「我已經不對 Claude 下提示了。我有一些迴圈在跑，是它們在對 Claude 下提示、決定要做什麼。」
    • 他的話見諸文字時有兩種略有出入的版本；《Business Insider》還報導了他對 CNBC 說的第三句：「Claude 來寫提示，現在我是在跟那個負責協調的新 Claude 對話。」
    • 活動主辦方把他的做法概括為：數百個 Claude 實例在讀 Twitter、GitHub 議題與 Slack，找產品點子——並補了一句：這些點子目前大多不好。

  • Peter Steinberger · 2026 年 6 月 7 日

    「你應該去設計替代理下提示的迴圈」

    讓這個說法傳開的貼文：到 9 月已超過 850 萬次瀏覽。

    • 開頭是「這是你的每月提醒」——照他自己的說法，這不是第一次，只是這次傳開了。
    • 四天後，他貼出自己的迴圈：叫 Codex 維護你的程式庫，「每 5 分鐘醒來一次，把工作分派到各個執行緒」。
    • 《Business Insider》稱他為 OpenAI 的工程師。這則貼文是指示，不是定義：它說了該停止什麼，卻從沒說迴圈是什麼。

  • Claude Code 團隊 · 2026 年 6 月 30 日

    「你會碰到好幾種不同的答案」

    廠商先承認問題，再給出自己的答案。

    • Delba de Oliveira 與 Michael Segner 為 Anthropic 撰文：「如果你花點時間在 X 上想弄清楚迴圈到底是什麼，你會碰到好幾種不同的答案。」
    • 他們的定義是：代理反覆執行工作循環，直到滿足停止條件；分成四種——依回合、依目標、依時間與主動式——依「什麼啟動迴圈、什麼讓它停下」來分類。
    • 還有一句跟他們自己的熱情唱反調的建議：「不是每項任務都需要複雜的迴圈；從最簡單的解法開始。」

  • Armin Ronacher · 2026 年 6 月 23 日

    迴圈有兩個

    能解開大半困惑的那個區分。

    • 「每一個程式代理裡面本來就有一個代理迴圈。」另一個是「駕馭層的迴圈：代理迴圈外面的那個迴圈」——而且「那個迴圈也不是新東西」。
    • 外層迴圈做的事：在代理停下時接住它，判斷那是不是真的結束。任務一直活著，超過模型自己原本會說「我做完了」的那一刻。
    • 他自己的看法並不安心：對於「我真正在乎的程式碼」，他「用這種方式一直沒有太大的成功」。

以上每一項有多確定？ 先評等，再敘述——確信程度放在第一欄。

確信程度內容依據
有原始出處日期：Cherny 2026 年 4 月 15 日在舊金山登台；影片 6 月 2 日公開；Steinberger 的貼文在 6 月 7 日 18:58（UTC）活動本身的公告頁與 Cherny 當晚的貼文；WorkOS 的影片頁；貼文本身
有原始出處Osmani 的命名、他的定義，以及同一段裡的「我持懷疑態度」Addy Osmani，addyosmani.com，2026 年 6 月 7 日
有原始出處內外兩層迴圈，以及「那個迴圈也不是新東西」Armin Ronacher，lucumr.pocoo.org，2026 年 6 月 23 日
有原始出處四種迴圈；「好幾種不同的答案」；「從最簡單的解法開始」Delba de Oliveira 與 Michael Segner，Claude 部落格，2026 年 6 月 30 日
有原始出處Ng 的三個迴圈、各自的時間尺度，以及「情境優勢」Andrew Ng 本人的信，2026 年 6 月 30 日
有原始出處內層迴圈，由實際出貨的團隊描述，比這個說法早了四個半月Michael Bolin，OpenAI，2026 年 1 月 23 日
有量測，尚未經同儕審查最好的迴圈控制者完成 24.69% 的完整任務；代理自己做是 18.52%LoopArena，arXiv 預印本，2026 年 8 月 28 日
轉述Cherny 的原話。錄影確實存在；這裡的引文來自三篇文章，有兩種措辭Ezekiel Njuguna 於 Medium，2026 年 6 月 8 日；Osmani；Ronacher
轉述Cherny 那句「Claude 來寫提示」《Business Insider》對一次 CNBC 訪談的報導，2026 年 6 月 20 日
機器摘要Steinberger 2026 年 6 月 2 日在 Microsoft Build 台上說了什麼該場次頁面上的摘要，頁面自己標明是機器生成
本頁的解讀六種說法描述的是大小不同的迴圈，而不是在爭奪同一件東西的定義由這六種說法拼湊而來；沒有任何來源這樣說——最接近的只承認答案不同

時序

舊的機制，新的名字 所有標有日期的項目，由舊到新。只有最後一項是量測。

  1. 2022 年 10 月 6 日內層迴圈，先以論文形式出現。ReAct 讓語言模型把推理與行動交錯進行，解一個任務就成了一連串「思考—行動—觀察」的步驟。此後每一個程式代理跑的，都是這個循環的某個版本。
  2. 2025 年 7 月 14 日一行 shell 寫成的外層迴圈。Geoffrey Huntley 發表「Ralph」：while :; do cat PROMPT.md | claude-code ; done——同一份提示一遍又一遍餵給代理，每一輪只做一件事。
  3. 2025 年底「把迴圈閉合」開始流行——這是 Andrew Ng 事後的定年：給代理一份規格與測試，讓它反覆迭代。他說這「徹底改變了局面，讓程式代理能在沒有人介入的情況下，更長時間地有效工作」。
  4. 2026 年 1 月 23 日內層迴圈，從產品內部來看。OpenAI 的 Michael Bolin 描述 Codex 的代理迴圈：「負責協調使用者、模型與工具之間互動的核心邏輯」。當模型不再呼叫工具、直接回答時，一個回合就結束。
  5. 2026 年 4 月 14 日大部分程式碼都在迴圈周圍。一篇分析 Claude Code 公開原始碼的研究發現，它的核心是「一個呼叫模型、執行工具、再重複的簡單 while 迴圈」，而大部分程式碼都在它周圍的系統裡：權限、情境管理、擴充機制、子代理。
  6. 2026 年 4 月 15 日第一次說出口。在 WorkOS 於舊金山舉辦的晚間活動上，Cherny 對《Acquired》播客的兩位主持人說，他已經不對 Claude 下提示了：他寫迴圈，由迴圈來下。當晚他就發文向主持人道謝。
  7. 2026 年 6 月 2 日錄影公開，WorkOS 同時發表活動重點整理。同一天，Steinberger 在 Microsoft Build 主講一場〈打造那個打造東西的東西〉，談他為了更快開發 OpenClaw 而做的工具。
  8. 2026 年 6 月 7 日傳開的貼文，以及名字。Steinberger：「這是你的每月提醒：你不該再對程式代理下提示了。你應該去設計替代理下提示的迴圈。」同一天，Osmani 發表一篇題為〈Loop Engineering〉的文章——並在第一段寫下「我持懷疑態度」。
  9. 2026 年 6 月 8 日一個白話的說法。一篇在 Medium 上整理 Cherny 發言的文章，給出了收集到的最具體定義：一支程式，替你對代理下提示、讀它的產出、判斷任務是否完成，沒完成就再下提示。文中把發言日期寫成 6 月 2 日，也就是影片公開的那天。
  10. 2026 年 6 月 11 日一個迴圈，作者自己怎麼用。Steinberger：叫 Codex 維護你的程式庫，「每 5 分鐘醒來一次，把工作分派到各個執行緒」，再配上他自己的分類與審查技能，讓「有些工作能自動落地」。
  11. 2026 年 6 月 20 日主流媒體跟上。《Business Insider》：「『迴圈工程』現在正夯」——而且「提到迴圈時最大的顧慮，遠遠領先的是成本。」
  12. 2026 年 6 月 23 日兩層迴圈的區分。Armin Ronacher 把每個代理內部的迴圈，和它外面駕馭層的迴圈分開，並說出他看過外層迴圈管用的地方：移植程式碼、效能實驗、資安掃描、研究。
  13. 2026 年 6 月 30 日一天之內兩個定義。Claude Code 團隊的四種迴圈；以及 Andrew Ng 打造產品的三個迴圈——每幾分鐘跑一次的代理寫程式迴圈、以數十分鐘到數小時計的開發者回饋迴圈，以及由使用者與測試構成、以數小時到數週計的外部回饋迴圈。
  14. 2026 年 7 月 1 日業界媒體有所保留。《ADTmag》：這個詞「最後可能證明更像是開發者的簡稱，而不是一門正式的學科」。
  15. 2026 年 8 月 28 日第一次量測。預印本 LoopArena 固定同一個程式代理，比較由不同模型來指揮它的結果。在完整任務上，最好的完成 24.69%；讓代理自己做是 18.52%；每一輪只重申目標，也是 18.52%。

論點

六個答案，六種尺寸 它們並不是在描述同一件東西。

把六種說法排在一起，麻煩不在於它們意見不合，而在於它們描述的是大小不同的迴圈。

Cherny 的迴圈是關於一個人的工作日：他不再下提示，改寫那些替他下提示的東西。Osmani 的是一套定時運轉的系統——「一個遞迴的目標：你定下目的，AI 反覆迭代直到完成」，由自動排程、工作樹、技能、連接器與子代理組成，再用磁碟上的一個檔案當記憶；他把它放在「駕馭層的上面一層」。Medium 那篇文章的是一支程式：下提示、讀結果、判斷、再下提示，直到模型成了你的程式呼叫的一個副程式。Ronacher 的是兩台機器，一台套在另一台裡面。Anthropic 的是一套分類，依「什麼啟動迴圈、什麼讓它停下」來排。而 Ng 的是一個組織：三個迴圈，最外層的一跑就是幾天或幾週，裡面有早期測試者與 A/B 測試。

把兩端放在一起看。Anthropic 的依回合迴圈是一次提示加一次回覆——「你送出的每一個提示，都會啟動一個由你主導每一回合的手動迴圈」。Ng 的外部迴圈，是一個由使用者花上好幾週重塑的產品願景。在 2026 年 6 月，兩者都叫「迴圈」。仔細讀，它們無法化約成同一個東西，本頁也不會寫出一個假裝可以的定義：沒有人發表過那樣的定義。

最能解開困惑的區分，是 Ronacher 的。一個程式代理裡面本來就有一個迴圈：模型呼叫工具、讀結果、改檔案、跑測試。這個內層迴圈可以追溯到 2022 年的 ReAct，OpenAI 也在 1 月描述過自家的版本。人們從春天開始談的，是那一圈「外面」的迴圈——在代理停下時接住它、判定工作還沒完成的那個東西。許多爭論，其實是兩個人各自在指不同的迴圈，卻以為指的是同一個。

這也點出這個詞真正的內容。其中沒有任何機制是新的，來源也都這麼說：Ronacher 的「那個迴圈也不是新東西」；Ng 把閉合迴圈定在 2025 年底；還有 2025 年 7 月那一行 shell 迴圈。改變的是由誰來下提示。這是工作的改變，不是技術的改變——而每種說法描述的，都是作者自己看得到的那一部分工作。

還有一件事值得直說，因為它是揭露而不是論證。聲音最大的人，打造的正是迴圈所運行的產品。Cherny 是 Anthropic 的 Claude Code 負責人；《Business Insider》稱 Steinberger 為 OpenAI 的工程師；Osmani 在 6 月被形容為 Google Cloud 的總監，如今在自己的網站上寫的是 Anthropic 的技術人員、負責 Claude Code。而最謹慎的話，也出自同一批人——Osmani 的「我持懷疑態度」、Anthropic 的「從最簡單的解法開始」。他們的建議，值得就內容本身來衡量，而內容比周圍的熱情要謹慎得多。

  • 2個迴圈，在把兩者分開的那個說法裡：代理自己的，以及包在外面的駕馭層迴圈
  • 分鐘 → 週Ng 三個迴圈的時間跨度，從程式代理的一輪，到使用者與 A/B 測試

補充

迴圈實際上在做什麼 在機制上，各方倒是一致——和定義不同。

  1. 1把工作放在別的東西拿得到的地方不是你敲進去的提示，而是一個佇列、一份排程或一個事件。Steinberger 自己的做法：一個每五分鐘醒來一次、把工作分派到執行緒的代理。Anthropic 的主動式迴圈，由事件或排程觸發，沒有人即時盯著。
  2. 2讓代理去做，然後停下來這是內層迴圈，不需要幫忙：模型呼叫工具、讀結果、改檔案、跑測試，最後說它做完了。讓它成為迴圈的一切，都發生在這句話之後。
  3. 3不同意「我做完了」由駕馭層判定那是不是真的結束。Ronacher 列出它接下來能做的事：接續同一個工作階段、插入另一則訊息、用修改過的情境開新的工作階段，或把任務交給另一台機器。Anthropic 的 /goal 則用第二個模型來做：「檢查你的條件，再把它送回去工作」。
  4. 4讓檢查可以量化，並讓檢查者獨立Anthropic：「檢查越能量化，Claude 就越容易自我驗證。」Osmani：把寫的代理和檢查的代理分開，因為「寫程式的那個模型給自己的作業打分數，實在太客氣了」。
  5. 5然後用行得通的最小迴圈出自最能從相反建議中獲利的廠商：「不是每項任務都需要複雜的迴圈。」成本也是真的：在《Business Insider》對這場討論的整理裡，「提到迴圈時最大的顧慮，遠遠領先的是成本」。

第一次量測 一份預印本、一個固定的代理、27 項任務各跑三次。

由什麼指揮代理完成的完整任務每次執行的估計成本
什麼都沒有——代理自己做18.52%$2.01
每次交接都重申目標，仿照 /goal18.52%$5.58
最好的指揮模型24.69%$18.84
最弱的指揮模型16.05%$4.86

直到 8 月底以前，沒有任何研究固定代理、只改變迴圈。2026 年 8 月 28 日發表的預印本 LoopArena，針對迴圈裡「決定下一步」的那個部分做了這件事。所有工作都由同一個程式代理完成；每一輪結束後，另一個模型讀取這一輪的摘要，決定下一項任務，或者喊停。這個位子上試了五個模型，另外還有兩種固定策略作對照。

結果令人清醒，而不是令人振奮。最好的指揮模型完成了 24.69% 的完整任務，讓代理自己做則是 18.52%——依論文每種策略 81 次執行換算（本頁自行計算），是 20 次對 15 次——而每次執行的估計成本高出 9.4 倍。有一個模型指揮的成功次數，甚至比完全不指揮還少。最接近目前最簡單迴圈的策略——每次代理停下就重申目標——完成的完整任務數和什麼都不做一模一樣，成本卻是 2.8 倍。在同一批任務的較短片段上，它倒是有幫助，從 39.51% 提高到 46.91%。作者的結論是：有用的迴圈控制「必須隨著執行的演變而調整，而不只是堅持一個目標」。

請把它放鬆地拿著，並按它本來的樣子理解。這只是一份尚未經同儕審查的預印本，只用了一個執行代理模型與 27 項任務，成本也是假設沒有快取的定價估算。它並沒有比較迴圈與人工下提示——它的基準是代理自己工作。它量的是哪個模型最會指揮，而發現指揮很難。

迴圈目前真正管用的地方，按一位不信任它的人的說法，比熱潮所說的窄。Ronacher 列出的是移植程式碼、效能實驗、資安掃描與研究：這些工作轉換既有的程式碼，或者產出「本來就不打算長久保存」的程式碼。對於要長久存在的程式碼，他說得很直：迴圈會放大模型到處加上局部防禦的習慣，讓系統「在看起來更穩健的同時，慢慢變得更難理解」。目前流傳的唯一一個關於實際迴圈的大數字——關掉了數以千計的 GitHub 議題——只建立在一場演講的機器摘要上，列在下方無法查證的部分。

  • 24.69%第一個迴圈基準測試（2026 年 8 月 28 日）中，五個指揮模型在完整任務上的最佳成功率
  • 18.52%同一個代理完全不指揮時的成功率——每一輪只重申目標時也一樣
  • 9.4×最好的指揮模型每次執行的估計成本，相對於代理自己做

結論

可以帶走的幾件事 四件事，依重要性排列。

先問是哪一個迴圈，你就懂了一大半

一個程式代理裡面本來就有一個迴圈——推理、行動、觀察——這個想法 2022 年就有了。2026 年談的，是那一圈「外面」的迴圈：在代理說「我做完了」的時候接住它、並判定還沒完的那個東西。Ronacher 把這條界線畫得最清楚，而這個題目上許多糊塗的對話，都是兩個人各自在指不同的迴圈。

這個詞指的是工作的改變，不是技術

沒有任何機制是新的：2022 年的 ReAct、2025 年的一行 shell 迴圈、OpenAI 在 2026 年 1 月描述它的代理迴圈。改變的是：人不再是寫每一個提示的那個人。這就是定義四散的原因——每一種都描述作者自己看得到的那部分工作，各有各的尺寸。

第一次量測說：指揮很難

唯一一個固定代理的基準測試發現，最好的指揮模型完成 24.69% 的完整任務，代理自己做是 18.52%，成本卻約高九倍；只重申目標，在完整任務上毫無增益。它只是一份預印本，也從未比較人工下提示。「迴圈勝過人工提示」仍是一種預期，不是一項發現。

用倡議者自己的謹慎來衡量他們

與迴圈關係最密切的人，打造的正是迴圈所運行的代理，而他們同時也是呼籲小心的人：Osmani 在替它命名的那篇文章裡自稱持懷疑態度，Anthropic 說要從最簡單的解法開始，Ronacher 說這種做法在他在乎的程式碼上還沒有成功過。從小處開始，讓檢查與執行分開，並留意成本。

無法查證的部分

「傳言」——Steinberger 做的一個工具，在專案積壓的議題超過 10,000 個之後，自動關閉了約 15,000 個 GitHub 議題。這些數字只出現在他 2026 年 6 月 2 日 Microsoft Build 場次的機器生成摘要中，而那份摘要連專案名稱都拼錯了；找不到任何獨立的說法。

「傳言」——Steinberger 在更早的月份就發過同樣的提醒，正如他自己「每月提醒」的字面意思所暗示。找不到任何更早的貼文。

核心要點與來源

  • Yao 等，〈ReAct〉，arXiv（2022 年 10 月 6 日）
  • Geoffrey Huntley（2025 年 7 月 14 日）
  • Michael Bolin，OpenAI（2026 年 1 月 23 日）
  • Liu 等，arXiv（2026 年 4 月 14 日）
  • WorkOS，Acquired Unplugged 活動頁（2026 年 4 月 15 日）
  • Boris Cherny 於 X（2026 年 4 月 16 日，UTC）
  • WorkOS，對談影片（2026 年 6 月 2 日）
  • Noelle Festa，WorkOS（2026 年 6 月 2 日）
  • Microsoft Build，BRK245 場次（2026 年 6 月 2 日）
  • Peter Steinberger 於 X（2026 年 6 月 7 日與 6 月 11 日）
  • Addy Osmani（2026 年 6 月 7 日）
  • Ezekiel Njuguna，Medium（2026 年 6 月 8 日）
  • Brent D. Griffiths，《Business Insider》（2026 年 6 月 20 日）
  • Armin Ronacher（2026 年 6 月 23 日）
  • Andrew Ng 於 X，出自《The Batch》（2026 年 6 月 30 日）
  • Delba de Oliveira 與 Michael Segner，Claude 部落格（2026 年 6 月 30 日）
  • John K. Waters，《ADTmag》（2026 年 7 月 1 日）
  • Wang 等，〈LoopArena〉，arXiv（2026 年 8 月 28 日）。皆於 2026 年 9 月 28 日讀取。本詞是常設主題〈LLM 工程〉涵蓋的五個名詞之一，該頁把它與另外四個並排。

可不可靠

可靠，但有立場又可信又可靠兩者皆弱，謹慎採用立場可信，但材料薄弱

值不值得相信

每一點代表一項採用的來源，依兩項判斷置於六級量尺上。點不具名：本圖呈現的是證據的樣貌，而非對任何出版者的評價。

共享主題

共享來源網域

版本

本文內容需要更動時即改寫為新版本，每個版本都保留在自己的網址。

  1. v0002 目前
  2. v0001 已被取代

目前版本也位於 latest/。