用 Bedrock AgentCore 与 Nova 2 Sonic 构建低延迟餐厅电话点餐助手

2026-07-16 29 预计阅读时间: 1 分钟
来源: aws.amazon.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：10 分钟

电话点餐系统最难处理的并不是把语音转成文字，而是让电话网络、实时语音模型、智能体和餐厅业务系统在同一个低延迟会话里稳定协作。这个方案使用 Amazon Bedrock AgentCore 托管并运行智能体，以 Amazon Nova 2 Sonic 处理实时语音，再通过 Model Context Protocol（MCP）访问菜单、门店和订单后端。电话侧则由运行在 Amazon ECS 与 AWS Fargate 上的 SIP 网关接入。

其中一个很实用的设计是：电话仍在振铃时就预热智能体会话。这样接听后无需等待容器启动、工具发现或模型会话初始化，顾客听到的是立即响应的问候语，而不是几秒钟的静音。

一通电话经过了哪些组件

完整链路可以拆成五层：

  1. 电话运营商或企业电话系统把呼叫通过 SIP 转发到网关。
  2. SIP 网关负责呼叫状态、音频编解码和双向媒体流，并运行在 ECS/Fargate 上。
  3. AgentCore 智能体会话维护当前点餐上下文，例如门店、菜品、数量和顾客确认状态。
  4. Nova 2 Sonic处理实时语音输入与语音输出，让顾客可以自然地打断、补充或修改订单。
  5. MCP 服务向智能体暴露结构化工具，例如查询菜单、检查营业状态、计算价格和提交订单。

这里的边界很重要。模型可以理解“汉堡不要洋葱，再加一杯无糖可乐”，但价格、库存、税费和最终订单编号必须由餐厅后端决定。MCP 把这些确定性操作包装成工具，避免模型凭上下文猜测业务数据。

一次典型调用可以表示为：

SIP INVITE
  -> 创建或预热 AgentCore 会话
  -> 接听电话并建立双向音频
  -> Nova 2 Sonic 理解顾客请求
  -> 智能体调用 MCP 查询菜单和价格
  -> 智能体朗读订单摘要
  -> 顾客明确确认
  -> MCP 提交订单
  -> 返回订单号并结束通话

为什么要在振铃阶段预热会话

如果系统等到接听电话后才创建智能体会话，冷启动时间会直接暴露给顾客。初始化过程可能包括分配运行环境、建立实时模型连接、加载系统提示词以及发现 MCP 工具。

更合适的时机是收到 SIP INVITE 后、发送最终接听响应前。网关可以用呼叫 ID 创建预热任务，并让它与振铃过程并行执行：

收到 INVITE
  ├─ 立即返回 180 Ringing
  └─ 并行预热 AgentCore 会话
         ├─ 建立模型连接
         ├─ 加载门店上下文
         └─ 初始化 MCP 工具

顾客接通
  -> 绑定音频流与已预热会话
  -> 立即播放问候语

预热逻辑需要处理两个现实问题：顾客可能在接听前挂断，同一个 SIP 事件也可能因重试而重复到达。因此，会话创建应当以呼叫 ID 作为幂等键，并为未接通的预热会话设置较短的过期时间。

可以这样实践：部署 CDK 栈

下面是一个可改造的部署脚本。假设项目已经包含 CDK 应用，并通过上下文参数接收 SIP 域名、MCP 服务地址和门店编号；具体参数名需要按照实际项目调整。

#!/usr/bin/env bash
set -euo pipefail

: "${AWS_REGION:=us-east-1}"
: "${CDK_STACK_NAME:=RestaurantVoiceStack}"
: "${SIP_DOMAIN:?Set SIP_DOMAIN, for example sip.example.com}"
: "${MCP_ENDPOINT:?Set MCP_ENDPOINT to the restaurant MCP service URL}"
: "${STORE_ID:?Set STORE_ID to the target restaurant identifier}"

aws sts get-caller-identity >/dev/null

npm ci
npx cdk bootstrap "aws://${CDK_DEFAULT_ACCOUNT:-$(aws sts get-caller-identity --query Account --output text)}/${AWS_REGION}"

