导语

语音 AI 正在从演示走向生产。OpenAI 最新发布的一篇客户案例显示，语音 AI 平台 Retell AI 目前每月处理超过 1 亿次通话，较 2026 年初的 3,000 万次大幅增长；OpenAI 模型为其平台上 80% 的通话生成回复，客户问题解决率超过 80%，Retell 在 OpenAI 模型上消耗的 tokens 已突破 1 万亿。更值得技术团队关注的是，Retell 报告其每位员工的年化收入运行率达到 160 万美元，并将 Codex 视为工程效率的关键变量。

这不是一个“模型跑分”故事，而是一个关于实时语音系统如何在延迟、可靠性、工具调用和工程组织之间做取舍的样本。依据现有素材，本文梳理 Retell 的模型选型方法、通话架构、容量策略与研发流程，并给出对语音智能体落地的一些判断。

配图建议：Retell 语音智能体基准测试结果图（素材中已有真实图片，可在编辑器中上传对应原图）

一、模型选型：用真实通话而不是演示来投票

企业语音智能体面临的约束比通用聊天机器人更苛刻：它需要遵循公司政策、保持在指定角色范围内，即使对话走向发生变化也不能“跑偏”。Retell 为此构建了 vCX 基准测试，使用来自真实生产场景的困难多轮对话来比较数十个模型，测试维度包括指令遵循、基于给定信息作答、调用正确工具以及使用自然对话语言的能力。

在 Retell 2026 年 10 月 13 日的基准测试中，GPT‑6 Astra 以 89.7% 的指令遵循率排名第一。Retell 还分享了 GPT‑6 Astra 发布前的评估结果：在启用推理的情况下，GPT‑5.5 在非幻觉率（88.0%）和工具调用正确性（88.3%）两项指标上均排名最高，优于 Gemini‑3.1‑Pro 和 Claude‑4.6；在关闭推理的情况下，它在非幻觉率上也处于领先地位。

Retell 的选型逻辑可以用其原话概括：“我们选择模型的方式就像客户选择供应商一样：看真实通话，而不是演示。OpenAI 一直在赢得它的位置。”素材还提到，选择 OpenAI 模型的新客户会继续使用这些模型；客户可以通过 Realtime API 使用 OpenAI Realtime 模型，并将 OpenAI 文本转语音作为语音引擎；Retell 会在新的 OpenAI 模型发布当天即提供这些模型，并随着模型改进重新运行基准测试。

要点：

• 语音场景的模型评估应以多轮、带工具调用的真实任务为主，而非单轮问答。
• 指令遵循率、非幻觉率、工具调用正确性应作为并列的核心指标。
• 模型发布当天即上线、并持续重跑基准，意味着平台需要把“模型评估”做成常态化工程能力。

二、通话架构：harness 负责调度，模型负责决策

从素材披露的架构看，Retell 并没有把“语音智能体”简化为一次 LLM 调用。在通话过程中，Retell 的 harness 负责运行音频模型、跟踪对话，并管理智能体何时说话、倾听或响应打断。OpenAI 模型（包括 GPT‑6.1 Sol、GPT‑6 Astra 和 GPT‑5.5）使用客户的指令和对话上下文来生成响应并请求工具调用；Retell 通过与客户系统的集成执行这些调用，并可将结果写回客户记录。

人工接管也被设计进流程：当需要人工判断时，语音智能体会向代表简要说明上下文，回答他们的后续问题，并在确认他们准备好后再接通客户。通话结束后，Retell 使用 GPT‑5.6 Terra 分析转录文本并提取结果和其他数据。

配图建议：Retell 通话架构示意图（素材中已有真实图片，可在编辑器中上传对应原图）

这一分层值得注意：实时语音的难点不只是“生成一句话”，而是打断处理、轮次管理、工具调用编排和结果回写。把调度逻辑放在 harness、把语义决策交给模型，是一种更接近生产系统的职责划分。

三、效果验证：从解决率到 NPS 与人力再分配

Retell 报告客户解决率超过 80%。素材给出了两个具体案例：

• Anker：智能体在美国和英国处理一线售后服务，包括订单跟踪、保修检查和故障排除，报告 80.4% 的案例解决率和 63 的净推荐值（NPS）；其团队表示智能体的语气、节奏和亲和力达到了对 AI 智能体的预期标准。
• Pine Park Health：智能体处理预约提醒和主动排程，并将结果记录在患者病历中；团队回收了相当于 2.1 个全职角色的医疗助理时间，并将其重新分配到患者护理中；其排程智能体在联系到患者时实现了 55.7% 的预约率。

