Loop Engineering：為什麼代理執行時是新的中介層

本文建立在 長時間執行代理模式：讓代理跨越數小時和數天保持存活 之上，後者映射了在數小時至數天範圍內出現的三種失敗模式（軌跡級偏差、壓縮侵蝕、自演化）以及捕獲它們的三層強制機制。這裡我們關注一個互補的發展：執行時層本身正在成為一種受管理的、可檢查的中介層——TrueFoundry 稱之為 loop engineering，發布於 2026 年 8 月 23 日。

關鍵要點

• LangGraph 擁有 3450 萬月度 PyPI 下載量和約 400 個企業部署，包括 Klarna、Uber 和 BlackRock — 模型周圍的執行時層是生產差異化積累的地方，而非模型選擇（uvik.net 生產比較）
• TrueFoundry 的 loop engineering 模式命名了五個從 prompt 轉向執行時的操作決策：審批檢查點、工作階段持久化、憑證隔離、上下文壓縮和按需能力載入 — 每個都是執行時屬性，而非 prompt 指令（TrueFoundry）
• 圖工程治理循環之間的邊：誰在行動、什麼跨越邊界、花費多少以及什麼證據留存 — 「評估節點，治理邊」原則使權限、資料流動和支出在拓撲層可執行（TrueFoundry）
• 單一代理在 64% 的基準測試任務中達到或超過多代理系統，成本僅為 2 倍 — 第一個架構決策是你是否需要多個代理，而循環是執行該決策的地方（Princeton NLP）

每個企業軟體時代都會發展出一個看似次要的層，直到操作決策在那裡積累。在客戶端-伺服器時代是應用伺服器。在雲端時代是容器編排器。在資料時代是管道排程器。對於 AI 代理，這個層有一個名字：包裹模型並將其轉變為可靠、長時間執行代理的執行時。僅 LangGraph 就有 3450 萬月度 PyPI 下載量和約 400 個企業部署——執行時不是次要層。TrueFoundry 的文件將 agent harness 明確定義為「圍繞 LLM 的執行時層，將其轉變為可靠的長時間執行代理。」本文映射了 loop engineering 模式——循環中介了什麼、為什麼它表現得像中介層以及圖工程治理層添加了什麼——並解釋了為什麼循環而非模型是 B2B 部署可靠性決定的地方。

問題：操作判斷存在於循環中，而非 prompt 中

Prompt 工程問的是對模型說什麼。上下文工程問的是給它看什麼。循環工程問的是系統在模型呼叫之間做什麼。這個問題屬於平台和安全工程的程度不亞於 prompt 作者，因為循環是機構操作決策變得可執行的地方。

當列出循環在每個回路中中介的內容時，這個區別變得具體。配置的工具呼叫是寫入生產系統還是暫停等待人工。工作階段狀態是否在重連和重啟後存活。生成的程式碼是否能看到 harness 憑證。長任務是否裁剪或卸載上下文。委託的子任務是否返回最終結果而非整個工作記錄。這些都無法僅靠模型行為可靠地強制執行。每一個都是組織可能希望一致應用的操作決策——這就是為什麼循環開始看起來像中介層。

翻譯表讓模式變得可見：

操作判斷	作為 prompt，它是...	在循環中，它變成...
寫入/破壞性操作等待人工	建議	強制檢查點
工作在重連/重啟後恢復	盡力而為	持久工作階段
憑證遠離執行中的程式碼	希望	架構式隔離
長任務管理上下文	無限歷史	受管理壓縮
能力按需到達	載荷膨脹	按需發現

循環決策與 prompt 指令的組合方式不同，因為執行時策略可以確定性地中介每一輪。改變壓縮發生的位置，使用該執行時的每個長任務都繼承了這一改變。添加審批邊界，一類風險操作現在需要明確授權而非僅依賴行為紀律。這個機制在中介層中很常見——定義一次控制，一致應用——它解釋了為什麼高階工程注意力正在轉向執行時。

這個模式直接連接到父文件記錄的三種失敗模式。基於壓縮的侵蝕（治理衰減）是循環問題：丟棄安全規則的摘要器存在於循環的上下文管理步驟中。軌跡級偏差是循環問題：逐操作閘控看到一系列通過的工具呼叫，而屬於循環的軌跡級監控看到了偏差。自演化是循環問題：編輯自身約束的代理在編輯循環管理的狀態。循環是所有三種失敗模式出現或被抑制的基底。

