作者 | 褚杏娟

　　“1 年前我寫代碼的方式，是在 IDE 里，配合某種自動補全功能。去年 11 月，我卸載了 IDE，因為我已經用不到它了。那個時候，我可能同時跑著 5 到 10 個 Claude，我所謂的寫代碼就是提示 Claude 去寫代碼。”

　　Anthropic 工程師、Claude Code 創建者 Boris Cherny 最近的一次分享中說道，“現在，我覺得又到了下一個層級：我不再提示 Claude 了，我有一堆循環（loops）在運行，它們才是在提示 Claude 并判斷接下來該做什么。我的工作變成了寫循環。我認為，這是接下來幾個月，甚至今年剩余時間里我們會看到的下一次轉變。

　　就在今天，現在 OpenAI 任職的 “龍蝦之父”Peter Steinberger 也發推表示，“你不該再給編程 Agent 寫提示詞了。你應該設計一套循環機制，讓這些循環去提示你的 Agent。”截至發稿，該帖子已獲得 150 萬瀏覽量，并引發大量開發者討論。

　　Boris Cherny 和 Peter Steinberger 的公開評論，正在把一個新范式推到臺前：Loop Engineering，即開發者不再只是手動向編程 Agent 輸入提示詞，而是設計能夠持續提示、調度和約束 Agent 的循環系統。

　　有網友評論稱，LinkedIn 可能會很快掀起一波“Loop Engineering”新潮流。Peter 隨后回應稱，“不用擔心，大概還需要 3 個月才會到那一步，之后人們將討論‘設計你的 loops 的艦隊’。”

　　這反映出社區已經開始把“寫 Loop”視為繼寫 Prompt 之后的下一層抽象，也有人把這種變化概括為“從 prompt engineer 到 meta-prompt engineer”。

　　此外，有開發者表示自己已經驗證了這種方式是走得通的，“我就在搭建循環流程（loops），現在配置終于調順了，但又開始出現字符膨脹（character bloat），把我的額度燒得飛快。這挺煩人的，因為它確實能跑通，但同時如果我能搞明白到底哪里出了問題，那它明明就可以用 2 倍速度、以低得多的成本完成同樣的事。”

　　Loop 不是機械重復

　　“Loop 不基本就是一個 cron job 嗎？他們只是反復告訴模型‘把這個應用做得更好’嗎？”有開發者對 Loop 工程的含義發出疑問。

　　對此，有開發者表示，要讓它真正有用，你需要的是一個反饋循環。

　　想想我們作為一個開發團隊需要什么：我們需要知道一個新功能是否按預期工作、哪里還能改進、用戶還有哪些其他問題、哪些工作流可以優化，以及優化這些工作流能帶來什么價值等等。

　　有些事情，LLM可以直接訪問數據；但你也可以生成數據，比如用戶訪談、創建任務等，或者讓它自己生成數據，比如做A/B測試、增加監控等。

　　就像一個開發團隊一樣，你也需要一些OKR或目標。如果你是在為內部員工開發應用，目標可以和提升性能、降低錯誤率、自動化 / 簡化工作流等有關。如果是電商，目標可能是優化從轉化漏斗到成交的流程，并提高收入。它也可以用來升級庫，比如類似Dependabot，修復安全漏洞、管理技術債，分析使用情況，做QA等等。你需要一個清晰的目標，以及一個能驗證輸出結果的反饋循環。

　　YC CEO Garry Tan 轉發相關討論時也提醒道，不要把 Agent 變成“富士康工廠”式的重復勞動機器。他認為，Agent 通常是智能、有思考能力、且并不危險的，開發者應該讓它們承擔更多工作，而不是只是重復執行同一個動作。

　　有開發者指出，可以讓 Agent 做更多事，但邊界必須明確。目標不應該是每一步都盯著它們看，而是給 Agent 提供清晰的上下文、可信的工具、可審計的操作記錄，以及安全的停止條件。這樣它們才能自主運行，而不會變成一套失控的“影子自動化”。

