AI辅助整理：本文基于下方列出的公开原始来源改写，不代替原文。
核心摘要： AWS 官方博客介绍如何在 Amazon Bedrock AgentCore 上构建并部署 MCP Apps：用 AgentCore 运行时托管 MCP 服务器，用 AgentCore Gateway 暴露统一端点，业务逻辑仍放在原有服务中。示例应用以“独角兽租赁”演示浏览、预订、查看与归还四步交互，AI 宿主可直接渲染卡片式 HTML 组件而非纯文本。来源未披露该方案在真实客户环境中的业务指标。
业务背景：用户开始从AI宿主访问服务
越来越多用户通过 ChatGPT、Claude 这类 AI 宿主与数字服务交互。对企业来说，这意味着服务入口正在从自有 App 和网页，扩展到第三方 AI 对话界面。
问题在于，如果为每个宿主单独做适配，维护成本会迅速上升。企业需要一种方式，让服务在多个宿主中以一致的形态出现，并且能承载比纯文本更丰富的界面。
问题：纯文本交互撑不起转化路径
在纯文本模式下，用户问“有哪些可租”，得到的是文字列表；要下单还得再描述一遍。对于商品浏览、预订确认这类场景，缺少结构化界面会拉长交互链路。
MCP Apps 的思路是扩展 Model Context Protocol，让 AI 宿主直接渲染交互式 HTML 组件。工具返回结构化数据，宿主把数据注入沙箱 iframe 中的组件完成渲染，用户看到的是卡片而不是一段文字。
AI 怎么落地：薄协议层加原有业务逻辑
示例架构中，MCP 服务器运行在 AgentCore 运行时上，前面由 AgentCore Gateway 暴露单一安全端点。业务逻辑放在独立的 Lambda 函数中，对接 DynamoDB 做持久化，这个函数完全不了解 MCP。
官方强调，MCP 服务器只是一个薄协议适配器。企业现有的 ECS、EKS 或其他计算服务可以原样保留，通过标准调用方式接入 MCP 层，不需要为了接入 AI 宿主重构后端。
实施步骤：从工具注册到宿主连接
服务器侧需要注册两类能力：工具负责业务动作，如查询、预订、查看与归还；资源负责返回组件 HTML。工具配置中的资源 URI 字段告诉宿主该渲染哪个组件，工具响应中的结构化数据会被注入组件。
部署上，代码打包上传后创建 AgentCore 运行时资源，指定运行环境、入口与 MCP 协议模式。随后在宿主侧添加连接器，填入网关地址即可。文中给出了 ChatGPT 与 Claude 的具体配置路径。
结果证据与边界：演示应用，非客户收益
文中演示的独角兽租赁应用展示了四步交互：列出可租对象并渲染卡片、完成预订并显示确认信息、查看当前租用、归还并结算费用。其中查看与归还返回纯文本，说明并非每个请求都需要富界面。
需要说明的是，这是 AWS 提供的示例应用，来源未披露任何真实客户的转化率、成本或效率数据。方案价值在于架构模式可复用，而非效果数字可引用。
可复制动作：安全边界要先于功能上线
官方建议在生产部署时，对工具参数使用严格模式校验，并在业务逻辑层再次校验，避免下游服务信任未经验证的输入。跨边界的非结构化文本应经过内容过滤、越界话题拦截与敏感信息脱敏。
网关侧应配置 IP 白名单、托管威胁检测规则与限流，运行时用资源策略限制可调用主体。监控方面可关注网关请求指标、函数调用与运行时容器健康，并对错误率与延迟设置告警。
证据与边界
- 来源为 AWS 官方博客，含完整架构图、部署脚本与示例代码仓库。
- 示例应用为演示性质的独角兽租赁系统，来源未披露真实客户业务指标。
- 文中给出 WAF、IAM 执行角色、资源策略等安全配置说明，可核实。
企业今天可以做什么
建议企业先梳理哪些服务适合前置到 AI 宿主，例如商品查询、预约、订单状态；再评估是否用托管运行时承载 MCP 服务器，避免自建会话隔离与扩缩容。上线前应在信任边界做参数校验与内容过滤，并对网关端点配置访问控制与限流。