我先在哪個真實場景撞上這個問題
年初我在做一個自動化程式碼審查工具，目標是讓 Agent 能根據測試失敗資訊自動修復程式碼並重新提交。最开始的方案很直接：Agent 调用一次 LLM，拿到修复建议，打补丁，跑测试。但很快就發現問題——第一次產生的修復常常不對，甚至引入新 bug。
這時我才真正撞上 Loop Engineering：不是簡單地“調用 LLM 拿結果”，而是需要設計一個循環——評估輸出、反饋修正、再評估，直到通過或達到終止條件。很多文章講的是理論上的“閉環”，但我面對的是實實在在的 retry 隊列、終止條件判斷和狀態管理。
做完之後真正改變我判斷方式的幾個結論
1. 循环次数不是越多越好，关键在信号质量
我一開始設了 max_retries=5，想著多試幾次總是能過。實際上，第 3 次之後 Agent 往往只會微調標點或換同義詞，毫無實質改進。後來我把終止條件從「固定次數」改為「訊號變化率」——如果連續兩次的修復方案語意相似度超過 90%，就直接終止並標記為「無法自動修復」。
2. 上下文膨脹是隱形殺手
每次循環都把完整對話歷史發給模型，上下文視窗很快就堆滿，模型開始「遺忘」最初的程式碼。我踩過這個坑後，改為只保留當前代碼塊、最近一次失敗訊息和前一次修復 diff。結果修復成功率反而提升了 12%。
3. 測驗的可靠性決定了循環的有效性
如果測試本身有 flaky（脆弱的）因素，例如網路抖動或計時問題，循環就會在錯誤的訊號上反覆嘗試。我花了兩週時間把 flaky test 比率從 8% 降到 1% 以下，這才讓循環真正有指導意義。
當時踩過的坑和後來怎麼修正
坑 1：沒有區分「可重試錯誤」和「不可重試錯誤」
一開始對所有失敗都重試，包括編譯錯誤（例如缺少 import）——這類錯誤重試 10 次也不會變好，只會浪費時間和 tokens。修正方法是預先定義錯誤分類：語法錯誤、缺乏依賴、邏輯錯誤——前兩類直接報錯終止，只有「邏輯不夠完善」才能進入循環。
坑 2：循環日誌太粗，無法除錯
最初只記錄“retry 1: fail, retry 2: fail”，完全看不出失敗原因。後來我在每個循環節點上列印出：原始錯誤、模型輸出 diff、測試輸出摘要。有了這個日誌，定位問題的時間從小時降到分鐘級。
坑 3：沒有考慮成本上限
一个复杂的修复任务可能跑 8 次循环，花费 2 美元。對於實驗階段來說不可持續。我的修正方案是：設定 token 預算，一旦當前循環累計 tokens 超過條目的預期價值（例如這個 bug 修復的預估人工成本），就自動降級到簡單 LLM 或直接掛起。
如果你也在做類似工作，最值得先抄寫的一步
直接在你的修復循環入口處加上這段檢查（偽代碼）：
def should_retry(error, history):
if error.type in UNRECOVERABLE_ERRORS:
return False
if len(history) >= 2 and similarity(history[-1], history[-2]) > 0.9:
return False
if total_tokens_used > BUDGET:
return False
return True
這三點檢查涵蓋了最常見的問題：錯誤不可修復、模型陷入原地打轉、成本失控。把它放在迴圈最外層，能節省至少 30% 的無謂消耗。
什麼時候該繼續投入，什麼時候該換路線
繼續投入的訊號：
- 你有明確的訊號（如測試通過率、實際修復率）在持續改善，即使提升緩慢。
- 你已經在循環設計中加入了上述的終止和降級邏輯，成本可控。
- 團隊有精力維持測試穩定性和錯誤分類清單。
換路線的號誌：
- 你發現大多數失敗是同一類「不可重試」錯誤，例如依賴版本衝突或 API 變更——這時應該去修復來源問題，而不是循環。
- 循环次数增加了，但修复成功率长期低于 30%。這可能意味著 LLM 本身不擅長這個任務，需要更換模型或換 prompt 策略。
- 你發現自己花了 80% 的時間在調循環參數（max_retries、temperature、top_p）而不是改善任務本身。
當我遇到這些訊號時，果斷暫停了自動修復循環，改為半自動方案：循環只負責產生建議，人工確認後再落地。兩個月後，等模型版本升級才重新嘗試全自動。
總結
Loop Engineering 不是銀彈，它解決的是「有明確回饋訊號、有可重試空間、成本可接受」的任務。如果在你的場景裡這些條件不滿足，不要硬套。但如果你正好面對這類問題，上面這些經驗──尤其是終止條件設計、情境管理、錯誤分類和預算控制──可以直接拿來用。
下一步，如果你想獲得更有系統的 Agent 工程方法論，包括上下文視窗策略、循環成本模型和錯誤恢復模式，可以進入我們的付費文章和課程。
暫無評論，快來發表你的看法吧