HEMA 用 MCP 和 Amazon Bedrock 实现内部 AI 助手转型

This post is co-written with Mauro Rallo and Patrick van der Plas from HEMA.

当 HEMA 的工程师需要某个答案时，他们不得不"门户跳跃"——在彼此割裂的 wiki、服务目录和 IT 门户之间来回查找。为了将这种摩擦转化为即时答案，这家拥有百年历史的荷兰零售商在 Amazon Bedrock AgentCore 上构建了一层知识库。HEMA 在多个国家拥有超过 750 家门店，由工程师、产品负责人和业务分析师组成的技术组织推动数字化转型。HEMA 需要一个能跨角色和工具运作的解决方案。

Over the years, HEMA had quietly built something valuable: a large, structured picture of its own technology landscape. A service catalog mapped people to teams, teams to services, and services to the APIs we expose, and the business capabilities we support. The problem was never that the knowledge didn't exist. It was that the knowledge was hard to reach. As the engineering organization grew, the informal "just ask the person next to you" model broke down, and teams ended up scattering answers across portals, wikis, and documentation that few people knew how to navigate.

多年来，HEMA 悄然积累了一项宝贵的资产：一幅关于自身技术格局的大规模结构化图景。服务目录将人员与团队、团队与服务、服务与我们暴露的 API 以及所支持的业务能力对应起来。问题从来不是知识不存在，而是知识难以触达。随着工程组织的扩大，这种非正式的"直接问旁边的人"模式逐渐失效，团队最终将答案散落在很少有人知道如何导航的门户、wiki 和文档中。

In this post, we describe the challenge HEMA faced with fragmented internal knowledge, why we chose to build HAL, HEMA's internal AI assistant, using Model Context Protocol (MCP) and Amazon Bedrock AgentCore, and how it changed the way our teams work.

在这篇文章中，我们描述了 HEMA 在碎片化内部知识方面面临的挑战，选择使用 Model Context Protocol (MCP) 和 Amazon Bedrock AgentCore 构建 HAL（HEMA 内部 AI 助手）的原因，以及它如何改变了团队的工作方式。

The idea rests on two complementary goals. HAL puts knowledge in one place, and MCP delivers that knowledge inside the tools people already use (the HAL chat, Kiro, Claude, and other agents). Security is anchored in Microsoft Entra ID, with no AWS credentials on the client. What began as a developer tool is already a cross-role assistant. The same architecture will be the foundation for a next step: turning HAL from a read-only knowledge layer into an action layer.

这个理念建立在两个互补的目标之上。HAL 将知识集中在一处，而 MCP 则将知识传递到人们已经在用的工具中（HAL 聊天界面、Kiro、Claude 和其他 agents）。安全性依托于 Microsoft Entra ID，客户端无需 AWS 凭证。最开始只是一个开发者工具，现在已经成为了跨角色的助手。同样的架构将成为下一步的基础：将 HAL 从只读的知识层转变为行动层。

The challenge: Portal-hopping and knowledge fragmentation

挑战：门户跳跃与知识碎片化

HEMA's knowledge problem had two distinct layers.

HEMA 的知识问题有两个截然不同的层次。

The first layer, structured infrastructure knowledge, was actually in good shape. For years, HEMA has maintained a service catalog that captured how the technology estate fits together: which teams own which services, what APIs those services expose, and how they map to business capabilities. Structured data from systems such as the product information management (PIM) engine and the data-mesh tables had been imported and organized. For anything about what exists and who owns it, the answer was usually available, if you knew where to look.

第一层是结构化的基础设施知识，实际上状况良好。多年来，HEMA 维护着一个服务目录，记录了技术资产之间的关联：哪些团队拥有哪些服务，这些服务暴露了哪些 API，以及它们如何映射到业务能力。来自产品信息管理（PIM）引擎和数据网格表等系统的结构化数据已被导入并组织起来。关于存在什么以及谁拥有它，答案通常是可获取的——只要你知道去哪里找。

The second layer was the gap. Knowing what exists is not the same as knowing how to do something. "How do I request access to an API? How do I get a new group provisioned? What's our rule for X?". These procedural questions had no single home. When teams were small and everyone knew each other, that was fine. People asked directly. As HEMA grew and onboarded new engineers, that model stopped scaling, and there was little written documentation to fall back on.