循環作為中介層：歷史解讀

跨技術時代的重複模式並不是中介層不可避免地成為開源。企業應用伺服器仍然包括與開放標準並存的主要專有產品。容器編排強烈收斂到開源 Kubernetes 周圍。工作流排程有影響力的開源系統（Apache Airflow）與託管替代方案並存。教訓更窄：一旦操作層變得戰略重要，企業就重視可檢查性、可移植性以及按自己條件執行或替換該層的能力。

時代	被讚頌的元件	決定結果的層	最終去向
客戶端-伺服器	資料庫	應用伺服器	混合：專有加開放標準
雲端	虛擬機	容器編排器	開源 Kubernetes 成為主導
資料	資料倉儲	管道排程器	開源排程器與託管服務共存
代理	模型	循環	正在決定中

代理循環可能遵循這條弧的一部分。開放的理由是具體的：原始碼可用性使實作級稽核成為可能（它不證明部署的二進位檔案是可信的，但使稽核成為可能）。支援自託管的執行時可以將執行層放在你的邊界內。可擴展的開放實作讓團隊更改壓縮、檢查點或整合行為而無需等待供應商路線圖。TrueFoundry 以 MIT 授權發布了其 harness TrueForge，支援本地和託管執行，將模型、MCP 伺服器和沙箱提供者視為連接的相依項。

戰略總結：執行你判斷的層應該是你可以判斷的層。

向你的循環提出什麼問題

如果循環是操作判斷所在的地方，採購問題是你的執行時是否可檢查和可移植。六個問題構成審問框架：

1. 工作能在重啟後存活嗎？工作階段持久化是執行時屬性。一個必須在每次中斷後從頭開始的代理不是長時間執行的代理——它是一個不斷被重啟的短命代理。
2. 程式碼執行環境能看到什麼？沙箱設計將 harness 憑證保持在模型觸達範圍之外。如果模型能讀取提供自身運算的 API 金鑰，隔離是 prompt 而非邊界。
3. 哪些操作為人工暫停——由執行時還是由希望？工具審批是強制檢查點和建議之間的區別。循環使其確定化。
4. 能力是按需載入還是在每輪都攜帶？延遲的工具和技能減少載荷膨脹。在每次回路中發送每個工具描述的循環浪費了代理推理所需的上下文視窗。
5. 執行可以從其痕跡重建嗎？僅追加的工作階段日誌模式——由 DeepSeek Harness 和 Meta Muse Code 獨立收斂——是重播、回滾和稽核的基底。父文章詳細記錄了這一收斂。
6. 如果你明天離開執行時供應商，你會失去什麼？真正的可移植性取決於資料格式、整合和操作實踐，而不僅僅是原始碼可用性。但實作無法檢查的執行時使深度稽核、自託管、修改和退出規劃更加困難。

從循環到圖：治理連接

具有持久循環的單一代理解決了執行問題。但生產系統很少執行單一代理。從代理到循環到圖的進階——在每一步添加不同的系統問題。TrueFoundry 的 From Agent to Loop to Graph 架構文章框架了升級：第一個可工作的代理引入能力和工具使用問題。持久循環添加狀態、恢復、上下文和審批關注。圖添加拓撲、協調和委託。自修改引發驗證、隔離和推廣問題。編排將組合系統轉變為操作問題。

關鍵區別是圖不替代循環——它組織循環和其他節點。生產圖可能包含代理、確定性函式、路由器、連接、佇列、人工檢查點、評估器、資料庫寫入和普通服務。只有代理節點需要自己的本地執行循環。圖擁有如下問題：下一個執行哪個節點、分支是否並行執行、哪個結果解鎖連接、一個分支失敗時會發生什麼以及哪條路徑需要人工檢查點。代理節點內的循環擁有一組不同的問題：代理看到什麼上下文、選擇哪個工具、如何處理觀察、何時重試以及本地工作何時完成。

第二個區別很重要：圖編排不是知識圖譜。知識圖譜結構化資訊——實體和關係。代理執行圖結構化執行——參與者、計算節點、轉換、相依和工作狀態。一個可以餵養另一個，但它們回答不同的問題。如果研究代理查詢知識圖譜然後委託驗證給第二個代理，知識圖譜是系統所知的一部分；執行圖描述系統所做之事。

