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

但 Realtime API 不是完整的 AI 语音客服系统。它不会替你完成客户授权、号码和线路运营、知识库治理、CRM 幂等写入、转人工队列、录音审计或成本预算。尤其当目标是中文电话客服生产环境时，系统能否上线取决于电话链路、中文关键字段、打断策略、工具边界和业务闭环，而不只是模型能否“实时说话”。

本文基于 OpenAI 公开 API 文档拆解自研路径，不报告真实通话压测或成本数据。Realtime 模型、可用接口与价格可能调整，实际接入前应以当前官方模型页和定价页为准。

一、本文范围与限制

本文讨论的是用 OpenAI Realtime API 构建 Voice Agent 的工程边界：

• 浏览器、服务端或电话链路如何建立实时会话；
• 实时语音、文本、图片输入与工具调用在系统中的位置；
• 为什么函数调用需要企业后端做权限与状态校验；
• 会话上下文、音频使用量和工具调用如何进入成本口径；
• 中文客服、转人工、CRM 和可观测性需要额外补哪些层。

本文不评价任何行业的合规适用性，不承诺国内电话线路可用性，也不把官方模型能力等同于业务系统已经具备生产闭环。

二、Realtime API 做的是实时会话层，不是完整客服闭环

官方 API 参考将 Realtime 描述为通过 WebRTC、WebSocket 或 SIP 进行低延迟多模态实时通信的接口；当前模型页也将 gpt-realtime 定义为支持实时文本和音频输入输出、并支持函数调用的模型。

在一个自研 Voice Agent 中，合理的职责拆分应是：

Realtime API 可以让 C 和部分 B 更快落地，但 F、I 以及电话运营策略仍由企业负责。把模型的 Function Call 直接理解为“模型可以安全写 CRM”是一个常见误区：模型只能提出工具调用意图，真正的写操作必须由业务服务做身份、权限、参数和状态校验。

三、WebRTC、WebSocket、SIP：先按入口选连接方式

Realtime API 的连接方式不是互相替代的“性能档位”，而是适合不同入口：

入口	更适合的连接方式	需要额外注意
Web/App 用户实时对话	WebRTC	麦克风权限、网络切换、播放取消、短期凭据
服务端编排或测试工具	WebSocket	密钥隔离、会话事件消费、断线重连与状态恢复
电话接入	SIP 或电话平台桥接	号码、SIP trunk、编解码、通话状态、转人工

官方 Realtime API 参考提供了通过 SDP 创建 WebRTC call 的接口，并在会话创建时允许传入 session 配置。工程上不应把长期 API Key 放到浏览器：浏览器侧只负责媒体与会话协商，业务权限和敏感工具仍应由后端控制。

四、工具调用能连上业务，但不能绕过业务规则

Voice Agent 常见工具包括查询订单、查库存、预约日历、创建工单和转接人工。实时模型的函数调用很适合把自然语言意图变成结构化的工具请求，但后端必须把它视为“不可信的业务请求”，而不是直接执行指令。

建议的安全链路如下：

例如，客户说“帮我把明天的演示改到下午”，模型可以抽取时间意图，但不能自行决定客户身份、可用库存或是否覆盖已有预约。后端应至少校验：

1. customer_id 是否已确认且有权限操作；
2. 请求是否来自当前通话/会话；
3. 预约是否存在、时间是否可用；
4. session_id + tool_name + business_id 是否构成幂等键；
5. 失败时是重试、回退，还是创建待人工确认任务。

五、成本控制不能只看模型单价，要看每通会话的结构

Realtime 模型页将文本和音频的输入、输出分别计量；在真实 Voice Agent 中，成本不是“每分钟一个固定值”，而是会话时长、用户沉默、模型回复长度、上下文、音频输入输出、缓存命中和工具调用共同作用的结果。

建议把每次会话拆成如下成本与体验记录：

记录项	目的
session_id、call_id、customer_id	把模型用量与业务事件对齐
用户音频时长与 Agent 播放时长	识别沉默、无效对话和长播报
输入/输出音频与文本用量	对齐模型账单和成本归因
工具调用次数、耗时和失败率	判断业务接口是否拖慢会话
转人工率、拒答率和重复来电率	判断成本是否换来了有效业务结果
首个可听音频延迟	避免为了压缩文本而牺牲对话体验

