RAG 找到了退款規則，然後呢？

使用者說：「昨天收到的耳機左耳沒聲音，我下週要出國，可以直接退款嗎？」

一套成熟的 RAG 可以找到正確政策，確認瑕疵品在到貨七日內能申請退貨，附上引用，並提醒使用者準備訂單編號與照片。答案完全正確，但使用者的退款仍然沒有完成。

接下來，系統還要辨識使用者身分、找到訂單、確認地區與付款方式、判斷是否需要照片、建立退貨單、等待核准、執行退款，再確認款項狀態。任何一步的結果，都可能改變下一步。

這就是我們從 RAG 走向 Agent 時，真正跨過的邊界。

RAG 把未知變成證據；
Agent 則必須把目標變成一連串受控、可觀察、可終止的狀態轉移。

這篇你會帶走

• Agent 的分界不在有沒有 Tool，而在誰決定下一步與何時停止
• 一個 Agent System 必須承擔的六項核心責任
• 什麼情況應該使用 Workflow，什麼情況才值得 Agent 化

圖 1：回答正確只代表資訊處理完成，不代表外部任務已完成。

Agent 的分界不是 Tool，而是控制權

今天許多產品只要接上 Function Calling、加一段 Loop，便開始稱自己為 Agent。但這些能力都不是充分條件。

一個固定程式可以要求模型填入退款 API 的 JSON 參數，再依預先寫好的條件執行；它有 Model、有 Tool，也可能因失敗而 Retry，控制流程仍然是一套 Workflow。

Anthropic 將 Workflow 描述為由預先定義的程式路徑協調模型與工具；Agent 則讓模型動態控制流程與工具使用。

OpenAI 的官方指南也把 Agent 的重點放在代表使用者獨立完成任務、管理 Workflow Execution、判斷任務何時完成，以及必要時停止或交還使用者。

不同框架的命名並不一致。

Google ADK 把 Sequential、Loop、Parallel 等固定控制流程也稱為 Workflow Agents；

Microsoft Agent Framework 甚至能把 Workflow 包成 Agent 介面。
因此不能看到類別名稱、Graph 或 Loop，就斷言模型擁有控制權。

比較實用的方式，是將系統放在一條光譜上：

這不是業界正式標準，而是用來檢查責任的操作性分類。真正該問的是：每一個 Decision Point，到底由 Code、Model、Human 還是 Environment 決定？

圖 2：RAG、Tool 與 Loop 是可重用能力，不是判定 Agent 的充分條件。

一個 Agent，多出六項不可逃避的責任

Agent 不是某一個元件，而是一個持續推進目標的控制系統。跨越不同框架後，可以將它收斂成六項責任：

可以把它寫成：

Agent System
  = Goal Contract
  + Observable State
  + Bounded Policy
  + Action Interface
  + Progress Evaluator
  + Termination Authority

Model 不必負責全部。Production Agent 通常讓模型處理高模糊、可逆、可評估的判斷，讓程式負責 Permission、Budget、不可逆副作用與最終狀態驗證，再由人類處理高風險例外。

這也解釋為什麼 Memory、Planning、Reflection、MCP 或 Multi-agent 都不是 Agent 的單一必要條件。它們只是完成上述責任時可能採用的元件。

圖 3：模型只是控制迴圈中的一位決策者，程式、人類與環境也共同承擔責任。

同一個退款問題，四種系統會走到不同終點

RAG：終點是有根據的回答

RAG 能解釋退款規則並引用政策，但不驗證訂單，也不改變外部狀態。它的成功條件是 Grounded Answer，不是 refund_completed。

Tool Calling：產生一個候選動作

模型可以選擇 lookup_order 或 create_return，並產生符合 Schema 的參數。但 Schema 合法不代表語意正確，Tool 回傳 200 OK 也不代表退款已完成。

Fixed Workflow：沿著已知程序執行

程式依序要求訂單號、檢查到貨日期、品類、付款方式、建立退貨單、等待核准，再執行退款。規則穩定且例外有限時，這通常比 Agent 更安全、更便宜，也更容易測試。

Agentic Workflow：在固定邊界內處理未知分支

身份驗證、退款資格、金額上限、人工批准與 Idempotency 仍由 Code 控制；模型只負責判斷該補問什麼、查哪份政策、是否需要照片，以及哪種例外應交給人工。