第二层是知识缺口。知道存在什么不等于知道如何做。"如何申请 API 访问权限？如何请求一个新群组的配置？关于 X 的规则是什么？"这些流程性问题没有统一的归属。当团队规模小、彼此熟悉时，这没问题——人们直接询问。但随着 HEMA 规模扩大、新工程师入职，这种模式无法 scale，缺乏可参考的书面文档。

That translated into slow onboarding for new joiners, inconsistent answers depending on where someone looked, constant context-switching, and friction that pulled people out of their actual work. Finding an answer that once meant navigating three or four portals, sometimes across an entire afternoon, now happens in seconds, from inside the Integrated Development Environment (IDE) or chat window.

这导致了新员工入职缓慢、答案因查询渠道不同而不一致、频繁的上下文切换，以及将人们从实际工作中抽离出来的摩擦。曾经需要穿梭三四个门户、有时花上整个下午才能找到的答案，现在在 IDE 或聊天窗口内几秒钟就能获得。

Figure 1: The "before" state, showing the sources a user had to consult

Why MCP and Amazon Bedrock AgentCore

为什么选择 MCP 和 Amazon Bedrock AgentCore

Two goals shaped the solution, and they map cleanly onto the two technologies we chose.

两个目标塑造了这个解决方案，它们与我们选择的两种技术一一对应。

The first goal belongs to HAL: consolidate HEMA's fragmented knowledge into one governed source of truth. The second goal belongs to MCP: deliver that knowledge to people where they already work, rather than forcing them to visit yet another portal.

第一个目标归属于 HAL：将 HEMA 碎片化的知识整合到一个治理过的单一真实来源中。第二个目标归属于 MCP：将知识传递到人们已经在工作的地方，而不是强迫他们再去访问另一个门户。

Why MCP: Model Context Protocol gives us a standardized interface between AI clients and backend capabilities. Instead of building a bespoke integration for every knowledge source and re-building it for every client application, we expose each source once as an MCP tool.

为什么选择 MCP：Model Context Protocol 为 AI 客户端和后端能力之间提供了一个标准化的接口。我们无需为每个知识来源构建定制集成，也无需为每个客户端应用重建，而是将每个来源暴露为 MCP tool 一次。

MCP-compatible clients such as the HAL web chat, Kiro, Claude, and other agents can then consume the same tools without custom work. This is what makes "access from your daily tool" practical rather than a per-tool engineering project.

MCP 兼容的客户端（如 HAL web 聊天、Kiro、Claude 和其他 agents）可以无定制工作地消费相同的工具。这使得"从日常工具中访问"成为现实，而不再是逐工具的工程项目。

Why Amazon Bedrock AgentCore: Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale, with any framework or model. For HEMA, it meant building HAL without standing up and operating custom MCP server infrastructure. The capabilities that mattered most:

为什么选择 Amazon Bedrock AgentCore：Amazon Bedrock AgentCore 是一个大规模构建、连接和优化 agents 的平台，支持任何框架或模型。对 HEMA 而言，这意味着无需搭建和运营自定义 MCP server 基础设施就能构建 HAL。最重要的能力包括：

Gateway turns OpenAPI specifications and AWS Lambda functions into MCP tools directly. There is no custom MCP server code to write or run.

Gateway 将 OpenAPI 规范和 AWS Lambda 函数直接转换为 MCP tools，无需编写或运行任何自定义 MCP server 代码。

Identity provides managed inbound JSON Web Token (JWT) authentication and managed outbound OAuth2 (a token vault) to our internal APIs.

Identity 为内部 API 提供托管的入站 JSON Web Token (JWT) 认证和托管的出站 OAuth2（token vault）。

Runtime hosts the internal agent (built with the Strands framework) as a container.

Runtime 将内部 agent（使用 Strands 框架构建）作为容器托管。

Memory and Amazon Bedrock Guardrails provide conversation memory and content filtering, with EU inference regions and Dutch-language support.

Memory 和 Amazon Bedrock Guardrails 提供对话记忆和内容过滤，支持 EU 推理区域和荷兰语。

Together, these gave us enterprise-appropriate footing: Entra ID OAuth, read-only access today, and access control driven by existing Active Directory groups, safe enough to expose real internal knowledge.

这些共同为我们提供了企业级的基础：Entra ID OAuth、当前的只读访问，以及由现有 Active Directory 组驱动的访问控制——安全性足以暴露真实的内部知识。

Building HAL, step by step

分步骤构建 HAL

HAL didn't arrive fully formed. It grew in two deliberate steps. First, the team built a standalone assistant with its own chat UI. Then, once that foundation proved itself, we opened it up to the tools people already work in through MCP.

