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

本文展示如何部署一个基于 Amazon Bedrock AgentCore 和 Amazon Nova 2 构建的多模态 WhatsApp 点餐助手。许多快餐连锁将点餐渠道分散在 App、网站、电话热线和柜台。每个渠道都是一套独立的系统，需要分别构建和运行。同时这些渠道还会将顾客历史割裂开来，使同一位顾客在每个渠道上都像是陌生人。顾客已经生活在自己的即时通讯应用中。WhatsApp 覆盖超过二十亿用户。顾客可以在同一对话中发送文字、语音消息或拨打电话，无需安装任何应用或登录账号。

一个 WhatsApp Business 号码承载这个助手。顾客可以给餐厅发文字、发送语音消息或拨打电话。一个 AI 智能体从头到尾处理订单，从问候到确认。三个渠道共享同一个后端和跨渠道记忆。今天发文字，明天打电话的顾客会被识别为同一个人。

该解决方案使用 Meta WhatsApp Business Platform 作为顾客入口。Amazon Bedrock AgentCore 承载这些智能体。Amazon Nova 2 Lite 通过 Amazon Bedrock Converse API 处理文本，Amazon Nova 2 Sonic 处理语音消息和通话中的实时语音。这些智能体通过 Model Context Protocol（MCP）访问餐厅后端。整个系统使用 AWS Cloud Development Kit（AWS CDK）部署。渠道和点餐逻辑保持分离，因此添加或移除渠道时后端不需要改变。

该设计将三部分分离：（1）WhatsApp 层处理对话，（2）三个智能体运行时为其各自的渠道运行对话，（3）后端持有菜单、购物车、订单和位置信息。入站流量到达一个 HTTPS webhook，立即返回 200 确认，然后异步处理，这样不会有任何请求阻塞响应。这种分离使每一层都可以独立部署，也更容易理解。

顾客入口是 Meta WhatsApp Business Platform。它暴露 Cloud API webhook、Messages API、Media API 和 Calling API。Meta 负责管理此服务。你将其作为先决条件进行设置和连接，而不是由本解决方案部署。AWS CDK 在 AWS 侧配置所有资源。它发出你在 Meta 注册的 webhook URL。

你使用 AWS CDK 按依赖顺序部署以下 AWS 资源作为一组堆栈，按功能分组。

Amazon API Gateway 提供两个 REST API。第一个是基于 AWS 托管证书的区域性 HTTPS webhook。这是唯一的公共端点。第二个是在点餐逻辑前面的 AWS Identity and Access Management（IAM）授权后端 API。

AWS Lambda 运行 webhook 摄取、webhook 处理程序、消息发送器和点餐业务逻辑。

Amazon Simple Queue Service（Amazon SQS）提供入站队列，包含死信队列，将快速确认与剩余处理解耦。

AgentCore 运行时是 Amazon Bedrock AgentCore 的一项能力，承载三个智能体。每个对话在其自己的 microVM 中运行。会话保持隔离。

Amazon Nova 2 Lite（通过 Converse API 处理文本）和 Amazon Nova 2 Sonic（语音转语音处理语音）通过 Amazon Bedrock 调用。

AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项能力，是一个托管的 MCP 服务器，将后端 REST API 暴露为 MCP 工具，智能体按名称调用。

AgentCore 内存是 Amazon Bedrock AgentCore 的一项能力，是一个共享的跨渠道记录，以哈希后的顾客 ID 作为键。

Amazon DynamoDB 存储顾客档案、订单、菜单项、购物车和位置。它还存储 WhatsApp 层的最后一个入站窗口表。

Amazon Location Service 处理地理编码和最近位置查询。

Amazon Kinesis Video Streams（Amazon KVS）提供一个信令通道，语音通话运行时使用它来为托管的 NAT 遍历中继（TURN）中继生成凭证，该中继承载通话媒体。

带有单个网络地址转换（NAT）网关的 Amazon Virtual Private Cloud（Amazon VPC）是语音通话运行时的出站路径。这是唯一需要 VPC 的运行时。

