Product · 方案概述

把语音 AI 助手,
建在 Amazon Connect 之上。

语音 AI 助手常见做法是用一个 voice-to-voice 模型(如 Amazon Nova 2 Sonic)端到端处理语音进、语音出。本方案改用 Amazon Connect 的原生 agentic 能力做出同等语音体验:浏览器直接说话,Connect 负责语音识别与合成、AI agent 负责推理与工具调用——以组件化、可托管、可编排的方式实现,而非依赖单一 voice-to-voice 模型。

🎙️ 浏览器语音 Connect agentic voice Orchestrator AI agent MCP 工具 🔊 语音回答
▶ 打开实时演示 看架构与数据流
0
电话号码——纯浏览器 WebRTC 接入
≈95%
链路 CDK 一键部署,其余用 SDK 补齐
2
演示工具:报时间、报天气(确定性、可离线)
Capabilities · 核心能力

五块拼在一起,就是一个语音 AI

🎙️

浏览器语音入口

通过 Connect web calling(WebRTC)+ Amazon Chime SDK,网页点一下即可通话,无需电话号码、无需安装客户端。

🗣️

Agentic voice

Connect 托管的富表现力 ASR + TTS,支持自然停顿、打断(barge-in)。采用组件化语音,而非单一 voice-to-voice 模型(如 Nova 2 Sonic)的 speech-to-speech。

🧠

托管的“大脑”

Connect orchestrator AI agent 负责多步推理,自行判断该调哪个工具——无需自建 Bedrock 调用循环。

🔧

MCP 工具

工具逻辑在我们的 Lambda 里,通过 AgentCore Gateway 以 Model Context Protocol 暴露给 AI agent。

📝

可对比的字幕

对话双方文本都从 Connect 的 AI agent 日志实时拉取,让你直接对比“听到的”与“回答的”。

📦

基础设施即代码

工具、Gateway、MCP 注册、JWT 授权、Lex bot、Contact Flow、AI agent 全链路由 CDK 部署;少数 CFN 未覆盖处用 SDK 补齐。

Comparison · 两类语音 AI 方案对比

Voice-to-voice 模型 vs Connect 组件化

同样是“语音进、语音出 + 会调工具的 AI 助手”,两条实现路线的取舍。

维度Voice-to-voice 模型方案(如 Amazon Nova 2 Sonic)本方案(Amazon Connect 组件化)
语音引擎单一模型端到端 speech-to-speechConnect agentic voice 的 ASR + TTS(可托管、50+ 语言/嗓音)
“大脑”模型内置对话与工具调用Connect orchestrator AI agent(托管,多步推理、可编排)
工具随模型的函数调用约定MCP:AgentCore Gateway → Lambda(标准协议、可复用)
浏览器接入自建 WebSocket + 模型双向流Connect web calling(WebRTC)+ Chime SDK(开箱即用)
运维与治理自行承载模型会话与扩缩Connect 托管:安全档案、日志、观测、合规入口

取舍诚实说明:voice-to-voice 模型是真正的端到端语音(自然停顿、极低延迟);Connect + agentic voice 是回合制(说完 → 识别 → 推理 → 合成),但支持打断(barge-in),并把语音、推理、工具、合规入口都变成可托管、可编排的标准组件。演示工具(get_current_time / get_weather)为确定性实现、无外部依赖。

Contact Flow · 呼叫编排脚本

Flow:把语音、会话与 AI 串起来的编排

Contact Flow 是 Amazon Connect 的可视化编排(本质是一个状态机)——每一通接入的联系(这里是浏览器 web call)都会“走”一遍这个 flow,按块(block)顺序被处理。它决定了:用什么嗓音、什么时候建立 AI 会话、把话交给谁、以及出错/结束怎么走。我们这个 demo 的 flow 只有 5 个块,却把整条语音 AI 链路串了起来。

1 · 开启日志 2 · 设置嗓音 3 · 建 AI 会话 4 · 获取客户输入(Lex bot) 5 · 挂断

1 · 开启流日志

UpdateFlowLoggingBehavior

打开这通联系的流日志。后续排障、以及网页字幕所依赖的对话记录,都从这里开始产生。

2 · 设置嗓音

UpdateContactTextToSpeechVoice

把本通对话的 TTS 嗓音设为 Matthew(Amazon Connect agentic voice)。之后所有语音合成——包括开场白与 AI 回答——都用这把嗓音,保证声音一致。

3 · 建立 AI 会话

CreateWisdomSession

创建一个 Q in Connect 会话并绑定 orchestrator AI agent,得到一个 SessionArn这是关键一步:没有它,下一步的 AI 意图会因为“没有活动会话”而失败。

4 · 获取客户输入

ConnectParticipantWithLexBot

核心块。先播开场白“Hi! How can I help you today?”,再把语音交给 Lex bot。两个要点:
· 通过 LexSessionAttributes 把第 3 步的 SessionArn 作为 x-amz-lex:q-in-connect:session-arn 传入,AI 会话才接得上;
· Lex 的 QInConnectIntent 把整句转发给 AI agent——真正的语音识别(agentic voice ASR)、推理与工具调用都在这一步内部完成,最后合成语音回放。

5 · 挂断

DisconnectParticipant

对话结束(或 AI 选择 Complete / Escalate 返回控制)后,结束这通联系。生产中可在此接入“转人工队列”等分支。

🧩

为什么用 Flow 来编排

Flow 让“语音 + 会话 + AI + 出错处理”变成一段可视化、可版本化、可发布的脚本,而不是散落在代码里的胶水逻辑。整个 flow 由 CDK 以 AWS::Connect::ContactFlow 部署并直接发布(State=ACTIVE)。

想看这 5 个块在一次真实对话里逐帧怎么走、数据形态如何转换,见 架构页的场景数据流

▶ 打开实时演示 看架构与数据流