HAL 并非一步到位。它分两个精心规划的步骤演进。首先，团队构建了一个独立的助手，有自己的聊天 UI。然后，一旦这个基础被验证有效，我们就通过 MCP 向人们已经在用的工具开放了它。

Step 1: HAL as a standalone assistant

第一步：作为独立助手的 HAL

The first version of HAL was a self-contained assistant: a web chat UI (built with Next.js) backed by an agent that could answer questions from HEMA's knowledge. There were no MCP and no external clients yet, only the HAL UI talking to the HAL agent.

第一个版本的 HAL 是一个自包含的助手：一个由 Next.js 构建的 web 聊天 UI，后端是一个能从 HEMA 知识库回答问题的 agent。当时还没有 MCP 和外部客户端，只有 HAL UI 与 HAL agent 之间的对话。

The HAL agent is a Strands agent packaged as a Linux/ARM64 container and hosted on AgentCore runtime, together with AgentCore memory (short-term conversation context) and Amazon Bedrock Guardrails (Standard tier, EU Cross-Region inference for Dutch-language support). AgentCore runtime and AgentCore memory are capabilities of Amazon Bedrock AgentCore.

HAL agent 是一个 Strands agent，打包为 Linux/ARM64 容器，托管在 AgentCore runtime 上，同时配备 AgentCore memory（短期对话上下文）和 Amazon Bedrock Guardrails（Standard 层级，EU 跨区域推理以支持荷兰语）。AgentCore runtime 和 AgentCore memory 是 Amazon Bedrock AgentCore 的能力。

The agent reaches knowledge along two distinct paths:

agent 通过两条不同的路径获取知识：

Local tools, direct to the Knowledge Bases. The agent's semantic-search tools are local Strands tools that call the Amazon Bedrock Retrieve API directly over the Knowledge Bases, no gateway in between. This is the bread-and-butter "answer from the knowledge base" path.

本地工具，直达 Knowledge Bases。agent 的语义搜索工具是本地 Strands 工具，直接通过 Knowledge Bases 调用 Amazon Bedrock Retrieve API，中间不经过 gateway。这是"从知识库获取答案"的常规路径。

MCP to an AgentCore Gateway, for live APIs. For live data, full OpenAPI specifications, service-catalog lookups, and people/team queries, the agent connects over MCP to its own AgentCore Gateway, a capability of Amazon Bedrock AgentCore. This Gateway is authenticated with AWS Identity and Access Management (IAM) SigV4, which in turn calls our internal APIs.

通过 MCP 连接 AgentCore Gateway，获取实时 API。对于实时数据、完整 OpenAPI 规范、服务目录查询和人员/团队查询，agent 通过 MCP 连接到其专属的 AgentCore Gateway（Amazon Bedrock AgentCore 的一项能力）。该 Gateway 使用 AWS Identity and Access Management (IAM) SigV4 进行认证，再由其调用内部 API。

Figure 2: Step 1, HAL as a standalone assistant

We started from the structured data we already had, the service catalog, and added the highest-value documentation, prioritizing by pain and by how often something was asked. Behind HAL sit several knowledge bases built on Amazon Bedrock Knowledge Bases, the fully managed Retrieval Augmented Generation (RAG) capability: IT and how-to documentation, API/OpenAPI specifications, Kafka event-streaming topics and their Avro schemas, Data Consolidation Layer (DCL) data-exchange channels, and the service catalog (people, teams, services, and APIs).

我们从已有的结构化数据（服务目录）开始，逐步添加最高价值的文档，按痛感和被询问频率排序。HAL 背后有多个基于 Amazon Bedrock Knowledge Bases（完全托管的 RAG 能力）构建的知识库：IT 和操作文档、API/OpenAPI 规范、Kafka 事件流主题及其 Avro 模式、数据整合层（DCL）数据交换通道，以及服务目录（人员、团队、服务和 API）。

There's no custom MCP server code. AgentCore Gateway generates the MCP tools directly from OpenAPI specifications for the API passthrough targets, and from a Lambda function for semantic search over the Knowledge Bases. Pointing the Gateway straight at our existing API specifications isn't the ideal end state. An API designed for system-to-system use does not always map cleanly onto a tool an agent can reason about, so we plan to refactor those definitions into more agent-friendly tools.

没有自定义 MCP server 代码。AgentCore Gateway 直接从 OpenAPI 规范为 API passthrough 目标生成 MCP tools，从 Lambda 函数为 Knowledge Bases 语义搜索生成工具。直接将 Gateway 指向现有 API 规范并非理想的最终状态。为系统到系统使用而设计的 API 不总能良好地映射为 agent 可以推理的工具，因此我们计划将这些定义重构为更 agent 友好的工具。

