迴圈工程的藝術

代理之所以有用，是因為它們能透過在實際世界中採取行動來幫助我們實現自動化。但要讓代理穩定地完成有價值的任務，需要的不僅僅是一個好模型，還需要一個精心設計的、適合特定任務的“框架”。

核心的代理演算法很簡單：給LLM上下文，讓它迴圈呼叫工具直到完成。這是最基本的迴圈。但遠非唯一。Swyx最近寫了一篇關於“迴圈工藝：堆疊迴圈的藝術”的好文章，其理念是透過堆疊和擴充套件迴圈來構建更有效的代理。

以下是我們對這一堆疊的理解，以及如何使用LangChain原語對每一層進行工具化。

第一層：代理迴圈 本質上，代理就是模型在迴圈中反覆呼叫工具直到任務完成。這就是LangChain的create_agent提供的功能。選擇任意模型，接入工具，你就擁有了一個可工作的代理迴圈。工具賦予代理在實際世界中採取行動的能力。

以我們內部的文件代理為例（本文後續以此為示例），在第一層迴圈中，它接收文件改進請求，模型規劃並起草更改，使用工具克隆倉庫、讀取檔案、編寫文件、發起拉取請求等。

第二層：驗證迴圈 代理迴圈能完成工作，但並非總能第一次就產生正確或一致的結果。當一致性至關重要時，通常需要在代理迴圈外包裹一個驗證迴圈，檢查輸出並在不達標時將結果連同反饋返回給模型。

驗證迴圈增加了一個“評分器”：它根據標準檢查代理輸出，如果失敗則連同反饋返回結果。評分器可以是確定性的，也可以是代理性的（以LLM作為評判者是一個經典例子）。RubricMiddleware處理了這種模式，或者你也可以透過create_agent的after_agent鉤子來實現。

在文件編寫示例中，評分器在每次嘗試後執行測試，檢查所有連結是否可解析、所有CI檢查是否透過、diff是否僅限於實際請求的範圍。無需人工稽核即可捕獲這類錯誤。

一個權衡：新增驗證會增加每次執行的延遲和成本。當質量比速度更重要時，這是值得的，大多數生產用例正是如此。

第三層：事件驅動迴圈 代理開發中最關鍵的部分之一是整合層：將代理連線到你的生態系統，使其能夠在後臺執行。

事件驅動迴圈將代理連線到你的生態系統。一個事件觸發（新文件落盤、定時觸發、webhook到達），代理即執行。代理不再是手動呼叫的工具，而是作為更大系統中持續執行的元件。

LangSmith Deployment支援觸發基礎設施，包括cron定時任務和webhook。OpenClaw中的“心跳”是cron的一個流行例子，它將代理變成了一個始終線上的主動助手。

我們的文件代理由Fleet（無程式碼代理構建器）驅動。Fleet的頻道和日程處理事件驅動和cron式觸發。我們使用一個頻道，每當在#docs-plz Slack頻道中傳送訊息時，就會觸發文件代理。

第四層：爬山迴圈 前三層實現了自動化。第四層（也是最關鍵的一層）實現了改進的自動化！

每次代理執行都會產生一條軌跡：模型做了什麼、呼叫了哪些工具、評分器反饋等。這些軌跡包含關於什麼有效、什麼無效的高價值訊號。爬山迴圈在這些軌跡上執行一個分析代理，並根據發現重寫框架，改進配置。這可能包括提示/工具調整或評分器調整。

在LangSmith中，你可以使用Engine（軌跡分析代理）來實現這第四層迴圈。

總結文件代理的類比，我們在文件代理軌跡上執行Engine以檢測任何問題。當多個軌跡指向一個潛在問題時，會提出一個問題單，要求修改有問題的提示或工具。

關鍵點在於，返回箭頭不僅僅迴圈回頂層——它深入到內部並直接更新代理迴圈。外迴圈的每次迭代都讓內迴圈更加有效。

展望未來：提示和工具配置是最簡單的改進物件，但並非唯一選擇。對於執行開源模型的團隊，爬山迴圈可以反饋到強化學習微調中，利用軌跡或評估結果作為訓練訊號來改進模型本身。輔助上下文（如記憶和檢索技能）也可以同樣方式改進。迴圈是模式；具體最佳化什麼由你決定。

人類監督與專業判斷 自動化並不意味著將人類排除在迴圈之外。在每一層，都有自然節點讓人類監督增加價值。自動化評分器可以檢查連結是否可解析；但需要人類才能注意到框架對受眾而言是錯誤的。這種來自上下文、經驗和品味的判斷正是人類稽核應有的位置。

某些專業判斷應編碼到提示/工具本身，但對於敏感操作（如金融交易、資料庫操作），即時的稽核是必不可少的。LangChain使得在每個迴圈中工具化這些接觸點變得簡單：在代理迴圈中，要求敏感操作前的人類輸入；在驗證迴圈中，人類可以充當敏感工作流的評分器；在應用迴圈中，輸出返回給終端使用者前可經人類批准；在爬山迴圈中，框架改進在部署前可經人類稽核。LangChain的所有開源框架都將“人在環中”作為一等原語。

綜合應用 下表總結了四個迴圈如何堆疊：

| 迴圈 | 作用 | 影響 | LangChain原語 | |------|------|------|----------------| | 1. 代理迴圈 | 模型反覆呼叫工具直至任務完成 | 自動化工作 | create_agent, 任何LangChain支援的模型 | | 2. 驗證迴圈 | 代理執行，輸出按標準評分，失敗時連同反饋重試 | 確保工作質量與正確性 | RubricMiddleware | | 3. 事件驅動迴圈 | 事件觸發代理執行，更新實際系統 | 大規模的自動化工作 | LangSmith Deployment的cron觸發/webhook，或Fleet頻道 | | 4. 爬山迴圈 | 生產軌跡輸入分析代理，改進框架配置 | 框架改進 | LangSmith Engine |

這就是“迴圈工程”或Swyx所說的“迴圈工藝”在實踐中的樣子。AI領導者如Steipete、Boris和Andrej都得出了相同的結論：代理的潛力在於你圍繞它們構建的迴圈。

我們考慮第一層和第二層已有一段時間。但重點應轉向第三層和第四層，透過將代理嵌入你的生態系統並持續根據你的標準改進，價值會複合增長。

Satya闡述了組織層面的意義：那些早期建立學習迴圈的公司，讓人類判斷和代幣資本協同增長，將建立起難以複製的優勢。

致謝：感謝Vivek、Mason、Harrison和Hunter的深思熟慮的審閱。

參考：deepagents quickstart, create_agent docs, rubric middleware, cron jobs/webhooks, LangSmith Engine, Fleet channels。