首个动作时间应该从真实用户触发开始，直到客户端显示第一个与回复相关的动作，而不是从某个内部 API 调用开始。只有统一定义指标，团队才知道是在优化 Agent、TTS、动作服务还是本地渲染。
核心结论
- 明确起点、终点、冷启动和失败会话的统计规则。
- 先消除不必要的串行工作，再考虑预加载和预热。
- 让 TTS 尽快产生有意义、可提交的首段音频。
- 不要用虚假动作或过早语音换取漂亮指标。
优化前先定义指标
建议同时记录：用户结束输入、Agent 首 Token、首个可说文本、首个 TTS 音频、动作服务接收、客户端收到首个动作和首个可见动作。使用 Performance API记录客户端时间，并通过关联 ID 与服务端 Trace 对齐。
移除可以避免的启动工作
检查是否把权限请求、Token 签发、角色配置、资源下载、Agent 初始化和 TTS 初始化全部串行执行。能安全并行的步骤应并行；与用户动作无关的配置可在更早阶段准备。
同时记录冷启动与热启动。只公布热缓存结果会低估新用户和长时间未使用后的体验。
有意识地预热渲染器
预加载并不等于在每个页面下载所有资源。根据用户进入相关工作流、打开面板或明确选择数字人等信号分阶段加载，并遵守设备内存与流量预算。浏览器可以使用 Resource Timing API确认实际资源成本。
从有用的音频分片开始
TTS 首段过大，会让动作开始变慢；首段过小，则可能产生不自然的断裂和错误开头。以句法边界和可提交内容为准，而不是固定字符数。对于需要工具结果或引用确认的回答，宁可显示明确等待状态，也不要过早朗读。
避免虚假开始
与回答无关的点头、循环口型或“让我想想”可能缩短某个视觉指标，却会让用户误判系统已经开始回答。首个动作应与真实会话状态一致，并且用户仍能打断、退出或切换到文字。
测量 Spatius 启动路径
应用拥有 Agent 与 TTS；Spatius Motion Server 接收数字人语音音频并返回动作数据，AvatarKit 本地渲染。因此要分别测量 TTS 首段、音频发送、首个动作返回与首个本地渲染。根据集成路径指南在实际部署边界埋点。
整体实时体验可继续参考什么让 AI 数字人真正具有实时感。
常见问题
首个动作时间等于首帧时间吗？
不等于。首帧可能只是静态角色或加载画面；首个动作必须是与当前回复相关、用户可见的动作。
是否应该在首页预加载？
只有当用户很可能启动数字人，且资源、隐私和性能成本可接受时。更常见的做法是按工作流信号逐步准备。