Amazon Bedrock AgentCore MCP Apps 让交互式 AI 超越纯文本

Amazon Web Services 发布了一套完整的 Amazon Bedrock AgentCore MCP Apps 模式，将一个 MCP 服务器转变为可服务多个 AI 主机的交互式界面。9 月 11 日发布的这一方案意义在于，它让对话式集成超越了文本回复，同时不将底层服务绑定到某一种聊天产品。

AWS 示例允许用户浏览虚构的租赁库存、进行预订、查看进行中的租赁，并完成归还操作。部分回复会以对话内的交互式 HTML 卡片呈现；当界面无法带来太多额外价值时，其他回复则保持纯文本形式。

更大的竞争并非 AWS 与另一家云服务商之间的较量，而是主机中立的应用层与开发者目前为 ChatGPT、Claude 和其他 AI 客户端构建的定制集成之间的竞争。AWS 提供托管运行时基础设施，而 MCP Apps 扩展则定义了兼容主机如何发现和展示界面。

这种分离带来了一个颇具吸引力的承诺：服务器和小组件只需构建一次，便可在任何支持该扩展的环境中提供一致体验。但它也带来了核心不确定性：协议可移植性并不自动意味着完全相同的主机行为、生产级安全性或广泛的用户采用。

Amazon Bedrock AgentCore MCP Apps 将工具连接到小组件

这一新的 AWS 模式将由模型调用的工具与用户可在 AI 对话中查看和操作的界面连接起来。

名为 Unicorn Rentals 的示例应用始于一条要求展示可租赁库存的自然语言请求。主机不会返回文字版库存清单，而是渲染包含图片、名称、描述、小时费率和可用状态的卡片。

随后，用户可以要求预订某一只独角兽。应用会记录这笔交易，并展示包含预订标识符和租赁详情的确认信息。另一条请求可获取当前租赁记录，最后一条请求则完成归还并计算总费用。

虚构的主题让演示更易理解，但这一交互模型同样适用于常规商业软件。旅行服务可展示航班选项，支持系统可显示工单和状态控件。分析工具可以返回带筛选器的图表，而非用文字描述每一个数据点。

MCP Apps 是 Model Context Protocol 的一个扩展；该标准让 AI 主机能够发现并调用外部工具。传统 MCP 回复已可包含文本、图像、资源和结构化数据。该扩展新增了一种标准化方法，用于在这些结果旁交付交互式界面。

根据 MCP Apps specification，工具可以指定一个用户界面资源，由支持该功能的主机获取并在沙箱化框架中渲染。主机会将工具结果传递给该界面，并协调后续通信。

AWS 的实现通过 _meta.ui.resourceUri 字段将工具与其小组件关联。工具结果携带 structuredContent，为小组件提供渲染所需的数据。这种安排让界面声明与工具保持关联，而无需在每次回复中嵌入完整界面。

小组件被注册为 MCP 资源。主机通过标准协议调用发现可用工具和资源，并在需要展示界面时读取相应的 HTML 资源。

AWS 将服务器打包为使用官方 MCP SDK 和 @modelcontextprotocol/ext-apps 扩展的 TypeScript 应用。它通过 Express.js 服务器运行在 AgentCore Runtime 的 Node.js 22 环境中。

该公司的 参考实现提供了四项主要工具：列出库存、预订租赁、查看预订和归还租赁。它还包含视觉回复所需的小组件资源。

这不仅仅是为聊天机器人输出添加视觉呈现。该界面仍是由智能体协调的工作流的一部分。模型负责理解请求、选择工具并推动任务继续进行，而小组件则为用户提供更精确的结果审阅界面。

这种组合解决了纯聊天软件的一项基本弱点。文本很适合解释和简短确认；但当用户需要比较多个项目、检查结构化记录，或做出具有重要后果的选择时，文本就会变得低效。

轻量适配器是这项架构的押注

AWS 将 MCP 服务器视为轻量级协议适配器，把业务规则和持久化记录留在传统后端服务中。

该示例并未将所有应用职责都置于 AgentCore 部署中。专用的 AWS Lambda 函数负责库存查询和预订操作，而 Amazon DynamoDB 存储应用数据。

MCP 服务器在 AI 主机与业务层之间进行转换。它发布工具、描述可用界面资源、向后端发送请求，并返回结构化结果。

这一边界是该设计的核心。既有业务服务无需理解 MCP、小组件发现机制或主机渲染方式。它们可继续在适配器之后暴露标准 API 或 SDK 操作。

公司可以将演示中的 Lambda 函数替换为运行在 Amazon ECS 或 Amazon EKS 上的服务。只要服务器能够访问并妥善完成身份验证，也可以将适配器连接到 AWS 之外的系统。