For now, though, exposing the APIs as-is delivered high value for little effort. The kb-search Lambda wraps the Amazon Bedrock Retrieve API over the Knowledge Bases. It's scoped by AWS Identity and Access Management (IAM) to the specific Knowledge Base Amazon Resource Names (ARNs), plus read access to the source-document Amazon Simple Storage Service (Amazon S3) bucket.

不过就目前而言，原样暴露 API 投入小却获得了高价值。kb-search Lambda 封装了对 Knowledge Bases 的 Amazon Bedrock Retrieve API 调用，其作用域通过 AWS IAM 限定为特定 Knowledge Base ARN，并加上对源文档 Amazon S3 bucket 的读取权限。

Retrieval follows a two-step pattern: an initial Knowledge Base search answers most questions, and fetch_full_document pulls the complete document when a single chunk isn't enough. Retrieval quality is improved with Amazon Bedrock reranking on semantic queries and team_id metadata filtering for team-scoped lookups.

检索遵循两步模式：初始 Knowledge Base 搜索回答大多数问题，当单个 chunk 不够时，fetch_full_document 拉取完整文档。检索质量通过 Amazon Bedrock 语义查询重排序和 team_id 元数据过滤（用于团队范围的查询）来提升。

Step 2: Opening HAL to daily tools with MCP

第二步：通过 MCP 向日常工具开放 HAL

HAL worked well in its own chat UI, but people live in other tools: their IDE, their AI assistant. The second step was to let external MCP clients such as Kiro and Claude reach the same knowledge and tools, without handing out AWS credentials. That meant adding a second AgentCore Gateway, authenticated with Microsoft Entra ID instead of IAM.

HAL 在自己的聊天 UI 中运行良好，但人们生活在其他工具中：他们的 IDE、AI 助手。第二步是让外部 MCP 客户端（如 Kiro 和 Claude）访问相同的知识和工具，而不分发 AWS 凭证。这意味着需要添加第二个 AgentCore Gateway，用 Microsoft Entra ID（而非 IAM）进行认证。

Because an AgentCore Gateway supports only a single inbound authentication type, we could not reuse the agent's IAM-authenticated Gateway from Step 1 for these external clients. So, we added a second Gateway, an Entra MCP Gateway authenticated with a custom JWT through Microsoft Entra ID, dedicated to external MCP clients such as Kiro and Claude. It shares only the read-only Knowledge Bases with the agent Gateway. There is no shared code, so the external-facing surface can evolve, or fail, without impact on the internal agent.

因为 AgentCore Gateway 只支持单一入站认证类型，我们无法将第一步中 agent 的 IAM 认证 Gateway 重用于这些外部客户端。因此我们添加了第二个 Gateway——Entra MCP Gateway，通过 Microsoft Entra ID 用自定义 JWT 认证，专用于 Kiro 和 Claude 等外部 MCP 客户端。它只与 agent Gateway 共享只读的 Knowledge Bases。没有共享代码，因此面向外部的表面可以独立演进或故障，不影响内部 agent。

Figure 3: Step 2, opening HAL to daily tools with MCP

AgentCore Gateway exposes tools from OpenAPI specifications and Lambda functions. To surface the knowledge bases as a Gateway target, we built a small intermediate Lambda function that the Gateway calls as a tool, and which performs the semantic search over the knowledge bases on behalf of the Gateway. The live internal APIs, by contrast, are exposed directly as OpenAPI targets.

AgentCore Gateway 从 OpenAPI 规范和 Lambda 函数暴露工具。为了将知识库作为 Gateway 目标暴露，我们构建了一个小的中间 Lambda 函数，Gateway 将其作为工具调用，由它代为对知识库执行语义搜索。相比之下，实时内部 API 直接作为 OpenAPI 目标暴露。

One interesting piece is how external clients authenticate without AWS credentials. In front of the Entra Gateway sits an MCP auth proxy, an Amazon API Gateway v2 HTTP API backed by a single Lambda, that reconciles the MCP OAuth specification with the specifics of Entra ID. It serves the OAuth discovery documents and rewrites the requested scope to the resource app's invoke scope. It also strips the legacy resource parameter that Entra v2.0 rejects, adds response_mode=query so desktop clients can capture the authorization code, and proxies /mcp with the bearer token.

