详细内容或原文请订阅后点击阅览
使用 Amazon Bedrock AgentCore 部署多模式 WhatsApp 订购助手
了解如何部署基于 Amazon Bedrock AgentCore 和 Amazon Nova 2 构建的多模式 WhatsApp 订购助手，该助手通过单个企业号码上的文本、语音注释和实时语音通话来接受客户订单。渠道和订购层保持独立，一个共享内存可识别所有三个渠道中的每位客户。
来源:亚马逊云科技 _机器学习本文展示了如何部署使用 Amazon Bedrock AgentCore 和 Amazon Nova 2 构建的多模式 WhatsApp 点餐助手。许多快餐店通过应用程序、网站、电话线和柜台进行点餐。其中每一个都是一个单独的系统来构建和运行。每一个都将客户的历史记录碎片化，使同一个人在每个渠道上看起来都像陌生人。客户已经生活在他们的消息应用程序中。 WhatsApp 覆盖超过 20 亿用户。可以在同一对话中发短信、发送语音留言或拨打电话的客户无需安装任何内容或登录。
一个 WhatsApp Business 号码即可托管助理。顾客可以给餐厅发短信、发送语音留言或拨打语音电话。人工智能代理从头到尾处理订单，从问候到确认。所有三个通道共享一个后端和一个跨通道内存。今天发短信和明天打电话的客户会被识别为同一个人。
该解决方案使用 Meta WhatsApp Business Platform 作为客户前门。 Amazon Bedrock AgentCore 托管代理。Amazon Nova 2 Lite 通过 Amazon Bedrock Converse API 处理文本，Amazon Nova 2 Sonic 处理语音注释和呼叫中的实时语音。代理通过模型上下文协议（MCP）到达餐厅后端。您可以使用 AWS 云开发套件 (AWS CDK) 部署整个系统。频道和排序逻辑保持独立，因此当您添加或删除频道时后端不会更改。
解决方案概述
该设计将三件事分开：(1) WhatsApp 层处理对话，(2) 三个代理运行时为其频道运行对话，(3) 后端保存菜单、购物车、订单和位置。入站流量到达单个 HTTPS Webhook，立即使用 200 进行确认，然后异步处理，因此没有请求会阻止响应。这种分离使每一层都可以独立部署并且易于推理。
客户前门是 Meta WhatsApp 业务平台。它公开了 Cloud API webhook、消息 API、媒体 API 和调用 API。 Meta 管理此服务。您将其设置并连接为先决条件，而不是此解决方案部署的内容。 AWS CDK 配置 AWS 端的所有内容。它会发出您在 Meta 中注册的 Webhook URL。
您使用 AWS CDK 将以下 AWS 资源按依赖关系顺序部署为一组堆栈，并在此处按功能分组。
Amazon CloudWatch 捕获日志和指标，AWS Key Management Service (AWS KMS) 加密静态数据。
图 1 显示了完整的架构。该图将解决方案组织为带有请求路径的标记组 A 到 G。两个支持小组位于该路径之外，负责处理在部署时运行一次的构建管道，以构建在运行时支持每个通道的代理映像以及安全和监控服务。
图 1：AWS 上的多模式 WhatsApp 订购架构
两个支持组位于请求路径之外。构建管道（AWS CDK、AWS CodeBuild、Amazon ECR 和 Amazon S3）在部署时运行一次，以构建和存储 ARM64 代理映像。它不在任何请求的路径中。安全和监控（AWS Secrets Manager、AWS Systems Manager Parameter Store、Amazon CloudWatch 和 AWS KMS）在运行时为每个通道提供支持。
以下步骤通过架构端到端地跟踪单个请求：
工具通过后端 API 网关路由到 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 网关调用后端工具。回复通过 Sender Lambda，事件在会话结束时写入内存。
图 2 显示了从入站 Webhook 通过 Converse API 上的 Amazon Nova 2 Lite 到发送者 Lambda 传送的回复的文本流。
语音注释（语音到语音）：语音注释作为音频消息到达。工作人员下载 OGG Opus 字节并调用语音注释运行时。读取内存后，音频被解码为 16 kHz 脉冲编码调制 (PCM)，并输入到有界的 Amazon Nova 2 Sonic 语音到语音会话中。工具可通过同一网关获得。语音回复将作为 WhatsApp 语音消息返回。路径中没有转录服务。这是真正的声音输入，声音输出。
图 3 显示了语音笔记流，这是一个有界的 Amazon Nova 2 Sonic 语音到语音会话，它返回语音回复，路径中没有转录。
图 3：Amazon Nova 2 Sonic 的语音注释流程
语音呼叫 (WebRTC)：客户选择“呼叫”，Meta 的呼叫 API 会通过 WebRTC 会话描述协议 (SDP) 产品提供连接 Webhook。工作线程以turnOnly 模式将其中继到语音呼叫运行时，因为它没有公共IP。 TURN 凭证来自 Amazon KVS。 Meta 不提供细流交互式连接建立 (ICE) 路径。 aiortc 应答器等待 ICE 收集并返回单次 SDP 应答。工作人员将该答案传递给 Meta。然后，媒体通过 KVS 管理的 TURN 中继在数据报传输层安全和安全实时传输协议 (DTLS/SRTP) 上流动。亚马逊 Nova 2 Sonic 引发了话题。
图 4 显示了语音呼叫流程，其中 WebRTC 媒体通过 Amazon KVS 托管的 TURN 中继进行中继，并且 Amazon Nova 2 Sonic 驱动对话。
图 4：Amazon Nova 2 Sonic 的语音通话流程
先决条件
AWS 先决条件
您需要一个有效的 AWS 账户，并且为部署区域中的 Amazon Nova 2 Lite (amazon.nova-2-lite-v1:0) 和 Amazon Nova 2 Sonic (amazon.nova-2-sonic-v1:0) 启用了 Amazon Bedrock 模型访问权限。您的 IAM 用户或角色必须有权部署 AWS CDK 堆栈并创建该解决方案使用的资源，包括 AgentCore 运行时、网关和内存。在本地计算机上，安装 Node.js 24.x 或更高版本、配置了凭证的 AWS CLI 2.x 和 git。最后，在您的目标账户和区域中引导 AWS CDK (npx cdk bootstrap aws:///)。
代理容器在 ARM64 上的 AWS CodeBuild 内部构建，因此您本地不需要 Python、Docker 或音频工具链。在 Amazon Nova 2 Lite、Amazon Nova 2 Sonic 和 AgentCore 运行时、网关和内存均可用的 AWS 区域中进行部署。美国东部（弗吉尼亚北部）区域 (us-east-1) 是一个不错的起点。
有关按区域划分的模型可用性，请参阅 Amazon Bedrock 中按 AWS 区域划分的支持的模型。
WhatsApp 端在 Meta 控制台中设置一次，这是先决条件，而不是本演练中的步骤。 AWS API 无法为您创建元应用程序，因此请先完成它并在部署之前准备好值。对于演示来说，Meta 沙箱测试号（无需额外付费）就足够了。您不需要业务验证或生产编号。完整的过程位于 Meta 的文档中，链接在下一节中。
对于语音通话，该号码已启用 WhatsApp Calling API。
不将这些内容存储在源代码管理中。访问令牌、应用程序密钥和验证令牌是机密，在部署期间进入 AWS Secrets Manager，而不是进入 CDK 模板。
使用 AWS CDK 部署解决方案
完整的解决方案位于 GitHub 上的示例存储库中。该存储库包含三个代理容器、AWS CDK 基础设施代码以及将 WhatsApp Webhook 连接到您的账户的设置脚本。克隆它，运行预检检查，然后使用前缀进行部署。该前缀会添加到每个资源名称中，因此您可以为每个帐户部署多次。
git 克隆 https://github.com/aws-samples/sample-multimodal-whatsapp-restaurant-agent.git
cd 示例-multimodal-whatsapp-restaurant-agent./scripts/preflight-check.sh./scripts/deploy-all.sh --deploymentPrefix qsr-wacd 脚本/whatsapp-setupnpm start # 部署后选择“Pre-deploy”，然后选择“Post-deploy”node Whatsapp-setup.mjs --doctor # 只读端到端检查
脚本按依赖顺序配置每个堆栈。它将每个堆栈的输出传递到下一个堆栈。首先它部署共享 VPC。然后它部署后端：Amazon DynamoDB、Amazon Location Service、排序 Lambda 和后端 REST API。接下来，它部署 AgentCore Gateway 和共享 AgentCore 内存。然后，它使用 AWS CodeBuild 构建每个 ARM64 容器，推送到 Amazon ECR，并部署三个运行时。之后，它会部署 WhatsApp Webhook 和订单通知程序。然后它会播种样本菜单和位置数据。每个容器的第一次构建大约需要 8-12 分钟。要获得基于浏览器的引导式体验，请使用./scripts/deploy-all.sh --interactive-web-ui。
WhatsApp 值如何到达部署对于安全性至关重要。 CDK 为这三个密钥创建空的 Secrets Manager 容器。它不将秘密作为 CDK 参数，CDK 参数会将其烘焙到合成模板中。您可以在带外填充秘密值，而非秘密标识符（电话号码 ID、WABA ID、应用程序 ID）则作为参数使用。 script/whatsapp-setup/ CLI 通过两个流程处理此问题。预部署流程验证访问令牌并自动发现 WABA 和电话号码 ID。如果需要，它会生成验证令牌并填充秘密。部署发出 Webhook URL 后，部署后流程会在 Meta 中设置回调 URL、验证令牌和订阅字段。然后订阅WABA并完成验证握手。
一旦订阅了 webhook 并填充了机密，该号码就会变为活动状态，并且代理会通过所有三个渠道进行回复。
快速确认并异步处理
Meta 期望得到带有 200 OK 状态代码的提示 HTTP 响应。接受订单、获取媒体、调用代理以及中继呼叫信令所需要的工作量比简短的确认窗口所允许的要多一些。所以工作一分为二。 Webhook Ingest Lambda 仅执行快速、安全的部分，即验证签名、排队到 Amazon SQS 并返回 200。然后，Webhook Worker Lambda 使用队列并执行其余处理。突发的消息变成一个要处理的队列，并且公共表面停留在一个端点。如果工作线程处理某条消息失败，该消息将返回到队列并重试。经过几次失败的尝试后，消息将进入死信队列以供以后检查。
一个内存跨三个通道
是什么让这感觉像一个助手是共享内存。单个 AgentCore 内存资源由散列的 customer_id 作为密钥，并且所有三个运行时都使用相同的密钥。每个运行时都会在会话开始时读取客户的长期见解，并在结束时写回事件。这些见解包括客户之前提到的过去的订单、最喜欢的商品和偏好。由于每个渠道都会将同一客户解析到相同的内存中，因此今天发短信并明天打电话的客户会通过一个号码被识别为同一个人。没有单独的跨渠道状态需要协调。
存储菜单、购物车和订单
Amazon DynamoDB 表涵盖了工作流程。它们是客户（用于识别回头客的个人资料）、订单（带有提货位置和渠道的历史记录）、菜单（商品、价格和可用性）、购物车（带有生存时间的正在进行的购物车）和位置（坐标、时间以及总计和建议的税率）。按需容量随流量扩展，因此无需管理吞吐量。
查找上车地点
无需登录即可识别客户
订购演练
需要考虑的事项
清理资源
结论
关于作者
没有 AgentCore 运行时直接调用后端 Lambda 函数。 AgentCore Gateway 是托管 MCP 服务器。每个 AgentCore 运行时都作为 MCP 客户端通过 HTTPS 连接到它，使用运行时的 IAM 角色进行身份验证，并按名称发现工具。每个运行时都有自己的角色，因此网关仅授予运行时需要的访问权限。网关后面没有单独的 MCP 服务器。网关位于后端的 REST API 前面，并为每个端点生成一个 MCP 工具。当代理调用 PlaceOrder 等工具时，网关会将其转换为 REST 请求，后端 API 网关将其路由到匹配的 Lambda。由于代理与命名工具而不是特定函数通信，因此您可以更改处理程序或添加工具，而无需更改任何代理。所有三个渠道都使用相同的工具和数据下订单。购物车和订单工具拥有所有定价和总计。代理不会计算它们，并且每个订单都通过通道 =“whatsapp”保存在 Amazon DynamoDB 中。
亚马逊定位服务可帮助客户无需大量打字即可找到取货点。代理传递邮政编码或地址以将其地理编码为坐标。然后，后端对最近的餐厅进行排名，并返回客户可以采取行动的具体选项。
WhatsApp 客户未登录，因此系统使用电话号码作为身份基础。它在 AWS Systems Manager Parameter Store 中对 E.164 编号进行哈希处理，结果成为 customer_id ("wa-" + sha256(E164 || Pepper)[:16])。原始数字不存储在内存或会话状态中，这有助于满足个人身份信息 (PII) 要求。如果与已知客户匹配，客服人员会叫出他们的名字并回忆他们的偏好。否则，他们会作为新客户订购。发送回复的运行时不保存令牌或电话号码。发件人 Lambda 在发送时从“最后入站”窗口表解析收件人。这是识别，而不是身份验证。需要验证的部署可以添加一次性密码等步骤。
没有 Web UI 或测试客户端。使用安装了 WhatsApp 的手机发送消息或拨打 WhatsApp Business 号码。此示例显示了典型的交换（以“Agent”为前缀的行是助理的回复，括号中是工具调用）。
顾客：75201附近有什么菜单？
代理：[工具：GeocodeAddress、GetNearestLocations、GetMenu]
以下是 Amazing Burgers - 达拉斯提供的商品：
- 汉堡套餐（$8.99）
- 鸡柳 ($6.49)...顾客：请给我一份汉堡套餐和一杯奶昔。代理：[工具：AddToCart、GetCart]添加到您的购物车：- 1x 汉堡套餐 - 8.99 美元- 1 杯奶昔 - 3.49 美元总计：12.48 美元。要我下订单吗？顾客：是的。代理：[工具：PlaceOrder]您的订单已下达，并准备在以下地址取货：令人惊叹的汉堡 - 达拉斯。准备好后我会通知您。语音注释和语音通话通过 Amazon Nova 2 Sonic 运行相同的流程。您说出命令，客服人员会用语音回复。随着订单的进展，订单通知程序会将主动状态更新发送回 WhatsApp。您可以关注 Amazon CloudWatch Logs 中的对话。WhatsApp 还可以接收图像和文档。该解决方案侧重于订单处理，不对这些附件起作用。如果您的用例需要它们，您可以配置后端和聊天代理来处理它们，因为 Amazon Nova 2 Lite 已经是多模式的。客服人员可以读取会员卡照片或 PDF 餐饮请求，并将其转换为结构化订单。萨尔曼·艾哈迈德塞尔吉奥·巴拉扎拉维·库马尔
您需要为系统使用的 AWS 服务付费，并单独支付 Meta 的 WhatsApp 消息传递费用。成本主要与对话量和语音流量份额有关，每个会话比文本消耗更多的资源。此示例部署了所有三个渠道（文本、语音注释和语音呼叫），因此将部署限制在特定渠道可以降低您的基准成本。有关特定于区域的详细估算，请使用 AWS 定价计算器并参阅 Meta 的 WhatsApp Business Platform 定价页面。在 AWS Cost Explorer 中设置预算以跟踪流量增长时的支出。
这种模式也不仅仅局限于餐馆。核心构建块是一个业务号码、多个对话通道、共享内存和后端的 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 内存为每个客户提供跨渠道的持续关系。首先，克隆 GitHub 上的示例存储库并使其适应您的菜单和位置。在评论中分享您如何调整此模式以适应您自己的频道。
Salman 是 AWS 的高级技术客户经理，专门帮助客户设计、实施和优化其 AWS 环境。他将深厚的网络专业知识与探索新兴技术的热情相结合，帮助组织充分利用其云投资。工作之余，他喜欢摄影、旅行和观看他最喜欢的运动队比赛。Sergio 是 AWS 的高级技术客户经理，帮助客户设计和优化云解决方案。他拥有超过 25 年的软件开发经验，指导客户采用 AWS 服务。工作之余，Sergio 是一位多乐器音乐家，演奏吉他、钢琴和鼓，还练习咏春拳。
Ravi 是 AWS 企业支持部门的高级技术客户经理，帮助旅游和酒店行业的客户简化 AWS 上的云运营。他是一位注重结果的 IT 专业人士，拥有 20 多年的经验。 Ravi 对生成式人工智能充满热情，并积极探索其在云计算中的应用。工作之余，拉维喜欢绘画等创造性活动。他还喜欢打板球和去新的地方旅行。