趋势判断： 语音智能体的价值评估正在从“像不像人”转向“能不能闭环”。解决率、NPS、预约率、释放的人力时间，都是比语音自然度更接近业务结果的指标。依据现有素材判断，能够在通话中完成工具调用并回写业务系统的智能体，才具备规模化运营的基础。

四、容量与可靠性：50 倍日间峰值下的延迟工程

Retell 平台上的日间流量可达夜间低峰的 50 倍以上。为在需求高峰时保持通话响应性，Retell 使用与 OpenAI 合作的专用服务器，并在其客户之间共享。

延迟方面，在 Retell 2026 年 10 月 13 日的基准测试中，GPT‑6 Astra 和 GPT‑6 Sol 的首句延迟中位数均为 883 毫秒，GPT‑5.6 Luna 以 497 毫秒排名最高。OpenAI 的区域 API 端点允许开发者将流量路由到特定地理区域，这有助于 Retell 减少网络传输时间，并满足医疗保健和金融服务等行业客户的数据驻留要求。

可靠性上，Retell 在服务的每一层构建了冗余：运行自己的电话技术栈，并备有第二套技术栈随时接管，同时为语音和模型服务提供备份，以帮助在服务故障时保持通话运行。

要点：

• 首句延迟是语音体验的关键指标，但不同模型之间存在明显差异，需要按场景做路由。
• 区域化 API 端点同时服务于延迟优化与数据驻留合规，这在医疗、金融行业尤为关键。
• 电话栈、语音服务、模型服务三层冗余，说明语音智能体的 SLA 不能只押注在单一供应商上。

五、Codex 进入研发闭环：从读代码到测试前端

素材显示，Retell 的工程师在整个开发过程中使用 Codex：从研究不熟悉的代码到构建功能和调试问题，并使用 GPT‑6 Astra 测试前端界面。

具体而言，在编写代码之前，工程师向 Codex 提出高层次需求，Codex 会浏览代码、对照实际数据进行检查，并解释需要更改的内容；一位工程师表示，Codex 在这项研究上做得比他更好，而且快得多。在实现过程中，工程师们表示 Codex 经常能捕捉到他们未曾考虑到的细节。调试方面，Codex 会将日志和数据库记录与代码进行交叉引用，以调查正在发生的情况。Retell 的工程师还在与基于 OpenAI 模型构建的客户合作时使用 Codex，以加速编写“指导模型在客户应用中如何响应”的指令等任务。

前端测试则依赖 GPT‑6 Astra 的计算机使用能力：当工程师打开一个前端拉取请求时，GPT‑6 Astra 会打开界面、点击浏览、测试流程、尝试破坏它们，并报告发现的问题。Retell 表示，早期的模型无法可靠地完成这项工作。

Retell 继续招聘，但其工程团队无需以与业务相同的速度增长，公司报告每位员工的年化收入为 160 万美元。其工程师将 Codex 描述为“一个虚拟队友，可以在任何类型的困难任务上与他们配对协作”。

趋势判断： 依据现有素材判断，AI 编程工具的价值正在从“补全代码”扩展到“代码库研究、跨日志与数据库的调试、以及基于计算机使用的端到端测试”。这类能力对定制化工作流密集的企业服务公司尤其重要，因为它直接缓解了“业务增长快于工程团队扩张”的组织压力。

六、下一步：把专业知识交还给最接近业务的人

Retell 的定位是让最接近这项工作的人员直接运用他们的专业知识，使用语音 AI 和一个能够构建、测试和改进智能体的平台。素材提到，Retell 接下来计划扩展质量保证和模拟、支持更多语言，并开发知识库自动学习功能。

其负责人 Bing 的表述是：“没有人比公司本身更了解其客户。我们赋予他们运用这种专业知识并直接改进 AI 智能体的能力。目标是让他们建立一个由内部部署工程师组成的内部团队，负责并运营这一切。”

结论

Retell 的案例提供了三个可复用的观察：

1. 模型选型要产品化。 用真实生产对话构建基准、在新模型发布当天上线并持续重跑，是把模型能力转化为产品能力的前提。
2. 实时语音是系统工程。 harness 调度、工具调用、结果回写、人工接管、区域化路由与多层冗余，共同决定了通话能否稳定闭环。
3. 工程效率是增长杠杆。 Codex 与计算机使用能力进入研究、实现、调试和前端测试环节，使得工程团队的扩张速度可以低于业务增长速度。

依据现有素材判断，语音智能体的竞争焦点已经从“能不能对话”转向“能不能在高峰流量下稳定解决业务问题，并让企业自己持续改进它”。这或许才是每月 1 亿次通话真正的含义。

生成标记：本文由 ITPUB 文章生成平台基于已选素材整理生成。