航空公司的应用和网站早已支持旅客查询航班、挑选座位和管理预订。如果在这些界面之上再叠加一层自然语音交互，旅客只需开口说话就能完成同样的操作，既不用离开当前应用，也不必在多个页面之间来回切换。不过，构建这样一层并不轻松：需要让双向音频流稳定传输，在多轮对话中始终保留上下文，在不与现有后端紧耦合的前提下接入既有系统，还要在节假日前的高峰流量下按需扩展。
本文将演示如何为航空公司应用加入一个语音旅行管家，它建立在三项托管服务之上。Amazon Bedrock AgentCore 是一个用于安全构建、部署和运营 AI 代理的平台，允许自由选择框架与模型；Amazon Nova Sonic on Bedrock 是面向实时语音的语音到语音模型；Amazon Bedrock Knowledge Bases 则是完全托管的检索增强生成服务，可让回答扎根于企业自有文档。旅客开口之后，管家可以调出行程、更改座位、更新餐食偏好、回答政策问题，并在旅客要求时转接人工客服。
值得注意的是，管家是与现有界面并存的，而不是取而代之，因此旅客可以在同一会话中自由切换点击与语音两种方式。它运行在按需扩展的服务上，开发者可以把精力放在体验本身而不是基础设施上。AI 层通过合成数据连接到一套示例航空公司后端，方便把同样的模式迁移到自有系统。整个项目按模块拆分，可以只复用那些适配现有后端的部分，并把它们作为工具暴露给代理。
按照文中列出的学习目标，读者将掌握：使用 AWS Cloud Development Kit（AWS CDK）在 AWS 上部署语音 AI 管家；用 Strands Agents 框架和 Amazon Nova 2.5 Sonic 构建代理，并托管在 AgentCore 运行时上；通过 AgentCore Gateway 以 Model Context Protocol（MCP）把代理连到后端服务；用 Amazon Bedrock Knowledge Bases 回答航空公司政策问题；以及在转接人工客服时提供参考编号和预计等待时间。
整体架构把前端、AI 代理和后端服务划分为相互独立的层，便于各自开发与扩展。MCP 是一种连接 AI 应用与外部工具、数据的开放标准，它在代理和后端之间传递标准化消息，从而让两者保持松耦合。方案部署的服务包括：Amazon Cognito 负责用户认证并签发临时 AWS 凭证以支持签名 API 访问；AgentCore 运行时以每会话 microVM 隔离的方式托管代理；AgentCore Gateway 把后端端点暴露为可发现的 MCP 工具；Amazon API Gateway 以 IAM 授权发布 REST 端点；AWS Lambda 承载行程、座位图、旅客信息更新、航班状态、忠诚度、政策查询与升级等业务逻辑；Amazon DynamoDB 存储客户档案、预订、旅客、座位图、购买历史、偏好、对话记录和航班数据；Bedrock Knowledge Bases 基于航空公司政策文档作答；Amazon SES 发送邮件通知；AWS Amplify 托管 React 前端。
架构图分为四个部分。A 部分为后端基础设施，用五个 CDK 堆栈部署 DynamoDB 表、Lambda 函数、API Gateway 端点、Bedrock Knowledge Bases 和 Cognito。B 部分是 AgentCore Gateway，由一个 CDK 堆栈基于 MCP 协议创建网关，并把每个后端端点暴露为代理可以按名称调用的工具。C 部分是 AgentCore 运行时，由两个 CDK 堆栈配置运行时基础设施：Amazon ECR 存放容器镜像，Amazon S3 保存源码上传，AWS CodeBuild 生成 ARM64 Docker 镜像，运行时则借助 Strands Agents 框架与 Amazon Nova 2.5 Sonic，并支持 WebSocket。D 部分是前端，由一个 CDK 堆栈把 React 应用部署到 AWS Amplify。
用户请求的流转过程如下：用户在浏览器或移动设备上打开托管于 AWS Amplify 的 Web 应用；在登录页输入凭证后，Cognito 完成认证并返回 JWT 与临时 AWS 凭证；前端与 Bedrock AgentCore 建立经过 SigV4 签名的 WebSocket 连接，开启语音会话；运行时用 Cognito 校验令牌，并通过 Bedrock 初始化 Nova 2.5 Sonic；用户说话后，Nova 2.5 Sonic 处理音频并触发工具调用，代理通过 MCP 调用 AgentCore Gateway 来获取航班数据、管理预订和更新旅客偏好；网关再把请求以 REST 调用转发给 API Gateway，进而路由到 Lambda；Lambda 查询 DynamoDB 中的预订、旅客、座位图、忠诚度状态和航班信息，并通过 SES 发送邮件通知；最后 Nova 2.5 Sonic 生成结合上下文的语音回复，经 AgentCore 运行时通过 WebSocket 流式返回。遇到政策类问题时，网关会经由 MCP 的知识库连接器直接查询 Bedrock Knowledge Bases，知识库以引用形式返回相关政策段落。当用户要求人工客服时，Lambda 会在 DynamoDB 中记录升级并返回参考编号，随后 Amplify 从用户设备发起呼叫，接通真人客服。
构建与运维环节同样清晰。AWS CDK 用单个脚本完成部署：构建过程把代理源码上传到 Amazon S3，触发 CodeBuild 生成容器镜像并存入 Amazon ECR 供 AgentCore 运行时使用。Amazon CloudWatch 汇总所有服务的日志、指标和告警，AWS KMS 负责静态数据加密。开始前的准备条件包括：一个 AWS 账户；在部署区域为 Amazon Nova 2.5 Sonic 开通模型访问权限（知识库使用服务托管嵌入模型，因此无需单独申请嵌入模型权限）；Node.js 20.x 或更高版本；Python 3.12 或更高版本；已配置凭证的 AWS CLI 2.x；通过 npm 安装并引导账户的 AWS CDK CLI 2.x；以及来自 aws-samples GitHub 仓库的配套代码。部署时只需克隆仓库、配置凭证并运行部署脚本，详细步骤可参考仓库 README。
示例数据模型方面，API Gateway 发布了带 IAM 授权端点和 Lambda 集成的 REST API，DynamoDB 以个位数毫秒延迟和按需扩展能力存储数据，覆盖客户档案、预订、旅客、座位图、购买历史、偏好、对话记录和航班状态。
在政策问答上，旅客常会询问行李限额、改签费用、宠物出行和忠诚度条款。方案通过 Bedrock Knowledge Bases 的检索增强生成（RAG）以航空公司政策文档为依据作答，仓库中自带行李、取消与退款、改签与重新预订、票价等级规则、忠诚度条款、宠物出行、特殊协助和升舱等示例政策文档。用户把文档上传到 Amazon S3 并一次性创建知识库，之后的嵌入、分块、索引、存储和检索都由 Bedrock 处理，存储运行在 Amazon S3 Vectors 上；Smart Parsing 能让 PDF 中的表格和结构化版式被准确检索。政策文档变更时只需同步知识库，新内容立即可用，无需重新部署流水线。把知识库接到代理也很直接：在 AgentCore Gateway 中将其添加为 Connectors 目标，选择标准检索或代理式检索，网关就会把它作为具名 MCP 工具与后端 API 工具并列暴露，代理在运行时自动发现并按名称调用，无需编写自定义 Lambda 或检索代码。若要使用自有政策，把 PDF 或文本文件放入政策文档目录并重新部署知识库堆栈即可。
语音 AI 处理方面，每个会话都作为托管容器运行在 AgentCore 运行时上，并具备 microVM 隔离，因此在高负载下旅客对话依然彼此独立；AgentCore 还提供自动扩展、内置监控和会话路由。生产部署建议加入 Amazon Bedrock Guardrails，用于过滤提示注入尝试并验证回答的依据来源。本方案采用“写入前确认”模式，即在做出任何更改前先请旅客确认，再加上能追溯到源文档的知识库引用，构成负责任 AI 实践的基本基线。代理使用 Strands BidiAgents 框架定义系统提示、工具和对话流程，而 Nova 2.5 Sonic 则为管家带来多项能力：跨口音的语音识别与对背景噪声的鲁棒性；可适应旅客语调的口语回复；低延迟的双向流式传输；无需暂停对话即可并行取数或调用工具的异步工具调用；在等待工具结果时生成临时语音以掩蔽延迟，保持对话自然；支持打断与自然轮流；以及跨多轮延续的上下文。音频以前端 16 kHz PCM 的形式经 WebSocket 流向 AgentCore 运行时，Nova 2.5 Sonic 转写语音，代理挑选合适的工具并经 MCP 调用；AgentCore Gateway 把每次 MCP 调用转换为 REST 请求，Lambda 执行逻辑并返回结果，最终由 Nova 2.5 Sonic 把这些结果整合成一段口语回复。本方案使用的是具备强推理能力的 Nova 2.5 Sonic，对需要调用后端工具并遵循详细系统提示的语音管家而言，这种推理能力体现在更好的工具调用与代理式任务完成等方面。