AWS Secrets Manager 持有 Meta Access Token、App Secret 和 Verify Token，创建为空容器，你通过带外方式填充。AWS Systems Manager Parameter Store 持有顾客 ID 加盐值。

Amazon Elastic Container Registry（Amazon ECR）、AWS CodeBuild 和 Amazon Simple Storage Service（Amazon S3）构建并存储 ARM64 智能体容器镜像。

Amazon CloudWatch 捕获日志和指标，AWS Key Management Service（AWS KMS）加密静态数据。

图 1 显示了完整的架构。该图将解决方案组织成标记为 A 到 G 的分组，每个分组承载请求路径。两个辅助分组位于该路径之外，处理在部署时运行一次以构建智能体镜像的构建管道，以及在运行时支持每个渠道的安全和监控服务。

图 1：AWS 上的多模态 WhatsApp 点餐架构

A. WhatsApp 入口和投递：Webhook API Gateway、摄取 Lambda、处理程序 Lambda 和发送器 Lambda，以及 Amazon SQS 队列。摄取器验证 Meta 签名并将消息加入队列。处理程序处理剩余的处理。发送器 Lambda 投递回复。

B. 智能体运行时：AgentCore 运行时上的三个智能体，每个都是一个 ARM64 容器，每个渠道一个：聊天（Amazon Nova 2 Lite）、语音消息（Amazon Nova 2 Sonic）和语音通话（通过 Web 实时通信即 WebRTC 的 Amazon Nova 2 Sonic）。只有语音通话运行时在 VPC 中运行。

C. 人工智能和机器学习（AI/ML）：通过 Amazon Bedrock 调用的 Amazon Nova 2 Lite 和 Amazon Nova 2 Sonic，加上共享的 AgentCore 内存（以哈希后的 customer_id 作为键）用于跨渠道连续性。

D. MCP 服务器（托管）：AgentCore Gateway 将后端 REST API 暴露为可发现的 MCP 工具（GetMenu、AddToCart、PlaceOrder 等），每个运行时按名称调用。

E. API 和计算：IAM 授权的后端 API Gateway 和持有业务逻辑的点餐 Lambda。

F. 数据存储：Amazon DynamoDB 存储顾客档案、订单、菜单项、购物车和位置。

G. 网络和位置：用于地理编码和最近位置查询的 Amazon Location Service、用于语音通话媒体的 Amazon KVS 托管 TURN 中继，以及作为语音通话运行时出站路径的带有 NAT 网关的 VPC。

两个辅助分组位于请求路径之外。构建管道（AWS CDK、AWS CodeBuild、Amazon ECR 和 Amazon S3）在部署时运行一次以构建并存储 ARM64 智能体镜像。它不在任何请求的路径中。安全和监控（AWS Secrets Manager、AWS Systems Manager Parameter Store、Amazon CloudWatch 和 AWS KMS）在运行时支持每个渠道。

以下步骤通过架构端到端追踪单个请求：

Meta 向 Webhook API Gateway 和 Webhook 摄取 Lambda 投递入站 webhook（文字、语音消息或通话事件）。

摄取器验证 Meta 签名，加入 Amazon SQS 队列，并在 Meta 的时间窗口内返回 200。

Webhook 处理程序使用 AWS Systems Manager Parameter Store 中的加盐值推导出一个假名顾客 ID。

处理程序从 Meta Media API 获取媒体，并在 Amazon Bedrock AgentCore 运行时上调用匹配的智能体（聊天、语音消息或语音通话），session_id = customer_id。

运行时在会话开始时从 AgentCore 内存中读取顾客的长期洞察。

它通过 Amazon Bedrock 使用 Amazon Nova 2 Lite（文本）或 Amazon Nova 2 Sonic（语音）运行对话。

AgentCore Gateway 是托管的 MCP 服务器。它将后端 REST API 暴露为智能体按名称调用的 MCP 工具。

