/agents → 你的智能体 → 语音流水线。四个控件：流水线、提供商、 模型，以及音色。
大多数人应该保持原样，直到有具体的东西出了问题。这一页讲的是具体的东西出了 问题的时候。这里的一切也都可以通过让 Octo 来改，那通常是一条更稳妥的路径—— 原因见本页最后一条约束。
三条流水线
三者都能端到端地处理真人通话和交互式电话菜单。区别在成本、可检查的程度，以及 听起来的自然程度。
| 流水线 | 它是什么 | 什么时候选它 |
|---|---|---|
| Standard (STT + LLM + TTS) | 语音转文字 → 语言模型 → 文字转语音 | 默认选项。最便宜，也最容易检查，因为每一环都留下书面痕迹。适合通话量大的场景。 |
| OpenAI Realtime | 单一模型，原生音频 | 如果你的组织已经全面使用 OpenAI，这是合理选择。 |
| Gemini Live | 单一模型，原生音频 | 三者中最干净的实时架构，听起来也最自然。 |
真正重要的分野是标准还是实时，而不是选哪家供应商。标准流水线先转写，再 思考，然后开口——三个环节，每一个都可以单独替换。实时流水线把听和答合为一次 操作，这就是它打断和恢复得更像人的原因。
模型
每条流水线都有自己的模型家族，选错家族的模型会被直接拒绝，而不是悄悄替换。
标准流水线，小而快的模型是推荐的默认——便宜，普通接待绰绰有余。更大的模型 存在，值得在智能体听岔了的时候去够，而不是默认就用。
实时流水线，用当前的推荐模型。旧模型出于兼容性仍然可用，但其中至少一个 处理电话菜单的效果明显更差。如果你要点名某条实时流水线，请连同当前的模型 一起点名。
这个选择在水面下改变的四件事
它们产生的不是错误消息，而是让人迷惑的结果。
切换流水线不会把音色带走。 实时流水线有各自内置的音色——OpenAI 上是 Alloy、Ash、Coral、Marin、Cedar；Gemini 上是另一套。标准 流水线用的是你的文字转语音提供商的目录，并附一句 “在 elevenlabs.io 试听语音。” 一切换，你就得重新从一个不含你原有音色的列表里挑。
音色属于生产音频的那一方。 来自错误提供商的音色会被当场拒绝。同一件事从 另一头看，也是为什么这两个问题总是成对出现。
STT 和 TTS 的选项只存在于标准流水线。 提供商控件在标准流水线上有意义， 在实时流水线上基本消失——没有独立的转写环节可供配置。
并非每个被接受的提供商都已接线。 最锋利的边缘。有些组合校验通过、保存顺利， 然后在真正拨打电话时失败——这是最坏的发现时机。Octo 会引导你避开它们，这正是 「靠提需求来换音色」比「直接改配置」更值得做的最大理由。
当它应付不好电话菜单时
如果智能体按错了按键，或者对着刚刚接起的人滔滔不绝，按梯子一级级来，别瞎猜：
- 同一条流水线里换更大的模型。 往往整件事就解决了，而且是最便宜的尝试。
- 如果标准流水线还是吃力，换到 Gemini Live。 原生音频理解对付连绵的菜单， 比转写成文字再读文本强得多——你需要的时间信息，正是在转写环节被丢掉的。
- 知道你为此付出什么。 实时流水线按进出两侧的音频秒数计费，长通话比标准 流水线贵。对必须可靠打通的菜单，这钱花得值；对以人说话为主的普通通话，不值得 当默认。
对营销活动而言，编辑器里有一个对应的控件——电话菜单（IVR），就在收件人 旁边，因为有没有菜单要过，是关于你在给谁打电话的事实。
自定义音色或克隆音色
不在标准列表里的音色 ID，在标准流水线上没有问题，只要它属于你已配置的文字转 语音提供商。上面的提供商规则照样适用——它是唯一一条没有例外的规则。
从哪一条开始
从智能体创建时的配置开始，只有在能说出理由的时候才换。「听起来稍微好一点」不是 理由；「打断来电的人」或「听不清我们街道的名字」是理由。
在电话上验证改动
/agents 上的开始麦克风测试是快速循环，能告诉你音色听起来的效果。但它测不出 流水线在电话路径上的表现，因为 “WebRTC 可用于浏览器测试。电话路由需要一个号码。”
任何流水线改动之后，用一部真正的电话拨打一次号码。能够抓住「校验通过、接线却 不通」的提供商的，正是这一步。