详细教程展示如何用Amazon Connect+Agentic Voice+MCP协议构建餐厅电话接单系统,无需App或网站即可完成端到端语音点单。
在许多餐厅,大量订单仍然通过电话下达,而这些电话通常会由一名正在招待柜台顾客的员工接听。来电者等待持线,订单手工记录,繁忙时段让两者都雪上加霜。增加 App 或网站可以服务那些更喜欢在线下单的顾客,但对只想打电话下单的人毫无帮助。
在本文中,我们将向你展示如何构建一个语音订餐系统,从问候到确认全流程接听电话号码并完成订单,无需 App、无需网站、无需登录。来电者拨打一个电话号码,AI 智能体会迎接他们、回答菜单问题、查找附近的取餐点,并通过语音确认订单。该系统使用 Amazon Connect Customer 提供电话渠道,Amazon Lex V2 配合 Amazon Connect Agentic Voice 实现实时语音,以及 Amazon Connect Customer AI agents 来编排对话,通过 Model Context Protocol(MCP)和 Amazon Bedrock AgentCore 连接到餐厅后端。
该解决方案专门处理电话渠道的通话。音频通过电话网络而非浏览器到达,系统通过电话号码而非登录来识别来电者。该解决方案将智能体逻辑和后端服务构建为独立模块,使订餐逻辑与调用它的渠道保持解耦。
本教程将展示如何:
使用 AWS Cloud Development Kit(AWS CDK)部署系统
通过 Amazon Connect 应答入站电话并通过联系人流路由
通过 Amazon Connect Agentic Voice(高级 ASR 和 TTS)提供实时语音识别与合成
通过 Amazon Connect AI agent 编排对话和后端工具调用
通过 Amazon Connect AI Guardrail 保持对话安全且围绕主题
通过 AgentCore Gateway 和 MCP 将智能体连接到后端服务作为可发现的工具
Amazon Connect Agentic Voice 在 Amazon Connect 中原生提供语音层,处理听力的语音识别和说话的文本转语音。Amazon Lex V2 机器人同时使用它进行语音识别和合成,而 Amazon Connect AI agent 则负责推理和后端调用。后续章节将介绍 Agentic Voice 如何加快话轮转换。
该设计将三部分保持分离。Amazon Connect 处理通话,Amazon Connect AI agent 运行对话,后端则存储菜单、购物车、订单和位置信息。来电通过 Amazon Connect 接入,联系人流打开一个 Amazon Connect AI agent 会话并将来电者连接到智能体。Amazon Connect Agentic Voice 在整个通话过程中提供语音识别和合成,AI agent 对对话进行推理,并通过 AgentCore Gateway 暴露的 MCP 工具访问后端。由于 MCP 是将智能体连接到外部工具的开放标准,后端可以变更而无须触碰智能体。
在本解决方案中,联系人流、Amazon Lex V2 语音层(Amazon Connect Agentic Voice)和 Amazon Connect AI agent 全部通过 Amazon Connect 进行配置和管理。你无需将它们作为独立服务部署。一套 Amazon Connect 部署将电话、语音和 AI 智能体整合在一起。AgentCore Gateway 和餐厅后端是你需要自行构建和集成的部分。
该解决方案部署以下组件:
Amazon Connect Customer 提供入站电话、联系人流和接受通话的电话号码。
Amazon Lex V2 托管语音机器人,联系人流将来电者连接到该机器人。它使用 Amazon Connect Agentic Voice 进行语音处理,并将每一轮对话路由到 AI agent。
Amazon Connect Agentic Voice 在 Amazon Connect 中原生处理高级 ASR(含置信度话轮结束检测)和富有表现力的 TTS。
Amazon Connect Customer AI agents 提供编排型 AI agent 来驱动对话,由 Amazon Bedrock 中的 Anthropic Claude Haiku 4.5 提供支持。
Amazon Connect AI Guardrails 通过内容过滤器、禁止话题和脏话过滤保持对话安全和围绕主题。
AgentCore Gateway 将后端 API 暴露为 MCP 工具,智能体可以按名称发现和调用。
Amazon AppIntegrations 将 AgentCore Gateway 注册为 MCP 应用程序,AI agent 可以使用它。
Amazon API Gateway 用 REST 端点为后端提供前置层,由 AWS Identity and Access Management(IAM)提供安全保障。
AWS Lambda 运行菜单、购物车、订单和位置查询的业务逻辑,并将来电者的电话号码推入智能体会话。
Amazon DynamoDB 存储客户资料、订单、菜单项、购物车和位置信息。
Amazon Location Service 提供取餐推荐所需的地理编码和路线计算。
图 1 展示该解决方案,的组织成四个部分。
图 1:电话语音订餐解决方案,组织成四个部分。
A 区,后端基础设施。本部分部署餐厅后端。Amazon DynamoDB 保存客户、订单、菜单、购物车和位置数据,Amazon Location Service 处理地址和路线。AWS Lambda 运行业务逻辑,Amazon API Gateway 在 IAM 授权下暴露业务逻辑。资源按依赖顺序部署。
B 区,AgentCore Gateway。本部分配置一个 AgentCore Gateway,在部署时读取 REST API 的 OpenAPI 模式并将每个端点注册为命名的 MCP 工具。该网关使用自定义 JSON Web Token(JWT)授权,并针对 Amazon Connect 实例验证入站令牌。
C 区,Amazon Connect 实例和 AI agent。本部分创建 Amazon Connect 实例、Amazon Connect AI Agents 助手和编排型 AI agent。它在 Amazon AppIntegrations 中将 AgentCore Gateway 注册为 MCP 服务器,并创建一个使用 Amazon Connect Agentic Voice 进行高级 ASR 的 Amazon Lex V2 机器人。随后定义包含内容安全策略的 AI Guardrail,使用 Anthropic Claude Haiku 4.5 系统提示词和附加的护栏定义 AI agent,发布智能体版本,并关联一个授予智能体后端工具访问权限的安全配置文件。
D 区,Amazon Connect 电话。本部分创建联系人流并注册电话号码。联系人流是每个入站电话的入口点。它启用日志记录、为文本转语音设置 Agentic Voice,并捕获来电者的电话号码。随后打开一个 Amazon Connect AI agent 会话,用 Lambda 函数将来电者的电话号码推入该会话,以便智能体识别来电者,播放问候语,并将来电者连接到 Amazon Lex V2 机器人。Lex 机器人提供实时语音层,使用 Agentic Voice 高级 ASR 进行听力识别,使用 Agentic Voice TTS 进行说话,而 AI agent 处理推理和工具调用。
图 1 中的编号标注从头到尾追踪该解决方案的完整流程:
来电者发起呼叫,拨入 Amazon Connect 配置的电话号码,可以是客户直接拨打或从其他线路转接。
Amazon Connect 联系人流设置 Agentic Voice、捕获来电者的电话号码、打开 Amazon Connect AI Agents 会话、将来电者的电话号码推入会话并向来电者播放问候语。
联系人流将来电者连接到 Amazon Lex V2 机器人,由 Amazon Connect Agentic Voice 在整个对话过程中提供语音识别和合成。
Amazon Lex V2 将对话路由到 Amazon Connect AI Agents,将对话逻辑委托给编排型 AI agent。
Amazon Connect AI agent,由 Amazon Bedrock 中的 Anthropic Claude Haiku 4.5 提供支持,并由 AI Guardrail 提供内容安全保护,负责驱动对话,解析来电者位置、获取菜单、管理购物车和下订单。
AI agent 通过 MCP 协议调用 Amazon Bedrock AgentCore Gateway 中可用的工具。
AgentCore Gateway 将每个工具调用转发到 Amazon API Gateway,后者将请求路由到相应的 AWS Lambda 函数。
AWS Lambda 读写 Amazon DynamoDB 中的购物车、订单、菜单和位置数据,并调用 Amazon Location Service 进行地理编码和最近位置查询。
AWS CDK 在单个脚本中部署所有八个堆栈。
Amazon CloudWatch 为所有服务提供集中监控、日志记录和告警,所有静态数据均使用 AWS Key Management Service(AWS KMS)加密。
标注 1 至 8 在单个电话通话中发生,标注 9 涵盖解决方案的构建和部署方式,标注 10 涵盖其监控和安全保障方式。下一节将搁置部署和运营问题,更贴近通话本身。
本节从来电者的角度跟踪一次通话,从第一次响铃到语音回复。它与图 1 中的标注 1 至 6 的运行时路径相同。图 2 将其展示为序列图,使事件的顺序更加直观。
图 2:入站呼叫流程,Amazon Connect 边界内的组件。
虚线边界标记了 Amazon Connect 提供的内容。联络流、Amazon Lex V2 语音层(Amazon Connect Agentic Voice)和 Amazon Connect AI 智能体均来自同一个 Amazon Connect 部署,因此通过 Amazon Connect 而非独立服务来配置它们。AgentCore Gateway 位于边界之外,将智能体连接到你的后端。
图 2 中的编号步骤对应呼叫的以下阶段:
在开始之前,请确认你已具备以下条件:
npx cdk bootstrap aws://<ACCOUNT_ID>/<REGION>)部署会自动在你的 Amazon Connect 实例上启用 Contact Lens 和机器人管理设置,这是 Amazon Lex V2 机器人配合 Agentic Voice 和 Amazon Connect AI 智能体所必需的。无需 Docker 或 Python。部署到 Amazon Connect Agentic Voice、Anthropic Claude Haiku 4.5、配备 AI 智能体的 Amazon Connect 和 AgentCore Gateway 均已推出的区域。US East(N. Virginia),us-east-1 是一个不错的起点。
完整解决方案可在 GitHub 示例仓库中找到。克隆仓库并进入项目目录。
git clone https://github.com/aws-samples/sample-restaurant-telephony-ai-host-using-amazon-connect-customer.git
cd sample-restaurant-telephony-ai-host-using-amazon-connect-customer
使用部署前缀运行部署脚本。前缀会添加到每个资源名称中,这样你可以在同一账户中多次部署解决方案。
./scripts/deploy-all.sh --deploymentPrefix qsr-cn
脚本先运行预检,然后按依赖顺序部署每个 AWS CDK 堆栈,将上一个堆栈的输出传递给下一个。它首先构建后端,包括 Amazon DynamoDB 表、Amazon Location Service 资源、AWS Lambda 函数和 Amazon API Gateway REST API,并植入示例菜单和位置数据。然后创建 Amazon Connect 实例和 Amazon Connect AI Agents 助手,在后端 API 前添加 AgentCore Gateway,定义 Amazon Lex V2 机器人、AI 护栏和编排 AI 智能体,最后创建联络流并申请电话号码。由于网关需要针对 Connect 实例验证令牌,因此它在 Connect 实例之后部署。
脚本完成后,会打印要拨打的号码:
Your restaurant AI host is live at +1XXXXXXXXXX — dial to test.
电话层的工作范围很窄。Amazon Connect 接听电话,联络流决定接下来发生什么。联络流为每个入站呼叫运行一序列短步骤。

