AWS Agentic RAG 與多智能體協作：Bedrock Agents 實踐

經歷過了基礎建設、SDK 介紹、RAG 架構設計，我們終於來到 2026 年 AWS AI 戰略的最核心：Agentic Cloud (智能體雲端)。

當 RAG (檢索增強生成) 走到了盡頭，我們發現這世界上有很多問題，不是「查一份 PDF 文件」就能解答的。

如果今天營運主管問系統：「昨天的網站當機事件，影響了哪些重要客戶？請整理出補償名單並自動發送道歉信草稿給我確認。」

用傳統的 RAG，你會覺得這神經病，根本做不到。 但在 Bedrock Agents 與 多智能體協作 (Multi-Agent Collaboration) 的世界裡，這也就是幾個 API 互相呼叫的事情。

什麼是 AWS Bedrock Agents？

在 Bedrock 裡，一個 Agent (智能體) 的靈魂組成如下：

1. Foundation Model (大腦)：通常選擇推理能力極強的 Nova 2 Pro 或是 Claude 4.5 Sonnet / 4.6 Opus。
2. Action Groups (工具箱)：我們用 OpenAPI 規格寫好定義檔，並綁定到 AWS Lambda 上。讓 Agent 知道它有能力去「呼叫資料庫 API」、「寄放 Email」或者是「重啟伺服器」。
3. Knowledge Bases (記憶庫)：幫 Agent 掛上我們上一篇提到的全託管 RAG 知識庫。

當你給 Agent 下達指令時，它會自己思考「現在這狀況我要先用哪個工具？」、「工具回傳的數據代表了什麼？」、「我接著該去 Knowledge Base 查退費條款嗎？」。這個思考過程，就是所謂的 Agentic 工作流 (ReAct Pattern)。

2025/2026 重磅升級：AgentCore 的三大超能力

在 2025 年底的這波更新中，AWS 把原本堪用的 Agents 大幅強化成了 AgentCore Runtime。這賦予了智能體極其關鍵的三個新特性：

1. 多智能體協作 (Multi-Agent Collaboration)

別以為一個 Agent 可以包山包海解決所有事。在真實世界中，叫一個模型同時搞懂「後端故障排除」和「公關道歉信怎麼寫」是很容易產生幻覺的。

Multi-Agent 的概念是：我們派出一位 Supervisor Agent (主管 Agent) 來聽用戶講話，然後主管把任務往下發包。

圖說：AWS Bedrock AgentCore 的 Supervisor 與 Worker 協作模式

如圖所示，主管 Agent 聽到「當機」，就會去叫底下的「資料庫查詢 Agent (Data Analyst)」寫 SQL 去查受災戶名單；查完名單，主管再把名單轉給「文案 Agent (Copywriter)」去對接 Knowledge Base 的過往聲明稿並寫出草稿。這就像一家真正的顧問公司在運作！

2. 情節記憶 (Episodic Memory)

過去每次呼叫 API 時，Agent 都是金魚腦，只要 Session 關掉它就全忘了。 藉由 Episodic Memory，Agent 會把之前跟你對話中「學習到的重要線索」存進自己的長期記憶中（也就是偷偷存在後台的一塊儲存區）。下次你再問類似問題時，它會自己說：「根據上次你說的...我們直接這樣處理吧。」讓它越來越像是你私人的資深助理。

3. Policy (自然語言政策保護網)

「讓 AI 自己去呼叫資料庫和寄信，這不會太危險嗎？」 AWS 提供了一套機制，讓你直接用英文寫下 Policy：

"Under no circumstances should this agent approve refunds exceeding $100 without a human-in-the-loop confirmation."

Bedrock AgentCore 會自己在執行所有的 Action 前套用這些 Policy，這是讓大企業願意把 Agent 上線的定心丸。

開發者的實務考量：Agentic RAG 設計

從 RAG 升級到 Agentic RAG，你的工作內容不再只是刻那些切塊與向量搜尋邏輯，而是轉向：

1. 寫非常乾淨的 OpenAPI Spec 讓 Agent 看得懂你的 Lambda 到底在幹嘛。
2. 設計清晰的職責邊界：哪個 Agent 負責算錢、哪個 Agent 負責查文檔，不要混淆。
3. 把 Amazon Q 納入你的開發流：透過 Amazon Q Developer 自動幫你寫好這些串接 AWS Lambda 的樣板程式碼，能省你半條命。