RAG、Workflow、Agent 差在哪？什麼時候真的需要 Agent？（2026 完整比較）

需求會議上大家都說「我們需要一個 Agent」，但你真的需要嗎？這篇帶你用三個問題拆需求，看懂 RAG、Workflow、Agent 各自該用在哪裡！

「我們需要一個 Agent。」這兩年，這句話很常出現在需求會議的第一頁。

熱度是真的。iThome 2026 年初調查 396 位台灣大型企業與機關的資訊主管，代理式 AI 的採用率從前一年的 17% 升到 32%，幾乎翻倍；RAG 架構從 26% 升到 35%。

名不副實也是真的。研究機構 Gartner 在 2025 年 6 月預測，到 2027 年底，超過 40% 的 agentic AI 專案會被取消，原因是成本不斷升高、商業價值不清楚，或風險控管不足。同一份新聞稿裡，Gartner 把一種現象叫做「agent washing」：把既有的 AI 助理、RPA（機器人流程自動化）、聊天機器人重新包裝成 agent，實際上沒有多少自主能力；他們估計，自稱做 agentic AI 的數千家廠商裡，真的算得上的大約只有 130 家。Gartner 資深分析師 Anushree Verma 說得更直接：今天很多被包裝成 agentic 的用途，根本不需要用 agent 來做。

這兩組數字是 Gartner 的預測與估算，並非實際普查統計。但它指出的現象，在需求會議上很容易看到：「Agent」這個詞被用來指查文件、跑固定流程、自主決策這三種完全不同的東西。名字一混，架構就跟著選錯。

快速回答 RAG 是回答前先查文件，補的是資料；Workflow 是由程式事先寫好步驟和分支；Agent 是由模型看完這一步的結果，再決定下一步。三者可以疊在同一個系統裡。Agent 多了選錯下一步的風險：假設每步做對 95%、彼此獨立，走 10 步全對只剩約 60%。所以能寫成流程的先寫成流程，只把寫不出路徑的那一段交給 Agent，半路加檢查；退款這類收不回來的動作，前面要有核准關卡。

評估是否需要 Agent 前先依序問三題：缺資料用 RAG、步驟明確用 Workflow、下一步看現場才交給 Agent

在討論要不要做 Agent 之前，建議先把需求改寫成三個問題：

1. 系統缺的是外部資料嗎？答案需要公司文件、最新規定或持續更新的知識。
2. 步驟能不能事先寫清楚？順序與分支能不能在上線前列出來。
3. 下一步是否要看現場結果才知道？做完這一步，才知道下一步該做什麼。

這三題有出處。Anthropic 在 2024 年 12 月發表的〈Building effective agents〉，整理了他們和客戶做過的 agent 專案，把這類系統統稱為 agentic systems，再在裡面畫一條架構上的線：Workflow 是由預先寫好的程式路徑，把模型和工具串起來；Agent 是由模型自己動態決定流程與要用哪個工具。同一篇文章把「檢索、工具、記憶」列為這兩者共用的基本零件，RAG 就是其中一種。第二題和第三題，問的就是這條線要畫在哪裡；第一題問的是要不要加檢索這個零件。

這三題要依序確認，彼此並非互斥的單選題。一個退款系統可以同時缺資料（要查退貨規定）、大部分步驟寫得出來（收單、審核、退款），只有一小段要看現場（物流狀態對不上時去查原因）。

缺資料：先處理資料怎麼進來

答案需要模型訓練時沒看過、或會一直更新的資訊，就先看 RAG（檢索增強生成）：回答前先找出相關的文件段落，放進模型的 context。2020 年提出 RAG 的 Lewis 等人，把「替答案交代出處」和「更新知識」列為只靠模型參數做不好的兩件事，這也是 RAG 到今天最主要的用途。