npx cdk deploy "${CDK_STACK_NAME}" \
  --require-approval never \
  --context sipDomain="${SIP_DOMAIN}" \
  --context mcpEndpoint="${MCP_ENDPOINT}" \
  --context storeId="${STORE_ID}"

运行前设置环境变量：

export AWS_REGION=us-east-1
export SIP_DOMAIN=sip.example.com
export MCP_ENDPOINT=https://orders.internal.example.com/mcp
export STORE_ID=store-001
export CDK_STACK_NAME=RestaurantVoiceStack

chmod +x deploy.sh
./deploy.sh

部署完成后，不要只检查 CloudFormation 是否成功。还应确认 Fargate 任务处于健康状态，并观察网关日志：

aws ecs list-tasks \
  --region "$AWS_REGION" \
  --cluster restaurant-voice \
  --service-name sip-gateway

aws logs tail /ecs/restaurant-sip-gateway \
  --region "$AWS_REGION" \
  --since 10m \
  --follow

这些集群、服务和日志组名称是实践示例，需要替换成 CDK 栈实际输出的资源名。

MCP 工具要围绕业务约束设计

不要把一个通用数据库查询接口直接交给模型。更可靠的方式是提供窄而明确的工具，例如：

{
  "name": "submit_order",
  "description": "Submit an order only after the caller explicitly confirms the final summary.",
  "inputSchema": {
    "type": "object",
    "required": ["store_id", "items", "confirmation_token"],
    "properties": {
      "store_id": { "type": "string" },
      "items": {
        "type": "array",
        "items": {
          "type": "object",
          "required": ["menu_item_id", "quantity"],
          "properties": {
            "menu_item_id": { "type": "string" },
            "quantity": { "type": "integer", "minimum": 1 },
            "modifiers": {
              "type": "array",
              "items": { "type": "string" }
            }
          }
        }
      },
      "confirmation_token": { "type": "string" }
    }
  }
}

confirmation_token 应由后端在生成最终订单摘要时签发，而不是让模型自行构造。提交接口还应接受幂等键，例如 SIP 呼叫 ID 加确认轮次，防止网络重试生成重复订单。

语音智能体的系统提示词也应明确提交边界：

You are the phone host for store {{store_id}}.
Use MCP tools for menu availability, prices, taxes, hours, and order submission.
Never invent an item, price, modifier, discount, or preparation time.
Before submitting an order:
1. Read every item, quantity, modifier, pickup method, and total.
2. Ask the caller for explicit confirmation.
3. Submit only after an unambiguous confirmation such as “yes” or “place the order.”
If audio is unclear, ask a short clarification question instead of guessing.

上线前检查延迟、失败路径和合规性

电话系统不能只测试“正常点一份套餐”。上线前至少要覆盖以下场景：

  • 顾客在振铃时挂断，预热会话是否及时释放。
  • 顾客打断智能体时，旧的语音输出是否立即停止。
  • MCP 查询超时或菜单服务不可用时，系统是否避免承诺错误价格。
  • SIP 重传、媒体流重连或工具调用重试是否导致重复订单。
  • 顾客修改数量后，最终摘要和总价是否重新计算。
  • 音频、电话号码和订单数据是否按照所在地法规设置保存期限与访问控制。
  • 无法识别语音、顾客要求人工服务或发生支付问题时，是否有转人工路径。

建议分别记录振铃到预热完成、接听到首个音频字节、每次 MCP 调用以及最终订单提交的耗时。只有把电话、模型和业务工具的指标放到同一条呼叫追踪中，团队才能判断延迟究竟来自 SIP 网关、AgentCore 会话、Nova 2 Sonic，还是餐厅后端。

这套架构的价值不只是“让模型接电话”，而是建立一条可观测、可确认、可重试的订单链路。AgentCore 负责智能体运行，Nova 2 Sonic负责实时对话，MCP 则把模型能力限制在餐厅认可的业务操作内。真正决定体验的，是会话预热、幂等提交、明确确认和失败转移这些工程细节。

# AI # AWS # LLM # 云原生 # 云平台 # 机器学习

相关推荐