該用工作流還是 AI Agent？先畫得出流程圖就不要用代理

想把某件事自動化之前，先問自己一個問題：下一步該做什麼，是不是事先就能寫清楚？能寫清楚，就用工作流（workflow，照固定步驟跑的流程）；寫不清楚、必須看前一步結果才能決定下一步，而且情況多到沒辦法一一列出，才需要真正的 AI Agent（會自己規劃、呼叫工具、判斷下一步的代理）。判斷錯了,代價通常是成本失控、結果不穩定、出錯時完全查不出原因。

自主性光譜：固定流程走到完整代理

把自動化方案排在一條線上，從左到右是彈性遞增、但可預測性遞減：

1. 固定流程：步驟寫死，每次都照同一順序跑。
2. 條件分支：遇到明確分類就走不同路徑，但每條路徑本身還是固定的。
3. 工具呼叫：流程中某幾步交給模型決定要不要呼叫工具，但整體順序仍是框好的。
4. 完整代理：模型自己決定要做幾步、用什麼工具、什麼時候算完成。

越往右，系統越能處理你沒想到的情況，但你也越難預測它會怎麼做、花多少錢、多久能跑完。這條光譜的核心取捨，就是彈性換可預測性。

判斷標準：能畫出流程圖，就別用代理

最實用的判斷準則很簡單：如果你能把整個任務畫成一張流程圖，箭頭清楚、每個分支都列得出來，那就該用工作流，不需要代理。只有當「下一步做什麼取決於前一步的結果,而且可能的組合多到窮舉不完」時，才真的需要讓模型自己決策。

Anthropic 在自家研究裡也是這樣分的：workflows 是預定義步驟的系統，agents 則是讓模型自主決定流程與工具使用的系統。他們的建議是找最簡單能解決問題的方案，只在必要時才增加複雜度——因為代理系統要付出的是延遲與成本的代價，必須拿任務表現去換。真正該用代理的情境，是那種開放式問題、步驟數沒辦法事先預測、也沒辦法硬寫出固定路徑的狀況，而且你對模型的判斷要有一定信任。

濫用代理的代價：一個真實的失敗案例

有一個文件處理的需求,本來流程很單純：分類 → 擷取資料 → 寫入資料庫，三個步驟寫死就能跑。但如果改成讓代理自己決定處理順序，同一份文件,呼叫次數可以從 4 次跳到 11 次，成本在不同次執行之間浮動到三倍,處理時間從 8 秒拉長到 40 秒不等。更麻煩的是，出錯的時候完全不知道為什麼——因為每次執行的路徑都不一樣，沒有固定的步驟可以對照著除錯。

這類案例說明了濫用代理最直接的代價：不是「比較貴」，而是「貴多少都說不清楚」；不是「偶爾出錯」，而是「出錯了也查不出原因」。對一個本來就能寫死的流程,這種不確定性沒有換到任何好處。

Agent 到底是什麼：三個組成部件

AI Agent 的定義,可以拆成三個部件：LLM（大型語言模型）、上下文（context window）、工具（tools）。

• LLM 是大腦：負責決策、理解使用者意圖、思考規劃、做判斷。
• 上下文是眼睛：接收環境觀察、使用者記憶、領域知識、自己目前的狀態與任務進度，讓模型知道「現在是什麼情況」。
• 工具是手腳：用來感知或改變外部世界的接口,比如呼叫 API、搜尋、執行程式碼。LLM 負責下指令，但不直接動手操作工具。

這三者合起來,才構成一個能「做事」的代理，而不只是能「聊天」的模型。更基礎的組件還包括檢索（retrieval）、工具使用與記憶（memory），這些是建構代理前就該有的基本能力。

Agent 跟 Chatbot 差在哪

多步驟與自主性,是兩者最關鍵的分界線。

項目	Chatbot	AI Agent
運作方式	一問一答	目標導向，自主執行多步驟
工具使用	通常不使用工具	可呼叫 API、搜尋、執行程式碼
記憶	僅限當次對話	有跨任務的持久記憶
錯誤處理	回傳錯誤訊息	自動重試或調整策略

Agent 之所以能做到這些，靠的是五個核心能力：感知、規劃、行動、記憶、反思。常見的架構分三種：ReAct（推理與行動交替進行，簡單直觀、容易追蹤，缺點是效率不高、需要多次 LLM 推理）、Plan-and-Execute（先訂出完整計畫再逐步執行，適合結構化的複雜任務）、Multi-Agent（多個代理協作分工）。想粗略感受一下門檻，一個最小的 ReAct 實作大約 30 行程式碼就能跑起來，但距離能上生產環境還差很多。