這才是 Agent 的真正價值：

不是繞過政策，而是在政策邊界內，根據最新 State 動態消除不確定性。

完全自主不一定比較好。只有當路徑難以事前枚舉、每一步結果確實會改變下一步，而且系統能安全限制與驗證行動時，提高自主程度才有意義。

圖 4：能力差異不只在步驟多寡，也在誰決定下一步，以及終點是回答還是真實狀態。

會 Loop，不代表知道何時停止

Agent 最常見的流程看起來很簡單：

Goal → Observe → Decide → Act
     → Update State → Evaluate → Continue or Stop

真正困難的是每次循環都可能改變外部世界。

假設 Agent 呼叫退款 API 後遇到 Timeout。它不知道請求沒有送達，還是退款成功但 Response 遺失。如果直接 Retry，可能產生第二筆退款；如果直接停止，又可能留下未完成的案件。

所以 Retry 不是單純的可靠性功能，而是另一個副作用決策。Agent 必須先查詢真實交易狀態，使用 Idempotency Key 對帳，再判斷重試、補償或轉人工。

同樣地，以下狀況都不能只靠模型自己說明：

• 反覆查詢同一筆訂單，卻沒有產生新資訊
• 已完成退款，仍繼續呼叫 Tool
• 尚未建立交易，卻回答「退款完成」
• 使用另一位客戶或前一次 Session 的 State
• 從處理退款逐漸偏離成推薦商品

因此 Agent Runtime 需要 No-progress Detector、Turn／Time／Cost Budget、Typed State 與 External Final-state Assertion。狀態也要分清楚：awaiting_user、awaiting_approval 是可由使用者回覆或批准事件喚醒的等待狀態；completed、handoff、cancelled、failed 才是這次執行的終止結果。若任務需要跨時間恢復，還必須保存 Checkpoint 與明確的 Resume Event。

ToolSandbox 將 Stateful Tool、隱含依賴與中間 Milestone 放進 Agent Evaluation；τ-bench 也以最終資料庫狀態，而非最後一句文字判斷客服任務。這些研究共同提醒：Agent 的成功存在於 Environment，不在它對自己行為的描述。

圖 5：會重複執行不等於能安全停止；副作用前必須先核對外部狀態。

什麼時候不要 Agent 化？

Agent 不是 Workflow 的升級版。每增加一個由模型決定的分支，系統便增加一個需要觀測、限制、評估與恢復的不確定點。

可以用六個問題判斷：

選擇原則很簡單：

1. 固定規則能完成，就使用 Workflow。
2. 只有局部模糊，就使用 Agentic Workflow，把 Model 放在有限 Decision Points。
3. 只有開放目標真的無法事前枚舉，而且每一步都能安全驗證，才考慮更高自主程度。

Anthropic 的工程建議 同樣主張從最簡單的方案開始，只在確實改善成果時增加複雜度。Agent 往往以更多 Latency 與 Cost 換取任務能力；自主性不是免費的品質提升。

Agent System Design，從分配控制權開始

前面幾天談 RAG 時，我們一路追蹤 Evidence 如何成為 Answer；進入 Agent 後，要追蹤的則是 Goal 如何經過多次 Decision、Tool 與 State Transition，最後改變外部世界。

成熟的 Agent Architecture 不會把所有事情交給模型，也不會因為害怕不確定性而把每個分支寫死。它會逐一標示：

• 哪些 Decision 由 Model 處理
• 哪些 Policy 必須由 Code 強制執行
• 哪些結果要由 Environment 證明
• 哪些動作一定需要 Human Approval
• 哪些條件必須立即停止或交接

Agent 的分界不在它會不會呼叫工具，而在執行期間，誰擁有下一步與停止的決策權。

Day 12 的目的不是鼓勵所有系統 Agent 化，而是先建立一張責任地圖。
接下來，我們才能逐一拆解 Tool Contract、State 與 Memory、Permission 與 Approval、Recovery，以及 Multi-agent Handoff。

AI 你怎麼看？

你目前最接近哪一種情況？

• A：固定 Workflow 已經足夠
• B：只有少數步驟需要模型動態判斷
• C：任務路徑真的無法事前枚舉

留下一個字母與情境，下一篇我們會從 Agent Loop、Planning 與 Stop Condition 開始。