图 3:联络流步骤,从入站呼叫到挂断。
它首先启用 Contact Lens 日志记录,以便每个步骤都记录在 Amazon CloudWatch 中用于调试。然后设置呼叫的语音为 Amazon Connect Agentic Voice,使每个口头回复都使用智能体文本转语音引擎。它捕获呼叫者的电话号码作为联系属性。它打开一个绑定到助手的 Amazon Connect AI 智能体会话(Lex 机器人需要此会话),并存储该会话以便通话的其余部分可以引用它。然后它调用一个 Lambda 函数,将呼叫者的电话号码推入 AI 智能体会话,这样智能体无需询问即可识别呼叫者。最后,它播放简短问候语并将呼叫者连接到 Amazon Lex V2 机器人,该机器人使用 Agentic Voice 高级 ASR 来收听和使用 Agentic Voice TTS 来说话,为通话的其余部分提供实时语音层。
当 AI 智能体完成时,机器人将控制权返还给联络流,联络流读取结果并结束通话。智能体通过两种结果之一发出结束信号。Complete 表示订单已完成,Escalate 在呼叫者要求转人工时可用。在本解决方案中,两种结果都会断开呼叫,但由于通话在 Amazon Connect 中,你可以将 Escalate 路径连接到 Amazon Connect 队列,以便将呼叫者连同完整对话上下文转接给真人客服。
五个 Amazon DynamoDB 表覆盖了订单工作流。Customers 表存储个人资料,包括姓名、电话和会员信息,你可以用这些信息来识别回头客。Orders 表保留订单历史记录和取餐地点。Menu 表存储菜品、价格和库存,库存可能因地点而异。Carts 表存储进行中的购物车,并使用生存时间值,使被放弃的购物车自动清理。Locations 表存储餐厅详情,如坐标、营业时间和税率,智能体用这些信息来计算总价和推荐。DynamoDB 按需容量随流量自动扩展,因此无需管理吞吐量。
Amazon Location Service 帮助呼叫者无需输入任何内容即可找到方便的取餐点。打电话的人没有浏览器可以共享位置,所以智能体会询问邮政编码或交叉路口,并使用 Amazon Location Service 将其转换为坐标。从此,后端可以用这些坐标做一些事情。它可以找到最近的餐厅,按驾驶时间而非直线距离排名,这样更倾向于呼叫者路线上短距离绕行的地方,或者对特定地址进行地理编码。这样智能体可以说出呼叫者可以采取行动的信息,比如"最近的门店在主街,大约五分钟路程",而不是念回一个内部编码。
两个托管功能运行对话。Amazon Lex V2 机器人上的 Amazon Connect Agentic Voice 提供语音,Amazon Connect AI 智能体提供推理。
Amazon Connect Agentic Voice 在通话中处理语音工作,原生集成于 Amazon Connect。其高级 ASR 可以识别各种口音的语音,并能容忍电话线路带来的背景噪音,它使用基于置信度的轮次结束检测来判断呼叫者何时说完,而不是等待固定的静音窗口。这缩短了呼叫者说完一句话与智能体响应之间的停顿,使对话感觉更自然。其文本转语音为智能体的回复生成富有表现力的声音,呼叫者可以像真实通话一样打断。当联络流选择语音时,机器人本身不携带语音设置,改变智能体的声音是编辑联络流而非重新部署机器人。可以针对每个意图调整轮次结束置信度和静音阈值,以处理诸如念回付款卡号或地址等场景。指导说明请参阅 Agentic Voice 最佳实践。
由 Anthropic Claude Haiku 4.5 驱动的 Amazon Connect AI 智能体在每一轮对话中决定做什么。它的系统提示词是为语音设计的,因此回复保持简短,价格自然地说出,例如"五块九毛九",内部 ID 永远不会大声朗读。智能体问候呼叫者,回答菜单问题,确定取餐地点,添加购物车,念回购物车内容供确认,然后下订单。它仅通过 AgentCore Gateway 暴露的工具访问后端,因此对话逻辑与后端保持分离。
AI 智能体从不直接调用后端 Lambda 函数。AgentCore Gateway 位于两者之间,将后端端点呈现为 MCP 工具,智能体通过名称来发现和调用这些工具,涵盖菜单查询、购物车操作、下单、客户与订单历史、地理编码和位置搜索等功能。该网关通过 Amazon AppIntegrations 注册为 Amazon Connect AI 智能体助手的一个 MCP 应用,并对每次调用进行授权——它用针对 Amazon Connect 实例验证的 JSON Web Token 来完成授权。
这一层设计保持了系统的松耦合。当智能体调用 PlaceOrder 这样的工具时,网关将其转换为发往 Amazon API Gateway 的 REST 请求,再路由到匹配的 AWS Lambda 函数。由于智能体调用的是具名工具而非特定函数,你可以更改后端处理器或添加新工具,而无需修改智能体。同一后端也可以服务其他渠道,因为它们都针对相同的工具和数据来下单。
图 4 展示了单个工具调用如何从智能体一路到达后端。
图 4:单个工具调用,从 AI 智能体到后端。
无需登录即可识别来电者
来电者不会登录,因此系统用来电者的电话号码作为身份基础。Amazon Connect 联系人流程捕获来电者的电话号码,然后由一个 Lambda 函数将其推送到 AI 智能体会话中,智能体将其作为会话属性读取。智能体将该号码转换为一个客户 ID,并在对话中的每次工具调用中使用它。
该 ID 使每位来电者的购物车相互独立,并将完成的订单标记上来源号码,这样事后就能将订单与来电者匹配起来。如果完全没有号码可用(因为来电者屏蔽了来电显示),智能体会为该会话生成一个匿名 ID,订单仍然可以完成。每位来电者获得一个独立的购物车,因此并发来电不会相互干扰。示例还将客户档案和订单历史暴露为工具,因此你可以扩展智能体,使其能够用名字问候回头客,或者推荐他们上一次点的餐。
这实现了无需登录即可识别回头客,但这并非身份验证,来电者的电话号码不应被视为来电者身份的证明。需要验证身份的生产部署可以添加一次性验证码等步骤。
使用 AI 护栏保障对话安全
AI 智能体附加了 Amazon Connect AI 护栏,以确保对话安全且不偏离主题。护栏对有害类别(如仇恨、侮辱、性内容、暴力、违规行为和提示注入攻击)应用内容过滤器。它阻止一组被拒绝的主题,如政治讨论和投资建议,并使用托管列表和自定义词表来过滤脏话。
当来电者说出偏离主题或不安全的内容时,护栏会介入,智能体用预设消息回复,例如"抱歉,我只能帮助处理餐厅订单",并将对话引导回点餐。护栏在同一 AWS CDK 堆栈中定义并附加到智能体,因此它随解决方案的其余部分一起部署,无需任何控制台步骤。
护栏强度值得针对你自己的提示词进行调整,而不是设得越高越好。过宽的过滤器会阻止合法的对话回合,特别是个人身份信息过滤器可能会拦截来电者必须提供的用于查找取餐点的地址或邮政编码。
部署输出中的号码拨出。智能体会向你打招呼并询问你需要什么。你可以自然地说话,询问菜单、提供取餐的邮政编码,并确认订单,全程通过语音完成。来电话者说话时,智能体在后台调用后端工具,因此数据加载时不会有任何停顿。
你可以在 Amazon CloudWatch Logs 中跟踪通话。联系人流程日志显示通话设置,Amazon Connect AI 智能体日志显示对话回合和工具调用,订单则带着总价和预计准备时间落入 Orders 表中。
你需支付系统使用的 AWS 服务费用。截至 2026 年 7 月,在美国东部(弗吉尼亚北部)使用默认设置运行此解决方案,1000 个平均时长五分钟的语音订单每月费用约为 35 美元。
费用最高的项目是 Amazon Connect 的入站通话分钟数、用于编排的 Anthropic Claude Haiku 4.5 token 数,以及 Amazon Lex V2 语音请求。该解决方案默认申请一个本地直接拨入号码(DID),这保持了较低的按分钟计费率。切换到免费电话号码则会提高费用。没有常驻计算费用,因为 Amazon Connect 和 AI 服务按使用量计费。价格会发生变化,因此请查看每个服务的定价页面,并在 AWS Cost Explorer 中设置预算以跟踪支出。
为避免持续产生费用,请在完成后删除资源。清理脚本按倒序删除堆栈,以便在删除依赖它的堆栈之前先移除每个堆栈。
./scripts/cleanup-all.sh --force --deploymentPrefix qsr-cn
清理操作具有破坏性。它会释放电话号码、删除 Amazon DynamoDB 中的订单历史,并移除 Amazon Connect 实例、Amazon Connect AI 智能体助手、AI 智能体、AI 护栏、Amazon Lex V2 机器人以及 AgentCore Gateway。请先备份你要保留的任何内容。脚本完成后,在 AWS CloudFormation 控制台中确认所有八个堆栈都显示为已删除,且电话号码已被释放。
在本文中,我们向你展示了如何构建一个电话语音点餐系统,该系统接听电话并全程完成点餐。Amazon Connect 接听电话并运行联系人流程,Amazon Connect Agentic Voice 提供实时语音识别和合成,Amazon Connect AI 智能体处理推理,AI 护栏保证其安全且不偏离主题,AgentCore Gateway 则通过 MCP 工具将智能体连接到后端。由于智能体与工具对话而非与特定函数对话——