RAG 本身通常是一條固定流程：使用者提問、檢索、篩選、生成、檢查引用，每一步都能事先定義。用了向量資料庫，不代表系統有自主決策。它的關鍵在文件品質、版本、權限與引用：找錯文件，回答就跟著錯；找對文件卻漏了限制條款，也一樣不可靠。檢索為什麼會把語意很像的舊版排在前面，〈Token、Embedding、Context Window 是什麼？LLM 基礎一次搞懂（2026 完整懶人包）〉有一個可以自己跑的實驗。

步驟寫得出來：就把規則寫明

任務有穩定的順序和明確的分支，例如收資料、檢查必填欄位、生成草稿、交人核准、寄送，Workflow 往往比較合適。每一步的輸入、輸出、錯誤處理和負責人都能事先定義。模型可以負責其中需要讀懂文字的節點，整條流程仍由程式控制。

Anthropic 那篇文章列了五種常見的 Workflow 寫法：把任務拆成前後相接的幾步（prompt chaining）、先分類再分流（routing）、同時跑幾份再合併（parallelization）、由一個模型分派工作給其他模型（orchestrator-workers）、一個模型寫一個模型評（evaluator-optimizer）。介紹第一種寫法時，他們提到可以在任何中間步驟加上程式寫的檢查關卡（gate），確認流程還在軌道上。後面的模擬會看到，這道關卡值多少。

固定流程容易被低估，因為它看起來不夠聰明。但任務可預測、動作有後果、團隊需要稽核的時候，能重跑同一條路徑很有價值。重試幾次、失敗交給誰、何時停止，都能寫得清清楚楚。

下一步要看現場：才讓系統選路

Agent 適合下一個動作要依觀察而改變的局部任務。Anthropic 的說法是：問題是開放式的，很難或無法預測需要幾步，也沒辦法把路徑寫死。例如檢查程式庫時，先跑測試，依錯誤訊息決定讀哪個檔案、改哪個模組，再驗證。

Anthropic 用一張很簡單的迴圈圖說明 agent 和固定流程的差別：中間沒有預先寫好的箭頭，只有「行動、看回饋、再行動」，直到碰到停止條件。

同一篇文章也直接寫了代價：自主代表成本更高，也代表錯誤會累積。他們建議在沙箱裡大量測試，並設停止條件，例如最多跑幾輪。錯誤會累積到什麼程度，可以自己算。

錯誤連乘模擬：自由選路的 Agent 走 10 步正確率掉到 60.3%，每三步加檢查能拉回 94.2%

一個每步做對 95% 的 agent，聽起來很可靠。走 10 步呢？如果每一步獨立，全部做對的機率是 0.95 的 10 次方，大約 60%。這個算術很簡單，但它和實際系統還隔著幾件事：固定流程也會出錯嗎？加檢查能補回多少？檢查本身要付什麼代價？下面用模擬回答。

想驗證的三件事

1. 不加檢查的 agent，做對的比例隨步數快速下降，大致照 p 的 n 次方走。
2. 固定流程衰減得比較慢，因為「下一步做什麼」寫在程式裡，少了一種錯。
3. 每三步加一道檢查，能補回大部分，代價是多跑幾步。

跑出來如果不是這樣，上面的說法就要改。

前提假設

所以 agent 每一步做對的機率是 0.97 × 0.98，約 95%。每個步數各跑 10 萬次。這些數字都是假設，目的是看形狀，不代表任何真實系統的成功率。

思路與程式碼

程式只需要 numpy 和 pandas。先把上表寫成常數：

import numpy as np
import pandas as pd

RUNS = 100_000
STEPS = range(1, 31)
EXEC_OK = 0.98     # a step is carried out correctly
CHOOSE_OK = 0.97   # the agent picks the right next action; a workflow's next step is fixed in code
GATE_EVERY = 3     # a check after every 3 steps
CATCH = 0.90       # the check notices a bad segment
RETRIES = 2        # a caught segment is redone at most twice, then handed to a person

核心是一個函式：把 n 步切成幾段（有檢查時每段 3 步，沒有檢查就整段一起），每段抽亂數決定每一步對不對。有檢查的話，錯誤段有 90% 會被抓到並重做；沒被抓到的錯，就變成「靜默出錯」：系統回報完成，結果其實是錯的。同時記下實際跑了幾步，重做的步數也算進去。