　　一名開發者在 Peter 帖子下也指出，設計 loop 只完成了一半，另一半是在 loop 里放入能夠說“不”的機制，例如測試、類型檢查或真實錯誤。否則，一個沒有反饋機制的 loop，只會讓 Agent 不斷重復并自我確認。Peter 隨后回應稱，他在項目中使用VISION.md文件。

　　這些說明，真正有效的 Loop Engineering 不是簡單的自動化腳本，而是一套帶有反饋閉環的工程系統。Loop 需要知道什么情況下繼續、什么情況下停止、什么情況下回滾、什么情況下交給人類處理。否則，Agent 的錯誤可能在循環中被不斷放大。

　　也有開發者表示，這高度依賴具體場景：如果用 loops 構建 Web 應用，可能會導致系統膨脹，之后又需要再用 loops 去削減復雜度，因此必須建立嚴格的治理棧和清晰規范。

　　還有人追問，所謂 loop 到底是在 CLI 里循環、在 shell 腳本里循環，還是直接讓 Claude 自己循環？

　　實際上，Claude Code 之前就發布了 Loop 功能，開發者可以直接在 CLI 中設置周期性提示詞，讓 Claude Code 按固定間隔反復執行任務。

　　Boris Cherny 近日也介紹過自己現在的工作流：讓大量 AI Agent 長時間并行工作，在夜間通常運行“幾千個”AI Agent，讓它們持續執行更深層次的開發任務，并通過 Claude App 管理這些任務。而這套工作流的關鍵，在于 Claude Code 中兩個面向持續自動化的功能：/loops和 Routines。

　　Cherny 介紹道，用戶可以通過 cron 在本地定時運行/loops，讓 Agent 按計劃循環執行任務；而 Routines 則運行在服務器端，可以執行周期性任務。這樣一來，即使工程師合上筆記本電腦，相關 Agent 仍然可以繼續工作。

　　其中，Loops 的關鍵變化在于，它不再依賴外部 cron 或 shell loop。過去用腳本包裹claude -p時，每次調用都是一次“冷啟動”，缺少上一輪上下文；而 Loops 會在持續存在的 Claude Code 會話中運行，保留上下文窗口、工具權限和 MCP 連接，讓 Agent 能記住上一輪操作，并在下一輪繼續推進。

　　開發者可以用自然語言創建任務，例如：“每 5 分鐘檢查一次 PR 構建是否通過。如果失敗，就讀取錯誤日志，修復問題，并推送一個新 commit。”也可以通過命令創建：

　　/loop "Summarize any new posts taggedin the team Slack channel" --interval 30m --expires 8h

　　當網友詢問 Peter 是如何做到的時候，Peter 則僅表示在用 claw 監視其 Codex，并未過多解釋。

　　目前，Codex 雖然有自動化 / 定時能力，但在 CLI 里并沒有像 Claude Code 那樣設立明確的原生循環命令，比如創建新的計劃循環的cron create，查看當前會話中的所有活躍 Loopcron list，以及通過 ID 立即終止指定 Loop 的cron delete。

　　有意思的是，有用戶詢問 Peter 如何在 VS Code 中實現這一點，Peter 反問：“現在還有誰用 VS Code？”

　　“我們已經從‘學會寫代碼’，走到了‘學會編寫那個會寫代碼的東西’。不知為什么，這聽起來既像進步，又像一場金字塔騙局。”有網友評價道。

　　開發者：你們有無限 token 供應，我沒有啊

　　設想很美好，但現實就是：這種循環工程的 token 消耗量可一點不低。無論 Boris Cherny，還是 Peter Steinberger ，其背后的公司都提供了近乎無限的 token 支持，但對于社區中的很多人來說，自己的 token 預算并沒有那么高。

　　此前，Developers Digest 發文提醒，每一次 Loop 迭代都是一次完整提示詞執行。如果設置 1 分鐘執行一次、連續運行 8 小時，就會產生 480 次 API 調用，因此團隊需要提前規劃使用成本。

