很多團隊一開始討論 AI Agent 導入，就會直接問工具：LangGraph、AutoGen、CrewAI、OpenAI Agents SDK、Mastra、Dify，到底該用哪一個？
這題可以問，但通常問太早。
更好的第一題是：你現在要解的問題，真的需要 agent 嗎？還是只是 RAG、workflow，或一個普通自動化腳本？
這個判斷很重要，因為 AI 導入失敗常常不是工具不夠強，而是任務類型分錯。把知識查詢做成多 agent 系統，會把成本和維護複雜度拉高；把長流程硬塞進 agent framework，會讓重試、審核、回滾和權限變得很難管；把需要模型判斷的模糊任務寫成死板流程，又會卡在例外情境。
所以在選工具前，先把需求分成三層：RAG、Workflow、Agent。
第一層：RAG 解的是「找得到、答得準」
如果你的問題主要是「資料散落、搜尋困難、回答不穩」，優先想 RAG，而不是 agent。
典型場景包括：
- 員工想問內部 SOP、產品規格、合約條款
- 客服想快速找到過去案例與標準回答
- 工程師想查系統文件、架構決策與 runbook
- 銷售想從資料庫找產業案例與報價規則
這類需求的核心不是模型能不能規劃下一步，而是資料能不能被正確切分、索引、召回、引用與更新。
如果資料源很混亂，先上 agent 只會讓模型更有自信地亂答。這時候真正該補的是文件 ingestion、chunking、metadata、權限同步、引用來源和答案評估。
RAG 適合的成功指標也很清楚：
- 找到正確資料的比例有沒有提高
- 答案是否附來源
- 使用者是否少問重複問題
- 人類審核時是否能快速追到原文
- 文件更新後，答案是否跟著更新
如果這些都還沒處理好，先別急著談多 agent 協作。
第二層：Workflow 解的是「事情要穩定跑完」
如果你的問題主要是「有一串步驟要穩定執行」，優先想 workflow。
典型場景包括：
- 每天固定抓資料、清理、產報表、寄摘要
- 新客戶註冊後，建立 CRM、開通帳號、寄 onboarding 信
- 發票、請款、合約審核需要跨多人批准
- 內容產線要排程、生成、檢查、發布、更新內鏈
- 系統監控觸發後，要通知、派工、追蹤狀態
這類需求真正難的不是「下一步要做什麼」，而是流程要能承受失敗。
API timeout 怎麼辦？同一個 webhook 重送會不會重複執行？人工審核隔兩天才回來，狀態放哪裡？第三步成功、第七步失敗，要補償還是重跑？這些都是 workflow engineering。
Agent 可以是 workflow 裡的一個步驟，例如：
- 幫客服工單分類
- 幫合約抽取風險點
- 幫報表產生摘要
- 幫內容草稿檢查是否缺少轉換入口
但整條流程最好仍由穩定的任務系統管理：排程、重試、狀態、審核、回滾、稽核與通知。
如果一條任務會跨分鐘、跨小時、跨人、跨系統，就不要只靠 agent framework 硬扛。讓模型負責判斷，讓 workflow 負責活著，通常比較接近正式環境。
第三層：Agent 解的是「需要根據上下文動態決策」
只有當任務需要模型根據上下文反覆判斷、選工具、調整策略時，agent 才真正有必要。
典型場景包括：
- 讀一個 GitHub issue，判斷要查哪些檔案、怎麼修、要跑哪些測試
- 分析一批客服對話，判斷哪些需要升級、哪些可直接回覆、哪些要補資料
- 研究一個市場題目，自己找資料、比較來源、整理觀點與風險
- 協助營運排查異常，根據觀測資料決定下一步查詢
- 在受限權限內操作多個工具，完成一個需要中途判斷的任務
Agent 的價值在於彈性，但成本也在這裡。
彈性代表它可能走不同路徑、呼叫不同工具、消耗不同 token、產生不同風險。這就是為什麼 agent 任務一定要先設邊界：
- 它可以讀哪些資料
- 可以呼叫哪些工具
- 哪些動作只能草稿，不能直接執行
- 什麼情況下要停下來問人
- 每次任務的成本和時間上限是多少
- 結果要怎麼被驗收
沒有這些邊界，agent 不是自動化，而是把不確定性包成一個看起來很聰明的黑盒。
一張簡單選型表
選工具前，可以先用這張表粗分：
| 需求 | 優先類型 | 判斷問題 |
|---|---|---|
| 讓使用者問內部文件 | RAG | 資料是否可索引、可引用、可更新？ |
| 固定時間產出摘要或報表 | Workflow | 步驟、重試、狀態和通知是否清楚？ |
| 客服工單自動分類 | Workflow + Agent step | 分類結果是否能快速驗收？ |
| Coding agent 修 bug | Agent | 是否有 repo 邊界、測試、回滾與人工 review？ |
| 內容產線自動發文 | Workflow + Agent step | 生成、審稿、發布、內鏈和追蹤是否分層？ |
| 企業知識問答加行動建議 | RAG + Agent | 答案來源與行動權限是否分開？ |
真正的系統常常不是三選一，而是組合。
例如內容站可以是：
- RAG：整理過去文章、關鍵字、內鏈與讀者問題
- Workflow：固定排程生成、檢查、發布、更新
- Agent：針對題目判斷角度、補缺口、做自我檢討
這樣的組合比「找一個最強 agent 框架包全部」更健康。
什麼情況下不要用 Agent
有幾種任務不該一開始就上 agent。
第一，規則已經很穩定。
如果任務只是把 A 欄位轉成 B 格式、固定查一個 API、固定寄一封信，普通程式或 workflow 就夠了。用 agent 只會多一層不可預期。
第二，資料品質太差。
如果文件過期、命名混亂、權限不明、來源沒有版本，agent 只會把資料問題放大。先整理資料，再談智能。
第三，失敗代價太高。
刪資料、改帳務、發正式信、調整廣告預算、合併大型 PR，這些可以讓 agent 協助準備，但初期不要讓它直接執行最後動作。
第四，沒有人願意驗收。
Agent 不是無人機器人。早期最重要的設計之一，是讓人類 reviewer 可以快速看懂它做了什麼、為什麼做、結果能不能接受。
如果驗收比重做還慢，這條任務還沒準備好。
這跟被動收入有什麼關係
如果目標是每月穩定 60,000，而不是只追 AI 熱點，內容產線就不能只寫「某某工具值得看嗎」。
工具文能帶來入口，但選型比較才會讓讀者靠近決策。
讀者真正會付費、訂閱、下載模板或找顧問，通常不是因為他知道某個框架很紅，而是因為他終於搞清楚：
- 我的問題屬於哪一類
- 我現在不該買什麼
- 第一個低風險實驗要怎麼做
- 需要哪些檢查清單和流程卡片
- 哪些部分可以交給現成工具，哪些需要客製
這種文章可以自然延伸成產品：
- AI 導入選型表
- RAG / Workflow / Agent 診斷問卷
- 第一條 agent 工作流卡片模板
- 內容產線自動化 SOP
- 小團隊 AI 導入顧問服務
也就是說，選型文不是為了多一篇文章，而是為了把流量接到可轉換的決策頁。
一個務實結論
AI Agent 導入不要從工具名單開始。
先問三個問題：
- 這是知識查詢問題嗎？如果是，先做 RAG。
- 這是穩定流程問題嗎？如果是，先做 workflow。
- 這是需要上下文動態決策的問題嗎？如果是，再引入 agent。
如果答案是混合型，就把系統拆開：RAG 管資料，workflow 管流程，agent 管判斷。
這樣做沒有「全部交給 AI」聽起來帥，但更接近可維護、可驗收、可轉換的內容資產與產品資產。對小團隊來說，這才是 AI 導入真正會長出收入的地方。