# 策展 · X (Twitter) 🔥🔥🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Akshay 🚀 (@akshay_pachaar) · 平台：X (Twitter) · 日期：2026-06-23

> 原始來源：https://x.com/akshay_pachaar/status/2069118430582866051

## 中文摘要

# 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.has_tool_calls():
        results = run_tools(response.tool_calls)
        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 是你設計一個能引導它的系統，然後退居幕後。

你的工作從給予指令轉變為設計三件事：

1. **目標**：寫成 Agent 可以自我驗證的成功標準。
2. **迴圈**：設置合理的煞車，確保它能正確停止。
3. **驗證器**：確保「完成」是被證明的，而不是被宣稱的。

Andrej Karpathy 抓住了這種心態。不要告訴模型該做什麼，給它成功標準，然後看著它執行。他會整晚執行研究迴圈，自動調整腳本、測試、保留有效的、丟棄無效的，而他自己完全不在迴圈中。他只需安排一次，然後按下開始。

這就是關鍵所在。你不再是動手操作的人，而是設計這台機器的人。

# 從哪裡開始

你不必第一天就追求全自動化的 Agent。請循序漸進：

1. 從基礎迴圈開始，立即加上最大迭代次數、逾時機制和成本上限。
2. 在開始之前，將「完成」定義為自動化檢查，而不是事後的感覺。
3. 保護 context。壓縮長執行過程、卸載大型輸出、隔離混亂的子任務。
4. 審核你的 tool。保持數量精簡且聚焦，確保寫入操作可重複，並重寫錯誤訊息以便 Agent 能據此行動。
5. 在迴圈中放入審核者。只有當你信任那個能說「不」的機制時，才完全放手。

# 總結

Loop Engineering 不是一個框架或工具，而是一種努力方向的轉變。

模型正在成為商品。圍繞在模型周圍的迴圈，才是現在真正工程技術的所在。

最優秀的開發者已經不再問「我該告訴 Agent 做什麼？」，他們開始問「什麼樣的系統可以在沒有我的情況下完成這件事？」

只要能回答好這個問題，你也會停止依賴 Prompt。

以下是總結

![這張資訊圖表總結了優化 AI 代理（Agent）效能的四個關鍵策略。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/0df336a3b0fc3a1c.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">這張圖表分為四個區塊，探討如何提升 AI 代理的運作效率與品質：

1. **Keep the context clean（保持上下文簡潔）**
   - 指出長循環會導致「上下文腐敗」（context rot），累積過時輸出與無效推理，使代理效率下降。
   - 建議：保持精簡（lean）。
   - 方法：
     - Compact：總結後繼續執行。
     - Offload：將大型輸出轉存至檔案。
     - Sub-agents：將雜亂的子任務隔離處理。

2. **Know when to stop（知道何時停止）**
   - 強調終止條件應基於實際原因而非感覺。
   - 建議的停止機制：
     - max iterations（最大迭代次數 - 硬性上限）
     - budget + time（預算與時間 - token/$/秒）
     - no-progress（無進展 - 重複的呼叫與參數）
     - completion check（完成檢查 - 測試通過）

3. **A critic that can say no（能說「不」的評論者）**
   - 強調應將「創作者」（Maker）與「檢查者」（Checker）分離，避免代理自我審查。
   - 檢查機制包含：測試、型別檢查、真實錯誤偵測。
   - 核心概念：不應讓代理評分自己的作業。

4. **Tools it can actually use（代理真正能使用的工具）**
   - 建議提供少量、聚焦且功能不重疊的工具集，避免代理因工具過多而迷失。
   - 建議：
     - Few, focused, non-overlapping（少量、聚焦、不重疊）
     - Make writes safe to repeat（確保寫入操作可安全重複）
     - Errors written for the agent（為代理撰寫錯誤訊息）</div></details>

---

感謝閱讀！

Cheers :)
Akshay.

## 標籤

Loop Engineering, Claude Code, Agent, Skills, 教學資源, Anthropic, Claude