*圖 1｜Agent Loop 提供彈性；Workflow 將必要順序、重試與人工介入變成可觀察步驟*
## 第一個問題：流程順序不能只靠模型記得 有些企業操作有明確先後關係。例如必須先驗證資料，再建立任務；必須先取得使用者確認，才能寄信或寫入正式系統。這些不是「最好照順序做」，而是不能跳過的規則。 如果只在 Prompt 寫「請先驗證再執行」，模型大多數時候可能會照做，但真正需要可靠性的流程不能建立在「大多數時候」。 ## 第二個問題：失敗與重試需要明確位置 假設 Google Sheets 資料工具發生逾時（Timeout），系統應該重試幾次？如果檢索增強生成（RAG）的搜尋結果不足，是回到搜尋節點，還是重新問使用者？如果 Gemini 失敗，是否切換到備援模型（Fallback Model）？這些控制邏輯放在單一代理循環裡，會逐漸變成大量隱性規則。 一旦問題發生，也很難快速知道是路由錯誤、工具錯誤、模型錯誤，還是流程根本走錯分支。 ## 第三個問題：Human-in-the-loop 不適合藏在黑箱裡 當系統開始具備寫入能力，例如建立任務、修改資料或發送通知，高風險動作通常需要人工確認。這代表 Workflow 必須能在某個明確節點暫停，保存目前狀態，等使用者批准後再繼續。 這種「暫停再恢復」的需求，本身就已經超出單純 prompt-driven loop 最舒服的範圍。 ## 從自主代理（Agent）走回可控工作流程（Workflow） 這裡不是要否定 Agent，而是重新分工：**讓模型負責需要語意判斷的地方，讓程式負責不能出錯的流程。** 哪個工具最適合可以交給模型判斷，但「驗證失敗必須回到搜尋」、「高風險操作一定要人工批准」則應該寫成明確流程。 這也是為什麼下一篇 LangGraph 才真正有必要出場。它不是因為我們想再加一個新框架，而是目前的問題已經需要 State、Node 與 Edge 來把執行路徑畫清楚。 ## 延伸閱讀｜AgentExecutor 什麼時候開始不夠用？ 簡單任務下，ReAct 或 AgentExecutor 類型的單一 Agent loop 很有效率；問題通常出現在流程開始需要嚴格順序、人工暫停、狀態保存與可稽核的 Retry 路徑之後。幾個常見訊號包括：Prompt 裡開始出現大量「一定要先做 A 再做 B」、Agent 偶爾跳過必要步驟、流程中需要等人批准，以及除錯時只能重看整段模型輸出卻不知道真正失敗節點。 可以把架構演進理解成：**Agent loop 讓模型決定下一步，Graph Engineering 則重新決定哪些選擇可以交給模型、哪些流程必須由程式保證。** 這不是「LangGraph 一定比 AgentExecutor 好」，而是架構應該隨著任務的風險與複雜度成長。只有 2–3 個工具、沒有複雜分支的簡單 Agent，仍然沒有必要過早引入 Graph。