昨天小雷刷到吳恩達在 X 上的一篇推文，講的是 Agent 的 Loop（循環）工程。

圖片來源：X

如果你最近半年用過 Claude Code、Codex、Workbuddy、Kimi Work 或者其他 Agent 產品，你可能已經感受到了那種變化——相比過去一句一句教 AI 干什么，現在你把需求扔進去，它自己會寫、會跑、會報錯了自己改，直到把東西做出來。

這種「自己轉起來」的感覺，就是 Loop 工程在 Agent 產品上的落地。

「……你不該再給 Coding Agent 寫提示詞了，你應該設計 Loop。」6 月，OpenClaw（龍蝦）創始人 Peter Steinberger 一條推引起大量的討論。事實上，就在這之前不久，Google 工程負責人 Addy Osmani 系統性整理 Loop 這個概念，提出了 Loop 工程。

圖片來源：X

不過從公開信息來看，最早提出 Loop 的人，也是最早讓它發光發熱的 Claude Code 創始人 Boris Cherny。就在 6 月底，Anthropic 還發了篇博客，把 Claude Code 里的四種 loop 原語全部公開。

一個月的時間，Loop 工程基本完成了一次華麗的轉身，不只是行業共識，也成為了主流的焦點。所以，到底什么是 Loop？對我們普通用戶又有什么影響？

從提示詞到 Harness 和 Loop，Agent 到底多了什么？

過去講 AI 使用，繞不開提示詞。你讓模型寫代碼、改文檔、做研究，提示詞寫得越細，結果越像樣。從模型走向 Agent，模型不只要回答，還要知道什么時候讀文件、什么時候跑命令、什么時候查網頁、什么時候停下來問人，提示詞工程、思維鏈根本不夠用。

所以出現了 Harness 工程。它可以理解成模型外面那套運行框架，負責接工具、管權限、塞上下文、存狀態。模型還是負責推理和生成，但它開始被放進一個能執行任務的環境里。

Loop 工程又往前走了一步，它關心怎么讓 Agent 圍繞一個目標不斷「循環」運作。

「龍蝦」官方文檔將 Loop 視為「基礎」，圖片來源：OpenClaw

簡單來說，用戶給出目標，Agent 先理解任務，再拿上下文，調用工具，觀察結果，判斷有沒有完成；沒完成，就繼續改，繼續跑，繼續檢查。這個過程看起來像人類工作的日常：先做一版，發現問題，再修一版，直到結果能交付。

所以 Loop 的重點不在「循環」這個詞本身，而在循環里到底放了什么。

Claude Code 的例子最典型。它不是簡單把 Claude 接到終端，而是讓模型在一個 while-loop 里反復調用工具、編輯文件、運行命令、觀察返回結果。真正復雜的部分反而在循環外面：權限系統、上下文壓縮、插件、skills、hooks、子 Agent、會話存儲。

Agent 能不能自己轉起來，靠的不是模型一時興起多想幾步，而是一整套工程設計托著它往前走。

這也是吳恩達這次談 Loop 工程的核心背景。到了 2026 年，Claude Code、Codex、ZCode、MiniMax Code，Agent 產品已經再把「寫—跑—看結果—再改」變成默認能力。

Anthropic 在博客中還把 Loop 分成四種：turn-based（回合制）、goal-based（目標驅動）、time-based（定時觸發）、proactive（主動式）。

- 「幫我寫個登錄頁面」，它寫、測、改，這就是goal-based loop；
- 你每發一條消息它回一條，這是 turn-based；
- time-based 是你可以讓它每隔兩小時自動去檢查某個PR，有更新就幫你 review；
- proactive 更激進，它會自己發現問題、自己開干，比如發現測試覆蓋率下降了，自己去補測試用例。

目標驅動 Loop，圖片來源：Anthropic

而這波討論在 5、6 月突然變熱，也和產品進展有關。OpenAI 的 Codex 已經不只是「幫你寫代碼」的入口，而是在獨立環境里讀倉庫、改文件、跑測試，再把日志和結果交回來。

Anthropic 這邊，Claude Code 本身幾乎成了 Loop 工程最好的樣板。Boris Cherny 那句「不再自己寫提示詞，而是讓一個 Agent 去提示 Claude」，聽起來有點繞，但意思其實就是人不再負責每一步怎么問模型，人負責設計讓模型持續工作的機制。

這也是 Loop 工程真正值得普通用戶關心的地方。Loop 工程做得越好，Agent 越像一個能接住任務的人：你給它方向，它自己往前跑；跑偏了，它能從反饋里拉回來；做完了，它還會把過程和結果交給你檢查。

殺死提示詞，對咱們普通人到底有什么用？