　　對于 token 消耗問題，實際上連 Peter 也無解。有人指出“20 美元的套餐根本不可能”后，他只是說道，“沒錯。可難道你的時間真不值錢嗎？”

　　還有開發者說道，“Loop 可以是for循環，也可以是while循環。Token 充裕的公司可以隨意使用while循環；Token 緊張的初創公司也能用for循環實現同樣目標，只是花的時間更長。”

　　為此，有網友半開玩笑地對 Peter 說道，“多么虛偽啊，你在對那么有無限 token 的人說這些嗎？為什么把這事兒說得好像是技術問題，而不是資金問題？”Peter 的回答也挺“正確廢話”的：能賣出去的好創意，依然需要人類的巧思。

　　具體落地中，當前 Claude Code 對于 token 消耗問題的做法基本是做各種限制：

　　Loops 支持最小 1 分鐘間隔，最長運行 3 天，到期后自動停止，以避免無人管理的后臺進程和失控 API 賬單；Loops 不是持久化后臺任務系統，它綁定當前 Claude Code 會話，關閉終端或結束會話后，Loop 就會停止。這一設計是為了安全和可預測性，避免任務在用戶遺忘后繼續消耗 API 額度；此外，Claude Code 也提供禁用 Loop 的開關。如果用戶擔心自動化任務失控、API 成本跑飛，或不希望團隊成員使用循環式 Agent 工作流，可以關閉這一功能。

　　除成本外，loops 的實現，可能比我們想的還麻煩。

　　“所有人都在沖向 loops，但調試一個已經跑了 47 輪的狀態機，比修好一個 prompt 難 10 倍。”有網友指出，“Loops 的方向是對的，但我們跳過了一個關鍵階段：大多數人現在連一個可靠的一次性 prompt 都還寫不好。”

　　還有一些開發者已經使用 Loop 的開發者表示，“一開始什么都很容易設置，但之后你才會意識到，里面有一堆痛點，修起來又太費勁。”

　　“現在想想，我都有點對不起同事，因為是我把 Loop 引進并推廣到我們組織里的。現在如果遷移到另一個方案，會耗費大量時間和資源，所以我們只能再撐一陣子，直到它變得實在太痛苦為止。”有開發者跟帖道。

　　“我們也干過這事，把它集成進來，想在一個項目里試用 Loop。結果現在光是把那個項目的數據導出來，再遷到我們現在用的工具里，就已經要花很多時間和精力，沒人想干。我的建議是：能多早遷就多早遷。時間拖得越久，情況只會變得越糟。”有開發者回復稱。

　　Claude Code 如何一年內從 20 分鐘跑到“數天”

　　Loops 工程的重點是“讓 Agent 在長時間運行中持續不跑偏，并能可靠判斷自己有沒有做對”。這方面，Claude Code 自己就是典型代表。

　　Anthropic 應用 AI 團隊的工程師 Ash 近日表示，公司當前探索方向更偏“盡量完全自主”，目標是把人類判斷寫入 Harness，而不是在不穩定環節插入人工兜底。團隊會同時運行多個生成結果、閱讀失敗案例、調整提示詞，再反復迭代，直到可以較放心地讓 Agent 自主運行。

　　過去一年，Claude Code 已從“只能連續運行約 20 分鐘、連 Bash 命令和字符串轉義都容易出錯”，進化到“幾乎由 Claude Code 自己編寫，并可連續運行數天”的階段。

　　Anthropic 工程師 Andrew 指出，讓 Agent 連續運行數小時甚至數天，核心難點主要有三類：上下文、規劃和自我判斷。

　　首先，上下文窗口有限，新會話會讓 Agent 像“失憶”一樣從頭開始；長會話中還會出現上下文腐爛（context rot），模型越接近上下文窗口末尾，越可能出現“上下文焦慮”，匆忙結束任務。其次，模型默認并不擅長長期規劃，可能一次性試圖完成所有任務，也可能只做完一半功能就停止。更關鍵的是，模型很難準確判斷自己的輸出，經常會把半成品誤認為完成，例如前端按鈕已經出現，但后端邏輯并不存在。