工具通过后端 API Gateway 路由到 AWS Lambda、Amazon DynamoDB 和 Amazon Location Service。语音通话媒体使用 Amazon KVS TURN 中继（运行在 VPC 中）。

回复通过发送器 Lambda（文本）或处理程序（语音）发出。事件在会话结束时写回内存。

AWS CDK 通过 AWS CodeBuild 将 ARM64 镜像构建到 Amazon ECR。Amazon CloudWatch 记录组件日志，AWS KMS 加密静态数据。

简而言之，每个请求都从 Meta 的 webhook 流向摄取器、队列、处理程序和智能体运行时，再到后端工具，然后通过 WhatsApp 返回给顾客。

所有三个渠道共享同一个入口、后端工具和内存。不同的是线上的媒体和处理它的运行时。

文本消息：文本消息到达 webhook。处理程序推导 customer_id 并调用聊天运行时，聊天运行时读取内存，通过 Converse API 流式传输 Amazon Nova 2 Lite，并根据需要通过 MCP 网关调用后端工具。回复通过发送器 Lambda 发出，事件在会话结束时写回内存。

图 2 展示了文本流程：从入站 Webhook 经过 Converse API 上的 Amazon Nova 2 Lite，到由 Sender Lambda 送达的回复。

图 2：使用 Amazon Nova 2 Lite 的文本流程

语音笔记（语音对语音）：语音笔记以音频消息形式到达。Worker 下载 OGG Opus 字节并调用语音笔记运行时。读取记忆后，音频被解码为 16 kHz 脉冲编码调制（PCM）并输入有边界的 Amazon Nova 2 Sonic 语音对语音会话。工具通过同一网关访问。口语回复作为 WhatsApp 语音消息返回。路径中没有转录服务，是真正的语音输入、语音输出。

图 3 展示了语音笔记流程，这是一个有边界的 Amazon Nova 2 Sonic 语音对语音会话，返回口语回复，路径中无转录环节。

图 3：使用 Amazon Nova 2 Sonic 的语音笔记流程

语音通话（WebRTC）：客户选择"通话"，Meta 的 Calling API 发送一个包含 WebRTC 会话描述协议（SDP）offer 的连接 Webhook。Worker 以仅通话模式将其转发给语音通话运行时，因为它没有公网 IP。TURN 凭证来自 Amazon KVS。Meta 不提供渐进式 ICE（Interactive Connectivity Establishment）路径。aiortc 应答方等待 ICE 收集并返回一次性 SDP answer。Worker 将该 answer 发送给 Meta。媒体随后通过 Datagram Transport Layer Security 和安全实时传输协议（DTLS/SRTP）经由 KVS 托管的 TURN 中继传输。Amazon Nova 2 Sonic 驱动对话。

图 4 展示了语音通话流程，其中 WebRTC 媒体通过 Amazon KVS 托管的 TURN 中继转发，Amazon Nova 2 Sonic 驱动对话。

图 4：使用 Amazon Nova 2 Sonic 的语音通话流程

该解决方案在两个领域有前置条件：你的 AWS 账户和你的 Meta WhatsApp 配置。在运行部署之前完成两项，因为它要求你提供特定的 WhatsApp 值，在这些值就位之前，智能体无法回复。

你需要 一个启用了 Amazon Bedrock 模型访问权限的活跃 AWS 账户，在部署区域可访问 Amazon Nova 2 Lite（amazon.nova-2-lite-v1:0）和 Amazon Nova 2 Sonic（amazon.nova-2-sonic-v1:0）。你的 IAM 用户或角色必须拥有部署 AWS CDK 堆栈及创建此解决方案所用资源的权限，包括 AgentCore 运行时、Gateway 和 memory。在本地机器上，安装 Node.js 24.x 或更高版本、配置了凭证的 AWS CLI 2.x 以及 git。最后，在目标账户和区域中引导 AWS CDK（npx cdk bootstrap aws://<ACCOUNT_ID>/<REGION>）。

