语音与对话
搭建语音 Agent 的完整链路
先确定接入方式，再把识别、话轮、工具与播放连成可观测闭环。
先选一条真正需要支持的通话路径。电话客服从 SIP 与媒体接入开始，网页语音从浏览器采集与播放开始。先让一轮对话闭环，再处理抢话、超时和转人工。
理解这条链路
三种路线如何取舍
级联 STT→LLM→TTS 适合要审查识别文本、替换语音模块和控制业务流程的团队；原生语音会话减少模块连接工作，但必须接好工具事件、打断与音频历史；托管平台适合先验证业务流程，同时仍要明确谁负责电话线路、录音和交接。以业务控制需求选路线，不按仓库热度决定。
一轮请求需要留下什么
统一记录 conversation_id、turn_id、audio_segment_id、generation_id 和 tool_operation_id。文本 final、服务端已发出音频、客户端已播放是三个不同事件。用户插话时提高 generation，并让生成端和播放端共同拒绝旧块；恢复时只保留实际听到的内容。
按这个顺序操作
- 选择呼入客服这一条主线，写清音频入口、业务系统和播放终点。
- 用固定回复完成媒体往返，再加入识别、判停和模型；每加入一层都观察同一组事件。
- 加入一个只读工具，验证工具失败时能给出符合实际状态的回复。
- 回放正常、用户纠正、打断、工具超时和挂断五类流程，记录最终状态。
配套本地工具
以下工具位于 AI 学习工作区。先阅读对应说明，确认所需数据与依赖；本轮未重新运行这些实验。
- speech-gateway/README.md
- speech-gateway-java/README.md
可直接复用的记录模板
接入方式：SIP / WebRTC / WebSocket 音频格式：采样率 / 声道 / 编码 / 帧长 一轮事件：user_end → turn_commit → model_start → audio_first → playout_start 取消规则：generation 增加后旧音频块不可再进入播放队列 结束条件：正常完成 / 转人工 / 用户挂断 / 可解释失败
做到什么程度才算通过
- 一轮能从音频入口追踪到播放终点。
- 识别稿修订不会重复触发同一个业务操作。
- 打断后的过期音频不再播放。
- 工具超时有结果对账入口。
这是参考架构，没有在本轮连接电话平台或实测端到端延迟。
本轮确认的事实与来源
以下为公开资料支持的具体结论；操作流程和验收建议属于工程推导。仓库说明或厂商效果表述不等于独立实测。
当前官方文档区分语音 Agent、持续翻译和转写会话，并分别说明 WebRTC、WebSocket 与 SIP 接入。端点和会话生命周期不能混用。
资料日期：页面未统一标注；以复核日期为准 · 复核：2026-09-08
阅读原始来源 ↗Pipecat 官方仓库将自己定义为可组合的实时多模态流水线，支持多种服务与传输适配；这些集成能力不构成生产延迟保证。
资料日期：页面未统一标注；以复核日期为准 · 复核：2026-09-08
阅读原始来源 ↗这次更新了什么
将框架盘点改成接入选择与生命周期指南；删除凭 GitHub 热度判断框架优劣的逻辑。
合并前的内容入口
以下旧地址仍可访问，并会带你来到本篇。完整重构前材料已留存本地备份。
- research-hub/voice-agent-frameworks.html