def run(rng, n, step_ok, gated):
    done = np.ones(RUNS, bool)     # finished with no error so far
    silent = np.zeros(RUNS, bool)  # an error got through and nobody noticed
    human = np.zeros(RUNS, bool)   # handed to a person after the retries ran out
    used = np.zeros(RUNS)          # steps actually executed, retries included
    seg = GATE_EVERY if gated else n
    for start in range(0, n, seg):
        size = min(seg, n - start)
        pending = done.copy()
        for attempt in range(RETRIES + 1 if gated else 1):
            used += pending * size
            ok = (rng.random((RUNS, size)) < step_ok).all(axis=1)
            caught = ~ok & (rng.random(RUNS) < CATCH) if gated else np.zeros(RUNS, bool)
            silent |= pending & ~ok & ~caught
            pending &= caught
        human |= pending
        done &= ~silent & ~human
    return {"done": done.mean(), "silent": silent.mean(), "human": human.mean(), "steps_used": used.mean()}

最後跑四種設計：固定流程與 agent，各自有加檢查與不加檢查。沒有檢查的兩種有公式解（p 的 n 次方），順便拿來核對模擬對不對。

DESIGNS = {
    "固定流程": (EXEC_OK, False),
    "固定流程＋每三步驗證": (EXEC_OK, True),
    "Agent 自由選路": (CHOOSE_OK * EXEC_OK, False),
    "Agent＋每三步驗證": (CHOOSE_OK * EXEC_OK, True),
}
rng = np.random.default_rng(18)
res = pd.DataFrame([{"steps": n, "design": d, **run(rng, n, p, g)}
                    for n in STEPS for d, (p, g) in DESIGNS.items()])
print(f"closed form, 10 steps: workflow {EXEC_OK ** 10:.3f}, agent {(CHOOSE_OK * EXEC_OK) ** 10:.3f}")
print((100 * res.pivot(index="steps", columns="design", values="done")).round(1).loc[[1, 5, 10, 20, 30]])
print(res[res.steps == 10].set_index("design")[["done", "silent", "human", "steps_used"]].round(3))

在一般筆電上幾秒鐘就跑完。

結果

把四種設計在 1 到 30 步的完成率畫成曲線，先看最下面那條：

三件事都成立。第一，不加檢查的 agent 走 10 步，做對 60.3%，20 步剩 36.0%，和公式算的 0.603、0.363 一致。第二，固定流程在 10 步時是 81.7%，衰減慢一截，因為少了「選錯下一步」這種錯。第三，每三步加一道檢查，agent 回到 94.2%，固定流程回到 97.9%。

10 步時，錯誤到哪裡去了，比完成率更值得看：

不加檢查時，出錯的那四成全部是靜默出錯：系統說它做完了，沒有人知道錯在哪裡。加了檢查，大部分錯誤在半路就被抓回來重做，代價是平均多跑約一成的步數，也就是多一成的時間和 token。

這張表有一個容易被忽略的結論：加了檢查的 agent（94.2%），比沒加檢查的固定流程（81.7%）還可靠。選 Workflow 不會自動變安全；真正決定可靠度的，是錯誤有沒有在半路被看見。固定流程的優勢在於它容易加檢查：每一步的輸入輸出是事先定義的，要驗什麼很清楚。

這個模擬有兩個邊界要說清楚。一是真實的步驟並不獨立：一步錯了，後面常常錯得更離譜，所以實際衰減可能更快。研究上，Toby Ord 2025 年分析長任務的評測資料，發現 agent 的成功率可以用「每一分鐘都有固定機率失敗」來解釋，也就是隨任務長度呈指數下降，形狀和這裡一樣；Laban 等人 2025 年也發現，模型在多輪對話裡一旦走錯方向，常常就回不來。二是固定流程只處理得了你寫得出路徑的那些案件，寫不出來的，只能交給人或交給 agent。這正是第二題要問的事。

動態決策要有權限邊界：依動作「能否復原」分級，不可逆操作必須由人核准

