Agents 之所以有用，是因為它們能透過在現實世界中採取行動來幫助我們自動化工作。但要讓 Agents 可靠地完成有價值的工作，光靠一個好模型是不夠的：還需要一個針對任務集精心設計的框架。
核心的 agent 演算法很簡單：給 LLM 上下文，讓它在一個迴圈中呼叫工具，直到任務完成。這是最基本的迴圈，但絕非唯一能驅動 agents 的迴圈。@swyx 最近寫了一篇很棒的文章，關於「loopcraft：堆疊迴圈的藝術」，概念是可以堆疊並延伸迴圈，以建立更有效的 agents。
以下是我們對這個堆疊的理解，以及如何使用 LangChain 的基本元件來為每個層級進行儀器化。
迴圈 1：Agent
核心上，agent 只是一個在迴圈中呼叫工具，直到任務完成的模型。
這就是 LangChain 的 create_agent 所提供的功能。選擇任何模型，插入工具，你就得到一個可運作的 agent 迴圈。工具賦予 agent 在現實世界中採取行動的能力。
以我們的內部文件 agent 為例（我們將以此作為本篇文章其餘部分的範例）。在第一個迴圈層級，它接收到一個文件改進的請求，模型會規劃並草擬修改，並使用工具來複製儲存庫、讀取檔案、撰寫文件、開啟 pull request 等。
層級 2：驗證迴圈
Agent 迴圈可以完成工作，但第一次執行時並不一定能產出正確或一致的結果。當一致性很重要時，通常會將其包裝在一個驗證迴圈中，該迴圈會檢查輸出，並在結果不符合標準時將反饋送回模型。
驗證迴圈加入了一個評分器：它會根據評分標準檢查 agent 的輸出，如果失敗，則將結果連同反饋一起送回。評分器可以是確定性的，也可以是 agent 式的（以 LLM 作為評審就是一個經典例子）。
RubricMiddleware 可以處理這個模式，或者你也可以在 create_agent 上使用 after_agent 鉤子來配置。
對於我們的文件撰寫 agent 範例，評分器會在每次嘗試後執行測試，檢查所有連結是否可解析、所有 CI 檢查是否通過，以及 diff 是否僅限於實際請求的範圍。無需人工審查即可捕捉這類錯誤。
一個取捨：加入驗證會增加每次執行的延遲和成本。當品質比速度更重要時，這就值得了，而這正是大多數生產環境使用案例的情況。
層級 3：事件驅動迴圈
Agent 開發中最重要的一部分是整合層：將你的 agent 連接到你的生態系統，使其能在背景執行。
事件驅動迴圈將你的 agent 連接到你的生態系統。當一個事件觸發時——新文件送達、排程觸發、webhook 到達——agent 就會執行。Agent 不是你手動呼叫的東西；它是一個在大型系統中持續運行的元件。
LangSmith Deployment 支援觸發基礎設施，包括 cron 排程和 webhook。其中一個 cron 的熱門應用範例是 openclaw 中的「心跳」，這能將你的 agent 轉變為一個永遠在線、主動的助手。
我們的文件 agent 由 Fleet 驅動，這是我們的無程式碼 agent 建構工具。Fleet 的 channels 和 schedules 負責處理事件驅動和 cron 風格的觸發。每當我們在 #docs-plz Slack 頻道中發送訊息時，我們就會使用一個 channel 來觸發文件 agent。
層級 4：爬山演算法迴圈
前三種迴圈能自動化工作。第四種（可以說是最重要的）則能自動化改進！
每次 agent 執行都會產生一個追蹤記錄：記錄模型做了什麼、呼叫了哪些工具、評分器反饋等等。這些追蹤記錄包含關於什麼有效、什麼無效的高價值信號。爬山演算法迴圈會對這些追蹤記錄執行一個分析 agent，並利用分析結果來改寫框架，改善配置。這可能包括提示/工具的調整，或是評分器的調整。
在 LangSmith 中，你可以使用 Engine（我們的追蹤分析 agent）來為第四個迴圈進行儀器化。
總結文件 agent 的類比，我們會在文件 agent 的追蹤記錄上執行 Engine，以檢測任何問題。當多個追蹤記錄表明存在潛在問題時，就會建立一個 issue，要求對有問題的提示或工具進行修改。
這裡的關鍵動作是，返回箭頭不僅僅是迴圈回到頂部——它會直接深入內部並更新 agent 迴圈本身。外部迴圈的每個週期都能使內部迴圈更有效。
展望未來：
提示和工具配置是最容易改進的項目，但它們並非唯一選項。對於使用開源權重模型的團隊，爬山演算法迴圈可以將結果回饋給 RL 微調，利用追蹤或評估結果作為訓練訊號來改進模型本身。像記憶體和檢索技能這類的輔助上下文，也可以用同樣的方式改進。迴圈是模式；它優化的對象則由你決定。
人類監督與專業知識
自動化並不意味著將人類排除在迴圈之外。在每個層級，都有自然的人類監督可以增加價值的地方。一個自動評分器可以檢查連結是否可解析；但需要人類才能注意到論述方式對目標受眾而言並不恰當。這種來自於脈絡、經驗和品味的判斷力，正是人類審查的價值所在。
有些專業知識應該被編碼在提示/工具本身，但對於敏感的操作，即時的人類審查至關重要（想想金融交易、資料庫操作等）。LangChain 讓你在每個迴圈中輕鬆設定這些接觸點：
- 在 agent 迴圈中，在執行敏感操作/工具呼叫前要求人工輸入
- 在驗證迴圈中，人類可以作為敏感工作流程的評分器
- 在應用程式迴圈中，人類可以在輸出返回給終端使用者之前批准結果
- 在爬山演算法迴圈中，框架的改進可以在部署前經過人類審查
LangChain 的所有開源框架都將「人在迴圈中」視為第一級基本元件。
總結
如果你偏好表格化的檢視方式，以下是這四種迴圈的堆疊方式：
迴圈 | 功能 | 影響 | LangChain 基本元件 |
|---|---|---|---|
1：Agent 迴圈 (模型 + 工具) | 模型反覆呼叫工具，直到任務完成 | 自動化工作 | create_agent，任何 LangChain 支援的模型 |
2：驗證迴圈 (agent + 評分器) | Agent 執行，輸出根據評分標準評分，若失敗則帶反饋重試 | 確保品質 | RubricMiddleware |
3：事件迴圈 (驗證 + 系統) | 事件觸發 agent 執行，更新真實系統 | 大規模運作 | LangSmith Deployment / Fleet channels |
4：爬山演算法迴圈 (系統 + Engine) | 生產追蹤記錄提供給分析 agent，改善框架配置 | 持續改進 | LangSmith Engine |
這就是迴圈工程——或者如 @swyx 所說的 loopcraft——在實踐中的樣子。AI 領袖如 Steipete、Boris 和 Andrej 都得出了相同的結論：agent 的潛力在於你圍繞它們建立的迴圈。
我們已經思考迴圈 1 和迴圈 2 一段時間了。但重點應該轉向迴圈 3 和迴圈 4，因為將 agents 嵌入你的生態系統，並讓它們根據你的標準持續改進，能產生複合價值。
Satya 點出了組織層面的利害關係：那些及早建立學習迴圈的公司——讓人類判斷與代幣資本共同複合增長——將會建立難以複製的優勢。
致謝
感謝 @Vtrivedy10、@masondrxy、@hwchase17 和 @huntlovell 提供深入的審閱。
