HEMA 用 MCP 与 Bedrock AgentCore 把分散知识变成即问即答

荷兰零售集团 HEMA 在全球运营着 750 多家门店，背后的技术团队需要在多个 wiki、服务目录与 IT 门户之间反复跳转才能找到一个内部问题的答案。为消除这种「门户穿梭」式摩擦，HEMA 基于 Amazon Bedrock AgentCore 与 Model Context Protocol（MCP）搭建了内部 AI 助手 HAL，把分散的知识装进员工日常已经在使用的工具里。

背景：知识存在，但够不着

HEMA 的内部知识其实并不匮乏。多年来，团队维护着一套结构良好的服务目录，清楚记录了团队、服务、API 与业务能力之间的映射关系，产品信息管理（PIM）系统与数据网格（data-mesh）表中的结构化数据也已经被整理过。要了解「什么存在、由谁负责」，答案往往就在那里。

真正的缺口在于第二类问题——「怎么做」。例如「怎么申请某个 API 的访问权限」「怎么申请新建一个用户组」「某条内部规则是什么」。这类流程性问题没有统一的安放之处，早年间靠同事之间互相问就能解决，但随着工程团队扩张、新人不断入职，这种非正式模式难以为继，文档化程度也不足。结果是新员工上手慢、答案因人而异、上下文频繁切换，一件本应几分钟搞定的查找工作有时会拖上一整个下午。

双层目标：HAL 与 MCP 各司其职

为解决上述问题，HEMA 把目标拆成两层。

• HAL 负责「把知识装进一个地方」：把分散在各门户中的内容整合成统一、可治理的唯一来源。
• MCP 负责「把知识送到用户已经待的地方」：让 HAL 的能力直接出现在聊天窗口、IDE 等日常工具中，而不是再造一个门户。

在客户端层面，HAL 网页聊天、Kiro、Claude 以及其他支持 MCP 的智能体都可以直接消费 HAL 暴露的能力，无需为每个客户端重复定制集成。用户身份通过 Microsoft Entra ID 管理，客户端不持有 AWS 凭据，满足企业内部对安全的要求。

为什么选择 MCP 与 Bedrock AgentCore

MCP 为 AI 客户端与后端能力之间提供了标准化接口。HEMA 把每一类知识源暴露为一次 MCP 工具，而不是为每个数据源和每个客户端各写一套集成。HAL 网页聊天、Kiro、Claude 等 MCP 兼容客户端都可以复用同一套工具，这让「在日常工具里就能用」成为工程上可交付的事实，而不是另起炉灶。

Amazon Bedrock AgentCore 则是承载 HAL 的运行平台。它让团队无需自行搭建和运维 MCP 服务端基础设施，最关键的能力包括：

• Gateway：把 OpenAPI 规范和 AWS Lambda 函数直接转化为 MCP 工具，无需手写 MCP 服务端。
• Identity：提供入站的托管 JWT 认证和出站 OAuth2（带 token vault），对接内部 API。
• Runtime：把基于 Strands 框架构建的内部智能体以容器方式托管运行。
• Memory 与 Guardrails：提供对话记忆与内容过滤能力，推理区域位于欧盟，并支持荷兰语。

整体架构建立在 Entra ID OAuth、当前只读访问、由现有 AD 组控制权限的基础上，达到了把真实内部知识安全暴露出来的门槛。

HAL 的建设路径

HAL 的演进分成了两个有意识的阶段。

第一步是独立形态的助手：先用 Next.js 做一个网页聊天界面，背后接一个能回答 HEMA 内部知识问题的智能体。这一阶段不涉及 MCP，也没有外部客户端，仅是 HAL UI 与 HAL 智能体之间的对话。

第二步是把 HAL 通过 MCP 接入员工已经在用的工具。等到独立形态被验证之后，团队把同一套能力以 MCP 工具的形式暴露出去，让 Kiro、Claude 等客户端无需改造即可调用。

第三步规划中：把 HAL 从「只读知识层」升级为「可执行层」，让助手能够直接驱动后续动作，而不仅仅是回答问题。

根据 HEMA 团队的描述，过去需要穿过三四个门户、有时耗掉半个下午才能找到的答案，如今在 IDE 或聊天窗口里几秒钟即可获得。这一架构同时为更广泛的跨角色辅助奠定了基础，HAL 已不再只是开发者工具，而是正在演变为跨职能的内部助手。