AWS整合Bedrock AgentCore、MCP与Nova 2 Sonic，打造全渠道订单系统——首个企业智能体实战展示

AWS发布了一个架构示例，首次将其三项新智能体服务——Bedrock AgentCore Runtime、MCP协议（模型上下文协议）和Nova 2 Sonic语音模型——整合到一个全渠道订单的实际场景中。该演示展示了一家餐厅如何同时通过语音电话、网页表单和文字聊天接收订单，由一个统一的智能体层协调所有三个渠道。

为何这次集成比普通教程更重要？

自AWS在上届re:Invent上宣布AgentCore以来，大多数公开示例都停留在「Hello World」层面——一个智能体、一个工具、一个渠道。这次架构是首次同时使用企业智能体的三大核心构建块：隔离的运行环境、用于外部工具的标准化协议，以及低延迟流式语音模型。

Bedrock AgentCore Runtime是智能体的托管执行环境。每个智能体会话运行在独立的microVM（微型虚拟机，通常是Firecracker）中，提供企业级隔离——两个并发智能体之间不会发生内存或状态泄漏，且运行时内置超时、内存和可观测性钩子。这与开发者自行在Lambda函数中运行LangChain等框架的DIY方式形成鲜明对比。

**MCP（模型上下文协议）**是Anthropic提出、AWS现已作为标准工具暴露方式支持的协议。智能体无需为每个模型使用自定义函数调用方案，而是获得一个MCP服务器列表（例如「库存系统」、「支付」、「订单」），并以统一格式与之交互。本示例使用MCP访问餐厅库存、价格和POS系统。

Nova 2 Sonic是AWS新推出的音频基础模型，语音到语音，低延迟，适合实时电话对话。它不是先将语音转为文本再转回来——而是直接处理音频令牌，消除了传统STT+LLM+TTS管道的累积延迟。

架构在实践中如何运作？

AWS博客中展示的场景如下：一位餐厅顾客致电并通过语音下单——电话连接到Nova 2 Sonic流式端点，该端点维持对话并将结构化意图（订单项目、修改、支付方式）传递给AgentCore智能体。与此同时，另一位顾客通过网页聊天下单——同一智能体层通过REST API接收文本，并将其传递给使用同一MCP栈的同一智能体处理。

两个渠道的智能体使用完全相同的工具集——用于检查库存（菜品是否可用）的MCP服务器、确认价格的MCP服务器，以及录入POS的第三个MCP服务器。整个协调过程在AgentCore Runtime中完成，尽管共享同一运行时，但每位顾客的会话内存是独立跟踪的。

与昨天发布的ToolSimulator有何不同？

这是理解AWS智能体栈的关键。ToolSimulator（在早间新闻中发布）是开发工具——开发者无需真正调用工具即可模拟智能体，适用于单元测试和评估。AgentCore Runtime是同一故事的另一面——在真实基础设施中执行智能体，使用真实工具调用、真实用户和真实计费。

ToolSimulator与AgentCore Runtime的组合为开发团队提供了完整的从开发到生产路径。在ToolSimulator中开发意味着更快的迭代和更低廉的测试成本；部署到AgentCore Runtime则意味着同一智能体上线时具备企业级隔离、审计日志和通过CloudWatch的可观测性。

对于已使用Bedrock的AWS客户，这篇博客是2026年首批严肃智能体试点项目的蓝图。餐厅订单是示例领域，但同样的架构可以直接应用于联络中心、旅行社、银行语音机器人，以及任何业务跨多个渠道进行的场景。问题只在于AWS的合作伙伴和集成商接手这一蓝图、将其转化为首个可公开展示的生产部署的速度。