把话听成文字
例如识别出
“明天天气怎么样”。
TECH TALK / 2.0
REAL-TIME VOICE AGENT
语音 Agent，怎样
更自然地交流？
语音 Agent 的工作原理与体验优化
现在怎么做 / 体验差在哪里 / 我们怎样改进
我们现在怎样完成一次语音问答？
你问“明天天气怎么样”，系统理解并查询，再用声音回答。背后是这样一条链路。
能理解请求、按需调用工具办事，并通过声音交流的系统，就是这里说的语音 Agent。
想明白、办事情
结合上下文，按需查天气，
组织回答文字。
把回答变成声音
将文字合成为音频，
再送到设备播放。
检测有没有人在说话
提供说话和静音信息，
帮助管理输入时机。
把识别、理解、合成这些独立模块接起来，称为“级联”语音方案。
故事没讲完，打断后发生了什么？
这版级联方案没有处理上下文与播放进度的不一致；插问答完，也没有继续故事。
级联 / 未对齐播放进度的示例
用户给我讲个故事。
级联 · 完整生成的故事
有个赶夜路的人，看见老人坐在石墩上提着灯笼。
↑ 用户只听到这里；以下已生成，但还没播放
老人送他走了半里，说：“不是照你的路，是怕你撞上树后的影子。”那人攥紧母亲给的桃木扣，赶回家，却发现灯笼挂在门把上，灯芯竟是自己去年掉的乳牙。
用户 · 故事还没播完，中途插问为什么老人坐在那里？
级联 · 回答插问他守在那里，是为了替过路人挡险。
01 / 上下文走在声音前面
没播完，完整文字已进上下文
用户只听到故事开头，
会话记录里已经有了完整故事。
已听到开头后续还没播放
02 / 原任务没有接回来
答完插问，故事就停了
“讲故事”这个请求还没完成，
回答却停在了这次插问。
故事开头 → 插问 → 解释 → 停止
听到了哪里？原任务还要不要继续？好的语音 Agent，应该接得住交流
先把体验目标说清楚，再看怎样实现。
听得完整，接得及时
思考时继续听。
真的说完后，减少机械等待。
随时插话，及时让话
助手说话时仍能接收新输入。
停下旧回复，接住新的条件。
懂内容，也懂场合
普通讨论继续旁听。
明确交给助手的任务再执行。
传统文本推理模型：一次请求，一次推理
以普通文本接口为例：提交请求 → 生成回答 → 请求结束。
开启 STREAMING 后
输出分块返回，
请求仍然会结束
- 请求提交一次
- 模型执行本次生成
- Token 分块返回
- 回答结束，请求结束
Streaming 改变输出的返回方式，
没有改变本次请求的生命周期。
没有改变本次请求的生命周期。
GPT-Live：一次会话，持续输入与输出
音频逐块进入同一个 Session；模型生成语音时，新的用户音频仍可进入。
01 / 连接持续存在
一句话后，不结束会话
后续交流沿用当前连接，
无需逐句发起完整请求。
02 / 输入持续追加
不必先录完一整段
用户音频分块进入；
模型结合当前上下文处理。
03 / 输出按需流出
边输出，也能继续听
模型按对话时机发声；
输入与输出可重叠，即全双工。
图中上下分组表示两个方向，
不表示“全部输入结束才开始输出”。
GPT-Live：接住插问，再接回故事
同样在讲故事时插问，GPT-Live 先回答眼前的问题，再继续原来的故事。
GPT-Live / 讲故事时插问
用户给我讲个故事。
GPT-Live · 正在播放海边小镇里，住着一位修表师。他每天都……
用户 · 中途插问他为什么要住在海边？
先回答插问海浪声像齿轮转动，让他觉得安心。
再继续故事有一天，一个小女孩拿着停走的表来找他……
01 / 接住当前插问
让出话头，先解释原因
用户不用等整段故事播完，
就能围绕刚听到的内容提问。
02 / 保留原来的任务
答完以后，故事继续
插问没有替代“讲故事”的请求，
回复自然接回了原来的叙事。
故事开头 → 插问 → 解释 → 续讲
全双工支持边说边听，任务承接还需要会话管理。有状态推理：后续音频接着已有状态处理
普通文本请求每次独立推理；GPT-Live 在同一会话内持续承接推理状态。
带上历史 ≠ 有状态推理：普通文本请求依靠应用传入历史，延续对话语义。
缓存复用 ≠ 持续会话：提示缓存可减少重复计算，不等于持续承接会话内的推理状态。
对话持续进行，任务在后台推进
一条实时媒体链路，一条异步委派链路。
后台仍需要时间，
媒体链路可以继续。
媒体链路可以继续。
A 继续对话，B 准备就绪再接手
把压缩与状态重建放到后台：先准备替代实例，再切换正在进行的会话。
交接期间维持媒体流；同一机制也可用于实例迁移。
体验自然，规模使用的成本也会累积
每人每天聊 20 分钟，1000 人的日常使用，成本就需要认真算一算。
GPT-LIVE-1 · 语音层$0.05
美元 / 会话分钟
按秒计费，不向整分钟取整。
后端模型与工具费用另计。
聊上 10 分钟
一次自然语音交流
$0.50每次会话 · 仅语音层每天聊 2 次
每人每天 20 分钟
$1.00每人每天 · 仅语音层1,000 人使用
按相同日使用量扩展
$1,000≈ ¥6,717 / 天 · 仅语音层测算用量：1000 人 × 每天 2 次 × 每次 10 分钟。汇率：1 美元 ≈ 6.7168 元（2026-11-06）；价格核验：2026-11-07。
相比之下，级联方案约 1,600 元 / 天。
听见问题，不代表应该回答
会议助手要持续倾听，也要区分：人在互相讨论，还是把任务交给助手？
官方机制音频路径不再依赖
音频路径不再依赖
独立 Turn Detector
会议音频→
GPT-Live何时回应：模型内部决策
→语音输出参会者在问同事
“这个方案大家怎么看？”
助手保持安静继续听，保留讨论上下文
参会者明确交给助手
“助手，帮我们总结一下分歧。”
助手回应结合上下文完成任务
我们的取舍：把回答时机做成可单独调整、验证的模块。工程判断：模型内部决策难以像独立模块一样直接替换；仍可通过提示词和应用逻辑定制，效果需验证。下一节：级联语音 Agent。
延续级联，调优模块之间的协作
流式识别与预判提前进行，轮次管理协调收尾、打断与结果提交。
能力分工示意；具体触发顺序、并行关系与打断处理，在后续章节展开。
ASR
把声音转为文字，
为后续理解提供输入。
VAD + Jev
结合语音活动、文本与
上下文，辅助判断接话。
Agent / 文本模型
组织回答，按需调用
工具与业务能力。
TTS + 播放
把回复转成语音，
送到用户耳边。
模块可以分别选型、调整，也可以分别核算费用。整体成本与体验是否更优，需要在相同场景下实测。
ASR 返回：partial 与 stable
用服务端返回的状态理解识别过程：同一片段持续更新，确认后再接上新片段。
服务端事件 · 从上到下按顺序返回
用户：“帮我查一下明天杭州的天气”
segment_id | type | text |
|---|---|---|
| 1 | partial | 帮我查一下 |
| 1 | stable | 帮我查一下明天 |
| 2 | partial | 杭州的天地 |
| 2 | partial | 杭州的天气 |
| 2 | stable | 杭州的天气 |
{"type": "done"}结束本轮音频输入、收齐尾部后，识别任务完成。
当前片段的暂定结果
同一个 segment_id 的新结果，
覆盖这个片段的旧草稿。
当前片段已经确认
保留已确认片段，
后面仍可继续返回新片段。
本次识别任务完成
尾部结果已经收齐，
Agent 会话仍可继续。
stable 确认的是片段，不代表用户这一轮已经说完。partial、stable、done 为讲解用事件名；字段、确认粒度与任务完成事件以具体服务协议为准。
VAD：现在有人在说话吗？
VAD 检测语音活动；检测到静音后，还要确认是否可以结束本轮输入。
VAD 输出： 把声音转成语音概率，再得到“有语音 / 没语音”的标签。
静音还不等于说完。 自然停顿和真正说完，都可能表现为“没语音”，需要再等一会儿。
动态静音阈值：跟着说话节奏调整
auto ESD：从会话内的真实停顿学习，调整“静音多久才收尾”。
动态阈值看节奏：适应当前会话的停顿习惯，减少固定等待的不合适。
Jev 再看内容：节奏不能确认表达是否完整，下一步用转写和上下文判断。
Jev：继续等，还是提交大模型？
同样出现停顿，结合当前 ASR 文字和上下文，决定下一步。
01 / 还没说完整
“帮我查一下明天……”
还缺地点和要查询的内容。
wait→ 继续听ASR 继续接收音频，等待用户补充。
02 / 请求已经完整
“帮我查一下明天杭州的天气。”
时间、地点、查询目标都已明确。
respond→ 提交大模型确认本轮 ASR 输入后，进入推理与工具调用。
下一步：把这两个判断接到静默计时上，减少用户已经说完后的等待。
用 ASR 内容，缩短静默等待
不必每次等满 ESD：较短静默后，用当前转写判断能否提前收尾。
提前判断：当前快照可以先算；最终输入确认后，再提交大模型。
继续补充怎么办？用户续说会改变输入，接下来沿时间线看旧判定如何处理。
ASR 抢跑：识别提前，提交仍需确认
接着看并行与复用：用户续说后，旧判定失效；最终输入一致，才采用新判定。
输入变了 → 重判。 用户续说或转写修正，旧结果失效，更新快照后重新计算。
输入一致 → 复用。 ASR 收尾后校验通过，才采用预判；否则用最终输入再判断。
Smart Turn从声音判断
是否说完
语音轮次结束检测模型
直接分析音频里的完成信号。
语速变化 · 句尾语调 · 停顿节奏
结合声学特征判断表达是否完整，而不只是等一段静音。
这一轮话，还会接着说吗？
“我今天想去……”Incomplete
“我今天想去杭州。”Complete
示意结果，实际判断还要结合完整音频。
未完成 → 继续听 · 已完整 → 进入收尾确认Smart Turn 为 Pipecat 开源模型 · 接入方案待验证。
Smart Turn：给 Jev 补上“说完没有”的判断
Jev 已经判断“要不要回应”，Smart Turn 再补上“用户说完没有”。
即使 Jev 已经 respond，Smart Turn 还是 Incomplete，也先等用户说完。
TTS：第一段先说，后续继续生成
大模型流式输出 → 按句切分并提交 TTS → 音频入队 → 按句序播放。
句末边界触发 → 逐句提交 TTS → 顺序播放流式处理概念示意 · 横轴为相对先后，不代表实测耗时
首段已开始播放，后续文本与音频仍在生成。
每形成一句，就提交一次 TTS；第一句先播，后续句子继续合成。按适合朗读的句末边界切分；生成结束时提交剩余尾句。音频按句序入队播放，分句长度兼顾首声等待与自然度。
用户改口，整条输出链路怎样跟上？
用户说“改查上海”时，停止旧输出，并把上下文对齐到实际听到的位置。
正在播放“明天杭州有小雨……”
用户插话 →
新要求“等等，改查上海。”
停播并清队列 → 停止旧生成 / 合成 → 按播放进度修订上下文已执行的工具结果保留真实状态，旧轮迟到结果要隔离；随后处理新的上海天气请求。图示为处理目标，实际效果需验证。
用户定制：说出你希望的规则
用户说要求，Agent 将自然语言整理成任务参数。
用户说出要求
本次会议
本次会议
“接下来开会，平时不要插话；
我说‘帮我记一下’时，把内容记下来并简单确认；
散会时，总结分工和时间节点，然后退出。”
01 / 默认行为
安静倾听
普通讨论不插话
持续积累会议材料
02 / 新建 Jev 业务选项
record_action
条件：用户明确要求记录
命中后记录并简短确认
03 / 结束交付
散会总结并退出
交付分工与时间节点instructions
04 / 有效范围
仅限本次会议
本场结束后退出lifetime: one_shot
“帮我记一下” → 新增选项 record_action；Agent 调用工具，将选项代码与触发条件写入 criteria。
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": {
"type": "choice",
"criteria": {
"record_action": "用户明确要求记录并简短确认",
"wait": "普通讨论，继续静默倾听"
}
},
"system_exit:meeting_record": {
"type": "choice",
"criteria": {"stop": "明确散会", "wait": "继续会议"}
}
}
}生效流程： manage → Agent 调工具 → 校验并暂存 → 当轮最终回复提交 → 注册表生效 → 组装右侧请求。
修改同一任务 “改成只听，散会再总结” → 相同
移除 record_action 后，该任务改为一题 wait / stop，不再拆分业务题与退出题。
task_id，传入 criteria={} 并更新 instructions。移除 record_action 后，该任务改为一题 wait / stop，不再拆分业务题与退出题。
Jev 的判定项，怎样随任务更新？
默认两道题；Agent 调工具登记任务后，后续 Jev 请求带上新的业务与退出判断。
普通回应按冲突暂停：兼容的任务可并行；本例会议要求静默，暂停默认回应题。
修改仍走同一闭环：manage → Agent 调工具更新同一 task_id → 下一轮 Jev 使用新规则。
完整级联链路：从听见到回应
从声音输入到语音输出：主链传递数据，Turn Manager 协调判停、轮次与打断。
轮次协调：核对轮次、输入版本与状态；续说使旧判断失效，超时走兜底。
中途打断：停播清队列，取消旧生成与合成，按实际播放进度修订上下文。
从说完到听见，怎样缩短等待？
用户感受到的等待：从最后发声，到首段有效回复真正播放。
把完整链路放回时间轴机制示意 · 条宽不代表实测耗时
判停端：少等静默
在确认说完的前提下及时收尾，同时观察误抢话。
决策端：并行预判
识别期间准备 Jev，最终输入确认后校验复用。
输出端：首句先播
首句提交 TTS，后续文本与音频继续生成。
怎样证明体验真的变好了？
用同一组场景验收四个维度，让每一次接话、执行和播放都经得起比较。
| 体验问题 | 用什么衡量 |
|---|---|
| 快不快？ | 首段有效回复等待 · P50 / P90同时观察典型请求与较慢请求 |
| 自不自然？ | 误抢话 · 打断响应 · 会议误回应该等时等、该停时停、该安静时安静 |
| 事情办成没有？ | 识别效果 · 任务成功率听对请求，也要拿到正确的执行结果 |
| 成本能否承担？ | 单次会话成本统一时长、工具与服务计价范围 |
速度、自然度、任务效果、成本，一起验收。用实测结果判断改善与取舍；拿到数据后再绘制对比图，不用最快的一次演示代替整体体验。
听得懂，接得住，办得成
从 GPT-Live 的实时交互方向，到适合业务的级联语音 Agent。
回到开场 / 目标体验示意
助手正在介绍第二天的安排……
等等，我想当天往返。
01 / 停下及时让话
停止旧回复，继续听用户说。
02 / 接住接收新条件
把“当天往返”带入上下文。
03 / 办成调整方案
按新要求继续完成任务。
好，那按当天往返重新安排。
自然交流
听懂表达，跟上改口。
该接话时接话，该让话时让话。
模块协作
选择级联，分别调整识别与判定。
让任务执行、语音生成与播放衔接。
效果与成本
在真实场景中验证效果与稳定性。
用可承担的成本，持续改善体验。
链路回顾ASR→VAD / Jev→Agent / 工具→TTS / 播放
让对话自然，让回应合时宜，让任务有结果。