2026年7月，AI程式設計領域經歷重大轉變。Peter Steinberger 在 X 平台宣布循環工程時代結束，引導業界轉向圖（Graph）工程。循環工程源自 Geoffrey Huntley 的 Ralph 方法，透過讓 AI Agent 持續運行直至達成目標來繞過上下文視窗限制。2026年4月至5月，Codex、Claude Code 等工具相繼推出 Goal 功能，實現循環的產品化。目前業界正在探索更複雜的圖工程，涉及組織圖和工作圖的協同設計。

文章作者、來源：微信公眾號 InfoQ（ID：infoqchina）

我們還在討論迴圈，還是已經轉向圖了？

2026 年 7 月 18 日，Peter Steinberger 在 X 平台上以這句話，悄然宣告了循環工程時代的終結。這則貼文在發布後兩天內獲得 260 萬次瀏覽。

六週前，他以「設計能提示 Agent 的循環」獲得 840 萬次瀏覽，讓全球開發者意識到提示工程的時代正在過去，循環工程才是新的方向。

兩篇帖子累計瀏覽量超過 1100 萬次，將 AI 編程領域最熱門的討論推向了下一個節點。

循環的崛起

過去一個月，「Loop Engineering（循環工程）」迅速成為 AI 編程領域的熱門概念。

但它真正的起源，要追溯到一年前。2025 年 7 月，軟體工程師 Geoffrey Huntley 提出了一種被他稱作“Ralph”的方法——一個簡單的 Bash 循環，讓 Claude 反覆執行任務直到目標達成：

while :; do cat PROMPT.md | claude-code ; done

Ralph 方法的核心在於繞過上下文視窗的限制。當時是 2025 年中期，上下文視窗的最大值為 200,000 Token。這對於更複雜的任務來說遠遠不夠，因此需要將 Agent 的運行拆分為更小的運行單元，然後逐一運行。

在這種背景下，Ralph 方法的運作方式如下：

• 為項目設定一個目標，然後持續運行或重新運行 Agent，直到實現目標。
• 以「壓縮」形式將已完成的工作持久化到檔案系統中，例如儲存為日誌或更新後的計畫。
• 使用全新的上下文啟動 Agent，從而盡量減少「上下文腐化」。
• 在必要時，允許每個 Agent 添加或修改「總體計劃」。

Huntley 使用此方法從零構建了一門編程語言，驗證了其可行性。但直到更強大的模型出現後，它才在開發者圈子中迅速傳開。

Loop 的火爆也離不開 Anthropic 和 OpenAI 的一些核心開發者。最初在 Anthropic 的開發者大會上，Claude Code 的創造者 Boris Cherny 表示：「我現在已經不再提示 Claude 了。我運行的是一些循環，由這些循環去提示 Claude，並判斷接下來該做什麼。我的工作是編寫循環。」

隨後，Peter Steinberger 也發帖呼籲開發者停止直接提示程式設計 Agent：「每月提醒一次：你不應該再親自提示程式設計 Agent 了。你應該設計能夠提示 Agent 的迴圈。」

前 Google 工程師 Addy Osmani 隨後還專門撰寫了一篇題為《Loop Engineering》的文章，將其概括為：「循環工程，就是讓自己退出親自提示 Agent 的位置，轉而設計一個替你完成這件事的系統。」

概念有了，名字有了，基礎設施也迅速跟進。

2026 年 4 到 5 月，Codex、Claude Code、Hermes 相繼推出 /goal 命令，將手工編寫的迴圈產品化為一條指令。

在 Ralph 開始廣泛應用約六個月後，Codex 發布了 goal 功能

Codex 文件指出：「Goals 是 Codex 中持久存在的目標，可讓一個對話線程在多輪互動中持續朝著明確的結果推進。Goal 會為 Codex 提供一個完成條件：哪些狀態應該成立、如何檢查是否成功，以及哪些約束必須始終得到保留。」

文件特別指出：「普通提示詞表達的是：接下來做這件事。Goal 表達的是：繼續工作，直到這個結果成立。」

在一般請求中，Codex 會處理當前指令、回報結果，然後等待下一步。在使用 Goal 時，線程上會附加一個持久目標。一輪執行結束後，它可以檢查當前證據，並判斷目標是否已完成。如果答案為否，且 Goal 仍處於啟用狀態、預算未耗盡，Codex 就能從最新狀態繼續工作。

例如：在確保正確性測試套件始終通過的前提下，將結賬基準測試中的 p95 延遲降低至 120 毫秒以下。