这限制了与对话协议耦合的应用逻辑数量。库存规则、交易验证和数据持久化仍可被网站、移动应用、内部仪表板及其他客户端复用。

小组件层也可以独立变化。团队可以重新设计产品卡片、引入图表，或添加审核表单，而无需将底层业务流程迁入主机。

这种分离对采用具有实际影响。许多企业不会围绕新的 AI 界面重建成熟的交易系统。它们更可能在已运营的服务前部署一个受控的协议层。

相同逻辑也适用于知识工作流。团队往往需要结合文档、工具输出和用户决策，而无需将所有来源迁移到一个界面中。一个可搜索的知识库可以保留源材料，同时由交互式智能体在其上提供聚焦操作。

AgentCore Runtime 为适配器提供托管执行环境。AWS 表示，该运行时负责基础设施配置、扩缩容、运行状况管理和会话隔离。它将 MCP 作为原生协议模式支持，而非将每个请求都视为通用 Web 流量。

AWS 文档说明，MCP 部署通常监听 0.0.0.0:8000/mcp。运行时可支持无状态或有状态的 Streamable HTTP 服务器，具体取决于应用是否需要多步骤协议功能。

无状态模式适合可独立完成的工具调用。有状态模式则支持涉及信息征询、采样、进度通知或其他依赖持续会话的交互工作流。

这一差异对交互式应用至关重要。展示搜索结果的卡片可能几乎不需要持久的协议状态；多步骤审批或配置流程则可能需要在多次用户操作之间保持连续性。

当请求中不含 MCP 会话标识符时，AgentCore Runtime 会添加一个。这有助于将相关请求路由到同一运行时会话，但并不能免除应用管理用户身份的责任。

AWS 明确警告，AgentCore 不会强制执行用户与会话标识符之间的映射。客户端后端必须维护这种关联，并防止某个用户提交另一个用户的会话值。

因此，轻量适配器方法减少了协议耦合，但并未消除应用架构工作。团队仍需制定授权规则、输入验证、审计记录、后端错误处理和交易保障措施。

主机中立界面令定制集成承压

主要竞争压力落在那些要求开发者为每个 AI 客户端重建相似界面的主机专属应用层上。

在 MCP Apps 出现之前，多个项目通过不同的模式和 SDK 探索对话式界面。开发者可以为某一主机构建应用，但另一主机可能需要不同的元数据、渲染规则或通信方式。

MCP 社区推出 Apps 扩展，旨在建立共享的界面模型。其最初提案吸收了 MCP-UI、OpenAI 的 Apps SDK，以及与 OpenAI 和 Anthropic 都有关联的贡献者的工作成果。

该扩展提案将交互式界面描述为经常被请求的功能。它还指出，互操作性和一致的安全模式是推动标准化的原因。

AWS 现在正将这一规范转化为托管部署路径。其示例将 MCP 服务器部署在 AgentCore Runtime 上，并通过 AgentCore Gateway 对外提供服务。兼容主机接收的是一个端点，而不是一组 AWS 专属资源。

这在基础设施选择与分发选择之间形成了重要区别。团队可以将服务器部署在 AWS 上，同时无需选择 AWS 模型或 AWS 自有的对话主机。

AgentCore 本身支持多种框架和模型。AWS 将其运行时定位为面向使用 Strands Agents、LangGraph、CrewAI 及其他开发技术栈构建的智能体的基础设施。

然而，对于 MCP Apps，更重要的中立性体现在协议边界。AI 主机可调用工具并请求界面资源，无需直接访问 Lambda 函数或 DynamoDB 表。

AWS 表示，同一个 Unicorn Rentals 服务器可与 ChatGPT、Claude 及其他支持该扩展的主机协同工作。这一限定至关重要：主机中立性适用于兼容客户端，而非所有正在使用的聊天界面。

支持情况还可能因客户端版本、运行环境和启用功能而异。开发者在承诺同一界面可随处呈现前，必须核查当前的主机兼容矩阵。

即使在兼容主机之间，相同的协议消息也无法保证相同的呈现效果。主机控制其容器布局、沙箱、权限、无障碍行为以及部分交互模型。

服务器可以交付相同的小组件代码和结构化数据，但周边产品仍决定用户如何授权连接、发现应用、批准工具调用，以及如何在聊天与界面控件之间切换。

这正是该公告会给定制集成带来压力、却不会立即取代它们的原因。主机专属 SDK 可以提供共享扩展无法提供的功能，也可能与主机的导航、身份系统或分发渠道实现更紧密的集成。

中立路线提供的是另一种优势：将应用投入集中于服务器、数据契约和小组件，而不是为每个主机重复构建这些组件。

这能增强开发者和企业采购方的议价能力。如果应用能在不同宿主平台之间保持实用，更换对话前端的成本就会降低。后端以及大部分界面工作都可以保持不变。