智能体容器在 AWS CodeBuild 上的 ARM64 中构建，因此你无需在本地安装 Python、Docker 或音频工具链。部署在 AWS 区域中进行，确保 Amazon Nova 2 Lite、Amazon Nova 2 Sonic 以及 AgentCore 运行时、Gateway 和 memory 均可用。美国东部（弗吉尼亚北部）区域（us-east-1）是一个不错的起点。

有关按区域的模型可用性，请参阅 Amazon Bedrock 中的按 AWS 区域划分的支持模型。

WhatsApp Business Platform（Meta）前置条件

WhatsApp 端在 Meta 控制台中一次性设置完成，作为前置条件而非本演练中的步骤。没有 AWS API 可以为你创建 Meta 应用，因此先完成它，并在部署前准备好相关值。对于演示，Meta 沙箱测试号码（免费提供）就足够了。你不需要企业验证或生产号码。完整流程位于 Meta 文档中，相关链接见下一节。

部署前准备好以下项目：

一个已添加 WhatsApp 产品的 Meta 开发者应用，链接到一个 Business portfolio。添加产品会免费配置一个 WhatsApp Business Account（WABA）和一个沙箱测试号码。请参阅 Cloud API 入门。

App ID 和 App Secret。App Secret 是 Meta 用于对每个 Webhook 签名的密钥，Webhook Lambda 会重新计算该签名。

一个 Access Token。临时令牌适用于快速测试，大约 24 小时后过期。对于更长期有效的令牌，创建一个具有 whatsapp_business_messaging 和 whatsapp_business_management 范围的 System User 令牌。

Business portfolio ID（设置 CLI 可以自动发现 Phone Number ID 和 WABA ID）。

一个你自己生成的 Verify Token。这是一个难以猜测的字符串，Meta 在一次性 Webhook 验证握手期间会将其回传。

对于语音通话，在号码上启用 WhatsApp Calling API。

不要将以上任何内容存入源码管理。Access Token、App Secret 和 Verify Token 属于密钥，在部署期间进入 AWS Secrets Manager，而不是进入 CDK 模板。

使用 AWS CDK 部署解决方案

完整解决方案位于 GitHub 上的示例仓库中。仓库包含三个智能体容器、AWS CDK 基础设施代码以及将 WhatsApp Webhook 连接到你账户的设置脚本。克隆它，运行部署前检查，然后使用前缀部署。前缀被添加到每个资源名称中，因此你可以在每个账户中部署多次。

git clone https://github.com/aws-samples/sample-multimodal-whatsapp-restaurant-agent.git
cd sample-multimodal-whatsapp-restaurant-agent
./scripts/preflight-check.sh
./scripts/deploy-all.sh --deploymentPrefix qsr-wa

脚本按依赖顺序部署每个堆栈。它将每个堆栈的输出传递给下一个。首先部署共享 VPC。然后部署后端：Amazon DynamoDB、Amazon Location Service、订购 Lambda 和后端 REST API。接着部署 AgentCore Gateway 和共享 AgentCore memory。然后使用 AWS CodeBuild 构建每个 ARM64 容器，推送到 Amazon ECR，并部署三个运行时。之后部署 WhatsApp Webhook 和订单通知器。然后填充示例菜单和位置数据。每个容器的首次构建大约需要 8–12 分钟。对于引导式浏览器体验，请使用 ./scripts/deploy-all.sh --interactive-web-ui。

WhatsApp 值如何到达部署环节对安全性至关重要。CDK 为三个密钥创建空的 Secrets Manager 容器。它不将密钥作为 CDK 参数接收，否则会将其烘焙到合成的模板中。你在带外填充密钥值，而非密钥标识符（Phone Number ID、WABA ID、App ID）作为参数跟随。scripts/whatsapp-setup/ CLI 通过两个流程处理此事。部署前流程验证 Access Token 并自动发现 WABA 和 Phone Number ID。它在需要时生成 Verify Token 并填充密钥。部署发出 Webhook URL 后，部署后流程在 Meta 中设置回调 URL、Verify Token 和订阅字段。然后订阅 WABA 并完成验证握手。

