AI Voice Bots 是一个用于构建、交付和调优语音机器人的技能，覆盖电话 IVR、实时语音代理和语音优先的客户交互，采用纯 Python 框架实现。
本技能负责语音特有的流水线部分：STT、TTS、电话平台、延迟工程和语音质量。对话设计、人设与升级模式请参考 ../ai-bot-builder/SKILL.md。
当需要对文本进行检查、脱敏或确定性通话状态时，默认使用流式 STT→LLM→TTS 流水线。自定义传输可选 Pipecat，LiveKit 房间或 SIP 集成可选 LiveKit Agents。当延迟或多模态行为可能需要不同流水线时，应对相同目标通话测试语音到语音（S2S）方案。
何时使用本技能：构建电话、IVR 或实时语音机器人；选择电话平台；选择语音流水线框架（Pipecat、LiveKit Agents、Vocode）；为语音设计延迟预算（TTFB、整体轮次延迟）；选择和配置 STT/TTS 提供商（Deepgram、ElevenLabs、Cartesia、Azure）；监控语音质量（MOS、WER、通话完成率）；设计 DTMF 与语音混合的 IVR 流程；构建外呼活动。
何时不使用：机器人对话设计、人设、升级转介到 ai-bot-builder；纯文本机器人架构转介到 ai-bot-builder；通用代理架构转介到 ai-agents；非语音的 WebSocket/SSE 基础设施转介到 software-realtime；语音/多模态参考材料转介到 ai-agents 的 references/voice-multimodal-agents.md。
默认工作流：定义通话流程（呼入/呼出、IVR 菜单树、对话状态）；选择电话平台（按呼叫量、地区、合规和 API 质量）；选择语音流水线框架（默认 Pipecat，或 LiveKit Agents）；设置延迟预算（在目标通话条件下测量每个阶段，并设定产品特定的分位目标）；选择 STT/TTS 提供商（按语言支持、延迟、质量和成本）；集成对话逻辑（使用 ai-bot-builder 模式作为 LLM 大脑）；添加语音特有的护栏（按要求披露 AI 身份、录音同意作为独立步骤、语音中的 PII、打断安全）；测量语音质量指标（MOS、WER、通话完成率、延迟分位）；负载测试和调优（验证并发呼叫负载下的延迟）。
流水线架构：电话/WebRTC → 传输 → STT → LLM → TTS → 传输 → 电话/WebRTC。需要测量的组件包括：VAD 或轮次检测器（语音结束到轮次结束的决策）、STT（音频到稳定转写，含部分结果）、LLM（请求到首个可用输出 token）、TTS（文本就绪到首个可播放音频）、传输（主叫网络与 SIP/WebRTC 交付）。流式阶段会重叠，因此简单相加组件时长不一定等于感知到的轮次延迟。
框架选择：Pipecat（默认）适合自定义语音流水线、多传输，支持 WebSocket、Twilio、Daily、WebRTC，支持 S2S（OpenAI Realtime、Gemini Live），生态包括 Deepgram、ElevenLabs、Cartesia、Anthropic、OpenAI；LiveKit Agents 适合基于房间的语音、录音、多方通话，传输为 LiveKit（WebRTC），支持 S2S（OpenAI Realtime），生态包括 LiveKit Cloud、STT/TTS 插件；Vocode 适合简单语音机器人、电话场景，传输为 Twilio、Vonage、WebSocket，不支持 S2S，生态包括 Deepgram、Azure、ElevenLabs。
S2S 与级联：如果需要在主叫听到输出前用内联文本闸门拦截不安全输出，使用级联流水线。如果不需要该闸门，且同一通话集测试显示 S2S 能改善所选的延迟或体验指标，则使用 S2S。并行转写可用于事后审计，但无法拦截已经说出的音频。
生产默认值：框架为 Pipecat 流式流水线；STT/TTS 从已安装框架支持的提供商中选择，需比较语言/口音准确性、首音频延迟、中断恢复和当前提供商条款；LLM 按实测任务成功率、工具可靠性、延迟和成本选择；传输使用目标地区与编解码器已批准的 SIP/PSTN 或 WebRTC 集成；延迟目标从产品通话测试设定 p50/p95 与中断目标，不要直接采用供应商基准作为 SLO；质量监控包括 MOS 跟踪、WER 采样、通话完成率；合规包括按司法辖区的录音同意、转写中的 PII 脱敏。
专家判断：优化前先分解延迟预算，将延迟归因到 VAD、STT、LLM 首 token、TTS 首音频和网络。即使 LLM 很快，瓶颈也可能是轮次检测或冷启动的 TTS 连接。打断（barge-in）是一条取消路径，用户抢话时必须及时停止正在播放的音频和待生成内容。需单独测量实际音频停止时间、误打断和恢复情况，与轮次结束延迟分开。
真实通话上线门禁：使用真实或回放的通话音频测试目标语言、口音、编解码器、手机网络、背景噪声、静音、打断、DTMF、转接、提供商超时和重连路径。按场景报告轮次结束和首音频延迟分位、中断成功率、任务完成率、误转接、挂断和同意捕获率。只有当每个阻塞场景都有确定性回退，且并发呼叫测试满足相同边界时才上线。提供商连接或合成干净音频演示不能作为上线证据。
已知陷阱：用合成实验提示证明延迟，而非真实打断、中断、丢包和手机网络条件；把电话接通当作对话成功，而真实失败是接通后延迟、轮次切分不佳或 TTS 重叠；跨地区混用录音、转写保留、PCI 脱敏和同意规则而没有明确策略负责人；只优化平均延迟而忽略让生产通话感觉崩坏的 p95 或 p99 尾部；只发布一条 STT 或 TTS 提供商路径，没有故障回退、回滚或降级行为；S2S 会话状态在模型切换时丢失：在会话中途切换 S2S 模型版本（任何提供商）会丢弃所有临时会话状态——声音、语气配置、对话历史和工具状态都不会保留。解决方法是每轮后将对话状态持久化到外部存储（Redis 或 Postgres），恢复或切换模型时从存储重新加载。不要把 S2S 会话当作状态存储。
常见反模式：批处理式语音流水线——等待完整话语或完整合成会破坏轮次交替并让机器人显得卡顿；LLM 优先架构没有确定性通话状态——IVR 路由、转接和合规提示需要显式状态机，而不只是提示逻辑；单一指标质量报告——仅看 MOS 或仅看 WER 会掩盖中断质量、完成失败和升级痛苦；把外呼语音当作聊天自动化——拨号、同意、语音信箱处理和重试策略需要渠道特定控制；直接沿用文本机器人护栏用于语音——语音机器人需要打断、静音、DTMF 和防抢话保护。
参考资料包括：s2s-and-native-voice-apis.md、telephony-platform-selection.md、voice-pipeline-architecture.md、pipecat-patterns.md、livekit-agents-patterns.md、latency-engineering.md、voice-quality-metrics.md、ivr-design.md、voice-safety-compliance.md、queueing-theory-applied.md。资产包括语音机器人规格模板、延迟预算工作表、上线前质量检查清单、端到端语音代理评估场景模板。脚本包括 python3 scripts/voice_latency_audit.py --input pipeline_logs.jsonl 和 python3 scripts/call_quality_scorer.py --input calls.jsonl。