01 / 开口太早
抢答
我还没说完，你就开始答。
用户周末想出去……
AI推荐你去杭州，先去西湖……
用户等等，我还没说完。
只是想一想，就被当成说完了。
TECH TALK / 2.0
REAL-TIME VOICE AGENT
从 GPT-Live
到实时语音 Agent
从听见声音，到理解场景，再到合时宜地回应。
流式语音链路 / 话轮判断 / Jev 自定义任务
实时语音 AGENT · 体验的起点 / 01
普通 AI 语音对话有哪些问题？
两个常见场景，让对话的节奏乱了。
02 / 插话无效
一开口就停不了
我已经插话，你还在继续说。
AI第一天逛西湖，晚上住在……
用户等等，我想当天往返。
AI第二天还可以去灵隐寺……
需求已经改了，回复却还在往下播。
什么时候该开口，什么时候该停下来？
对话的体验，取决于能否跟上人的节奏。
实时语音 AGENT · 体验的起点 / 02
全双工：说话的同时，仍在听你
同一段做饭指导：补充条件能听见，要求停下能响应，轻声附和能分清。
01 / 边说边听
听到新条件，马上调整
AI先热锅，再倒油……
用户我已经放油了。
AI那直接下鸡蛋。
说话时仍能听见，后续内容随之调整。
02 / 及时让话
用户叫停，立即停说
AI接下来加番茄翻炒……
用户等一下，先别讲。
AI（停止讲解，继续听）
用户一叫停，就把话语权交回来。
03 / 识别附和
听到“嗯”，继续讲解
AI炒出汁后，再加水……
用户嗯，你继续。
AI然后盖上锅盖，小火煮。
分清附和与打断，保持讲解连贯。
边说边听随时让话分清附和与打断
实时语音 AGENT · 体验的起点 / 03
听懂内容，也要跟上对话
从优秀语音模型，走向自然的全双工体验。
听得准
辨清说了什么，保留关键信息。
自然对话内容 × 上下文 × 时机
理解上下文
跟住补充、改口与真实意图。
接话时机合适
该回应时回应，该倾听时等待。
打断后能调整
停下当前回复，转向新的需求。
全双工交互
双方可同时收听与表达
用户说话系统收听
用户收听系统表达
体验还需要：音频流处理 · 说话时机判断 · 播放控制 · 会话状态管理
CHAPTER 02 · GPT-LIVE / 01
传统文本推理模型：一次请求，一次推理
以普通文本接口为例：提交请求 → 生成回答 → 请求结束。
开启 STREAMING 后
输出分块返回，
请求仍然会结束
- 请求提交一次
- 模型执行本次生成
- Token 分块返回
- 回答结束，请求结束
Streaming 改变输出的返回方式，
没有改变本次请求的生命周期。
没有改变本次请求的生命周期。
CHAPTER 02 · GPT-LIVE / 02
GPT-Live：一次会话，持续输入与输出
音频逐块进入同一个 Session；模型生成语音时，新的用户音频仍可进入。
01 / 连接持续存在
一句话后，不结束会话
后续交流沿用当前连接，
无需逐句发起完整请求。
02 / 输入持续追加
不必先录完一整段
用户音频分块进入；
模型结合当前上下文处理。
03 / 输出按需流出
边输出，也能继续听
模型按对话时机发声；
输入与输出可重叠，即全双工。
图中上下分组表示两个方向，
不表示“全部输入结束才开始输出”。
CHAPTER 02 · GPT-LIVE / 03
有状态推理：后续音频接着已有状态处理
Stateful Inference：从每次请求的处理流程，走向会话内持续维护的推理状态。
KV Cache：已处理内容的注意力键和值，供后续推理复用。普通请求也可以复用缓存。
“持续”指会话与状态承接，并非一直在后台生成 Token。
CHAPTER 02 · GPT-LIVE / 04
对话持续进行，任务在后台推进
一条实时媒体链路，一条异步委派链路。
后台仍需要时间，
媒体链路可以继续。
媒体链路可以继续。
CHAPTER 02 · GPT-LIVE / 05
会话越来越长，先把历史压缩下来
上下文空间有限：压缩较早的对话，为持续交流腾出空间。
压缩带来的新问题
上下文变了，推理状态也要重建
历史被压缩→相关 KV Cache 失效→重新预填充
重建状态需要时间。怎样准备新状态，同时让正在进行的对话继续？
CHAPTER 02 · GPT-LIVE / 06
A 继续对话，B 准备就绪再接手
把压缩与状态重建放到后台：先准备替代实例，再切换正在进行的会话。
交接期间维持媒体流；同一机制也可用于实例迁移。
CHAPTER 03 · 落地取舍 / 01
体验自然，规模使用的成本也会累积
从一段对话到每天万人使用，先算清持续运行的账单。
GPT-LIVE-1 · 语音层$0.05
美元 / 会话分钟
按秒计费，不向整分钟取整。
后端模型与工具费用另计。
聊上 10 分钟
一次自然语音交流
$0.50每次会话 · 仅语音层每天聊 2 次
每人每天 20 分钟
$1.00每人每天 · 仅语音层10,000 人使用
按相同日使用量扩展
$10,000每天 · 仅语音层测算假设：每人每天 2 次 × 每次 10 分钟；示例用量，不代表实际账单。价格核验：2026-11-03。
落地要回答：业务价值，能否覆盖长期使用的总成本？总成本 = 语音会话费 + 后端模型与工具费 + 应用运行成本；级联方案也需按同一用量口径实测。
CHAPTER 03 · 落地取舍 / 02
听见问题，不代表应该回答
会议助手要持续倾听，也要区分：人在互相讨论，还是把任务交给助手？
官方机制音频路径不再依赖
音频路径不再依赖
独立 Turn Detector
会议音频→
GPT-Live何时回应：模型内部决策
→语音输出参会者在问同事
“这个方案大家怎么看？”
助手保持安静继续听，保留讨论上下文
参会者明确交给助手
“助手，帮我们总结一下分歧。”
助手回应结合上下文完成任务
我们的取舍：把回答时机做成可单独调整、验证的模块。工程判断：模型内部决策难以像独立模块一样直接替换；仍可通过提示词和应用逻辑定制，效果需验证。下一节：级联语音 Agent。
CHAPTER 04 · 我们的选择 / 01
把语音交互拆成可组合的模块
听清内容 → 判断是否回应 → 理解与执行 → 说出结果
能力分工示意；具体触发顺序、并行关系与打断处理，在后续章节展开。
ASR
把声音转为文字，
为后续理解提供输入。
VAD + Jev
结合语音活动、文本与
上下文，辅助判断接话。
Agent / 文本模型
组织回答，按需调用
工具与业务能力。
TTS + 播放
把回复转成语音，
送到用户耳边。
模块可以分别选型、调整，也可以分别核算费用。整体成本与体验是否更优，需要在相同场景下实测。
CHAPTER 04 · 我们的选择 / 02
会议模式：持续听，按需答
同一个“是否需要回应”节点，让会议讨论和助手任务走向不同分支。
点击上方场景切换高亮 · 业务行为示意，判定输入、配置与实际效果在第六节展开。
把“是否回应”变成可以单独调整、验证的环节。拆分模块也带来额外延迟、打断处理和状态协调。接下来：声音如何通过 ASR 变成文字？
CHAPTER 05 · ASR / 01
边说，文字边出现
音频持续输入，文字逐步返回；后续模块不必等整段录音结束才拿到内容。
用户音频 · 持续输入“帮我查一下明天杭州的天气”
音频 ↓腾讯流式 ASR↓ 文字
识别结果 · 随音频更新
帮我查一下帮我查一下明天杭州的天气
深色：已确认片段浅色虚线：中间结果，可修正
说话期间，就有识别结果
文字随新音频陆续返回，
让后续处理尽早获得内容。
中间结果可能修正
新增声音提供更多线索，
当前文字不一定是最终版本。
片段确认 ≠ 整个任务完成
某段文字稳定下来，
后面仍可能继续输入音频。
ASR 先解决：用户说了什么。点击步骤查看文字变化 · 流式识别示意，确认粒度与完成事件以具体服务定义为准。
CHAPTER 05 · ASR / 02
识别出文字，用户就说完了吗？
文字已经出现，用户可能只是停下来想一想。
同一轮表达 · 时间向右 →
“帮我查一下”ASR 已返回前半句文字
现在就接话吗？短暂停顿 · 思考中
“明天杭州的天气”用户继续补充，才形成完整请求
有了文字，还不能只凭它决定接话。
ASR：提供内容→VAD / Jev：结合语音活动与上下文判断接话时机
听得准不准
地点、时间、业务词有没有听对？
文字出来快不快
说话期间，多久能拿到可用文字？
末尾收尾慢不慢
末字说完后，还要等多久确认结果？
文本可用、片段确认，都不直接等于本轮表达结束。接下来：VAD 与 Jev 如何判断“用户真的说完了吗，现在该不该接话？”
CHAPTER 06 · VAD & JEV / 01
VAD：现在有人在说话吗？
从连续采样到带状态的神经网络推理：VAD 输出帧级声学事实。
为何需要状态？ 连续帧携带上下文；每条音频流独立维护历史状态和上下文，样本坐标必须连续。
检测 ≠ 判停。 概率达到阈值，只给出该帧的语音标签；思考停顿和句末静音都可能落到低概率区。
CHAPTER 06 · VAD & JEV / 02
等多久，才算说完？
判停是时序状态机：连续静音累积，恢复语音清零，超过阈值才结束。
缩短静音阈值会提前触发，也可能把句内停顿当成话轮边界。
CHAPTER 06 · VAD & JEV / 03
Jev 基础：从上下文到判定
上下文 + 候选条件 → Jev 选择 → 运行时校验。
01 / 输入上下文 · state
current_asr“帮我查一下明天杭州的天气。”
pending_asr尚未处理的累积材料
recent_history已完成的近期对话
02 / 候选条件 · questions
system_semantic_default · choice
respond完整问候、提问或可执行请求
wait表达未完成，继续等待输入
03 / 判定输出 · answers
respondoption_code
0.96
selected_probability
≥ 0.75 阈值
校验通过 → 进入 Agent
若输入是“帮我查一下……” → wait。概率与阈值仅作示意，阈值由任务 / 运行时配置。
CHAPTER 06 · VAD & JEV / 04
用户定制：说出你希望的规则
用户说要求，Agent 将自然语言整理成任务参数。
用户说出要求
本次会议
本次会议
“接下来开会，平时不要插话；
我说‘帮我记一下’时，把内容记下来并简单确认；
散会时，总结分工和时间节点，然后退出。”
01 / 默认行为
安静倾听
普通讨论不插话
持续积累会议材料
02 / 新建 Jev 业务选项
record_action
条件：用户明确要求记录
命中后记录并简短确认
03 / 结束交付
散会总结并退出
交付分工与时间节点instructions
04 / 有效范围
仅限本次会议
本场结束后退出lifetime: one_shot
“帮我记一下” → 新增选项 record_action；Agent 调用工具，将选项代码与触发条件写入 criteria。
CHAPTER 06 · VAD & JEV / 05
Agent 调工具：让规则真正生效
左：智能体调用工具，创建任务。右：任务生效后，组装进后续 Jev 请求的判断参数。
智能体工具调用参数 · upsert_jev_task
upsert_jev_task(
task_id="meeting_record",
title="会议重点记录",
criteria={"record_action": "明确要求记录并简短确认"},
instructions="普通讨论静默；要求记录时执行并确认；"
"散会时总结分工和时间节点并退出",
lifetime="one_shot",
status="running"
)Jev 请求参数 · 新增 questions.meeting_record
{
"questions": {
"meeting_record": {
"type": "choice",
"criteria": {
"record_action": "用户明确要求记录并简短确认",
"wait": "普通讨论，继续静默倾听",
"stop": "用户明确散会，结束会议任务"
}
}
}
}生效流程： manage 开放工具 → 校验并暂存 → 当轮最终回复提交 → 注册表生效 → 组装右侧请求。
修改同一任务 “改成只听，散会再总结” → 相同
右侧 criteria 随之移除 record_action，保留 wait / stop；下一页沿用重点记录配置。
task_id，传入 criteria={} 并更新 instructions。右侧 criteria 随之移除 record_action，保留 wait / stop；下一页沿用重点记录配置。
CHAPTER 06 · VAD & JEV / 06
会议效果：该安静时安静，该行动时行动
同一个会议任务持续运行；一次记录完成，并不意味着任务结束。
01 / 普通讨论
平时，保持安静
“小李周三完成前端，
小王周四给接口。”
wait累积到 pending_asr
不启动 Agent，不播放回复
● running · 继续倾听
02 / 明确触发
需要时，执行记录
“帮我记一下，明天下午
两点和财务对账。”
option_code: record_action命中新建选项 → Agent 调记忆工具
“好的，已记下。”
● running · 动作完成后继续监听
03 / 会议结束
散会后，总结退出
“散会，总结一下
分工和时间节点。”
stopAgent 用累积素材总结
删除本次 one_shot 任务
○ 已退出 · 无其他抑制时恢复闲聊
会议总结前端：小李，周三完成 / 接口：小王，周四提供
待办：明天下午两点，与财务对账
待办：明天下午两点，与财务对账
场景行为示意。业务执行须通过有效结果校验与输入确认；静默时 Jev 仍在判断。
CHAPTER 06 · VAD & JEV / 07
ASR 抢跑：识别提前，提交仍需确认
流式 ASR 与语义预判重叠执行，通过快照一致性保护最终提交。
用户说话期间，ASR 已返回前半句；此时还不能提交完整请求。
300 ms 是预判触发值。 PCM 能量窗口累计静默；修订请求至少间隔 300 ms，同一快照去重。
复用取决于一致性。 续说会清除旧窗口结果；终判核对文本与上下文快照，不能把过时结果直接提交。
CHAPTER 07 · AGENT & TTS / 01
Agent：根据工具结果完成回答
拿到已确认的输入后，先明确任务，再执行查询，最后组织用户听得懂的结果。
“帮我查一下明天杭州的天气。”承接上一节：本轮输入已确认，需要回应
文字与上下文
当前请求
＋ 最近的对话
＋ 可用工具
明确查询条件
城市：杭州
日期：明天
意图：查询天气
调用天气工具
传入城市与日期
等待查询结果
检查成功或失败
读取结构化信息
天气：小雨
气温：18–23°C
演示数据
转成自然表达
“明天杭州有小雨，
18 到 23 度，
出门记得带伞。”
工具失败分支天气工具查询失败 → “暂时没有查到，请稍后再试。”· 不把失败当作天气结果
理解请求 → 调用工具 → 根据结果回答。Agent 可直接回答，也可按需调用工具；这里展示一次查询的流程，天气信息均为演示数据。
CHAPTER 07 · AGENT & TTS / 02
TTS：第一段先说，后续继续生成
文字不必全部写完才开始说；按短句形成文本块，再衔接对应的音频。
文本分段 → 音频生成 → 播放队列流式处理概念示意 · 横轴为相对先后，不代表实测耗时
首段已开始播放，后续文本与音频仍在生成。
按可朗读的短句分段，音频就绪后依次播放。分段要兼顾等待时间、句子完整与语音自然度；音频生成与播放分开，队列积压也会增加等待。
CHAPTER 07 · AGENT & TTS / 03
用户改口，整条输出链路都要跟上
从“杭州”改成“上海”：播放要停，旧任务与新请求也要分清。
助手正在播报 / 旧一轮“明天杭州有小雨，气温……”
用户改口
→
→
新输入 / 需要调整查询“等等，改查上海。”
停下正在说的
停止旧音频播放
及时把话权交回用户
清掉还没说的
移除旧回复待播音频
不让旧内容继续出声
停止继续生成
取消旧回复与合成
迟到旧结果不进入新轮
对齐实际听到的
区分已生成与已播放
记录改口与打断位置
新一轮 上海天气请求 → Agent 查询 → TTS 生成 → 播放新结果
旧回复正在播放；用户插话，提出新的查询条件。
停下旧回复，接住新请求。停止播放不等于后台任务已取消；打断需协调生成、合成、播放与会话。图示为处理目标，非当前实现的实测结果。
CHAPTER 08 · TURN MANAGEMENT / 01
说完了吗？等多久
再判断？
Smart Turn 判断表达是否完成；动态阈值决定首次检测时机。
从声音里判断“还要不要等”
“我今天想去……”
Incomplete
“我今天想去杭州。”
Complete
分析语调、节奏等音频线索，无需先取得 ASR 文本。
以上是期望结果，需用实际录音验证。
依据语速与历史停顿，调整等待
短停顿习惯
800ms
长停顿习惯
1200ms
以默认 1000ms 为起点的实验示例。
数据不足用默认值，调整时保持平滑。
等待时长 ≠ 模型概率判定阈值。
两者共同判断何时结束收集；是否回答，仍交给 JEV。机制示意 · 时间为实验示例，非生产推荐值。Smart Turn 为 Pipecat 开源音频轮次结束检测模型。
CHAPTER 08 · TURN MANAGEMENT / 02
四个判断，由一条链路串起来
VAD 检测静默 → 动态阈值触发检测 → Smart Turn 确认说完 → JEV 判断是否回答。
流式 ASR 从说话时持续运行；有效 Complete 才触发收尾。ASR 接口须支持外部控制本轮输入结束；协调服务端自动判停，避免 Smart Turn 判断前识别流已关闭。JEV 不需要回答时继续监听。
CHAPTER 08 · TURN MANAGEMENT / 03
一个 Turn Manager，统一轮次结束权
模型给判断，策略定时机；状态机负责收尾、重试与并发控制。
重试不重置总等待
从本次连续静默起计；ASR 收尾另设超时。
从本次连续静默起计；ASR 收尾另设超时。
接收结果前核对三项
turn_id + 音频版本 + 当前状态。
turn_id + 音频版本 + 当前状态。
收尾后新增语音独立入新轮
隔离旧 Final、JEV 与回复结果。
隔离旧 Final、JEV 与回复结果。
CHAPTER 08 · TURN MANAGEMENT / 04
统一调度，用真实录音
验证边界
这是待验证的进阶架构方案；先守住模块职责，再衡量等待与误判。
| VAD | 检测 speech / silence |
| Adaptive Endpointing | 动态等待 + Smart Turn 调用与重试 |
| Smart Turn | 判断 Complete / Incomplete |
| ASR | 转写与识别事件，受控收尾 |
| JEV | 结合完整文本、上下文与场景决定回应 |
先问：该等、该停、该回答吗？
正常问答 / 思考停顿
提前截断 · 额外等待
持续静默 / 推理中续说
超时兜底 · 旧结果隔离
会议旁听 / 轻声附和
错误回应
检查 Incomplete 不触发 JEV；旧 Complete 不关闭新输入；ASR 不提前自动结束。
把“何时判断、是否说完、是否回答”分开，再沿完整链路分析体验。例如“今天天气不错”：会议旁听场景可能无需回答，闲聊场景可能需要。期望结果必须结合录音与场景配置验证。
CHAPTER 09 · 我们如何逼近理想体验 / 01
用户说完以后，时间花在哪里？
从用户最后发声，到真正听见回复，把每一段等待放回同一条时间线。
同一句请求 / 帮我查一下明天杭州的天气链路示意 · 非实测耗时 · 时间从左向右
先找关键路径，再决定优化哪一段。重叠部分不能重复相加；如果先播“我查一下”，需把首个提示与首段有效结果分开计时。
CHAPTER 09 · 我们如何逼近理想体验 / 02
把能提前做、能并行做的工作排起来
提前识别 · 流式输出 · 合理判停，让第五至第七节的机制协作起来。
让工作重叠，让等待减少方案示意 · 不表示优化前后实测对比
说话时就开始 ASR
把识别放到用户说话期间。
提交前确认完整输入与判定一致。
有可朗读片段就合成
后续文本、音频与播放重叠。
分段仍需保护语义与语音连贯。
缩短等待，也守住完整性
结合场景调整规则或阈值。
等得过短，会增加误抢话风险。
优化瓶颈，同时保护对话质量。如果慢在工具执行，就单独分析工具链路；缩短判停无法消除工具耗时。
CHAPTER 09 · 我们如何逼近理想体验 / 03
怎样证明体验真的变好了？
用同一组场景验收四个维度，让每一次接话、执行和播放都经得起比较。
| 体验问题 | 用什么衡量 |
|---|---|
| 快不快？ | 首段有效回复等待 · P50 / P90同时观察典型请求与较慢请求 |
| 自不自然？ | 误抢话 · 打断响应 · 会议误回应该等时等、该停时停、该安静时安静 |
| 事情办成没有？ | 识别效果 · 任务成功率听对请求，也要拿到正确的执行结果 |
| 成本能否承担？ | 单次会话成本统一时长、工具与服务计价范围 |
速度、自然度、任务效果、成本，一起验收。用实测结果判断改善与取舍；拿到数据后再绘制对比图，不用最快的一次演示代替整体体验。
CHAPTER 10 · 总结
听得懂，接得住，办得成
从 GPT-Live 的实时交互方向，到适合业务的级联语音 Agent。
回到开场 / 目标体验示意
助手正在介绍第二天的安排……
等等，我想当天往返。
01 / 停下及时让话
停止旧回复，继续听用户说。
02 / 接住接收新条件
把“当天往返”带入上下文。
03 / 办成调整方案
按新要求继续完成任务。
好，那按当天往返重新安排。
自然交流
听懂表达，跟上改口。
该接话时接话，该让话时让话。
模块协作
选择级联，分别调整识别与判定。
让任务执行、语音生成与播放衔接。
效果与成本
在真实场景中验证效果与稳定性。
用可承担的成本，持续改善体验。
链路回顾ASR→VAD / Jev→Agent / 工具→TTS / 播放
让对话自然，让回应合时宜，让任务有结果。