cd scripts/whatsapp-setup
npm start          # choose "Pre-deploy", then "Post-deploy" after deploy
node whatsapp-setup.mjs --doctor   # read-only end-to-end check

一旦 Webhook 被订阅且密钥被填充，号码即上线，智能体将在所有三个渠道上回复。

快速确认并异步处理

Meta 期望一个带有 200 OK 状态码的即时 HTTP 响应。接单、获取媒体、调用智能体和中继通话信令需要比这个简短确认窗口更多的时间。因此工作分为两部分。Webhook Ingest Lambda 只做快速、安全的部分，即验证签名、入队到 Amazon SQS 并返回 200。然后 Webhook Worker Lambda 消费队列并完成其余处理。突发消息变成一个待处理的队列，公共表面保持为一个端点。如果 Worker 处理某条消息失败，该消息会返回队列并重试。经过几次失败尝试后，消息进入死信队列以供后续检查。

跨三个渠道共享一个记忆

让这一切感觉像一个智能体的是共享记忆。单个 AgentCore memory 资源以哈希后的 customer_id 为键，三个运行时都使用同一个键。每个运行时在会话开始时读取客户的长期洞察，并在结束时写回事件。洞察包括过去的订单、最喜欢的菜品以及客户之前提到的偏好。因为每个渠道都将同一客户解析到同一个记忆，今天发短信、明天打电话的客户被识别为同一个人的同一个号码。不需要协调单独的跨渠道状态。

使用 MCP 将智能体连接到后端工具

没有任何 AgentCore 运行时直接调用后端 Lambda 函数。AgentCore Gateway 是一个托管的 MCP 服务器。每个 AgentCore 运行时作为 MCP 客户端通过 HTTPS 连接到它，并通过运行时自带的 IAM 角色进行认证，通过名称来发现工具。每个运行时都携带自己的角色，因此网关只授予该运行时所需的访问权限。网关后面没有独立的 MCP 服务器。网关位于后端 REST API 的前端，为每个端点生成一个 MCP 工具。当智能体调用 PlaceOrder 这样的工具时，网关将其转换为后端 API Gateway 路由到匹配 Lambda 的 REST 请求。由于智能体调用的是命名工具而非特定函数，你可以更改处理程序或添加新工具而不必更改任何智能体。三个渠道都使用相同的工具和数据下单。购物车和订单工具负责所有定价和总计。智能体不参与计算，每笔订单都以 channel = "whatsapp" 为标识持久化到 Amazon DynamoDB。

存储菜单、购物车和订单

Amazon DynamoDB 表支撑着整个工作流程。包括：Customers（用于识别回头客的资料）、Orders（包含取餐地点和渠道的历史订单）、Menu（菜品、价格和供应状态）、Carts（带有生存时间的进行中购物车）以及 Locations（坐标、营业时间和税率，用于总价计算和推荐）。按需容量模式能够随流量自动扩展，因此无需管理吞吐量。

查找取餐地点

Amazon Location Service 帮助客户无需过多输入即可找到取餐地点。智能体将邮政编码或地址传递给服务进行地理编码得到坐标。后端随后对最近的餐厅进行排序，返回客户可以直接操作的明确选项。

无需登录的客户识别

WhatsApp 客户不登录，因此系统使用电话号码作为身份基础。它用 AWS Systems Manager Parameter Store 中的私密盐值对 E.164 格式电话号码进行哈希处理，结果作为 customer_id（格式为 "wa-" + sha256(E164 || Pepper)[:16]）。原始号码不会存储在内存或会话状态中，这有助于满足个人身份信息（PII）要求。如果匹配到已知客户，智能体会以姓名问候并调出其偏好设置；否则他们将作为新客户下单。发送回复的运行时本身不持有令牌或电话号码。Sender Lambda 在发送时通过"最近一次入站"窗口表解析收件人。这是识别机制，而非身份验证。需要验证的部署可以添加一次性密码等步骤。

