你的業務資料從來不住在同一個地方。
一個工單背後的資料迷宮
假設你的公司剛上線了一套 AI 客服系統。
一位大客戶發來工單：「我們上個季度在專案 Alpha 採購的伺服器，保固期還有多久？能否告知當時的合約條款和對應的技術支援聯絡人？」
聽起來是個再普通不過的問題。但你的技術負責人看到這條工單，沉默了三秒。
因為他知道，要回答這個問題，系統需要：
- 去 CRM 系統裡查這家客戶的客戶檔案和專案記錄
- 去 ERP/合約管理系統裡查專案 Alpha 的採購合約和保固條款
- 去 資產管理系統裡查那批伺服器的入庫日期和設備序號
- 去 HR 系統裡查客戶成功團隊的目前負責人
這四個系統，分屬不同的技術團隊維護，使用不同的資料庫，有不同的存取權限控制。
普通的 RAG 系統對這種情況束手無策。它只能回答：「抱歉，我找不到相關資訊。」
這就是 Agentic RAG 要解決的問題。
傳統 RAG：一次性的檢索員
先快速回顧一下 RAG 的運作原理。
RAG（檢索增強生成） 的核心思路很簡單：LLM 的訓練知識是靜態的，而企業資料是動態私有的。解決辦法是在生成答案之前，先去資料庫裡檢索相關文件片段，把它們塞進上下文，讓 LLM 基於這些材料來回答。
使用者問題 → [向量檢索] → 召回相關文件片段 → [LLM] → 生成回答
這個流程在單一知識庫、問題明確的場景下效果不錯。但它有兩個根本性的限制：
限制一：單次檢索，不迭代。 檢索一次，給 LLM 一次，完成。如果第一次檢索沒找到關鍵資訊，整個鏈路就斷了，LLM 只能靠猜或者說「我不知道」。
限制二：單一語料庫，不路由。 傳統 RAG 預設知識存在一個統一的向量資料庫裡。現實企業裡，資料分布在 CRM、ERP、Confluence、資料倉儲、私有文件庫……每個系統有自己的存取入口和權限邊界。
用一個比喻來說：傳統 RAG 是一個只能在圖書館一樓找書的圖書管理員，而你需要的書可能分布在四層樓，每層樓還有不同的入館許可。
Agentic RAG：會思考的檢索部門
Agentic RAG 的核心轉變是：把一次檢索變成一個有規劃、能迭代的檢索過程。
它不再是一個被動的查詢-回傳流程，而是一個由多個專職 Agent 協作的工作流，每個 Agent 負責不同的職責。
讓我們用前面那個客服工單的例子，拆解整個工作流是如何運轉的。
第一步：編排器拆解任務
使用者的問題被送到編排器（Orchestrator）。
編排器不直接去檢索。它先理解問題的結構：這個問題涉及幾個獨立的資訊需求？它們之間有沒有依賴關係？需要存取哪些資料來源？
對於我們的工單，編排器會拆解出：
- 子任務 A：從 CRM 查客戶「專案 Alpha」的基本資訊（客戶 ID、專案編號）
- 子任務 B：用專案編號，從合約系統查保固條款
- 子任務 C：用專案編號，從資產管理系統查設備序號和入庫日期
- 子任務 D：從 HR 系統查目前技術支援負責人
注意：子任務 B 和 C 依賴於子任務 A 的結果（需要先拿到專案編號）。子任務 D 可以並行執行。
這個依賴關係圖，就是規劃器（Planner Agent） 輸出的執行計畫。
第二步：查詢改寫，適配不同資料來源
每個資料來源的查詢方式不同。CRM 可能需要關鍵字檢索，合約系統可能需要結構化 SQL 查詢，向量資料庫需要語意檢索。
查詢改寫器（Query Rewriter） 負責把自然語言的子任務，翻譯成每個目標資料來源能理解的查詢形式：
- 對 CRM 向量庫：
"Alpha 專案 採購記錄 {客戶名}" - 對合約系統：
SELECT warranty_terms FROM contracts WHERE project_id = 'Alpha-XXX' - 對資產管理：
"Alpha專案 伺服器 入庫日期 序號"
第三步：並行檢索，跨越權限邊界
檢索擴散器（Search Fanout Agent） 同時向多個資料來源發起查詢。
這裡有個關鍵的工程問題：權限。
不同資料來源的存取權限不同。CRM 資料可能是業務團隊開放的，但 HR 資料只有管理員能存取，合約資料需要法務審批。Agentic RAG 框架需要在這一層維護「憑證池」——不同資料來源對應不同的存取權杖，且檢索時的權限不會超出目前使用者的授權範圍。
這不只是技術問題，也是合規問題：AI 不應該因為你用自然語言問了一個問題，就繞過了你本來不應該有的資料存取權限。
第四步：充足性判斷——這是最關鍵的創新
所有檢索結果彙整後，進入充足上下文檢驗器（Sufficient Context Agent）。
這個環節是 Agentic RAG 區別於傳統 RAG 最核心的設計：系統會主動判斷目前收集到的資訊是否足以回答原始問題，如果不夠，明確指出缺什麼，然後繼續檢索。
對我們的工單案例，檢驗器可能發現：
✅ 已找到：客戶檔案、專案編號、設備序號 ✅ 已找到：技術支援負責人 ❌ 缺失：合約系統回傳了檔案，但保固條款在附件 PDF 裡，向量檢索沒有命中
檢驗器輸出的不是「資訊不足」，而是精確的缺口描述：
「已取得專案編號 Alpha-2024-087，設備序號 SN-XXX-YYY-ZZZ，入庫日期 2024 年 3 月。合約主檔已檢索，但保固條款位於合約附件 B，需要針對『附件 B 保固期限』重新檢索合約附件庫。」
這條反饋驅動第二輪檢索：改寫器生成更精準的查詢，專門針對合約附件進行檢索。
這個「檢索 → 評估 → 再檢索」的迭代循環，會一直持續，直到充足性檢驗器判斷資訊已經完備，或者達到最大迭代次數限制。
第五步：綜合生成最終回答
所有資訊齊備後，綜合 Agent（Synthesis Agent） 把來自四個不同系統的碎片資訊，整合成一個連貫、準確、可引用來源的回答：
「專案 Alpha（編號 Alpha-2024-087）採購的 3 台伺服器（序號 SN-XXX-001 至 003），根據合約附件 B 第 4.2 條，保固期為自入庫日期（2024 年 3 月 15 日）起 36 個月，即至 2027 年 3 月 14 日到期。目前技術支援負責人為李明（分機 4521，[email protected]）。」
每一句話都有資料來源，都可追溯。
跨權限邊界：比技術更難的問題
值得單獨拿出來說的是權限邊界的處理。
真實企業裡，資料權限是一個多維度的問題：
| 維度 | 說明 | 範例 |
|---|---|---|
| 角色權限 | 不同角色能看到不同資料 | 業務能查合約摘要，但不能查原文 |
| 資料分級 | 同一資料庫內有不同密級 | 員工薪資 vs 員工通訊錄 |
| 時間權限 | 部分資料有時效性存取限制 | 稽核期間的財務資料唯讀 |
| 跨系統權限 | A 系統的資料不能出現在 B 系統的上下文裡 | GDPR 要求資料不跨境流動 |
Agentic RAG 框架需要在每次檢索呼叫時，都嚴格遵守這些權限規則，而不是在索引時統一授權。
這意味著架構上要實現查詢時權限校驗，而不是把所有資料統一向量化放進一個大庫這種簡單粗暴的做法。
用資料庫的比喻來說：傳統 RAG 像是把所有表 JOIN 成一張大表再給 LLM 用；Agentic RAG 像是為每次查詢動態生成帶權限過濾的 SQL。
實際場景中的三個關鍵決策點
當你在真實工程裡實現 Agentic RAG 時，有三個決策是繞不開的。
決策一：路由策略——靜態設定還是 LLM 路由？
靜態路由：根據查詢中的關鍵字或中繼資料，提前定義規則決定去哪個資料來源。速度快，可控，但應對開放式查詢能力弱。
LLM 路由：讓 LLM 理解查詢意圖後，動態決定路由到哪個資料來源。靈活，但每次路由都消耗 LLM 呼叫，增加延遲和成本。
決策二：迭代深度——什麼時候停下來？
系統可能陷入無限迭代——每輪檢索都覺得還缺點什麼，一直找下去。
工程上需要設定：
- 最大迭代輪數（通常 2-4 輪）
- 時間預算（超時直接用既有資訊回答）
- 降級策略（超出迭代限制時，用既有資訊回答並標注資訊可能不完整）
決策三：延遲 vs 準確率的權衡
Agentic RAG 比傳統 RAG 慢，這是無法迴避的事實。多輪 LLM 呼叫、並行檢索、充足性評估，每一步都有延遲成本。
| 方案 | 成本倍數 | 延遲倍數 | 適用場景 |
|---|---|---|---|
| 傳統 RAG | 1x | 1x | 簡單問答，單一知識庫 |
| Adaptive RAG | 1.5-2x | 1.2-2x | 查詢複雜度差異大的混合場景 |
| CRAG（糾錯 RAG） | 3-5x | 2-3x | 準確率要求高、可接受秒級延遲 |
| 完整 Agentic RAG | 5-10x | 3-6x | 複雜多跳、跨庫關聯、非同步場景 |
不是所有場景都需要完整的 Agentic RAG。
為查詢進行意圖分類，複雜查詢走 Agentic 流程，簡單查詢走傳統 RAG，可以把平均成本和延遲控制在合理範圍內。
寫在最後
我認為 Agentic RAG 的本質，就是把 RAG 中的檢索變成了可執行的策略：如果一次不夠，就繼續找，直到夠了為止。「夠了」這件事本身，也是系統來判斷的。
這個改變聽起來簡單，但它要求系統從「查詢-回應」的無狀態模式，轉變為「目標-規劃-執行-評估-迭代」的有狀態工作流。
這和 Agent 系統的通用挑戰是一樣的：狀態管理是核心難題。
如果你正在建構一個涉及多資料來源的企業 AI 系統，Agentic RAG 不只是一個檢索技術的升級，它要求你重新思考資料架構、權限設計和工作流編排。把這三件事想清楚了，比選擇哪個框架或哪家雲端廠商更重要。
參考資料
- Google Research, Unlocking dependable responses with Gemini Enterprise Agent Platform's Agentic RAG, June 2026
- Microsoft, Agentic Retrieval Overview -- Azure AI Search, 2026-04-01 GA
- Microsoft, What is a Knowledge Source? -- Azure AI Search
- Amazon Web Services, Knowledge Bases for Amazon Bedrock -- Multiple Data Sources, April 2024
- MarsDevs, Agentic RAG: The 2026 Production Guide（含各方案成本/延遲對比資料）
- Google Research, Deeper Insights into Retrieval-Augmented Generation: The Role of Sufficient Context