做到這裡，Data Machi 的 Agent 已經可以選工具、保留部分 Memory，也能在資訊不足時 Clarify、Re-query 或進行 Verification。能力看起來越來越完整，但同時也會出現另一個問題：系統的行為開始變得越來越難預測。

前面介紹 ReAct 時，我們讓 Agent 在每一次 Tool 執行後重新觀察結果，再決定下一步。這種動態決策確實帶來彈性，但如果所有判斷都藏在同一個 Agent Loop 裡，隨著 Tool、Retry、Memory、Verification、Clarification 與人工確認逐漸增加，開發者很快就會發現：明明每一項功能都合理，整體流程卻變得很難理解。

可以先把兩種架構簡單比較：

兩者並不是誰一定比較好，而是隨著任務風險與複雜度提高，我們開始需要把某些原本藏在 Agent Loop 裡的規則「拉出來」，變成程式可以明確控制的流程。

第一個問題：流程順序不能只靠模型記得

有些企業流程不是「最好按照這個順序」，而是一定要按照這個順序。例如「取得資料 → 驗證資料 → 確認結果 → 建立正式任務」，又或者「準備 Email → 人工確認 → 寄出 Email」。

如果只在 System Prompt 裡寫「請務必先驗證資料，再建立任務。」，模型大多數時候可能會照做，但企業系統真正需要的是：這個步驟在技術上就不能被跳過。 兩者差異很大。Prompt 比較像告訴同事「記得寄信前先讓我確認。」，Workflow 則像在系統裡直接設定：

沒有 approval = true
→ send_email() 無法被執行

後者才是真正的流程控制。

「模型大多會遵守」和「系統保證」不是同一件事

假設我們允許 Agent 使用 query_data、verify_result 和 create_task 三個 Tool。如果全部交給模型決定，理論上它應該依序執行 query_data → verify_result → create_task。但 Agent 也可能因為 Prompt 理解、Context 太長或模型決策不同，跳過中間那一步，直接從 query_data 走到 create_task。

如果 create_task 只是建立測試 Todo，問題可能不大；但如果未來換成 update_database、send_email、publish_report 或 approve_request，跳過 Verification 就可能產生真正的業務風險。因此可以把設計原則整理成：

需要語意判斷的地方交給模型；不能被跳過的規則交給程式。

這會是後面 LangGraph 很重要的架構思想。

第二個問題：失敗與 Retry 需要有明確位置

前面我們已經遇到過很多不同失敗：Timeout、Permission Denied、No Result、Missing Input 和 Model Failure。但當整段流程都存在同一個 Agent Loop 中時，「失敗之後去哪裡」很容易變成 Prompt 裡的一堆自然語言規則。例如：

如果 Google Sheets Timeout，請再試一次；如果仍然失敗就告訴使用者。如果 RAG 搜尋沒有足夠結果，請重新搜尋；如果還是找不到就詢問使用者。如果 Gemini 發生錯誤，改用另一個模型……

當規則增加之後，Prompt 很快會變成：

如果 A → B
但 C 時 → D
如果 D 失敗 → E
如果 E 又符合 F → 回到 B
除非 G → H

這時即使人類自己重新閱讀 Prompt，也未必能快速回答：「這個錯誤最後到底會走去哪裡？」

Retry 不是只有「再試一次」

不同錯誤需要完全不同的處理方式。例如 Google Sheets Tool 回 Timeout，合理策略可能是 Retry 1 次，仍然 Timeout 就停止，改給 Partial Answer。但如果回傳 Permission Denied，就不應該無限 Retry，因為再呼叫十次通常也不會突然取得權限，合理流程是停止 Retry，回報權限問題。如果是 Missing Input，可能要進入 Clarification；如果是 No Result，則可能調整搜尋 Query 之後 Search Again。

因此錯誤處理本身其實就是一張 Workflow。可以整理成：

如果這些路徑全部只藏在 Agent Prompt 裡，流程會越來越難追蹤。

第三個問題：除錯時很難知道真正是哪一步錯了

假設使用者問「找出最近問題最大的市場，確認定義，再建立改善任務。」，最後系統建立了一個錯誤任務。如果所有事情都在同一個 Agent Loop 裡，開發者可能只能看到：

Agent chose Tool A
Agent got result
Agent chose Tool B
Agent chose Tool C
Final output...

但真正想知道的是：

Step 1：Data Query 正確嗎？
Step 2：Top Market 判斷正確嗎？
Step 3：Document Search 找對定義嗎？
Step 4：Verification 通過嗎？
Step 5：Task Payload 正確嗎？
Step 6：為什麼最後允許建立 Task？

這就是 Observability（可觀察性） 的問題。當一條 Workflow 有明確 Node 時，就比較容易記錄：

Node: query_data
Status: SUCCESS

Node: verify_metric
Status: SUCCESS

Node: search_definition
Status: SUCCESS

Node: verify_answer
Status: FAILED

看到這裡就知道，流程根本不應該繼續進到 Action。相較之下，如果全部都只是一個長 Agent Loop，就需要重新翻整段 Trace 才能還原真正的決策路徑。

