AI 知識

Loop 與 Graph 的差別，在控制流複雜度

AI 知識｜Loop vs Graph｜2026-08-02

AI Agent 的架構討論很容易變成名詞競賽。今天是單一 Agent，明天是工作流，後天又變成 Graph、多 Agent 與動態編排。

但架構不是版本號。Graph 不是 Loop 的高級版，Loop 也沒有因為 Graph 出現就失效。真正的差別在於：系統的控制流是否已經複雜到需要把狀態、分支、並行與恢復機制明確建模。

如果一個簡單 Loop 已經能穩定完成任務，提早拆成大量節點與邊，通常只會增加理解、除錯與維護成本。

Loop 到底在做什麼

最常見的 Agent Loop 可以簡化成四個動作：

  1. 模型讀取目前任務與狀態。
  2. 模型決定下一個動作或工具。
  3. 系統執行工具並把結果交回模型。
  4. 模型判斷是否完成，否則進入下一輪。

這個結構看似簡單，但已能處理大量路徑無法事先完全寫死的工作。搜尋資料、修改程式、檢查錯誤與再次嘗試，都可以在同一個回饋迴圈內完成。

OpenAI 的 Agent 指南建議先把單一 Agent 的能力發揮到最大，因為多 Agent 與更複雜的編排會帶來額外 overhead。Anthropic 也建議從最簡單可行方案開始，只在任務表現確實需要時增加複雜度。

因此，以下情況通常不需要急著改成 Graph：

  • 主要由單一 Agent 處理。
  • 工具數量有限，選擇邏輯不複雜。
  • 任務路徑雖然動態，但輸入與完成條件清楚。
  • 不需要多條平行路徑同步資料。
  • 中斷後不必從精確步驟恢復。

Loop 真正需要補強的通常不是更多節點，而是清楚的停止條件、輪次上限、錯誤分類、狀態摘要與可驗證結果。

Graph 真正多了什麼

Graph 把工作拆成 nodes、edges 與 shared state。

Node 是一個可執行步驟，例如搜尋、分類、審查或人工批准；Edge 決定下一步去哪裡；State 則保存流程目前知道什麼、做過什麼，以及接下來需要哪些資料。

它的價值不是讓模型能力升級，而是讓控制流變得顯式。當流程開始出現多個分支、並行路徑與恢復需求時，Graph 可以讓系統更容易回答：

  • 現在在哪個節點？
  • 哪一個條件把流程送到這裡？
  • 哪些平行工作尚未完成？
  • 這個節點讀寫了哪些狀態？
  • 中斷後應該從哪個 checkpoint 繼續？

LangGraph 的文件也把 Graph API 定位在複雜決策樹、顯式共享狀態、平行路徑合併與團隊協作；相對地，標準 if／else、loop 與較線性的流程，可以繼續使用 Functional API。兩種 API 甚至能在同一個系統裡混用。

第一個升級訊號：分支開始長出分支

單一條件判斷不需要 Graph。一段清楚的 if／else 已經足夠。

問題出現在條件開始層層堆疊：分類結果決定工具，工具結果又決定是否重試，不同錯誤還要進入不同補償路徑，最後可能再回到前面某一步。

當開發者已經很難只靠閱讀程序碼回答「所有可能路徑有哪些」，把決策點建成顯式節點與條件邊，才開始產生實際價值。

第二個升級訊號：多個節點共享狀態

很多簡單 Agent 把聊天紀錄同時當成工作記憶、資料庫與交接文件。流程短時看不出問題，一旦節點增加，就容易出現某一步找不到資料、讀到舊版本，或無法確認哪個結果才是正式狀態。

如果搜尋、分析、驗證與發布都需要共同讀寫同一份候選資料，顯式 state schema 會比把所有資訊塞進對話更可靠。

Graph 並不會自動修好錯誤狀態，但它能讓狀態的擁有者、更新規則與流向更容易被檢查。

第三個升級訊號：平行工作必須合併

當多項工作彼此獨立時，平行處理可以縮短等待時間。例如同時查多個資料源、對同一候選執行多種檢查，最後再彙總結果。

真正困難的不是把工作同時啟動，而是知道何時全部完成、如何處理部分失敗，以及哪一版結果可以進入下一步。

Graph 能把 fan-out、等待條件與 fan-in 明確表示出來。若流程只有一條依序執行的路徑，這套能力則可能只是額外負擔。

第四個升級訊號：需要暫停、批准與恢復

會觸碰正式資料、付款、外部發布或高風險操作的 Agent，通常不能一路自動跑到底。流程必須在特定節點暫停，保存狀態，等待人工決策後再繼續。

同樣地，長時間任務如果失敗後只能全部重跑，成本與風險都會上升。Checkpointer 能保存 thread 的 graph state，讓流程在中斷後恢復，也支援 human-in-the-loop 與 fault tolerance。

當「從哪裡繼續」本身成為重要需求，Graph 與 persistence 才不只是架構美學，而是可恢復性的基礎。

Graph 解決不了的三件事

Graph 能管理控制流，但它無法替系統補上錯誤的目標、低品質工具與缺失的驗收標準。

如果任務一開始就沒有清楚定義完成條件，Graph 只會讓每個節點都用自己的方式猜測。如果工具回傳資料不可信，更多節點只會更快傳播錯誤。如果沒有 trace、測試或平台讀回，再漂亮的流程圖也無法證明結果正確。

因此，升級前應先確認三件事：

  1. 目前 Loop 的失敗真的是控制流問題，而不是 Prompt、工具或資料問題。
  2. 新增 Graph 後，有明確的狀態、路由或恢復需求會被解決。
  3. 新架構的正確性與成本有辦法被驗證。

最實用的選擇：讓複雜度跟著需求長

架構可以漸進演化。先用一個 Agent 加工具完成最小流程，再把真的變複雜的部分抽成節點；保留簡單程序式控制流，只在需要共享狀態、複雜分支、平行合併或中斷恢復的位置使用 Graph。

這比一開始就把所有事情畫成網狀流程更容易維護，也更容易知道新增的複雜度到底換來了什麼。

真正成熟的 Agent 系統，不是節點最多的系統，而是能清楚解釋每一層複雜度為什麼存在的系統。

查證摘要

  • Anthropic 建議從最簡單可行方案開始，只有必要時才提高 agentic system 複雜度。
  • OpenAI 建議先最大化單一 Agent 的能力，更多 Agent 會增加複雜度與 overhead。
  • LangGraph 將 Graph API 適用情境列為複雜分支、顯式共享狀態、平行路徑合併與協作視覺化。
  • LangGraph Functional API 仍適用於標準 loop、程序式控制流與較簡單的線性工作流。
  • Checkpointer 能保存 graph state，支援中斷恢復、human-in-the-loop 與 fault tolerance。

參考資料

回文章列表