AI 数字人的“实时感”不是单个服务器延迟，而是一连串用户可以感知的时刻：会话何时准备好、系统何时确认听见、第一段有用语音何时开始、动作是否与音频同步，以及失败后用户是否知道下一步。
核心结论
- 分别记录首个反馈、首个音频、首个动作和完整回答时间。
- 稳定的 p95 往往比极快的最佳案例更重要。
- 打断、停顿和轮次切换会直接影响“是否实时”的主观判断。
- 明确恢复状态比隐藏故障更容易建立信任。
实时是一串连续时刻
用户结束说话后，如果界面完全没有反馈，即使答案很快出现，也可能感觉卡顿。可以先给出轻量状态变化，例如“正在听”“正在查找”或清楚的加载状态，但不要用虚假的动作掩盖长时间等待。
Web 性能领域常用分阶段指标理解体验；数字人同样需要把处理分层。应用可用 Performance API记录客户端事件，再与服务端 Trace 对齐。
形成实时感的五个条件
1. 可预测的启动
用户要知道会话是否准备好、谁先说话，以及加载失败时可以做什么。冷启动、资源下载和权限请求都应单独测量。
2. 快速的首个有效输出
首个输出必须有意义。过早播放“嗯”或无内容动画，可能改善某个计时指标，却不能帮助用户。
3. 自然的轮次管理
用户需要能够打断、暂停或切换到文本。VAD、ASR、Agent 和播放层必须对“谁正在说话”保持一致。Web Speech API说明了浏览器语音能力，但生产产品通常还需要自己的轮次策略。
4. 音频与动作同时开始
口型漂移会迅速破坏真实感。分别测量起始偏移与长回答中的累计漂移，而不是只看帧率。
5. 故障恢复可见
连接中断后，应告诉用户任务是否仍在进行、系统是否重试，以及何时切换到纯音频、文本或人工路径。
用分位数衡量体验
中位数描述常见体验，p95 揭示尾部问题。按设备、地区、网络、冷启动和集成路径拆分数据，避免一个全局平均值掩盖特定用户群的问题。RTC 场景可以结合 WebRTC getStats观察抖动、丢包和帧表现。
Spatius 在实时链路中的位置
应用或 Agent 栈负责 ASR、LLM、TTS、权限、工具与工作流；Spatius 把数字人语音音频转成动作数据，AvatarKit 在客户端本地渲染。不同集成路径的责任位置不同，因此测量点也应随部署方式调整。
首个动作优化可以继续阅读如何缩短 AI 数字人的首个动作时间。
常见问题
延迟越低一定越好吗？
不一定。回答正确性、轮次控制、同步和恢复同样重要。为了提前几十毫秒而让系统说出未经确认的内容，通常得不偿失。
高帧率会让数字人更实时吗？
帧率会影响视觉平滑度，但不能修复慢启动、迟到的语音、错误轮次或音画漂移。