@akshay_pachaar：Loop Engineering 詳解 你的資訊來源中，有一半的人突然都在講同一件事：別再糾結於如何下 Prompt（提示詞）給你的 Agent 了，開始…

Loop Engineering 詳解 你的資訊來源中，有一半的人突然都在講同一件事：別再糾結於如何下 Prompt（提示詞）給你的 Agent 了，開始進行 Loop Engineering（迴圈工程）吧。 Claude Code 的開發者 Boris Cherny 說得很直白：「我不再給 Claude 下 Prompt 了。我現在執行的是迴圈。我的工作是編寫迴圈。」 這位打造了全球最受歡迎程式開發 Agent 之一的人，竟然不給它下 Prompt。那麼，他到底在做什麼？ 這就是 Loop Engineering 背後的核心概念。現在，讓我們來拆解為什麼這件事比看起來更困難。 首先，迴圈本身 Agent 並不是什麼魔法盒子。它的核心其實就是一個簡單的迴圈： `python while True: response = model(context) if response.hastoolcalls(): results = runtools(response.toolcalls) context += results else: break ` 模型讀取 context（上下文），然後要求呼叫某個 tool（工具）。你執行該 tool 並將結果回饋給它。模型再次讀取，這個過程不斷重複，直到它不再要求使用 tool 為止。 Model → tools → context → 重複。 令人驚訝的是，這個迴圈的邏輯其實早就被解決了。每一個嚴肅的 Agent 框架最終都會寫出這六行左右的程式碼。沒人在 while 語句上競爭。 所以，如果迴圈本身這麼簡單，大家到底在 Engineering 什麼？ 工作重心已轉移到模型之外 AI 的重心正持續從模型本身向外偏移。 Prompt Engineering：你發送的文字。 Context Engineering：模型所看到的一切，而不僅僅是你的指令。 Harness Engineering：圍繞在模型周圍、負責執行 tool、追蹤狀態並處理錯誤的程式碼。 Loop Engineering：驅動整個系統朝目標前進的自主循環。 每一層都包裹著前一層。你並沒有不再關心 Prompt，你只是意識到 Prompt 只是龐大系統中的一小部分。 LangChain 對此定義得很清楚：Agent = Model + Harness。如果你不是在開發模型，那你就是在開發 Harness。 以下這個發現應該會讓你重新調整優先順序：Harness 現在比模型更重要。 有些團隊保持模型不變，僅僅修改了周圍的程式碼，就從基準測試的中段躍升至前五名。同樣的大腦，不同的迴圈。 Loop Engineering 就是設計這顆大腦運作環境的學問。讓我帶你看看哪些部分最容易出錯。 難點 1：知道何時該停止 這是沒人會提醒你的問題。 當 Agent 不再要求使用 tool 時，它只是結束了當前的「回合」（turn），這並不等於完成了任務。 想像一個程式開發 Agent。它寫了一些程式碼，環顧四周，看到進度有推進，於是宣佈任務完成。但測試依然失敗。它卻自顧自地宣佈勝利。 終端機訊息結束的是回合，而不是任務。搞混這兩者是迴圈出錯最常見的原因。 好的迴圈會因為正確的理由停止，所以你需要設置多層煞車： 最大迭代次數：設置硬性上限，防止卡住的 Agent 無限執行。 預算與時間限制：對 token 使用量、金錢和執行時間設置上限。 無進度偵測：如果它重複使用相同的參數呼叫同一個 tool，代表它陷入了死循環。 真正的完成檢查：一個能證明任務已完成的自動化條件。 最後一點至關重要。「完成」應該是指測試通過，而不是 Agent 覺得自己做得很好。 難點 2：保持 context 的乾淨 長迴圈會從內部腐爛。 Agent 執行的回合越多，context 中堆積的垃圾就越多，例如舊的 tool 輸出、死胡同和過時的推理過程。隨著堆積物增加，模型效能會下降。業界稱之為「Context Rot」（上下文腐爛）。 迴圈會讓這種情況惡化。腐爛的 context 會導致更差的決策，進而產生更多雜訊，進一步腐爛 context。人們稱此為「毀滅迴圈」（doom loop），你一定感受過——Agent 執行越久，表現就越笨。 你要將 context 視為預算而非垃圾桶來進行管理： 壓縮：當對話變長時進行總結，然後從總結處繼續。 卸載：將龐大的輸出推送到檔案中，只保留你需要的部分。 子 Agent：將混亂的子任務交給獨立的 Agent，只讓它回傳乾淨的結果。 人的直覺是「以防萬一」而保留一切。但真正的技術是知道什麼該丟棄。 難點 3：Agent 真正能用的 tool 迴圈的品質取決於內部的 tool。 堆疊一百個 tool 只會讓 Agent 迷失方向。一套精簡、聚焦且功能不重疊的 tool 才是贏家。Anthropic 的經驗法則很精準：如果人類工程師都無法確定該用哪個 tool，那 Agent 更不可能知道。 有兩件事比預期中更重要： 確保寫入操作可重複執行：迴圈會重試，如果重試一次「建立客戶」的呼叫導致建立了第二個客戶，你就會面臨重複資料和重複計費的問題。任何會改變狀態的操作都必須確保能安全地呼叫兩次。 為 Agent 撰寫錯誤訊息，而非為人類：好的錯誤訊息會告訴 Agent 下一步該做什麼。在發布 tool 之前，先問問自己：LLM 讀到這個錯誤時，知道下一步該怎麼走嗎？ 在迴圈中，錯誤不是死胡同，而是下一個指令。 難點 4：要有能說「不」的機制 自主迴圈有一個隱蔽的失敗模式：無人看管的 Agent 往往會自我感覺良好。 這場辯論中最尖銳的評論一針見血：設計迴圈只完成了一半的工作，另一半是放入一個能說「不」的機制，例如測試、型別檢查或真實的錯誤回饋。 沒有審核者的迴圈，只是一個對自己的工作不斷點頭的 Agent。 解決方法是將「執行者」與「檢查者」分開。一個模型負責工作，另一個不同的檢查機制（通常是另一個模型或嚴格的測試）負責評分。執行者不該自己給自己的作業打分數。 真正的轉變 現在 Cherny 的話就說得通了。 Prompting 是你一步步引導 Agent。Loop Engineering 是你設計一個能引導它的系統，然後退居幕後。 你的工作從給予指令轉變為設計三件事： 目標：寫成 Agent 可以自我驗證的成功標準。 迴圈：設置合理的煞車，確保它能正確停止。 驗證器：確保「完成」是被證明的，而不是被宣稱的。 Andrej Karpathy 抓住了這種心態。不要告訴模型該做什麼，給它成功標準，然後看著它執行。他會整晚執行研究迴圈，自動調整腳本、測試、保留有效的、丟棄無效的，而他自己完全不在迴圈中。他只需安排一次，然後按下開始。 這就是關鍵所在。你不再是動手操作的人，而是設計這台機器的人。 從哪裡開始 你不必第一天就追求全自動化的 Agent。請循序漸進： 從基礎迴圈開始，立即加上最大迭代次數、逾時機制和成本上限。 在開始之前，將「完成」定義為自動化檢查，而不是事後的感覺。 保護 context。壓縮長執行過程、卸載大型輸出、隔離混亂的子任務。 審核你的 tool。保持數量精簡且聚焦，確保寫入操作可重複，並重寫錯誤訊息以便 Agent 能據此行動。 在迴圈中放入審核者。只有當你信任那個能說「不」的機制時，才完全放手。 總結 Loop Engineering 不是一個框架或工具，而是一種努力方向的轉變。 模型正在成為商品。圍繞在模型周圍的迴圈，才是現在真正工程技術的所在。 最優秀的開發者已經不再問「我該告訴 Agent 做什麼？」，他們開始問「什麼樣的系統可以在沒有我的情況下完成這件事？」 只要能回答好這個問題，你也會停止依賴 Prompt。 以下是總結 展開畫面重點這張圖表分為四個區塊，探討如何提升 AI 代理的運作效率與品質： Keep the context clean（保持上下文簡潔） - 指出長循環會導致「上下文腐敗」（context rot），累積過時輸出與無效推理，使代理效率下降。 - 建議：保持精簡（lean）。 - 方法： - Compact：總結後繼續執行。 - Offload：將大型輸出轉存至檔案。 - Sub-agents：將雜亂的子任務隔離處理。 Know when to stop（知道何時停止） - 強調終止條件應基於實際原因而非感覺。 - 建議的停止機制： - max…