這是一個足夠清晰的「結束標準」，可直接交給 Agent。隨後，Agent 會自行拆分任務、建立子 Agent，並持續運行，直到工作完成。Codex 團隊借鑒了 Ralph 循環的思路，在此基礎上構建了基礎設施：協調多個 Agent，避免它們彼此干擾；管理狀態；運行測試；啟動和停止 Agent；隨後又增加了預算設定等功能。

Goals 功能的架構

開發者如何使用迴圈

那麼開發者實際上在用迴圈做什麼？根據社區反饋，最常見的場景還是處理一些週期性工作。

但循環的能力遠不止於此。真正體現循環工程價值的，是一些更複雜、需要持續迭代的長期任務。

例如完成大規模代碼遷移。創業公司創始人 Rafel Mendiola 需要將一個 React 應用轉換成 React Native。傳統做法是創建一個大型 Epic，再拆分出 50 到 100 張工單，光是搭建基礎設施就讓人望而卻步。

他的替代方案是建立一個 Skill，讓 Agent 自行識別可遷移的程式碼區塊，完成轉換並追蹤進度，然後將這個 Skill 放入每 30 分鐘運行一次的 Cron 定時任務中。與管理一份龐大的遷移計劃相比，這種方式在認知上輕鬆得多。

下一站：Graph

Peter 的推文問題實際上指向了一條演進路徑。

一年前，提示工程還是核心技能。到了 2025 年到 2026 年初，重心轉移到了設計迴圈。而現在，Peter 所指向的已是更遠的地方：設計由多個迴圈組成的圖——每個 Agent 運行自己的迴圈，透過依賴關係彼此連接。

這條推文的討論串中最精彩的回覆來自 Luis Catacora：「循環有很大的容錯空間。圖表會迫使你承認，工作流程中還有多少部分根本沒有被真正建模。」

這句話能體現這兩種範式的區別。迴圈允許你延後架構設計：先讓一個 Agent 包攬所有工作，直到它再也處理不了為止。圖則要求你提前聲明整個結構——誰負責什麼，哪些任務依賴哪些任務，某個分支失敗後該怎麼辦。迴圈是延期決策，圖是提前決策。

Google 高級 AI 產品經理、Awesome LLM Apps 代碼庫（GitHub 上超過 12.4 萬顆星）的作者 Shubham Saboo，提供了另一種拆解方式，他區分了兩個層次：「組織圖長期存在，定義誰負責哪個領域並保留上下文；工作圖定義當前需要做什麼，可根據證據進行拆分、合併、重新排序或直接消失。」

Graph 到底是什麼？

Loop 讓 Agent 的行為變得可程式化。Graph 讓 Agent 的組織變得可程式化。

再進一步是動態 Agent 組織：在任務執行過程中，Graph 會自行重寫其結構。

Preston Holmes：至少有兩種 Graph 至關重要。第一種是你圖中展示的、由長期存在的 Agent 組成的 Graph，它們像區域聯防一樣，各自負責一個區域。第二種是需要完成的工作所形成的 Graph。它是動態的，會不斷變化。

Shubham Saboo：長期存在的「組織圖」決定由誰負責每個區域，並負責保留上下文；「工作圖」則決定當前需要完成哪些任務。隨著新證據出現，它可以拆分、合併、重新排序，或直接消失。

這是生產級多 Agent 系統的關鍵：實際上有兩張圖在同時運行。

組織圖（Org Graph）：定義「誰負責什麼」。它由長期存在的 Agent 組成，每個 Agent 負責一個固定領域，保留該領域的上下文、專業能力和工具權限。組織圖相對穩定，類似公司的組織架構。

工作圖（Work Graph）：定義「現在要做什麼，以及任務如何流轉」。它會隨著任務和新證據不斷變化，可拆分、合併、調整順序或直接取消。工作圖更像即時生成的專案計劃。

Preston Holmes 也認為這兩張圖都很重要，而且它們運行在不同的時間尺度上。組織圖會被預先設計並部署；工作圖則針對每項任務動態生成，並在任務完成後丟棄。

如果說迴圈讓 Agent 的行為變得可程式化，那麼圖讓 Agent 的組織變得可程式化。再進一步是動態 Agent 組織——在任務執行過程中，圖會自行重寫其結構。

從寫好 Prompt，到設計 Loop，再到構建 Graph，AI 編程的能力重心正在持續上移。開發者越來越不需要關心如何與單個 Agent 對話，而是需要思考如何設計 Agent 之間的協作結構。