HEMA用MCP和Amazon Bedrock AgentCore搭内部助手HAL，把找答案时间从半天压到几秒
这家有 750 多家门店的荷兰零售商把服务目录、API规范、Kafka主题和操作文档接入Amazon Bedrock知识库，再通过MCP把只读知识送进Kiro、Claude和自研聊天界面，客户端不持有AWS凭证。
AI解读：HEMA原来查内部技术问题要在门户、wiki和服务目录之间来回跳，有时耗掉整个下午。它把这些零散知识集中到一个叫HAL的助手，再通过MCP把答案送回工程师本来就在用的IDE和聊天窗口。
MCP的价值在于只把每个知识源暴露一次，HAL网页聊天、Kiro、Claude等兼容客户端都能复用同一套工具，不用为每个客户端重写集成。
安全上没有把AWS凭证发给客户端：内部代理走IAM SigV4，外部客户端走Microsoft Entra ID的JWT认证，权限沿用现有Active Directory组。方案里还用一个固定client ID的桩接口模拟MCP的动态客户端注册，并非真正的DCR。
目前HAL是只读的，能回答问题但不能执行操作。下一步它打算开放“新建AWS账户”这类动作，前提是这些门户本身已有API和Entra ID单点登录，所以只需新增受控工具，不用改安全模型。
HEMA是一家有 100 年历史的荷兰零售商，在多个国家经营 750 多家门店。它的技术组织在扩张后遇到一个具体问题：要查一个内部答案，得在互不相连的wiki、服务目录和IT门户之间反复跳转，有时一次要花掉整个下午。
HEMA把这块知识做成了内部AI助手HAL，底层用Amazon Bedrock AgentCore，并通过Model Context Protocol（MCP）把知识送到工程师已经在用的工具里，包括HAL聊天、Kiro、Claude等兼容客户端。
HEMA在AWS博客中与Mauro Rallo、Patrick van der Plas联合介绍了这套系统的搭建过程、认证细节和当前的使用范围。
知识原本就有，难的是拿不到
HEMA把问题分成两层。第一层是结构化基础设施知识，状态其实不错：公司维护了多年的服务目录，记录谁拥有哪个服务、服务暴露哪些API、对应哪些业务能力；来自产品信息管理（PIM）引擎和数据网格表的结构化数据也已被导入整理。只要知道去哪里找，“存在什么、谁负责”通常查得到。
第二层是缺口所在：知道存在什么，不等于知道怎么做。“怎么申请一个API的访问权限？怎么开通一个新组？X的规则是什么？”这类流程性问题没有统一归宿。团队小时候可以直接问旁边的人，和组织一起变大、新人不断加入后这套模式就失效了，能替代的书面文档又很少。结果是新人上手慢、答案因查找位置不同而不一致、频繁切换上下文。
HAL上线后，原本要翻三四个门户、有时耗掉半天的查找，现在在IDE或聊天窗口里几秒完成。
为什么选MCP和AgentCore
HEMA说方案由两个目标决定。第一个目标属于HAL：把分散的知识合并成一个受治理的单一事实来源。第二个目标属于MCP：把知识送到人们已经在用的地方，而不是再逼他们访问一个新门户。
MCP提供AI客户端与后端能力之间的标准化接口。HEMA不需要为每个知识源写定制集成、再为每个客户端重写一遍，而是把每个来源一次性暴露为MCP工具，HAL网页聊天、Kiro、Claude和其他agent可直接消费同一批工具。
Amazon Bedrock AgentCore则让HEMA不用自建和运维MCP服务器基础设施。HEMA点出几个关键能力：Gateway可把OpenAPI规范和AWS Lambda函数直接转成MCP工具，不需要写或运行自定义MCP服务器代码；Identity提供托管的入站JWT认证和面向内部API的托管出站OAuth2（令牌库）；Runtime把用Strands框架构建的内部agent作为容器托管；Memory和Amazon Bedrock Guardrails提供会话记忆和内容过滤，并支持欧盟推理区域和荷兰语。
安全底座是Entra ID OAuth、当前只读访问、以及由现有Active Directory组驱动的访问控制。
HAL分两步长成
第一步是独立助手。最早的HAL是自包含的：Next.js写的网页聊天界面，背后是一个能从HEMA知识中回答问题的agent，此时没有MCP，也没有外部客户端。这个Strands agent被打包成Linux/ARM64容器，托管在AgentCore Runtime上，同时使用AgentCore Memory做短期会话上下文，用Amazon Bedrock Guardrails（Standard层级、欧盟跨区域推理）支持荷兰语。
agent有两条取知识的路径。本地工具直连知识库：语义搜索工具是本地Strands工具，直接调用Amazon Bedrock Retrieve API访问Knowledge Bases，中间没有网关，这是“从知识库找答案”的主力路径。另一条是MCP连到AgentCore Gateway访问实时API：针对实时数据、完整OpenAPI规范、服务目录查询和人员/团队查询，agent通过MCP连到自己那个用IAM SigV4认证的AgentCore Gateway，再由网关调用内部API。
HAL背后是多个基于Amazon Bedrock Knowledge Bases的知识库：IT与操作文档、API/OpenAPI规范、Kafka事件流主题及其Avro schema、数据整合层（DCL）的数据交换通道，以及服务目录（人员、团队、服务、API）。没有自定义MCP服务器代码：Gateway直接从OpenAPI规范生成API透传目标的MCP工具，从Lambda函数生成针对知识库的语义搜索工具。HEMA也承认，直接把Gateway指向现有API规范不是理想终态——为系统间调用设计的API不一定能干净地映射成agent能推理的工具，因此计划把这些定义重构成更agent友好的工具；但眼下按原样暴露API已经以很低成本带来高价值。
kb-search Lambda封装了面向Knowledge Bases的Amazon Bedrock Retrieve API，并用IAM限定到特定Knowledge Base ARN和源文档S3桶的读取权限。检索采用两步模式：先做一次知识库搜索回答大多数问题，当单个分块不够时用fetch_full_document拉取完整文档。检索质量靠Amazon Bedrock重排序和team_id元数据过滤提升。
第二步：用MCP把HAL开放给日常工具
HAL在自己的聊天界面里运行良好，但人们生活在其他工具里：IDE、AI助手。第二步是让Kiro、Claude等外部MCP客户端能访问同一批知识和工具，同时不发放AWS凭证。
这意味着要加第二个AgentCore Gateway，用Microsoft Entra ID而不是IAM认证。由于一个AgentCore Gateway只支持单一入站认证类型，第一步那个用IAM认证的agent Gateway无法复用于外部客户端。因此HEMA增加了一个Entra MCP Gateway，用Microsoft Entra ID的自定义JWT认证，专供Kiro、Claude等外部MCP客户端使用，且只与agent Gateway共享只读知识库。两者不共享代码，所以对外暴露面可以独立演进，甚至出故障也不影响内部agent。
为了让知识库作为Gateway目标出现，HEMA写了一个小型中间Lambda函数，由Gateway作为工具调用，代表Gateway对知识库做语义搜索；而实时内部API则直接作为OpenAPI目标暴露。
认证与动态客户端注册的真实处理方式
外部客户端如何在没有AWS凭证的情况下认证，是这套系统里比较特别的一环。Entra Gateway前面放了一个MCP认证代理：一个由单个Lambda支撑的Amazon API Gateway v2 HTTP API，用来调和MCP OAuth规范与Entra ID的具体行为。它提供OAuth发现文档，把请求的scope改写成资源应用的invoke scope，剥掉Entra v2.0拒绝的旧版resource参数，加上response_mode=query以便桌面客户端捕获授权码，并以bearer token代理 /mcp。
HEMA特意点出一个细节：MCP客户端期待动态客户端注册（DCR），即一个返回client ID的POST /register调用。代理没有实现真正的动态注册，而是用桩接口返回一个固定的、预先配置好的client ID。DCR是模拟的，不是真的。
对最终用户来说，代价只是配置代理URL和一个空的oauthScopes列表，不需要AWS凭证，首次连接时在浏览器登录，之后自动刷新令牌。
部署、测试和今天的用户
基础设施用AWS CDK定义，是一个使用npm workspaces的TypeScript monorepo。内部agent作为Docker容器运行在AgentCore Runtime上，租户、客户端、资源标识等环境相关配置通过AWS Systems Manager（SSM）参数提供。
上线前，HEMA把HAL部署到预发环境，向工程师和业务用户开放一个月做手工测试，验证答案质量、覆盖缺口和日常可用性，之后才推广到生产环境。
HAL最初是开发者工具，现在已经是跨角色助手。开发者用它查文档、API规范、Kafka主题和schema、服务目录和DCL通道，入口是Kiro和聊天；产品负责人用它查文档、操作方法和流程知识，也就是过去没有归宿的流程层；业务分析师用它查基础设施知识，即存在哪些服务、暴露哪些API、由哪些团队拥有，直接来自服务目录。非开发者角色的需求真实且在增长，HEMA负责梳理和优化产品经理流程的端到端团队已经在使用HAL。HAL通过一个“Everyone Skill”和配套的引导文件在内部分发，并由每月一次的HEMA AI开发论坛维护。
下一步是从答案走向动作：今天HAL是只读的，只提供即时答案；接下来的目标是让同一个助手执行即时操作。之所以现在可行，是因为底层门户已经API化，并且已经接入现有的Microsoft Entra ID单点登录。HAL可以把这些操作作为MCP动作工具暴露出来，复用保护读工具的同一套Entra ID认证和Active Directory组授权模型，不需要新的安全模型，只需要新增经过仔细限定范围的工具。
旗舰例子是开通新的AWS账户：今天开发者要去专门的门户申请，之后可以直接在聊天、Kiro、Claude或其他agent里发起同样的请求，完全不用访问那个门户。由于HAL已经在服务产品负责人和业务分析师，这种动作模式也自然延伸到这些角色日常提出的更广泛运营请求。HEMA的总结是，读架构为写步骤铺了路：把身份、多客户端访问和治理做对之后，动作层才有基础。