给 OpenAI Realtime API 语音智能体添加虚拟人，最清晰的方式是让 OpenAI 继续负责对话，只把助手最终输出的音频交给独立的虚拟人层。 Spatius 将这段语音转换为动作数据，AvatarKit 在客户端本地渲染虚拟人。智能体、工具、提示词和轮次控制仍由原有 OpenAI 应用负责。
独立教程声明： Spatius 与 OpenAI 不存在隶属、背书或官方集成合作关系。本文根据双方公开 API 与文档说明一种互操作架构，不代表已经提供封装好的原生连接器。
最后核验：2026 年 9 月 22 日。
两个系统分别负责什么
OpenAI Realtime API 支持实时音频对话、会话状态、中断和工具调用。它属于语音智能体层，不需要同时承担虚拟人渲染。
Spatius Direct Mode 从另一侧切入：应用已经拥有经过确认的虚拟人语音，AvatarKit 把音频发送到 Motion Server，接收动作数据，并在客户端本地完成渲染。
| 职责 | OpenAI Realtime API 应用 | Spatius |
|---|---|---|
| 用户麦克风与对话会话 | 负责 | 不负责 |
| 智能体指令、工具、权限和业务逻辑 | 负责 | 不负责 |
| 助手语音 | 生成 | 作为虚拟人驱动输入接收 |
| 面部动作 | 无需负责 | Motion Server 生成动作数据 |
| 虚拟人渲染 | 不负责 | AvatarKit 在客户端本地渲染 |
| 产品 UI、分析与人工接管 | 负责 | 不负责 |
这样的边界可以避免团队为了增加一张脸而重建已经可用的语音智能体。
参考架构
核心规则很简单：用户实际听到的那一路助手音频，也应该用于驱动虚拟人。
用户麦克风
↓
OpenAI Realtime 会话
├─ 对话状态、工具、中断
└─ 助手输出音频
↓
应用音频交接层
↓
Spatius Motion Server
↓ 动作数据
客户端 AvatarKit
↓
本地渲染虚拟人不要把用户麦克风音频发送给虚拟人层。虚拟人只应跟随助手最终确认的语音运动。提示词、转录、工具参数、客户记录和智能体内部状态不需要为了驱动虚拟人而跨越这条边界。
选择 Direct Mode 还是 Backend Mode
Spatius 提供多种集成路径。选择依据是应用在哪一层能够取得助手音频。
| 音频归属 | 建议的 Spatius 路径 | 架构结果 |
|---|---|---|
| 浏览器或移动客户端接收助手音频 | Direct Mode | 客户端把虚拟人语音发送给 Motion Server，并通过 AvatarKit 渲染 |
| 可信后端接收并控制助手音频 | Backend Mode | 后端通过 Spatius Server SDK 连接，并把音频与动作负载传递给客户端 |
| 已使用 LiveKit Agents | 已有的 LiveKit 集成 | 使用现成 LiveKit 路径，不要再设计一套平行连接器 |
对于浏览器端 Realtime 应用，OpenAI 建议客户端使用 WebRTC，生成的语音以远端媒体到达。当客户端能以当前 Spatius 音频文档要求的格式取得输出音频时，Direct Mode 是自然的起点。
如果 OpenAI 会话通过可信服务器连接运行，并由后端持有输出音频分片，Backend Mode 可以形成更明确的安全边界。相应地，后端也需要负责传递、恢复和同步。
第一步：先建立稳定的 Realtime 语音会话
添加虚拟人之前，先按照 OpenAI 当前的 Realtime 入门文档完成语音链路。浏览器和移动客户端不应持有永久项目凭证，应使用 OpenAI 当前文档规定的短期客户端授权流程。
此时先在没有虚拟人的情况下确认四件事：
- 用户能够说话并听到助手；
- 工具调用和业务规则正常；
- 用户能够中断助手；
- 会话关闭和重连行为可以被观测。
如果语音链路尚不稳定就加入虚拟人，故障会更难归因。
第二步：独立初始化虚拟人
在独立产品边界中创建 Spatius 会话。Spatius API Key 应留在后端，只向客户端返回短期 Session Token 和所需的公开标识。Direct Mode 客户端文档描述了完整生命周期：初始化、加载并挂载虚拟人、连接、发送虚拟人语音，最后关闭并释放资源。
虚拟人应在第一段助手语音开始前准备就绪，否则用户可能已经听到回答，角色却仍在加载。
第三步：只交接一次助手音频
把 OpenAI 的助手输出作为唯一事实来源。应用只需要一个受控交接点，让同一段语音同时服务于播放和动作生成。
收到助手音频时：
保持分片顺序与时间戳
只播放或路由一次已确认输出
把对应虚拟人语音发送给 Spatius
助手回答完成时：
完成当前虚拟人语音轮次
用户中断时：
停止助手播放
停止或清除对应虚拟人轮次以上是伪代码。具体音频事件、媒体轨访问、编码方式和 AvatarKit 调用取决于当前 OpenAI 连接方式与 Spatius SDK 版本。实现时应参考双方最新官方文档，而不是从文章中复制未经验证的方法名。
常见错误是重复播放：一路播放 OpenAI 远端音轨，另一路又播放复制后的缓冲区。产品应只保留一个权威扬声器路径，另一个分支仅用于动作生成。
第四步：同步中断与结束状态
如果用户已经打断助手，但虚拟人仍继续说话，体验会立即显得失控。OpenAI 的 Realtime 对话文档说明了语音与回答结束附近的会话事件。虚拟人集成应把同一生命周期映射到视觉播放。
需要明确测试：
- 正常回答结束；
- 第一段音频期间用户插话；
- 回答即将结束时用户插话；
- 工具调用后继续说话；
- 说话过程中网络中断；
- 虚拟人或语音会话单独失败后的重连。
不要仅根据文字转录推断视觉状态。虚拟人必须匹配用户实际听到的内容，因此音频播放状态才是相关事实来源。
第五步：分别测试两个层级
报告端到端数字之前，应分别测量语音层和虚拟人层。
| 指标 | 语音智能体层 | 虚拟人层 |
|---|---|---|
| 首段助手音频时间 | OpenAI 会话与应用 | 不包含 |
| 音频间隙或轮次错误 | OpenAI/应用传输 | 不包含 |
| 音频到动作延迟 | 不包含 | Spatius 路径 |
| 客户端渲染帧稳定性 | 不包含 | AvatarKit 与目标设备 |
| 中断正确性 | 共享产品行为 | 两层必须同时停止 |
| 总成本 | OpenAI 用量与应用基础设施 | Spatius 套餐与虚拟人用量 |
OpenAI 在当前模型文档中公布模型价格，Spatius 则有独立的虚拟人价格。没有工作负载模型时，不应把两者合并成一个通用每分钟价格。
这种架构适合什么团队
当 OpenAI Realtime 智能体已经是产品的对话系统，而团队只想增加视觉存在感，同时保留提示词、工具、权限、分析和语音行为时，这种模式最合适。
如果团队希望一家供应商负责完整智能体和云端渲染视频体验，它就不一定合适。完整平台可能减少集成工作，但也会改变供应商归属和运营经济模型。
如需扩展评估，可阅读如何给现有 SaaS AI 智能体添加虚拟人和实时虚拟人价格对比。
OpenAI Realtime 虚拟人常见问题
这是 OpenAI 与 Spatius 的官方集成吗？
不是。本文是基于公开接口编写的独立互操作教程。Spatius 不声称与 OpenAI 建立合作关系，也不声称已经提供封装好的 OpenAI 连接器。
Spatius 会替代 OpenAI Realtime API 吗？
不会。OpenAI 负责实时对话会话、助手行为、工具和生成语音。Spatius 使用经过确认的助手语音生成虚拟人动作，并在客户端本地渲染角色。
浏览器应使用 WebRTC 还是 WebSocket 连接 OpenAI Realtime？
OpenAI 建议浏览器和移动客户端使用 WebRTC。服务器架构可以使用当前文档支持的服务器连接方式。应先确定连接架构，再选择 Direct Mode 或 Backend Mode。
必须向 Spatius 发送哪些数据？
虚拟人层需要助手语音，以及建立 Spatius 会话所需的标识和凭证。提示词、用户转录、工具参数和智能体内部状态不需要仅为了驱动虚拟人而发送。
概念验证应该确认什么？
应确认音频格式、有序流式传输、虚拟人就绪、正常结束、中断、重连、目标设备渲染，以及语音层和虚拟人层各自的成本与延迟。
添加一张脸，而不是替换智能体
OpenAI Realtime API 可以继续作为语音和推理系统，Spatius 则负责视觉呈现层。明确这条边界可以让架构更容易测试、保护和替换。
带上你的 Realtime 语音智能体架构和目标客户端，我们可以帮助你在不替换现有智能体的前提下评估 Spatius Direct Mode 或 Backend Mode。 预约演示, or ，或查看 Spatius 价格.。