如果想更完整了解 Agent 跟 Chatbot、自動化流程的差異，可以參考 AI Agent 是什麼？和 Chatbot、自動化流程差在哪。

六種設計模式：從簡單排到複雜

實務上不是只有「工作流」跟「代理」兩個選項，中間還有幾種漸進的模式可以選,依複雜度排列：

模式	特徵	例子
提示鏈（Prompt Chaining）	步驟固定，每一步都需要 LLM 處理	翻譯 → 潤稿 → 檢查術語一致性
路由（Routing）	有明確分類，各類處理方式不同	客服分流：退貨／技術問題／帳務
平行化（Parallelization）	多個獨立子任務可以同時進行	同時檢查合約的五個風險面向
協調者-工作者（Orchestrator-Workers）	子任務數量不固定，但類型已知	依改寫後的查詢分別檢索 N 個子問題
評估者-最佳化者（Evaluator-Optimizer）	有明確品質標準可以自我檢查	生成程式碼 → 跑測試 → 依錯誤修正
自主代理（Autonomous Agents）	步驟數與順序無法預先決定	調查一件客訴的來龍去脈

前四種本質上都還是「工作流」，只是框架比純粹的固定流程更有彈性；自主代理的步驟數與順序無法預先決定，才是真正需要代理自主決策的情境。多數需求其實落在前四種就能解決，不需要跳到完全自主的代理。

台灣常見需求：該用哪一種？

需求類型	建議做法	理由
資料擷取（如文件分類、擷取、寫入資料庫）	固定流程	步驟可窮舉,順序不需要隨內容變動
客服	路由 + 固定流程，長尾案件才交代理	常見問題分類清楚，少數複雜客訴才需要自主調查
研究彙整	協調者-工作者	子問題數量依查詢而變,但類型已知
程式修改	評估者-最佳化者，或視任務交代理	有測試可當品質標準時適合自我修正迴圈；若涉及跨檔案、多步驟排查,像 Claude Code 讀程式碼、找 bug、寫修復、跑測試的全流程,才比較適合交給能自主決策的代理

程式修改這類需求如果決定要用代理，可以參考 Codex、Cursor、Claude Code 怎麼選 以及 Cursor 教學。

混合做法：工作流外殼 ＋ 局部代理

比較穩健的做法不是「全部工作流」或「全部代理」二選一,而是分三個階段逐步推進：

1. 階段一：全部寫死。流程固定，模型只做單點任務（比如單純的擷取或分類）。這個階段的重點是累積真實的使用分布，看清楚哪些情況是現有流程處理不了的。
2. 階段二：加路由。把累積下來的常見情況做分類，各類走各自固定的流程。這一層通常就能覆蓋大部分需求。
3. 階段三：對長尾開放代理。剩下少數無法歸類、流程也說不清楚的情況,才交給裝了工具、設了迭代上限的代理去處理，並且把過程完整記錄下來。

這樣做的好處是,代理只負責處理真正複雜、無法窮舉的那一小塊，大部分需求還是靠可預測、可除錯的工作流撐著。

不可逆動作，一定要交給人確認

代理要不要放更多自主權，不該由「技術上做不做得到」決定，而該由「出錯的代價」決定。一個簡單的檢查方式：如果代理判斷錯了，後果是「使用者再問一次就好」，那可以讓它多試；如果後果是「刪掉資料、寄錯信、下錯單」這種不可逆的動作,就該先做成工作流,並且把關鍵動作留給人工確認,不要讓模型自己拍板。

部署代理至少要守住幾個底線：關鍵動作要有人在迴圈裡確認（human-in-the-loop）、給代理的權限要降到最小、要設 token 與成本的上限、所有行動要留下完整日誌可追溯。安全檢查這類機制,應該寫在實際執行工具呼叫的程式碼裡，而不是寄望寫在提示詞裡就有用；同時要有 max_iterations（最大執行步數）與成本上限,否則一個迴圈寫錯,能燒掉一整個月的預算。

市場要的是會判斷的人

從職缺內容也能看出這個趨勢:在生成式 AI 相關職缺中，有近半數會提到「Agent、工作流程與工具串接」這類要求。換句話說,企業要找的不是只懂一邊的人，而是能判斷「這個需求該用工作流、還是該用代理」的人。能畫出流程圖的事,就別浪費代理的彈性去處理；真正需要自主決策的長尾情況,再把代理放進來，並且守住不可逆動作的底線——這才是能在生產環境裡站得住的自動化設計方式。

想從頭認識 Agent 與工作流基礎概念,可以參考 AI Agent 是什麼？和 Chatbot、自動化流程差在哪；如果自動化涉及大量提示詞設計,也可以搭配 提示詞怎麼寫？2026 推理模型時代 一起看。