第四個問題：Human-in-the-loop 很難只是 Prompt 裡的一句話

當 Data Machi 還只有 Read Tool 時，Agent 做錯選擇的風險相對低。例如查錯一份文件，最多是回答錯誤。但當系統開始加入 Action Tool，例如 create_task、update_status、send_email 或 write_database，就會出現新的需求：某些操作必須先經過人工確認。

例如 Agent 準備：

Action:
Send Email

Recipient:
project-team@example.com

Content:
Project delay notification...

我們可能希望使用者先看到「即將寄出 Email，是否確認？」，只有使用者選擇 Approve 才能真正執行。這代表 Workflow 必須支援：

準備 Action → Pause → 等待使用者 → Approve / Reject → Resume

這不是普通 Agent Loop 最自然的使用方式，因為執行可能不是幾秒鐘後繼續，而是幾分鐘、幾小時甚至隔天才得到確認。

Pause 代表系統必須保存 State

假設流程停在「Task Draft 已建立，等待使用者確認」，使用者半小時後按下「確認建立。」。系統必須知道：當時是哪一個 Task？來源是什麼？使用者確認的是哪個版本？前面有哪些 Tool Result？Workflow 現在停在哪一個 Step？

因此 Human-in-the-loop 很自然會帶出另一個需求：State Persistence（狀態保存）。 例如：

workflow_id = wf_001
current_node = human_approval
pending_action = create_task
task_payload = {...}
verification_status = passed

等使用者確認後再從這個狀態繼續。這種「Pause → 保存 → Resume」的能力，就是為什麼後面會需要更明確的 Workflow Engine，而不是只依賴一段 Agent Prompt。

第五個問題：Memory、Verification 和 Retry 開始互相影響

目前 Data Machi 已經有 Tool Selection、Memory、Re-query、Clarification、Verification、Retry 和 Partial Success。每一個功能單獨看都不複雜，但組合後很快就會產生大量分支。例如：

使用者問題
    ↓
Memory 有舊結果？
    ↓
資料還新鮮？
    ↓
需要 Re-query？
    ↓
Tool 執行成功？
    ↓
Verification 通過？
    ↓
需要另一個 Tool？
    ↓
是否達到 Max Steps？
    ↓
需要 Clarification？

如果再加入 Action，還要多問一句「需要人工確認？」，流程會變得更複雜。

這也是很多 Agent Prototype 在 Demo 階段看起來很好，但真正加入企業規則後開始難以維護的原因：不是模型突然變差，而是控制邏輯變多了，卻仍然全部藏在同一個自由循環裡。

Agent Loop 的優勢其實仍然存在

講到這裡，不代表 Agent Loop 本身不好。如果任務只是 2–3 個 Tool 加上簡單搜尋，沒有高風險 Action，也沒有複雜 Retry，ReAct 這類單一 Agent Loop（例如 LangChain 早期的 AgentExecutor）其實非常方便。

例如「幫我找出公司政策裡和差旅住宿相關的規則。」，Agent 可以自己嘗試 Search Tool、修改 Query、再產生答案。這種任務如果硬畫成十幾個 Node，反而可能過度工程化。

因此真正的問題不是「Agent Loop 好不好？」，而是：

這個任務是否已經複雜到需要更明確的流程控制？

什麼時候 Agent Loop 開始不夠用？

可以觀察幾個很實用的訊號。

第一個訊號是 Prompt 開始大量出現「一定要先 A，再 B。」這類句子，例如一定要先查資料、一定要驗證、驗證失敗不能回答、寄信前一定要取得確認。這些規則如果越來越多，通常代表它們應該離開 Prompt，進入 Workflow。

第二個訊號是 Agent 偶爾會跳過必要步驟。例如十次裡九次都先 Verification，但有一次直接進到 Action。對高風險場景來說，「90% 會遵守」通常不夠。

第三個訊號是開始需要 Pause / Resume，也就是 Human-in-the-loop。第四個訊號是 Retry 路徑變多，而且不同錯誤有不同處理方式。第五個訊號是除錯時已經很難回答「這個 Request 到底經過了哪些節點？」

當這些現象開始出現，就代表架構可能需要從單純 Agent Loop 往 Graph Workflow 演進。

從 Agent Engineering 走向 Graph Engineering

可以把前面的 Agent 想成「根據目前情況，自己決定下一步」。而 Graph Engineering 更像是先替 Workflow 回答三個問題：哪些路可以走？哪些地方由模型決定？哪些地方由程式保證？兩者最大的差別不是「有沒有 LLM」，而是決策責任重新分配。

例如「理解使用者問題」需要語意理解，很適合交給 LLM；「驗證成功後才能進入 Action」這種規則則不需要讓模型判斷，交給程式 Edge 就好。再例如「查不到文件後，應該改 Query 還是 Clarify？」可以保留彈性，交給 LLM 或 Coordinator；但「最多 Retry 2 次」更適合使用 deterministic rule，由程式 Counter 控制。

因此可以整理成一個很重要的分工：

這就是 Graph Engineering 最核心的價值：不是消滅 Agent，而是替 Agent 畫出可以安全活動的道路。

