事件概述

OpenAI 于 2026 年 10 月 27 日发布客户案例，介绍语音 AI 平台 Retell AI 如何使用 OpenAI 模型支撑其通话业务。据原文，Retell 面向呼叫中心运营场景，帮助企业构建能够回答问题、执行操作、并在需要时转接真人的语音 Agent。平台目前服务超过 4000 家企业，月通话量从 2026 年初的 3000 万增长到 9 月的 1 亿以上。

几个关键数字：

  • OpenAI 模型为 Retell 平台上 80% 的通话生成回复，客户解决率超过 80%；
  • Retell 在 OpenAI 模型上累计消耗超过 1 万亿 tokens；
  • 工程团队未随业务同速扩张，公司报告每员工 160 万美元年度收入 run rate。

原文同时提到，Retell 工程师在开发全流程中使用 Codex，并用 GPT-6 Astra 的 computer use 能力测试前端界面。

关键技术点

1. vCX benchmark：用真实生产对话评测模型

Retell 构建了名为 vCX 的 benchmark，用来自真实生产场景的困难多轮对话对比数十个模型。评测维度包括：指令遵循、是否基于给定信息作答（grounding）、工具调用是否正确、以及对话语言是否自然。

原文给出的结果是：在 2026 年 10 月 13 日的 benchmark 中，GPT-6 Astra 在指令遵循上以 89.7% 排名第一。此外，Retell 还分享了 GPT-6 Astra 发布前所做的评测：开启推理时，GPT-5.5 在非幻觉率（88.0%）和工具调用正确性（88.3%）两项上均为最高，两项指标均优于 Gemini-3.1-Pro 和 Claude-4.6；关闭推理时，GPT-5.5 同样在非幻觉率上领先。

Retell 表示，新 OpenAI 模型在发布当天即上线，并会随模型迭代重跑 benchmark。原文未说明 vCX 的具体样本量、评分细则与数据集构成。

2. 模型组合与通话编排

Retell 的 harness 负责运行音频模型、跟踪对话状态，并管理 Agent 何时说话、倾听或响应打断。OpenAI 模型（原文列举了 GPT-6.1 Sol、GPT-6 Astra、GPT-5.5）依据客户配置的指令与对话上下文生成回复，并发起工具调用请求；Retell 通过与被叫方业务系统的集成执行这些调用，并将结果写回客户记录。

当需要人工介入时，语音 Agent 会向人工坐席简报上下文、回答坐席的追问，并在确认坐席准备好之后再接通客户。通话结束后，Retell 使用 GPT-5.6 Terra 分析转录文本，抽取结果与其他数据。

在语音链路上，客户还可以通过 Realtime API 使用 OpenAI 的 Realtime 模型，并以 OpenAI 文本转语音作为语音引擎。

3. 延迟、区域路由与冗余

原文指出，Retell 平台白天的流量可达夜间低点的 50 倍以上。为应对峰值，Retell 使用与 OpenAI 合作的专用服务器，并在客户之间共享。2026 年 10 月 13 日的 benchmark 显示，GPT-6 Astra 与 GPT-6 Sol 的首句中位延迟均为 883 毫秒，GPT-5.6 Luna 以 497 毫秒为最低。

OpenAI 的区域 API endpoint 允许开发者将流量路由到指定地理区域，Retell 借此缩短网络传输时间，并满足医疗、金融服务等行业的数据驻留要求。此外，Retell 在每一层都构建冗余：自建电话栈并配备可接管的第二套栈，同时为语音与模型服务准备备份。

4. Codex 与 computer use 的工程侧用法

据原文，Retell 工程师在写代码前会把高层需求交给 Codex，由 Codex 浏览代码库、对照实际数据核查，并说明需要改动的地方；有工程师表示 Codex 做这项调研比自己更好也更快。实现阶段，Codex 常能发现工程师未考虑到的细节；调试阶段，Codex 会交叉比对日志、数据库记录与代码来排查问题。工程师也在与客户协作时用 Codex 加速编写引导模型回复的指令。

在前端测试上，工程师提交前端 PR 后，GPT-6 Astra 的 computer use 会打开界面、逐项点击、测试流程、尝试破坏流程并报告发现的问题。原文称更早的模型无法可靠完成这类工作。

对数据科学或 AI Agent 落地的意义

这个案例的价值不在于“又一个语音 Agent 上线”，而在于它展示了一条可复用的工程路径：

第一，评测集来自真实生产对话，而不是演示脚本。语音 Agent 的失败模式高度依赖上下文——打断、改口、多轮工具调用、政策约束，这些在实验室数据里很难覆盖。Retell 用 vCX 把“指令遵循、grounding、工具调用、语言自然度”拆成可比较的指标，并在模型发布当天重跑，本质上把模型选型变成了持续性的回归测试。

第二，模型选型是组合而非单点。同一个平台上，回复生成、通话后抽取、语音合成、前端测试分别使用不同模型，延迟与质量的权衡按场景分配。这对构建 Agent 系统的团队是一个直接提示：不要用一个模型打满全链路。

第三，延迟与容灾是产品指标，不是基础设施细节。首句中位延迟以毫秒计、白天峰值 50 倍、跨区域路由、双层电话栈，这些都是语音场景的硬约束。原文未说明具体的超时阈值与降级策略，但从“每层冗余”的表述看，可靠性被当作架构前提处理。

第四，人工兜底被设计进流程。Agent 在转接前向坐席简报上下文并确认就绪，这一设计把“人机协作”从口号变成了具体接口。

我的技术点评

从公开信息看，这是一篇典型的厂商客户案例，数据由客户侧提供，缺少第三方验证。原文给出的 80% 解决率、Anker 的 80.4% 案例解决率与 NPS 63、Pine Park Health 节省相当于 2.1 个全职医疗助理的时间、预约触达后 55.7% 的预约率，都是值得关注但需要独立核验的业务指标。vCX benchmark 的完整题目、评分口径与对比模型的版本配置，原文未说明，因此“GPT-6 Astra 指令遵循 89.7% 排名第一”这一结论目前只能理解为 Retell 自建评测下的结果。

值得肯定的是评测方法本身：用真实生产多轮对话做模型横评，并在新模型发布当天上线、重跑 benchmark。这种“评测即基础设施”的做法，比一次性选型更接近生产现实。同时，把 Codex 用于代码调研、实现补漏、日志与数据库交叉排查，以及用 computer use 跑前端回归，说明 Agent 工具链的价值正在从“生成代码”转向“承担可验证的工程任务”。

需要保持谨慎的有两点。其一，“每员工 160 万美元年度收入 run rate”是 run rate 而非确认收入，且原文未说明统计口径与团队构成，不宜直接作为人效结论引用。其二，语音 Agent 的高解决率往往与场景边界强相关——Anker 的 Tier-1 售后、Pine Park Health 的预约提醒都属于流程相对结构化的任务，能否外推到更开放的业务流程，原文未提供证据。

对准备落地语音 Agent 的团队，这个案例最可操作的部分是：先建立自己的“真实对话评测集”，把指令遵循、非幻觉、工具调用正确性、首句延迟作为四个并列的一级指标，再谈模型选型；架构上默认人工兜底与多层冗余；把通话后结构化抽取作为独立环节，用转录数据反哺评测集迭代。

原文链接

https://openai.com/index/retell-ai