　　為解決這些問題，Anthropic 采用了兩條路徑：一是繼續提升模型本身，把更多長時任務能力寫入模型權重；二是改造模型外部的 Harness，也就是圍繞模型的智能體腳手架。

　　在具體機制上，Anthropic 早期長時運行 Agent 會先由初始化 Agent 將模糊需求拆解成一組持久化文件，例如 feature_list.json、progress 文件、Git 倉庫和初始化腳本。隨后，Agent 在新鮮上下文窗口中反復執行：讀取當前進度、啟動項目、選擇一個未完成功能、實現、測試、提交代碼，并繼續下一輪。這種模式通過“新上下文窗口 + 持久化工件 + 驗證循環”來緩解長任務中的上下文丟失和任務漂移。

　　但隨著 Opus 4.6 等新模型能力增強，Anthropic 已開始簡化這類 Harness。Opus 4.6 更擅長規劃和工具選擇，Sonnet 4.6 則以更低成本提供接近 Opus 的執行能力，因此常見組合是用 Opus 做規劃、用 Sonnet 執行代碼。同時，服務器端壓縮和百萬級上下文窗口使模型可以在單一長會話中保持更久連貫性，不再總是依賴頻繁開啟新會話。

　　當前，Anthropic 正在內部實驗的前沿 Harness 模式是：生成器—評估器—規劃器結構。這個設計借鑒了生成對抗網絡（GAN）的思想：生成器負責構建應用、評估器負責批判和打分，兩者通過對抗壓力不斷提升結果質量。

　　與讓一個 Claude Code 會話自查不同，Anthropic 會讓評估器擁有獨立上下文窗口和系統提示詞，并真正使用 Playwright 打開網頁、點擊、截圖和測試應用，而不只是閱讀代碼 diff。

　　不過，Ash 指出，自我評估是一個陷阱。模型很容易對自己的作品過于寬容，但如果把“構建者”和“批評者”拆開，單獨訓練一個更嚴苛的評估器會更可控。他用人類類比稱，一個人評價一幅畫或一道菜很容易，但親自畫出來或做出來要難得多。大語言模型同樣如此：它作為批評者和作為生成者之間存在能力差距，而 Harness 可以利用這種差距。

　　在評估主觀質量方面，Anthropic 還嘗試將“品味”寫成可評分的量規。Ash 表示，很多人認為設計審美無法評估，但只要有足夠明確的觀點并寫下來就可以評分。比如，Anthropic 將前端應用質量拆成設計、原創性、工藝和功能性四類標準，并根據模型能力調整權重。由于 Opus 4.6 在功能性上已經較強，當前評估更側重設計和原創性，目的是避免常見的“紫色漸變”“AI 味審美”等問題。

　　為了從頁面生成走向完整應用，Anthropic 又引入規劃器角色。規劃器只負責把一句話需求拆成高層規格和沖刺階段，而不是提前規定所有技術細節。真正開始寫代碼前，生成器和評估器還會先協商“什么叫完成”：生成器提出要實現的功能和測試方式，評估器則反駁范圍是否過大、測試是否太弱、是否漏掉邊界情況。雙方通過磁盤文件來回溝通，直到形成一份契約，之后評估器按照這份契約驗收，而不是按照最初模糊需求驗收。

　　對于 Ralph Loop （能讓 AI 在同一個任務上持續工作，直到真正完成所有目標是否仍有價值），Andrew 表示，在百萬級上下文窗口和 Opus 4.6 的連續會話能力下，Anthropic 已經在部分場景從新會話切換到單一長會話加壓縮，但具體選擇仍取決于用例和評測。Ash 則認為，上下文腐爛是當前模型的臨時性缺陷，某些支架組件未來可能會隨著模型進步被移除。

　　https://x.com/steipete/status/2063697162748260627

　　https://www.youtube.com/watch?v=RkQQ7WEor7w&t=546s

　　https://www.developersdigest.tech/blog/claude-code-loops?utm_source=chatgpt.com

　　https://www.youtube.com/watch?v=mR-WAvEPRwE&t=475s