Agent Loop 對普通用戶最直接的價值，就是降低提示詞設計門檻。

過去用 AI，很像在和一個聰明但沒經驗的實習生合作。你得告訴它每一步怎么做，什么時候停，哪里需要查資料，哪里不能亂編。你指揮得越細，它表現越好；你說得越粗，它越容易跑偏。

Loop 做得好的 Agent，更像一個已經知道基本工作流程的人。你也不用每次提醒它「如果代碼報錯就繼續修」，因為測試和返工本來就是循環的一部分。你甚至不用把所有上下文一次性塞進對話框，因為 Agent 可以通過文件系統、搜索工具、記憶和索引自己逐步拿到需要的信息。

這會改變用戶和 AI 的關系。

以前用戶在寫提示詞時，經常要扮演產品經理、項目經理、測試工程師和老師。你要給需求、拆步驟、盯進度、改錯誤。以后用戶更像是在設目標和驗收結果。

比如你讓一個 Agent 做旅行計劃。過去你可能要寫：預算多少、天數多少、先查機票、再查酒店、注意交通、給我表格、最后總結。Loop 做好以后，你只要說「下個月去東京 5 天，預算中等，想少折騰，多看展」，Agent 就應該能自己查時間、比價格、排路線、發現沖突、給出方案，還能在你反饋「第二天太滿」之后自動重排。

這就是「殺死提示詞比賽」的第一層含義。普通用戶不再需要把自己訓練成提示詞工程師，Agent 產品應該替用戶吸收復雜流程。

另一方面，軟件工程天然適合 Loop。目標可以寫成 issue，過程可以拆成文件修改，工具可以跑測試，結果可以用 diff 和 CI 驗證。一個 Agent 寫錯了，系統馬上能看到報錯；修好了，也能看到測試通過。這種反饋閉環清楚、可驗證、可沉淀，所以 Claude Code、Codex、ZCode、MiniMax Code 都先從代碼場景打穿。

圖片來源：智譜 Zcode

但代碼只是開始。研究、表格、PPT、數據分析、客服工單、法務檢索、招聘篩選、運營監控，都有類似特征：任務不是一句話能做完，但成功標準可以被寫出來，過程可以被記錄，結果可以被檢查。

這就是 Loop 的第二層價值：提高復雜工作的生產力。人不再盯著每一步，而是負責定方向、看結果、改規格。吳恩達提到的 developer feedback loop，就是說 AI 可以加速內部執行循環，但人仍然要在更高一層循環里判斷方向是否對。

另外，體驗不好的 Agent，可能給人的第一印象就是不穩定、亂點工具、越做越偏。而從工程角度看，Loop 恰恰給了可靠性一個抓手。

在 Loop 工程設計下， Agent 為什么搜索這個頁面，為什么修改這個文件，為什么調用這個工具，為什么判斷任務已經完成，這些都可以被記錄下來。修復可以變成 skill，項目規則可以寫進 AGENTS.md、CLAUDE.md 或類似記憶文件。下一次 Agent 再做同類任務，就不必重新摸索。

不過，這里也要把話說清楚，Loop 不會自動帶來可靠。事實上，一個設計很差的 Loop，只會讓錯誤更快地自我復制。

過去三年，我們使用 AI 的方式經歷了幾次大的變化，但底層邏輯沒變——都是人發指令，AI 執行，人再判斷結果。人一直在循環里，是驅動整個系統的核心。Loop 工程第一次把人從循環的中心移到了循環的外面，人不再是司機，變成了導航。

這個變化的影響會比想象中深遠。對開發者來說，核心競爭力變成了定義問題、設計驗收標準的能力。對產品來說，迭代速度會進一步加快，倒逼產品團隊更懂用戶、更懂業務，因為技術不再是瓶頸，判斷力才是。

當然，所有這些都建立在一個前提上：模型還得繼續變強。Loop 能轉多少圈、能處理多復雜的任務，最終還是取決于模型的基礎能力。如果模型跑個三五步就跑偏了，那再精巧的 Loop 設計也沒用。

好在從今年的情況看，模型進步的速度還沒慢下來。GPT-5.5、Claude 5、GLM-5.2、M3、K2.6、DeepSeek V4，半年時間各家都更新了一代，而且每一代都在 Agent 能力上有明顯提升。

模型越來越強，Loop 越轉越順，人越來越往外退。這個趨勢已經很清晰了。

這件事聽起來好像只是效率提升，但仔細想想，它可能是 AI 更進一步從「工具」變成「協作者」的關鍵一步。工具是你用它，你得知道怎么用、每一步怎么操作。協作者是你告訴它目標，它自己想辦法，你們一起把事情做成。

我們現在可能正站在這個分界點上。