实际效果取决于宿主厂商是否会继续围绕该扩展保持一致。标准的影响力来自兼容实现、可靠行为和有用的应用，而不只是发布本身。

托管网关解决的是可达性，而非信任

AgentCore Gateway 通过一个托管端点让 MCP 服务器可被访问，但示例中的访问模式需要经过有意识的生产级加固。

AWS 的架构在外部 AI 宿主与运行时之间部署了 AgentCore Gateway。网关使用其执行角色，通过采用 AWS Signature Version 4 身份验证的连接，将请求转发至运行时。

在该示例中，入站网关请求不使用身份验证。随后，AWS Web Application Firewall 会围绕公共端点实施 IP 白名单、托管威胁检测规则和速率限制。

这种安排简化了演示，因为外部宿主无需 AWS 凭证。但不应将其视为通用的生产环境身份验证设计。

示例仓库明确声明：未经适当的安全审查、测试和加固，并不适合用于生产环境。这一警告很重要，因为该应用执行的是操作，而不只是检索。

只读产品目录会限制潜在损害。预订、退货、购买、更改设置或批准操作，都可能影响持久化数据，并带来财务或运营后果。

IP 白名单可以缩小访问范围，但无法确认最终用户的身份。共享出口基础设施还可能使基于 IP 的规则不如基于账户或用户级别的授权精确。

生产团队需要明确身份验证在哪里结束、授权从哪里开始。宿主连接或许能够证明请求来自哪个服务，但应用仍必须确定每位用户可以查看或更改哪些记录。

服务器应验证每一项工具参数，而非假定模型生成的请求是安全的。它还应在后端执行授权，而不是依赖小组件隐藏不可用操作。

小组件代码应接受与其他 Web 应用代码同等严格的审查。MCP 宿主会在沙箱化框架中渲染这些界面，从而限制其对宿主页面的直接访问。但沙箱机制并不会验证应用的业务逻辑或数据处理方式。

小组件接收结构化工具输出，并可通过宿主中介的桥接层进行通信。团队必须将内容、网络目标和工具访问限制在界面实际所需的范围内。

提示词注入仍然值得关注，因为模型可能在选择或调用工具之前接触不可信文本。设计良好的界面并不能让不安全的工具变得安全。敏感操作仍需要确定性的检查，并在适当情况下要求明确确认。

AWS 的安全指南指出，服务器无状态运行时会为会话提供专用 microVM。根据文档，每个会话都将获得隔离的计算、内存和文件系统资源。

同一份指南也清晰说明了共同责任边界。应用所有者仍需负责 IAM 权限范围、依赖项安全、凭证处理、输入验证、网络规则以及会话与用户的绑定。

运行时会话中的执行角色凭证同样需要谨慎处理。在 microVM 内运行的代码可以访问提供给该环境的凭证。因此，最小权限策略仍然至关重要。

网关应仅有权限调用预定的运行时。运行时的资源策略应拒绝不相关主体的直接调用。后端服务还应分别限制运行时可发出的请求。

可观测性必须覆盖这些层级。团队需要足够的日志，来关联宿主请求、网关事务、运行时会话、工具调用、后端操作和用户身份，同时避免暴露敏感内容。

当一项对话请求产生多次工具调用时，这一点尤为重要。一次预订失败，可能源于宿主行为、协议处理、网关策略、运行时代码、后端验证或数据争用。

托管组件减少了基础设施工作，但并未将这些责任收拢为单一控制点。生产就绪程度将取决于团队如何清晰定义并测试每一条边界。

可移植性仍取决于宿主行为

从协议层面解释，MCP Apps 是可移植资源；但真正的可移植性必须经受发现、权限、渲染和更新差异的考验。

AWS 的演示支持了关于可移植性的最强论点：一台服务器发布工具、资源标识符、小组件 HTML 和结构化结果。支持该协议的宿主通过同一协议使用这一整套内容。

服务器无需为每个宿主单独实现一套业务逻辑。它也无需仅因用户从另一款兼容客户端启动任务，就提供不同的小组件包。

不过，共享传输格式只是兼容性的第一层。用户在小组件出现前，会经历完整的产品流程。

他们必须连接服务器、完成身份验证、理解所请求的权限、发现相关能力，并描述或发起操作。界面渲染后，他们还必须理解界面并完成工作流。

每个宿主都可能让这些阶段呈现不同体验。一个可能强调通过对话发现能力，另一个则提供应用目录。一个可能要求对每项外部操作进行确认，另一个则将批准请求分组处理。

响应式布局带来了另一项考验。适合宽屏桌面对话的小组件，可能会在移动设备上显得拥挤。键盘导航、屏幕阅读器、色彩对比度和焦点行为，也必须在宿主框架内正常运行。