自由和控制不是二選一

企業 Agent 並不是只能在「完全固定 Workflow」和「完全自由 Agent」兩種極端中選擇，真正實用的架構通常是兩者混合。例如：

其中「選哪個 Tool」仍然可以讓 Agent 自主決定，但「Verification Failed 就不允許 Execute」則由 Workflow 強制保證。因此我們不是把 Agent「關起來」，而是讓它：

在需要彈性的地方自主，在不能出錯的地方受到明確控制。

實務案例｜寄信前一定要經過 Verification 與 Approval

假設未來 Data Machi 可以自動產生異常通知 Email。使用者說：「如果香港的 Conversion Rate 下降超過 10%，幫我通知團隊。」如果全部交給 Agent Loop，它可能需要自行完成「查數據 → 計算下降幅度 → 判斷是否超過 10% → 產生 Email → 寄信」。企業版本可能更適合寫成：

這條流程裡 LLM 仍然可以負責理解異常原因、整理 Email 內容，但數字計算、Threshold、Verification Gate 和 Approval Gate 都由 Workflow 控制。這就是「Agent + Workflow」真正的混合設計。

為什麼這時候 LangGraph 才有必要？

如果 Day 06 就直接介紹 LangGraph，可能會很容易變成「因為大家都在用這個框架，所以我們也來學。」但走到 Day 23，問題其實已經自然出現了。目前我們需要處理 State、Tool Selection、Conditional Routing、Retry、Verification、Clarification、Memory、Human Approval、Partial Success 和 Pause / Resume，這些能力已經不是單一 Prompt 最適合管理的形式。

我們需要一種方式，把流程拆成幾個明確概念：State 是目前系統知道什麼，Node 是現在執行什麼，Edge 是下一步去哪裡。例如：

[Coordinator]
      ↓
[Tool]
      ↓
[Verification]
      ↓
   Passed?
   /     \
 Yes     No
 ↓        ↓
Answer   Retry

一旦流程被畫出來，就能開始回答：

• 哪個 Node 失敗？
• 哪個 Edge 被走過？
• State 現在是什麼？
• Retry 幾次了？
• 為什麼停在這裡？
• 哪裡需要人工批准？

這才是 LangGraph 真正要解決的問題。

不要因為 LangGraph 很熱門，就把所有流程 Graph 化

同樣地，Graph 也不是越多越好。如果目前應用只有「User → RAG → Answer」，根本沒有必要為了使用 LangGraph，硬拆成十個 Node。如果只需要「User → Agent → 2 個 Tool → Answer」，而且沒有 Human Approval、複雜 Retry 或高風險 Action，簡單 Agent Loop 可能仍然最合適。

架構應該跟著問題長大，而不是先選框架，再讓問題配合框架。可以把演進理解成五層：簡單問題用 Direct LLM，需要外部能力時加上 Tool Use，需要多步驟時用 Workflow，需要動態決策時才用 Agent，需要可控的動態流程時才走到 Graph-based Agent Workflow。不是每個階段都必須走到最後一層。

實務踩坑｜不要把流程規則全部藏在 Prompt

如果 System Prompt 開始出現大量這樣的內容：

先做 A
如果失敗做 B
如果還失敗就 C
除非 D
在 E 之前一定要 F
最多 Retry 兩次
沒有 Approval 不能 G

這通常就是一個訊號：這些內容有一部分已經不是 Prompt Instruction，而是 Workflow Specification。

Prompt 更適合處理角色、語意判斷、回答方式與 Tool 選擇原則；Workflow 則適合處理順序、分支、Retry、Stop、Approval 與 Failure Path。把兩者分開後，不只 Agent 比較容易理解，開發者也更容易測試整套系統。

從「Agent 有多聰明」改成「系統有多可控」

到 Day 23，可以重新看整個 Data Machi 的演進。一開始我們關心的是「LLM 能不能回答？」，後來變成「能不能查企業資料？」，接著是「能不能自己選 Tool？」，再來是「能不能根據結果調整下一步？」。到了現在，真正重要的問題已經開始變成：

• 它做錯時能不能知道錯在哪？
• 哪些步驟不能跳過？
• 什麼時候必須停止？
• 高風險 Action 能不能被攔住？
• 流程能不能被重現與稽核？

這也是企業 Agent 很關鍵的一次架構轉變：從追求「自主性」，開始轉向追求「可控的自主性」。

今天的重點：
Agent 越自主，不代表系統就應該越黑箱。當流程開始出現必要順序、Verification、Retry、Human-in-the-loop、Pause / Resume 與高風險 Action 時，就不應只依靠 Prompt 要求模型「記得遵守」。更可靠的做法，是讓模型處理需要語意判斷的地方，讓 Workflow 用程式保證不能被跳過的規則。企業真正需要的是：該自由的地方自由，該控制的地方明確控制。

下一篇，我們會正式進入 LangGraph，用 State、Node 與 Edge 三個核心概念，把目前散落在 Agent Loop 裡的 Tool Selection、Verification、Retry、Clarification 與 Human Approval，重新畫成一張可以觀察、測試與控制的 Workflow。

我們下集見囉！