企業級 GenAI 落地核心：Bedrock 平台與 Agent 實戰

很多團隊接觸 Bedrock 的第一步，是打一次 API 叫模型寫段文案，然後說「這跟直接接別家 API 有什麼不同」。這個問題問得很合理，因為在那個階段確實沒什麼不同。

差別要到你把它推上正式環境才出現：資料要進來、內容要被擋、每一次工具呼叫要留痕、換模型不能翻掉整套架構。這篇就從平台的高度談 Bedrock，不重複入門操作，重點放在 Knowledge Bases、Guardrails 與 Agent 這三塊怎麼組成一條能上線的路。

生成式 AI 專案卡住的地方，幾乎都不是模型不夠聰明，而是資料進不來、內容擋不住、行為查不到。

先把「平台」這兩個字講清楚

Amazon Bedrock 在官網把自己定位成建構生成式 AI 應用與代理的端到端平台（2026 年 8 月查閱）。這句話值得慢慢讀，因為它把重點從模型移到了平台。

用單一 API 接多家基礎模型，最常被講的好處是「方便換模型」。這只說對一半，而且是比較不重要的一半。

真正的好處是換模型的時候，其他東西不用跟著換。權限、網路邊界、稽核日誌、內容防護、成本歸戶，這些在企業裡最難改的部分留在原地。

• 身分與權限：模型呼叫走 IAM，不必為每家供應商各管一組金鑰。
• 資料邊界：呼叫發生在你自己的 AWS 帳號與區域裡，資料治理的討論才有得談。
• 可觀測性：呼叫紀錄與指標進到既有的監控體系，不是散在各家供應商的後台。
• 防護一致：Guardrails 設定與模型分離，換模型不必重寫防護邏輯。

2026 年最該先知道的一件事：Agents 改名了，路也換了

如果你是照著兩年前的教學在規劃架構，這一段請務必看完，因為它會直接影響你的技術選型。

依 AWS 官方文件，2023 年 11 月推出的 Amazon Bedrock Agents 已更名為 Amazon Bedrock Agents Classic，並自 2026 年 7 月 30 日起不再開放新客戶，服務進入維護模式。

• 既有代理繼續運作，多數 API 維持可用，官方也說目前沒有規劃終止服務的日期。
• 過去 12 個月有使用紀錄的帳號會被列入允許名單；沒有紀錄的帳號呼叫 CreateAgent 或 InvokeInlineAgent 會收到權限錯誤。
• Classic 的模型目錄凍結在生效日，之後推出的新模型只會出現在 AgentCore 這一側。
• Bedrock 本身、Knowledge Bases 與 Guardrails 都不受影響，繼續正常演進。
• 官方建議的遷移目標是 Amazon Bedrock AgentCore，並提供從 Classic 設定匯入的工具路徑。

所以現在動手做新的 Agent，只有一個合理起點：直接評估 AgentCore。舊教學裡那套動作群組與代理設定畫面，對新帳號來說已經不是可選項。

Knowledge Bases：全託管 RAG 把哪些工作收走了

企業要的 RAG 從來不是把幾份 PDF 切一切丟進向量庫，而是一條會自己保持同步、可以被稽核、壞了看得出來的資料管線。這條路線的維運成本，通常比大家預估的高一個級距。

2026 年 6 月 17 日，AWS 推出正式版的 Amazon Bedrock Managed Knowledge Base，官方定位是全託管的檢索增強生成服務。它把資料匯入、儲存最佳化與進階檢索都收進服務裡。

• 原生連接器：官方公告列出六種，包含 Amazon S3、SharePoint、Confluence、Google Drive、OneDrive 與網頁爬取，並支援自動同步。
• 託管向量儲存：不必自己建置與調校向量資料庫。
• 進階檢索：官方點名混合檢索、文件排序，以及會自動安排查詢規劃、中間結果評估與重新排序的代理式檢索。
• 與 AgentCore 銜接：官方說明可直接整合，權限自動產生並內建可觀測性。

自管路線並沒有消失。你自備向量儲存、自己決定索引與儲存設定，換來的是完全掌控。差別在於責任線畫在哪裡，不在功能多寡。

我的建議很簡單：沒有既有向量庫、也沒有特殊索引需求的團隊，從全託管開始。等到你真的說得出自管能解決哪個具體問題，再搬也不遲。

Guardrails：把安全做成一層可以被稽核的設定

很多團隊的防護是寫在提示詞裡的一句「請不要回答敏感問題」。這在展示的時候有效，在正式環境裡不算防護，因為它既不可稽核，也擋不住繞過。

Bedrock Guardrails 的做法是把防護抽成獨立設定。依官方頁面（2026 年 8 月查閱），它提供以下幾類政策。

• 內容過濾：針對仇恨、侮辱、暴力等有害內容，涵蓋文字與圖片。
• 拒絕主題：依你的應用情境定義哪些主題不該被討論。
• 字詞過濾：阻擋特定字詞與片語，包含競爭對手名稱這類商業需求。
• 敏感資訊過濾：遮蔽或阻擋個人識別資訊，也支援自訂正規表示式。
• 上下文接地檢查：比對回應與來源資料，抓出沒有依據的內容。
• 自動推理檢查：用形式邏輯規則驗證回應是否符合你定義的規則。

另外一個很實用的設計是 ApplyGuardrail API。同一份防護設定可以套用到 Bedrock 以外的模型，讓混合架構下的合規稽核只需要看一份規則。

AgentCore：一個 Agent 上線要接哪幾塊

AgentCore 的官方定位是用任何框架與任何基礎模型，安全地建置、部署與營運代理的平台。它不是把 Agents Classic 改個名字，而是拆成一組可以各自取用的模組。

官方文件把 AgentCore 的模組列成一張表，各自可以獨立使用。以下挑產品經理與開發者最需要先認得的幾個（2026 年 8 月查閱）。

另外還有瀏覽器與程式碼直譯器這類沙箱工具，以及 Registry 這種跨組織的資源目錄。這裡不逐一展開，重點是你可以只取需要的那幾塊。

2026 年 6 月，AWS 也宣布 AgentCore 的政策引擎支援 Bedrock Guardrails，讓內容偵測訊號可以直接餵進工具呼叫的攔截規則。這條線把「模型說了什麼」與「代理做了什麼」接在同一個治理面上。

落地順序：我會照這個次序推

工具都在，難的是次序。把順序排錯，最常見的結果是做出一個很會聊天、但沒有人敢讓它動真資料的東西。

1. 先把單純的模型呼叫跑通。 確認權限、區域、成本歸戶這些基礎設施層的東西是對的，再談功能。
2. 再接知識庫。 用真實文件測檢索品質，先確認「找得到」，才有資格談「講得好」。
3. 然後開防護。 Guardrails 設定完成後，用前面提過的雙向測試案例釘住鬆緊度。
4. 接著才給工具。 從唯讀的工具開始，寫入型工具一律先過 Policy 規則與人工確認。
5. 最後補評估與追蹤。 沒有評估集的代理，改版之後你只能靠感覺判斷有沒有變好。

站上另外有一組〈Claude on Bedrock〉的入門文章，以及 Bedrock 的起步教學，講的是主控台開通與第一次呼叫這類實作細節。這篇談的是它們之上的架構決策，兩邊搭配著看比較完整。