没有 Web UI 或测试客户端。直接在装有 WhatsApp 的手机上给 WhatsApp Business 号码发消息或打电话即可。以下示例展示了一次典型对话（以"Agent"开头的行是智能体的回复，方括号中为工具调用）：

Customer: What's on the menu near 75201?

Agent:    [tools: GeocodeAddress, GetNearestLocations, GetMenu]
          Here's what's available at Amazing Burgers - Dallas:
          - Burger Combo ($8.99)
          - Chicken Tenders ($6.49)
          ...

Customer: A burger combo and a milkshake, please.

Agent:    [tools: AddToCart, GetCart]
          Added to your cart:
          - 1x Burger Combo - $8.99
          - 1x Milkshake - $3.49
          Total: $12.48. Want me to place the order?

Customer: Yes.

Agent:    [tools: PlaceOrder]
          Your order is placed and is being prepared for pickup at
          Amazing Burgers - Dallas. I'll let you know when it's ready.

语音笔记和语音通话通过 Amazon Nova 2 Sonic 运行相同流程。用户口述订单，智能体用语音回复。随着订单进展，订单通知器通过 WhatsApp 向客户主动推送状态更新。你可以在 Amazon CloudWatch Logs 中追踪对话记录。

你需支付系统使用的 AWS 服务费用，以及 Meta 的 WhatsApp 消息费。成本主要随对话量和语音流量的占比增长，语音每会话消耗的资源比文字更多。本示例部署了全部三个渠道（文字、语音笔记和语音通话），因此将部署限制在特定渠道可以降低基础成本。如需获取详细的、针对特定区域的估算，请使用 AWS Pricing Calculator 并参考 Meta 的 WhatsApp Business Platform 定价页面。在 AWS Cost Explorer 中设置预算，以便随着流量增长追踪支出。

WhatsApp 也能接收图片和文档。本解决方案专注于接单，不处理这些附件。如果你的用例需要处理附件，可以配置后端和聊天智能体来支持，因为 Amazon Nova 2 Lite 本身就是多模态的。智能体可以读取会员卡照片或 PDF 餐饮请求并将其转化为结构化订单。

这种模式也超越了餐饮行业。其核心构建块包括：一个商业号码、多个对话渠道、共享内存以及位于后端前面的 MCP 工具。同样的架构适用于零售客服、医疗信息采集、现场服务预约和许多其他领域。你通过更改后端工具和数据来适应不同领域，而渠道层和智能体层保持不变。

对于生产部署，请考虑启用 Amazon Bedrock Guardrails 来添加内容过滤和基础验证。这有助于确保智能体的回复保持在策略边界内，并减少幻觉输出。

为避免持续产生费用，请在完成后删除相关资源。清理脚本按相反顺序销毁资源栈，每个消费者先于其生产者被删除。

./scripts/cleanup-all.sh --dry-run   # 预览而不删除任何内容
./scripts/cleanup-all.sh             # 删除部署创建的所有资源栈

清理操作是破坏性的。它会删除 Amazon DynamoDB 中的订单历史记录、Parameter Store 中的私密盐值、Secrets Manager 中的密钥以及 Amazon ECR 中的镜像。请先备份需要保留的内容。它不会触及 Meta 侧，因此请单独在 Meta 控制台中取消订阅 webhook 并撤销令牌。完成后，在 AWS CloudFormation 控制台中确认资源栈已被删除。

本文详细介绍了多模态 WhatsApp 订餐智能体的架构和部署，它通过单一商业号码在文字、语音笔记和语音通话上端到端完成订单。异步 webhook 快速接收流量并将其余工作排队。AgentCore 运行时上的三个运行时各自处理其渠道。Amazon Nova 2 Lite 和 Amazon Nova 2 Sonic 运行对话。AgentCore Gateway 通过 MCP 工具将智能体与后端连接。单一的 AgentCore 内存为每位客户提供跨渠道的持续关系。