MCP

把內部知識接進 IDE:HEMA 用 MCP 與 Bedrock 拆掉入口網站跳轉

HEMA 以 MCP 與 Amazon Bedrock AgentCore 建 HAL,讓工程師在 IDE 與聊天視窗直接取用內部知識。

把內部知識接進 IDE:HEMA 用 MCP 與 Bedrock 拆掉入口網站跳轉 — 文章封面

工程師要一個答案,得先開 wiki、再開 service catalog、再開 IT portal,一個下午就這樣過去。荷蘭零售商 HEMA 的技術組織把這個摩擦當成架構問題處理:知識本身不缺,缺的是一條能從日常工作工具直接走進知識的路。

根據 AWS Machine Learning Blog 於 2026 年 9 月 23 日發布的案例,HEMA 的做法是把內部知識集中成一個治理過的來源,再用 Model Context Protocol(MCP)把它送進人們本來就在用的工具。

問題不在知識庫,而在「怎麼做」沒有家

HEMA 的知識問題分成兩層。第一層是結構化資訊,其實狀況不錯:多年維護的 service catalog 記錄了誰擁有哪個服務、服務暴露哪些 API、對應哪些業務能力,PIM 與 data-mesh 的資料也已經整理進來。

第二層才是缺口。「我要怎麼申請某個 API 的存取權?新群組怎麼開?我們對某件事的規則是什麼?」這類程序性問題沒有單一落點。團隊小的時候,問隔壁同事就好;組織變大、新人變多之後,這個模式就撐不住了。

AWS 的案例描述,結果是新人上手變慢、答案取決於你查了哪裡、不斷切換情境。原本要跑三、四個入口網站、有時耗掉半天的問題,現在可以在幾秒內、在 IDE 或聊天視窗裡得到答案。

為什麼是 MCP 加 AgentCore,而不是又一個入口

HEMA 把目標拆成兩半:HAL(內部 AI 助理)負責把分散的知識收攏成單一來源;MCP 負責把知識送到人所在的地方,而不是再逼人開一個新網站。

MCP 的價值在介面標準化。每個知識來源只要以 MCP tool 的形式暴露一次,HAL 網頁聊天、Kiro、Claude 等相容的 client 就能共用同一批工具,不必為每個 client 重寫整合。

Amazon Bedrock AgentCore 則省下自建與維運 MCP server 的工作。Gateway 可直接把 OpenAPI 規格與 Lambda 函式轉成 MCP tool;Identity 處理 inbound JWT 驗證與 outbound OAuth2;Runtime 以容器託管用 Strands 框架寫的 agent;Memory 與 Bedrock Guardrails 提供對話記憶與內容過濾,並支援 EU 推論區域與荷蘭語。

兩個 Gateway,換來外部 client 的隔離

HAL 先做成獨立助理:Next.js 寫的聊天介面,接上跑在 AgentCore runtime 的 Strands agent。知識走兩條路——語意搜尋用本地 Strands tool 直接呼叫 Bedrock Retrieve API;需要即時資料、OpenAPI 規格、service catalog 查詢時,則透過 MCP 連到自己的 AgentCore Gateway,該 Gateway 以 IAM SigV4 驗證後呼叫內部 API。

第二步才是把 HAL 打開給外部 MCP client。因為一個 AgentCore Gateway 只支援單一 inbound 驗證類型,HEMA 沒有重用第一階段那個 IAM Gateway,而是另外加了一個以 Microsoft Entra ID 驗證的 Gateway,只共用唯讀的 Knowledge Bases。兩邊沒有共用程式碼,外部介面可以獨立演進或失效,不影響內部 agent。

這個切法值得筆記:當你同時要服務內部 agent 與外部 client,驗證模型往往比工具本身更早決定架構形狀。類似「端點選擇先於模型分數」的取捨,在 Grok 4.6 進 Bedrock 的端點選擇討論 裡也出現過。

先照現況暴露,再談重構

HEMA 坦言,直接把既有 API 規格指向 Gateway 並不是理想終態。為系統對系統設計的 API,不一定能乾淨映射成 agent 可以推理的工具,他們計畫把這些定義重構成更 agent-friendly 的工具。

但現階段這樣做成本低、價值高。檢索採兩步模式:先用 Knowledge Base 搜尋回答多數問題,單一 chunk 不夠時再用 fetch_full_document 取回完整文件;語意查詢加上 Bedrock reranking,並用 team_id metadata 做團隊範圍過濾。

安全面則以 Microsoft Entra ID 為錨,client 端不持有 AWS 憑證,目前是唯讀存取,權限沿用既有 Active Directory 群組。HEMA 表示,下一步是讓 HAL 從唯讀知識層變成可執行動作的層。

對正在評估內部助理的團隊來說,這個案例的實用順序是:先確認你已經有的結構化資料,再挑痛點最高、被問最多次的文件補上,最後才處理「怎麼送進日常工具」。反過來先做 client 整合,通常只會把入口網站換個地方重蓋一次。

需要留意的限制是:這份案例由 AWS 與 HEMA 共同撰寫,成效描述來自他們的實作經驗;文中沒有提供檢索準確率或使用量等量化指標,因此難以判斷同樣架構在別的組織規模下會複製到什麼程度。

參考來源

本文由 AI 協助自上述來源整理,經人工審核後發布。

這篇內容對你有幫助嗎?

支持本站繼續整理實用的 AI 文章、教學與開發筆記。

請我喝杯咖啡
分享X電郵