Agent 可以在預先允許的工具裡選下一步，但它不應該自己擴大權限、寄信或刪資料。問題是，「哪些動作要人核准」要怎麼劃？

新加坡資訊通信媒體發展局（IMDA）在 2026 年 1 月於達沃斯世界經濟論壇發布〈Model AI Governance Framework for Agentic AI〉，5 月 20 日更新為 1.5 版，加入 60 多個組織的回饋和十多個實際部署的案例。這份框架評估 agent 的風險時，把「動作能不能復原」列為影響程度的因素之一，舉的例子很好懂：排會議的 agent 排錯了，改期就好；對外寄信的 agent 寄錯了，收不回來。框架建議在敏感動作執行前設下需要人核准的檢查點，舉例包括高風險的決定，以及不可逆的動作，例如永久刪除資料、對外發送訊息、付款。

框架收錄的一個 IT 工單 agent 案例，把這個想法做成三級：密碼重設這類低嚴重度、完全可逆的動作，由 agent 自動完成，每兩週稽核一次；中度嚴重、部分可逆的，agent 只能診斷和提出修法，要人核准才能動手；權限變更這類高嚴重度、難以復原的，agent 完全不能碰。這是一家企業的自訂做法，並非 IMDA 的強制法規，但它清楚示範了「依可逆程度分級」在實務上長什麼樣子。

OWASP 的 LLM 應用風險清單（2025 年版）把這類問題叫做 Excessive Agency（過度代理），病根有三種：給了太多功能、太多權限、太多自主。2025 年 12 月 OWASP 另外發布了 agentic 應用的十大風險，其中「工具誤用」與「連鎖失效」兩項，分別對應前面說的權限，與錯誤在自動化流程裡一路放大。Claude Code 這類寫程式的 agent 要怎麼設權限、出事時怎麼收回，可以看〈Claude Code 權限要怎麼設？一直按「允許」真的安全嗎？（2026 完整懶人包）〉；接上外部工具時交出了哪些權限，看〈MCP server 該不該裝？安裝前一定要做的權限檢查（2026 資安懶人包）〉。

實務架構拆解：主流程走 Workflow、查規定用 RAG，只有例外調查才交給 Agent

拿電商的退款申請當例子，走一次三個問題。

• 缺資料嗎？要查現行的退貨規定，而且規定會改版。這一段用 RAG。
• 步驟寫得出來嗎？收單、檢查欄位、判斷資格、核准、退款、通知，大部分寫得出來。這是主流程，用 Workflow。
• 下一步要看結果嗎？有一種情況寫不出來：物流顯示已送達，客人說沒收到；或訂單金額和付款紀錄對不上。要查物流、訂單、對話紀錄，查到什麼決定下一步查什麼。只有這一段交給 Agent。

這樣拆完，需求單上的「做一個退款 Agent」，實際要 Agent 做的只剩一小段，而且有步數上限、有交回的出口。

元件交接要附來源與版本

混合系統最常出問題的地方在交接。檢索交出一段文字，判斷節點不知道它是哪一版；Agent 回報「查完了」，主流程不知道它查了什麼、還缺什麼。每一個交接點都該寫清楚要附哪些東西：

這張表就是前面模擬裡「檢查」能做的前提：每一步交出來的東西有固定欄位，下一步才知道要驗什麼。

權限依可逆程度分級

同一個退款系統，依動作能不能收回來分級：

最後兩列的重點在「Agent 沒有這個工具」。在提示詞裡寫「不要退款」擋不住它；工具清單裡根本沒有退款這個選項，才擋得住。

成本也要寫進選型

三種元件的維護成本不同。固定流程的例外分支要有人維護；檢索要持續更新文件、量測找不找得到；Agent 需要記錄每一步、控管權限、設計出錯後怎麼收拾。選型可以分階段：先用最小的固定流程上線，看哪些案件一直掉進「寫不出路徑」的那一桶，再針對那一桶開放 Agent。Anthropic 的建議也是這個方向：先找最簡單的做法，簡單的做法不夠時，才加複雜度。