一个便于分析的事件表可以包含：

session_id | turn_id | event | timestamp | usage_delta | tool_name | outcome

不要把“缩短提示词”当成唯一成本策略。更有效的做法通常是：只给当前业务阶段必要的上下文；把长文档交给检索和后端摘要；在用户沉默、无效线路或明确转人工后及时结束或切换会话；把高风险写操作转成待确认任务。

六、延迟要按 t0-t8 拆，不要只看模型首响

使用 speech-to-speech 的实时模型，可能减少部分串行模块的拼接，但用户体感依然受到媒体采集、网络、VAD、工具调用和播放链路影响。

时间点	含义
t0	用户开始说话
t1	客户端或服务端检测到语音段
t2	首个语音/转写事件可用
t3	当前轮输入结束判定
t4	模型开始处理或发起工具调用
t5	模型返回首个回复事件
t6	首个输出音频可用
t7	用户端或电话侧开始播放
t8	本轮结束、业务结果已写回

建议至少区分三类问题：t0-t7 高是媒体或模型交互慢；t4-t5 高可能是模型或上下文问题；t4-t8 高但 t4-t5 低，往往是工具、CRM 或转人工流程在拖慢业务闭环。

七、中文客服适配：要测的不是“能不能说中文”，而是能不能安全完成业务

对于中文 AI 语音客服，建议在真实或脱敏样本中单独测试：

• 手机号、地址、金额、日期、订单号和业务热词的确认流程；
• 客户插话时，旧音频是否停止、旧业务意图是否取消；
• 模型遇到知识库无答案、价格承诺、投诉或敏感信息时能否拒答并转人工；
• 电话窄带、网络抖动、方言和多人环境下的听辨与轮次控制；
• 人工接管时是否获得客户身份、已执行工具、待办和会话摘要；
• 会话记录、音频、工具参数和 CRM 数据是否满足企业的数据治理要求。

没有这些验证，任何“中文效果很好”的印象都只是 Demo 体验，而不是生产结论。

八、OpenAI Realtime API 与自建完整 Voice Agent 的取舍

更适合直接用 Realtime API 的情况

• 团队需要快速验证实时语音交互、工具调用和自然对话；
• 已有 Web/App、电话接入或自己的实时媒体层；
• 后端可以承接权限、CRM、检索、工单和审计；
• 愿意持续观察模型版本、用量、事件和异常样本。

需要额外建设，不能只依赖 API 的部分

• 电话号码、SIP trunk、外呼授权、频控和退订；
• CRM/工单的权限、幂等、补偿和字段治理；
• 中文业务知识的检索、拒答和版本控制；
• 转人工排班、摘要交接、录音质检和投诉处置；
• 用量预算、限流、异常会话终止与可观测性。

一句话总结：Realtime API 能缩短实时语音智能层的自研时间；要变成生产 Voice Agent，仍必须补齐电话、业务和运营三层系统。

FAQ

OpenAI Realtime API 可以直接做电话客服吗？

官方文档支持通过 WebRTC、WebSocket 和 SIP 进行实时通信。实际电话客服仍要解决号码、电话供应商、线路、呼叫状态、转人工和业务合规等工程问题。

Realtime API 的函数调用能直接写 CRM 吗？

不建议直接写。模型可发起结构化工具请求，但 CRM 写入应由企业后端执行权限、状态、幂等和审计校验。

怎样控制 Realtime Voice Agent 成本？

先记录每个 session 的音频输入输出、文本用量、上下文、工具调用和会话时长，再把成本与转人工率、业务完成率和异常会话关联。不要只凭单价或单次演示估算。

OpenAI Realtime API 适合中文客服吗？

需要实测。特别是电话音频、数字地址、打断、业务热词、拒答和人工接管，必须放进真实业务样本与目标线路下验证。

参考资料

• OpenAI Realtime API 官方参考
• OpenAI GPT-Realtime 官方模型页
• OpenAI 数据控制与 Realtime 区域支持
• OpenAI Audio API 官方参考