先说结论：国际 Voice Agent 的 Demo 往往能把“听懂—思考—说出来”这一小段实时交互做得很顺，所以第一次体验很容易惊艳。但中文客服上线面对的不是一段精心设计的对话，而是一条持续变化的业务链路：电话线路、噪声、身份确认、知识库、业务系统、用户打断、转人工、数据回流和异常补偿会同时发生。因此，Demo 强不等于生产不可靠；两者解决的问题不同。Demo 证明模型和实时链路有价值，生产系统

假设 Voice Agent 调用 CRM 创建投诉工单，等待两秒后收到超时。系统应该重试吗？直接重试，可能创建两张工单；不重试，用户的投诉又可能根本没有进入 CRM。最麻烦的是第三种情况：CRM 已经创建成功，只是响应在返回途中丢了。此时 Voice Agent 看到的是失败，CRM 里却已经有了一张工单。这才是 Voice Agent 接入 CRM 时真正难处理的分叉。Function Cal

本文沿用上一篇《Voice Agent 到底应该怎么测？一套可复现的评测维度、实验方法与评分模板》里的评测框架，不只看 Demo 语音效果，而是从实时语音链路、延迟、打断、知识库、工具调用、转人工和企业客服闭环几个角度拆解 ElevenLabs Voice Agent 是否适合中文客服场景。结论：ElevenLabs Voice Agent 的优势很清晰：它是一个语音体验很强、工程接口比较完整、适

先说结论：如果团队已有后端、CRM、订单或工单系统，想把语音交互接进既有业务流程，Vapi 值得看。它的价值不在于替你完成一套中文客服系统，而在于把电话或网页语音接入、Assistant 配置、工具调用、通话事件和转接这些通用层能力收拢起来。开发团队不用从零搭电话基础设施和实时语音编排，但仍要自己负责业务接口、权限、幂等、审计、中文测试集和人工承接。所以，Vapi 更适合“愿意自研业务闭环”的团队

BM25 保住精确词向量召回补语义RRF 合并多路名次reranker 重排候选answerable gate 决定是否该答citation verifier 阻止无来源答案直接播报如果这条链路仍然答错，日志能告诉我们问题发生在 ASR、召回、排序、阈值还是生成，而不是笼统归因于“大模型幻觉”。上一篇《Voice Agent 如何实现自然插话？从 VAD 到 Barge-in 完整拆解》处理的是用

适用范围：不适用范围：我最初把 TTS 接到 Voice Agent 时，链路看起来很顺：真正跑起来后，问题集中出现在两头。第一种情况是“假流式”。TTS 接口确实逐块返回音频，但程序一直等 LLM 把整段话生成完，才一次性把全文送去合成。TTS 首包可能只有 200 ms，用户却先等了 1～2 秒文本。第二种情况是“包到了，声音仍然断”。如果每收到一个 PCM 包就立即播放一次，浏览器会创建许多

VASI 的第一步不是训练一个更会“看人”的模型，而是限制系统可以做什么。它可以根据当前语音、对话和业务状态，选择更合适的沟通方式；它必须承认不确定性；用户一旦明确表达偏好，系统就要让位。高风险场景里，它更应该把问题交给人工，而不是证明自己有多聪明。最终，系统输出不该是“这个用户是什么类型”，而应是：在当前证据和风险边界下，我为什么选择这样说话；如果你不喜欢，我可以立刻换一种方式。

本文用一个可运行的 FastAPI + WebRTC + RAG 最小 Demo，把 Voice Agent 的实时连接、信令、DataChannel、知识库检索、回答引用和转人工预留口串成闭环，并说明从 Demo 扩展到生产级智能客服平台时需要补齐的 ASR、VAD、TTS、日志和权限能力。

先说结论：如果团队已经有前端或电话接入、后端业务接口和明确的 CRM/工单体系，OpenAI Realtime API 很适合承担 Voice Agent 的实时语音交互层。它能让语音和文本在低延迟会话里直接进入模型，并支持 WebRTC、WebSocket、SIP 和函数调用；开发团队可以更快验证实时对话、工具调用和语音交互的产品路径。但 Realtime API 不是完整的 AI 语音客服系统

评测 Voice Agent，不能只听 Demo 里的声音是否自然，也不能只看一次对话是否流畅。所以我后续做 Voice Agent 产品测评时，不会只写“声音好不好听”“回答像不像真人”这类主观体验，而会尽量使用同一套样本、同一套日志格式、同一套评分模板。这篇文章就是后续测评的“母篇”：先把评测维度、实验流程、样本格式、评分方法和 Mermaid 可视化图放出来。