結論：能寫成流程的先寫成流程，只把寫不出路徑的那一段交給 Agent 並在半路加檢查

下一次需求單寫著「做一個 Agent」，先把它拆開問三題：哪幾步缺資料、哪幾步寫得出來、剩下哪一段真的要看現場才知道。剩下的那一段，通常比需求單上寫的小很多。

把那一段交給 Agent 時，替它設好三件事：能用哪些工具、最多跑幾步、每幾步檢查一次。模擬裡最大的差距，來自錯誤有沒有在半路被看見。

Agent 的價值在它能選路，代價是每一步的錯都會乘上去。

Agent 能動的範圍劃好之後，下一個問題是出事時收不收得回來，接著讀〈Claude Code 權限要怎麼設？一直按「允許」真的安全嗎？（2026 完整懶人包）〉。

常見問題

用了向量資料庫，就算是 Agent 嗎？

不算。RAG 通常是一條固定流程：提問、檢索、篩選、生成、檢查引用，每一步都能事先定義。有沒有自主決策，看的是下一步由程式決定還是由模型決定，跟用不用向量資料庫無關。

Workflow 一定比 Agent 安全嗎？

不一定。用一組示意模擬來看（假設每步執行做對 98%、Agent 選對下一步 97%），走 10 步時，沒加檢查的固定流程做對 81.7%，每三步加一道檢查的 Agent 做對 94.2%。決定可靠度的是錯誤有沒有在半路被看見；固定流程的優勢在於每一步的輸入輸出事先定義，比較容易加檢查。

哪些動作不該讓 Agent 自己做？

依能不能收回來分。只讀、可以改回的動作，Agent 可以自動做並留紀錄；寄信只讓它寫草稿；退款、修改權限、刪除資料這類收不回來的動作，工具清單裡就不要有。在提示詞寫「不要退款」擋不住它。

Gartner 為什麼預測四成 agentic AI 專案會被取消？

Gartner 在 2025 年 6 月的預測列了三個原因：成本不斷升高、商業價值不清楚、風險控管不足。同一份新聞稿也指出很多產品只是把既有的 AI 助理、機器人流程自動化（RPA）、聊天機器人重新包裝成 agent。數字是 Gartner 的預測和估計。

延伸閱讀

• Token、Embedding、Context Window 是什麼？LLM 基礎一次搞懂（2026 完整懶人包）
• MCP server 該不該裝？安裝前一定要做的權限檢查（2026 資安懶人包）
• 新模型出來了要不要換？AI 功能答錯時，換模型多半沒用（2026 除錯懶人包）
• AI Demo 很成功，為什麼一上線就出事？五條失敗路徑一次看懂（2026）

參考資料

市場與趨勢

• Gartner (2025-06-25). Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027（新聞稿；預測與估計為 Gartner 的說法）.
• 王宏仁, iThome (2026-05-15).〈【2026 CIO&CISO大調查】AI原生架構快速崛起，32%企業要用AI增強軟體工程〉；調查方法見〈各產業加碼投資AI達65%，醫療業卻逆勢縮手〉（2026-04-24，有效問卷 396 份）.

架構與方法

• Anthropic (2024-12-19). Building effective agents.
• Patrick Lewis et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020.

錯誤累積

• Toby Ord (2025). Is there a half-life for the success rates of AI agents?. arXiv.
• Thomas Kwa et al., METR (2025). Measuring AI Ability to Complete Long Software Tasks. arXiv.
• Philippe Laban et al. (2025). LLMs Get Lost In Multi-Turn Conversation. arXiv.

治理與風險

• Infocomm Media Development Authority, Singapore (2026-05-20). Updated Model AI Governance Framework for Agentic AI（factsheet）；框架全文 Version 1.5 PDF（2026-06-05 更新）；初版發布見 2026-01-22 新聞稿.
• OWASP GenAI Security Project (2025). LLM06:2025 Excessive Agency.
• OWASP GenAI Security Project (2025-12-09). OWASP Top 10 for Agentic Applications.