失败处理需要特别关注。如果后端请求超时，界面应说明当前状态，而不能暗示操作已成功。重试操作也不得意外创建重复交易。

版本控制又带来一层复杂性。服务器可能更新小组件和工具 schema，而部分宿主会缓存资源，或仅支持较旧的扩展版本。兼容性测试必须覆盖计划内升级和部分发布状态。

官方扩展文档称，宿主会在沙箱化 iframe 中渲染界面资源，并通过 App Bridge 交换消息。这为通信和策略执行提供了共同基础。

但它并未规定每一项视觉细节。对于开放扩展而言，这是合理的边界，但也意味着开发者需要负责在多个客户端实现中测试同一应用。

因此，问题不在于相同代码能否跨平台运行，而在于它到达每个宿主后，最终任务是否仍然易懂、安全且可靠。

AWS 的示例还使用了数据模型紧凑的虚构租赁服务。真实应用则会涉及更大的结果集、账户权限、受监管数据、本地化和复杂的异常路径。

这些要求可能暴露隐藏的宿主依赖。某个设计可能依赖于特定视口、身份验证流程、文件选择器、浏览器能力或批准模式，而另一个宿主并不提供这些能力。

开发者应将可移植性定义为经过测试的服务水平，而不是二元的协议声明。核心工具契约应保持一致行为，同时将宿主特定的呈现差异控制在有限范围内并予以记录。

一套有用的测试方案，应在每个支持的宿主上运行相同的关键任务。团队应比较完成率、错误行为、授权提示、渲染性能、无障碍性以及后端副作用。

结果可能表明，大多数工作流适合共享小组件，而少数专门功能需要宿主特定体验。这样的结果仍能保留通用服务器的大部分价值。

三个信号将检验 AgentCore MCP Apps 的押注

下一阶段将由生产部署、跨宿主一致性，以及超越公开示例的安全模式决定。

第一个信号是，组织是否会将该架构应用于真实的事务型服务。演示证明了组件能够连接；生产部署则会同时检验身份、授权、可观测性、延迟、版本控制和故障恢复。

涉及账户专属数据的公开案例将增强这一论点。在不迫使后端进行重大改动的前提下，将 MCP 适配器置于现有服务之前的实现，也同样如此。

生产使用的证据将支持 AWS 的轻量适配器论点。如果团队反复将应用逻辑迁移到自定义宿主层，则表明该扩展可能尚不足以表达完整体验。

第二个信号是主要 AI 宿主之间是否提供一致支持。开发者应关注客户端兼容性列表、扩展版本支持情况，以及团队在多个环境中运行同一小组件的报告。

不断扩大的宿主支持矩阵，将加强 MCP Apps 能成为分发层的论点。即使每个客户端在技术上仍然兼容，巨大的行为差异也会削弱这一论点。

相关指标是任务完成情况，而不是勾选框。用户应能在无需接受宿主特定培训的情况下，连接、发现、理解并完成同一工作流。

第三个信号是可重复使用的生产安全设计是否出现。这些设计应涵盖用户身份验证、会话绑定、操作授权、小组件策略、审计轨迹，以及对不可信模型上下文的防护。

AWS 文档为调用 AgentCore Runtime 提供 IAM 和 OAuth 两种选项。其示例优先考虑易于理解的演示，而生产指南则将大量责任交给应用所有者。

面向经过身份验证的公共 MCP Apps 的清晰参考架构，将缩小这一差距。独立安全审查和部署模板将比单独的基础设施声明提供更有力的证据。

开发者还应关注 AgentCore Gateway 会话如何演进。AWS 文档称，网关管理的 MCP 会话可以保留状态，并减少重复初始化。带状态的功能需要谨慎的身份和生命周期控制。

对于企业采购方而言，当下的决定并不是是否用聊天替代所有界面，而是交互式对话界面能否复用成熟的业务服务，同时不再创建另一套孤立的应用栈。

对于开发者而言，AWS 示例提供了检验这一命题的具体起点。可将虚构 Lambda 服务替换为受控的内部 API，先让首批工具保持只读，并比较其在兼容宿主上的行为。

记录小组件对宿主做出的每一项假设。将工具调用视为不可信输入，将会话绑定至经过身份验证的用户，并让授权尽可能靠近数据所属系统。

Amazon Bedrock AgentCore MCP Apps 如今已具备可信的部署模式，不再只是协议图示。尚未回答的问题是：当真实身份、交易和宿主差异进入系统后，团队能否保持这种可移植性。

合理的下一步，是选择一个文本难以妥善处理的结构化工作流，并进行端到端测试。交互式小组件能否在多个宿主中降低用户负担，同时不削弱控制能力？其结果将比又一个精致的演示更能说明这一模式的价值。