TrueFoundry 用七個詞壓縮的治理原則：評估節點，治理邊。你仍然評估節點行為——模型評估不會消失。但僅靠評估無法使生產資料庫拒絕寫入、執行預算或要求在破壞性操作前審批。執行時、閘道和下游授權邊界在相關流量通過時執行這些約束。每個有後果的邊應回答五個問題：

問題	為什麼重要	可能的負責方
誰或什麼在行動？	歸因、最小權限、稽核	身分/註冊表
此節點能到達什麼？	發現不是授權	編排器+閘道+下游策略
什麼可以跨越邊？	資料最小化、prompt 注入防禦	應用策略+閘道護欄
可以花費或扇出多少？	圖乘以重試、分支和模型呼叫	編排器+閘道預算
什麼證據留存？	設計圖和執行圖會偏離	編排器+harness+記錄系統

框架格局：loop engineering 的位置

Loop engineering 是執行時級模式，不是框架選擇。截至 2026 年 8 月框架格局穩定：

• LangGraph — 3450 萬月度 PyPI 下載量，約 400 個企業部署包括 Klarna、Uber、LinkedIn、BlackRock 和 JPMorgan。有狀態代理的生產標準，具備檢查點、時間旅行除錯和原生 MCP 支援。LangSmith 用於可觀測性。
• CrewAI — 超過 44,600 GitHub 星標，平台上每月超過 10M 代理執行，約 60% 的 Fortune 500 在探索。簡單任務的 token 開銷比 LangGraph 高達 3 倍。
• Microsoft Agent Framework — 2026 年 4 月 3 日發布 1.0 GA，替代 AutoGen（現處於維護模式）。原生 MCP 支援；A2A 透過單獨介面卡（測試版）。
• OpenAI Agents SDK — 約 19,000 GitHub 星標，1030 萬月度下載量。
• Google ADK — Gemini 原生，A2A 優先。
• DeepSeek Harness — MIT 授權，超過 33K GitHub 星標，僅追加工作階段日誌。

Princeton NLP 的發現錨定了第一個架構決策：單一代理在 64% 的基準任務中達到或超過多代理系統，成本僅為 2 倍。在選擇多代理圖之前，先問任務是否值得協調開銷。循環是執行該決策的地方——一個工程良好的循環，具備檢查點/恢復、審批閘控和上下文管理，可以做多代理圖以更高成本和更多故障面才能做的工作。

Loop engineering 與所有這些框架相容。該模式關注執行時中介了什麼，而非你在哪個框架上建構。LangGraph 的檢查點和時間旅行除錯是 loop engineering 原語。DeepSeek Harness 的僅追加工作階段日誌是 loop engineering 原語。TrueForge 的工具審批和沙箱隔離是 loop engineering 原語。收斂就是訊號：當多個獨立執行時實現同一組操作控制時，這些控制就是結構要求，而非供應商選擇。

Loop engineering 模式——在模型和業務系統之間的執行循環中積累的執行時決策：

相關閱讀

• 長時間執行代理模式：讓代理跨越數小時和數天保持存活 — 父文章映射了三種失敗模式（軌跡級偏差、治理衰減、自演化）和三層強制機制（推理前、執行時、回滾），loop engineering 將其操作化
• Kill Switch by Design：代理治理架構 — 三層強制模型（推理前鉤子、執行時斷路器、事後回滾），循環在執行時層實現
• AI 代理可觀測性：你看不到的會傷害你 — 四層遙測棧，使 loop engineering 代理可查詢而非可 grep

一個執行 NetSuite 和 BigCommerce 的中型經銷商部署了一個代理，24/7 監控採購收件匣、檢查供應商目錄、應用商業規則並起草報價。該代理執行數小時而非數分鐘。Loop engineering 模式是讓它保持在邊界內的關鍵：在寫入 NetSuite 前暫停的審批檢查點、在供應商 API 逾時後恢復代理的工作階段持久化、將 NetSuite OAuth 權杖保持在模型上下文之外的憑證隔離，以及裁剪舊 RFQ 歷史而不丟棄治理定價的商業規則的上下文壓縮。建構是一個範圍明確的參與：RFQ 引擎、MCP 連接器模組、帶檢查點/恢復和審批閘控的循環執行時，以及治理報價代理、合規代理和 NetSuite 回寫之間邊的圖層。

一週發現。您獲得系統清單、工作流映射和固定範圍——whether or not you build with us.