HEMA 公开 MCP 知识层配方：AgentCore 两个 Gateway 分用 IAM 与 Entra 鉴权，DCR 用桩化 /register 顶替。 前置部署 FDE 为什么要读这条 HEMA 配方 前置部署 Forward Deployed Engineer（FDE）在企业内部搭知识层时，最难的一段往往不是检索效果，而是让同一个 MCP 服务同时被内部 agent 和员工手上的 IDE 客户端安全访问。荷兰零售商 HEMA 在 2026 年 9 月 23 日公开了内部 AI 助手 HAL 的构建过程，把两个 Gateway 的鉴权分工、模拟动态注册的做法与端用户配置一并写出。 HEMA 有 100 年历史、750 家以上门店，技术组织里有工程师、产品负责人与业务分析师三类角色。改造前，找到一个答案要在三到四个门户之间跳转，有时要占掉大半个下午；改造后从 IDE 或聊天窗口里几秒内拿到答案。 这条配方对前置部署 FDE 的价值集中在授权链：它没有把 AWS 凭证发给客户端，而是用 Microsoft Entra ID 加一个 Auth Proxy，把 MCP 规范对 OAuth 的期待与 Entra 的实际行为对齐。 HEMA 原来的两层知识问题 HEMA 的知识问题分成两半，一半是健康的。结构化基础设施知识那一半做得不错：服务目录把人与团队、团队与服务、服务与其暴露的 API，以及所支撑的业务能力串了起来；来自产品信息管理（PIM）引擎与数据网格表的结构化数据也已经导入整理。凡是问「存在什么、谁负责」，通常都答得上来。 另一半是缺口。「怎么申请某个 API 的访问权限」「怎么开通一个新组」「我们对某件事的规则是什么」这类流程性问题没有统一去处。团队小的时候靠「问旁边的人」解决，组织长大后这个模式失效，又没有留下多少书面文档兜底。 代价是新人上手慢、同一个问题在不同门户得到不一致的答案、频繁切换上下文，以及被打断后回不到手上的工作。前置部署 FDE 在客户现场做发现阶段时，这一层通常就是最值得先量化的部分。 第一步：先把 HAL 做成自包含的助手 HAL 不是一次成型的，它分两步长出来。第一步是自包含版本：一个用 Next.js 写的 Web 聊天界面，背后是一个能回答知识问题的 agent，此时既没有 MCP，也没有外部客户端，只有 HAL 界面与 HAL agent 对话。 这个 agent 是 Strands agent，打包成 Linux/ARM64 容器跑在 AgentCore Runtime 上，并配了 AgentCore Memory 做短期会话上下文、Amazon Bedrock Guardrails（Standard 档、EU 跨区域推理、支持荷兰语）做内容过滤。 前置部署 FDE 要注意 agent 取知识的两条路径是分开的：一条是本地 Strands 工具直连 Amazon Bedrock Retrieve API 打 Knowledge Bases，中间不经 Gateway，这是最日常的「从知识库回答」路径；另一条是走 MCP 连自己的 AgentCore Gateway（用 AWS Identity and Access Management 的 SigV4 鉴权），负责实时数据、完整 OpenAPI 规格、服务目录查询与人／团队查询。 背后挂了多个知识库：IT 与操作文档、API 与 OpenAPI 规格、Kafka 事件流主题及其 Avro schema、数据交换层（DCL）通道，以及服务目录。选材原则是按痛点与提问频率排序，而不是一次把所有文档搬进来。 用 Gateway 把 OpenAPI 规格直接变成 MCP 工具 整套系统没有自研 MCP server 代码。AgentCore Gateway 对 API 透传目标直接从 OpenAPI 规格生成 MCP 工具，对知识库语义检索则调用一个 AWS Lambda 函数，这个函数被命名为 kb-search。 kb-search 包住 Amazon Bedrock Retrieve API，并用 IAM 把权限收窄到具体的知识库 ARN，外加对源文档 Amazon S3 存储桶的读权限。这是前置部署 FDE 可以照抄的最小权限写法：工具只拿它真正需要的那几个 ARN。 检索是两步式：先做一次知识库搜索，回答大多数问题；单个分块不够用时，用 fetch_full_document 拉取完整文档。 检索质量靠两点提升：在语义查询上开 Amazon Bedrock 重排（reranking），以及用 team_id 元数据过滤做按团队范围的查找。前置部署 FDE 如果面对的是多团队共用一个知识库的场景，team_id 这类元数据过滤比调分块大小更直接有效。 第二步：为外部 MCP 客户端再开一个 Gateway HAL 在自己的聊天界面里跑通了，但人待在别的工具里：IDE、AI 助手。第二步是让 Kiro、Claude 这类外部 MCP 客户端够到同一批知识与工具，同时不发放 AWS 凭证。 这里撞上第一个硬约束：一个 AgentCore Gateway 只支持一种入站鉴权类型。第一步那个用 IAM SigV4 鉴权的 Gateway 没法复用，于是官方另开了一个用 Microsoft Entra ID 自定义 JWT 鉴权的 Entra MCP Gateway，专供外部 MCP 客户端。 两个 Gateway 只共享只读的知识库，不共享代码。作者给出的收益是隔离：对外那一面可以按自己的节奏演进，甚至挂掉，都不会影响内部 agent。代价是同一批工具定义要在两处各自维护。 前置部署 Forward Deployed Engineer（FDE）在设计阶段就要把「一套服务、两类身份」当成默认前提，而不是等接入外部客户端时再回头拆网关。 授权链实操：Auth Proxy 做五件事 Entra Gateway 前面挡着一个 MCP Auth Proxy：一个 Amazon API Gateway v2 HTTP API，背后挂单个 Lambda，作用是把 MCP 的 OAuth 规范与 Entra ID 的具体行为对齐。它做五件事。 第一，对外提供 OAuth 发现文档（discovery documents），让客户端能找到授权端点。 第二，把客户端请求的 scope 重写成资源应用（resource app）的调用范围，因为客户端按 MCP 规范传的 scope 与 Entra 期望的不是同一个名字。 第三，去掉 Entra v2.0 会拒绝的遗留 resource 参数。这是最容易被忽略的一条：不带这个改写，整条授权流在 Entra 侧直接失败。 第四，加上 response_mode=query，否则桌面客户端拿不到授权码。 第五，用 bearer token 代理 /mcp 路径，把真实的 MCP 请求转给后面的 Gateway。 最值钱的一条：DCR 是模拟的，不是真的 全系统只有一处出现动态客户端注册（Dynamic Client Registration，DCR）。MCP 客户端会按规范发 POST /register，期望换回一个 client ID，而 Entra 并不提供这个能力。 官方没有实现真正的动态注册，而是让代理用一个桩化的 /register 返回一个固定的、预先开通好的 client ID。原文的措辞很直接：DCR is emulated, not real，也就是 DCR 是被模拟出来的。 前置部署 FDE 在方案评审时必须把这一点讲清楚，否则客户会以为「支持 DCR」等于「任意客户端可以自助注册」。实际语义是：所有客户端共用同一个预置凭据。 适用边界也很清楚：客户端种类少、租户单一的内部场景，桩化方案足够用；一旦需要多套凭据、多租户按需注册，这个桩就是瓶颈。 端用户配置只剩下两项 接入方看到的配置只有代理 URL 和一个空的 oauthScopes 列表，不需要任何 AWS 凭证。首次连接走浏览器登录，之后令牌自动刷新。 这是前置部署 Forward Deployed Engineer（FDE）在客户现场做客户端接入时可以照抄的最小配置面：配置项越少，越不容易在培训与支持上返工。任何需要用户手工粘 token 或填 client secret 的方案，都会在推广阶段变成支持工单。 部署形态与一个月的上线前测试 基础设施用 AWS Cloud Development Kit（AWS CDK）定义，是一个用 npm workspaces 组织的 TypeScript 单仓（monorepo）。内部 agent 以 Docker 容器跑在 AgentCore Runtime 上；租户、客户端与资源标识这类随环境变化的配置，通过 AWS Systems Manager（SSM）参数注入，而不是写进代码。 上线前 HEMA 把 HAL 部署到 staging 环境，对工程师与业务用户同时开放，做整整一个月的手工测试，验证答案质量、覆盖缺口与日常可用性，之后才推广到生产。 前置部署 Forward Deployed Engineer（FDE）可以把这个「先双角色、后全员」的顺序当成标准动作：只让开发者试用，会漏掉产品负责人与业务分析师提出的那类流程性问题，而那恰好是第二层知识缺口的主体。 作者承认的局限与未覆盖场景 官方明写的第一条局限是方向性的：把 Gateway 直接指向现有 API 规格不是理想终态。为系统间调用设计的 API 不一定能干净地映射成 agent 能推理的工具，团队计划把这些定义重构成更 agent-friendly 的工具，目前的可用性来自「先原样暴露、成本很低」这个权衡。 第二条是 DCR 桩化带来的天花板：它不是真正的动态注册，一旦客户端需要多套凭据或按租户注册，这套方案要重做。 第三条是能力边界：HAL 当前是只读的，只回答不执行；两个 Gateway 刻意不共享代码，好处是隔离，代价是工具定义重复维护。 还有几类信息原文没有给出：答案质量的量化指标（准确率、命中率、满意度都没有数字）、知识库的分块与向量化配置、以及一个月的 staging 测试具体覆盖了多少问题、留下多少缺口。可复用的验收证据只有「双角色手工测试一个月」这一条过程性描述，这是引用时必须标明的地方。 前置部署 Forward Deployed Engineer（FDE）落地时的五个常见坑与绕法 坑一：以为一个 Gateway 能同时接 IAM 与 Entra。单个 AgentCore Gateway 只支持一种入站鉴权，必须开第二个，并接受两套工具定义各自维护；绕法是把只读知识库作为唯一共享面，其余全部隔开。 坑二：让 MCP 客户端直接打 Entra 的授权端点。Entra v2.0 会拒绝 MCP 规范里带的遗留 resource 参数，桌面客户端还需要 response_mode=query 才能拿到授权码；绕法是把这两处改写固定在 Auth Proxy 里。 坑三：对外声称支持动态客户端注册。MCP 客户端确实会发 POST /register，但拿回的是预置 client ID；绕法是在方案文档里写明 DCR 为模拟实现及其触发重做的条件。 坑四：把现有 API 规格原样当工具定义。能跑，但工具语义对 agent 不友好；绕法是按 HEMA 的规划，中期把这些定义重构成更适合 agent 推理的工具，而不是停在透传。 坑五：跳过 staging 直接上生产。HEMA 用一个月的双角色手工测试换来答案质量与覆盖缺口的清单；绕法是先把测试期当成产出物，而不是可压缩的等待时间。 前置部署 Forward Deployed Engineer（FDE）的实用结论 该行动的人：需要在企业内部把割裂知识做成一个被多客户端共享的 MCP 知识层的 FDE，尤其是客户端身份已经统一在 Microsoft Entra ID 或同类身份提供商上的组织。HEMA 的规模参照是 750 家门店、三类使用者角色。 第一步先定鉴权分面：内部 agent 走 IAM SigV4，外部 MCP 客户端走身份提供商的自定义 JWT，分成两个 Gateway，只共享只读知识库，不共享代码。 第二步把 Auth Proxy 的五件事写进验收清单：提供发现文档、重写 scope、去掉 resource 参数、加 response_mode=query、用 bearer token 代理 /mcp。缺任何一件，授权流都跑不通。 第三步把客户端配置压到最小：只给 proxy URL 与空 oauthScopes，不发 AWS 凭证，首次连接走浏览器登录、后续自动刷新令牌。 第四步按只读上线再规划写动作：HEMA 的路径是先把读工具与治理做扎实，再暴露写操作，因为底层门户已经 API 化并接了 Entra ID 单点登录，新增动作不需要新的安全模型。官方把这条判断总结为读架构挣来写这一步。 适用条件：知识源能被 API 化或已有 OpenAPI 规格，身份体系统一，组织能接受 MCP 客户端首次连接时走一次浏览器登录。 回滚方式：这是这套设计最实用的一点。两个 Gateway 不共享代码，停掉 Entra MCP Gateway 与其 Auth Proxy，只影响外部 MCP 客户端，内部 agent 与其 IAM Gateway 完全不受影响，等于自带的降级开关；要回退到单客户端时代，直接撤掉第二个 Gateway 即可。 不适用：只服务单一内部客户端的场景，开两个 Gateway 加一个 Auth Proxy 带来的是纯额外维护成本，直接用 IAM 鉴权的那一个 Gateway 就够。 关键实体中英对照 领域与角色：前置部署 Forward Deployed Engineer（FDE）、动态客户端注册 Dynamic Client Registration（DCR）、模型上下文协议 Model Context Protocol（MCP）、只读知识层 read-only knowledge layer、动作层 action layer、工具级授权 tool-level authorization。 本次出现的工具与平台：Amazon Bedrock AgentCore、AgentCore Gateway、AgentCore Runtime、AgentCore Memory、Amazon Bedrock Knowledge Bases、Amazon Bedrock Guardrails、Amazon Bedrock Retrieve API、Strands Agents、Microsoft Entra ID、AWS Identity and Access Management（IAM）SigV4、Amazon API Gateway、AWS Lambda、AWS Cloud Development Kit（AWS CDK）、AWS Systems Manager（SSM）、Amazon Simple Storage Service（Amazon S3）、Next.js、Kiro、Claude、HAL、HEMA。 原始来源： https://aws.amazon.com/blogs/machine-learning/from-portal-hopping-to-instant-answers-hemas-journey-with-mcp-and-amazon-bedrock/