一个有趣的细节是外部客户端如何无需 AWS 凭证进行认证。在 Entra Gateway 前面有一个 MCP auth proxy——一个由单个 Lambda 支持的 Amazon API Gateway v2 HTTP API，它将 MCP OAuth 规范与 Entra ID 的具体细节协调起来。它提供 OAuth discovery 文档，并将请求的 scope 重写为资源 app 的 invoke scope。它还剥离了 Entra v2.0 拒绝的旧版 resource 参数，添加 response_mode=query 以便桌面客户端捕获授权码，并用 bearer token 代理 /mcp。

One detail is worth calling out because it is the only place DCR appears in the whole system. MCP clients expect DCR, a POST /register call that hands back a client ID. Rather than implementing true dynamic registration, the proxy uses a stubbed /register that returns a fixed, pre-provisioned client ID. DCR is emulated, not real.

有一个细节值得指出，因为它是整个系统中唯一出现 DCR 的地方。MCP 客户端期望 DCR，即一个返回 client ID 的 POST /register 调用。proxy 没有实现真正的动态注册，而是使用一个 stubbed /register 返回一个固定的、预置的 client ID。DCR 是被模拟的，而非真实的。

The full handshake looks like this:

完整的握手过程如下：

Figure 4: The OAuth and DCR authentication sequence

For the end user, the payoff is that configuration is only the proxy URL and an empty oauthScopes list, no AWS credentials, a browser login on first connect, and automatic token refresh thereafter.

对最终用户而言，收益是配置只需要 proxy URL 和空的 oauthScopes 列表，无需 AWS 凭证，首次连接时浏览器登录，之后自动刷新 token。

The infrastructure is defined in AWS Cloud Development Kit (AWS CDK), a TypeScript monorepo using npm workspaces. The internal agent runs as a Docker container on AgentCore runtime. Environment-specific configuration, such as tenant, client, and resource identifiers, is supplied through AWS Systems Manager (SSM) parameters.

基础设施在 AWS Cloud Development Kit (AWS CDK) 中定义，这是一个使用 npm workspaces 的 TypeScript monorepo。内部 agent 在 AgentCore runtime 上作为 Docker 容器运行。环境特定配置（如 tenant、client 和 resource 标识符）通过 AWS Systems Manager (SSM) 参数提供。

Before going live, HEMA deployed HAL to a staging environment and opened it to both engineers and business users for hands-on testing over a one-month period. This validated answer quality, coverage gaps, and day-to-day usability before the solution was promoted to production for wider adoption across the organization.

上线前，HEMA 将 HAL 部署到预发环境，并在一整个月的时间里向工程师和业务用户开放，进行实操测试。这验证了答案质量、覆盖缺口和日常可用性，之后才将方案推向生产，在整个组织内推广。

HAL began as a developer tool, but it is already a cross-role assistant, and that breadth is the point.

HAL 起步是一个开发者工具，但它已经是一个跨角色的助手，而这正是其价值所在。

Developers use the full technical surface: documentation, API specifications, Kafka topics and schemas, the service catalog, and DCL channels, from inside Kiro and the chat.

开发者使用完整的技术层面：文档、API 规范、Kafka 主题和模式、服务目录，以及 DCL 通道——都从 Kiro 和聊天界面内访问。

Product owners rely on HAL for documentation, how-to, and process knowledge: the procedural layer that used to have no home.

产品负责人依赖 HAL 获取文档、操作指南和流程知识：这些曾经无处归属的流程性知识。

Business analysts use HAL for infrastructure knowledge: which services exist, what APIs they expose, and which teams own them, drawing directly on the service catalog.

业务分析师使用 HAL 获取基础设施知识：存在哪些服务、它们暴露哪些 API、哪些团队拥有它们——直接从服务目录中提取。

The pull from non-developer roles is real and growing: HEMA's end-to-end team, mapping and optimizing product-manager processes, is already engaging with HAL as part of that work. Internally, HAL is distributed through an "Everyone Skill" and accompanying steering files, shared and maintained through the monthly HEMA AI Development Forum.

来自非开发者角色的需求是真实且不断增长的：HEMA 的端到端团队在映射和优化产品经理流程时，已经将 HAL 纳入了工作。在内部，HAL 通过"Everyone Skill"及配套的引导文件分发，在每月一度的 HEMA AI Development Forum 上共享和维护。

What's next: From answers to actions

下一步：从答案到行动

Today, HAL is read-only and delivers instant answers. The next step is instant action, performed by the same assistant.

