基于 Amazon Bedrock AgentCore 构建多模态 WhatsApp 点餐助手

传统快餐连锁的点餐渠道高度碎片化，App、官网、电话热线与线下柜台各自独立，不仅运维成本高，顾客数据也因此割裂，同一位顾客在不同渠道往往被视为陌生人。亚马逊云科技此次发布的方案将三种交互模式——文字聊天、语音消息和实时语音通话——统一接入单一 WhatsApp Business 号码，由 AI 智能体全程处理从问候到订单确认的完整流程，从根本上消除渠道孤岛问题。

方案在技术选型上采用分层架构：Meta WhatsApp Business Platform 作为顾客入口，Amazon Bedrock AgentCore 托管三个独立的智能体运行时，分别对应文字聊天（Amazon Nova 2 Lite）、语音消息（Amazon Nova 2 Sonic）和实时语音通话（Amazon Nova 2 Sonic over WebRTC）三个渠道。后端餐厅系统通过模型上下文协议（MCP）与智能体对接，AgentCore Gateway 将后端 REST API 封装为可发现的 MCP 工具，智能体按名称调用 GetMenu、AddToCart、PlaceOrder 等接口，渠道层与业务逻辑层实现彻底解耦。

跨渠道记忆是该方案的核心差异化能力。AgentCore Memory 模块以哈希处理后的顾客 ID 为键，维护一份跨渠道共享的顾客记录。无论顾客通过哪种方式联系餐厅，系统均能识别其身份并调取历史偏好与订单信息，真正实现「今天发消息、明天打电话」的无缝体验。这一设计避免了传统多渠道系统中顾客需要反复自我介绍的痛点。

在基础设施层面，方案通过 AWS CDK 将所有资源以依赖顺序编排为多个堆栈统一部署。入站流量经由单一 HTTPS Webhook 进入 Amazon API Gateway，Lambda 函数完成签名验证后将消息投入 Amazon SQS 队列异步处理，确保 200 响应即时返回、不阻塞后续流程。顾客画像、订单、菜单、购物车和门店位置数据存储于 Amazon DynamoDB，Amazon Location Service 负责地理编码与最近门店查询，实时语音通话的媒体流则通过 Amazon Kinesis Video Streams 提供的托管 TURN 中继传输。

安全与合规方面，Meta Access Token、App Secret 和 Verify Token 存储于 AWS Secrets Manager，顾客 ID 加盐参数保存在 AWS Systems Manager Parameter Store，静态数据由 AWS KMS 加密，日志与指标通过 Amazon CloudWatch 统一采集。值得注意的是，实时语音通话运行时是三个智能体中唯一需要部署在 Amazon VPC 内的组件，通过单个 NAT 网关提供出站路径，其余两个运行时无需 VPC 即可运行，降低了整体网络复杂度。

该方案对餐饮行业的实际意义在于：企业只需维护一套后端系统，即可同时服务文字、语音消息和语音通话三类顾客群体，且新增渠道时后端代码无需改动。随着 WhatsApp 在全球尤其是新兴市场的高渗透率，这一架构为餐饮品牌提供了一条低摩擦、高覆盖的数字化点餐路径，也为其他需要多渠道统一服务的行业提供了可复用的参考蓝图。

要点

• 单一 WhatsApp Business 号码同时支持文字、语音消息、实时语音通话三种点餐方式，顾客无需安装额外应用
• AgentCore Memory 以哈希顾客 ID 为键实现跨渠道共享记忆，同一顾客在不同渠道均可被识别并延续历史记录
• 渠道层与业务逻辑层通过 MCP 协议解耦，新增或移除渠道无需修改后端代码，系统可扩展性强
• 全套基础设施通过 AWS CDK 一键部署，涵盖 API Gateway、Lambda、SQS、DynamoDB、Location Service 等核心服务
• 实时语音通话运行时通过 Amazon KVS 托管 TURN 中继传输媒体流，是三个智能体运行时中唯一需要 VPC 的组件