目前 HAL 是只读的，提供即时答案。下一步是即时行动，由同一个助手执行。

This is feasible now precisely because the underlying portals are already API-enabled and already integrated with existing Microsoft Entra ID single sign-on. That means HAL can expose those operations as MCP action tools using the very same Entra ID authentication and Active Directory group authorization model that already secures the read tools. No new security model is required, only new, carefully scoped tools.

之所以现在可行，正是因为底层门户已经 API 化，并已与现有 Microsoft Entra ID 单点登录集成。这意味着 HAL 可以使用与保护只读工具相同的 Entra ID 认证和 Active Directory 组授权模型，将这些操作暴露为 MCP action tools。不需要新的安全模型，只需要新的、精心界定范围的工具。

The flagship example is provisioning a new AWS account. Today a developer goes to a dedicated portal to request one. Next, they will make the same request directly from chat, Kiro, Claude, or other agents without visiting the portal at all. And because HAL already serves product owners and business analysts, the same action pattern extends naturally beyond developer operations to the wider set of operational requests those roles make every day.

旗舰示例是配置新的 AWS 账户。今天开发者要去专用门户请求配置。未来，他们将直接从聊天、Kiro、Claude 或其他 agents 发出相同请求，完全无需访问门户。而且因为 HAL 已经服务于产品负责人和业务分析师，同样的行动模式自然延伸到开发者运营之外，扩展到这些角色日常提出的更广泛运营请求中。

The lesson is that the read architecture earns the write step: by getting identity, multi-client access, and governance right for answers, we have laid the groundwork for actions.

经验是：读架构为写步骤铺路：通过在答案层面把身份、多客户端访问和治理做对，我们已经为行动层奠定了基础。

HAL puts HEMA's organizational knowledge in one governed place. MCP and Amazon Bedrock AgentCore make that knowledge reachable, multi-client, and secure without forcing every consuming application to rebuild authentication, authorization, or routing from scratch. The outcome isn't a developer chatbot, but a cross-role assistant for developers, product owners, and business analysts alike. The knowledge layer is live. The logical next step is extending it into an action layer. There, the same governed, authenticated infrastructure that today answers questions could tomorrow execute requests: provisioning access, triggering workflows, and acting on behalf of users directly from chat, Kiro, Claude, or other MCP-compatible agents.

HAL 将 HEMA 的组织知识置于一个统一治理的地方。MCP 和 Amazon Bedrock AgentCore 使这些知识可触达、多客户端化且安全，无需每个消费应用都从零重建认证、授权或路由。结果不是开发者聊天机器人，而是面向开发者、产品负责人和业务分析师的跨角色助手。知识层已经上线。合理的下一步是将其扩展为行动层。在那里，今天用于回答问题的相同治理认证基础设施，明天可以执行请求：从聊天、Kiro、Claude 或其他 MCP 兼容的 agents 直接为用户配置访问、触发工作流和代为行动。

If you want to explore the building blocks used in this post, the following resources are a good starting point. To learn about MCP server hosting, authentication, and gateway routing, see the Amazon Bedrock AgentCore documentation. For the Model Context Protocol specification and client compatibility guidance, visit the MCP specification site. To get hands-on with Strands Agents, the open source agent framework used to build HAL's internal agent, see the Strands Agents GitHub repository. If you're building a similar knowledge layer for your organization, the Amazon Bedrock workshop walks through RAG patterns, Knowledge Bases, and guardrails in a guided environment.

如果您想探索本文使用的构建块，以下资源是很好的起点。要了解 MCP server 托管、认证和 gateway 路由，请参阅 Amazon Bedrock AgentCore 文档。要获取 Model Context Protocol 规范和客户端兼容性指导，请访问 MCP 规范站点。要动手实践 Strands Agents（HEMA 用以构建内部 agent 的开源 agent 框架），请参阅 Strands Agents GitHub 仓库。如果您正在为组织构建类似的知识层，Amazon Bedrock workshop 以引导环境讲解 RAG 模式、Knowledge Bases 和 guardrails。

For related reading, see Building and connecting a production-ready ecommerce MCP server using Amazon Bedrock AgentCore and Mistral AI Studio and Introducing Amazon Bedrock AgentCore Identity: Securing agentic AI at scale.

相关阅读，请参阅使用 Amazon Bedrock AgentCore 和 Mistral AI Studio 构建和连接生产就绪电商 MCP server，以及推出 Amazon Bedrock AgentCore Identity：大规模保护 agentic AI。