给 SaaS 产品加入实时 AI 数字人，并不等于要把整套产品能力外包出去。真正要回答的问题更具体：哪一层能力值得成为团队长期自建和维护的核心？
对很多 SaaS 产品而言，客户真正购买的是工作流、行业上下文、智能体行为、产品数据和围绕数字人设计的界面，而不是动作生成或渲染本身。此时，评估一个专门的数字人层，往往比把动作与渲染做成新的内部平台更合理。反过来，如果动作表现或渲染能力就是产品的核心 IP，自建也可能是正确选择——但它意味着持续的工程责任，而不只是上线前的一个项目。
Spatius 是实时数字人交互层：Motion Server 接收经过应用批准的数字人语音音频，返回动作数据；AvatarKit 在客户端本地渲染数字人。你的应用仍然负责产品的智能与业务逻辑，包括 ASR、LLM、TTS、上下文与检索、权限、工具、工作流、决策、分析和人工交接。做架构判断前，请以 Spatius Docs Map 为准。
先把产品能力和数字人层分开
“AI 数字人”这个词常把多套系统混在一起讨论。要做出可靠选择，第一步是把责任边界画清楚。
| 层级 | 通常由 SaaS 产品负责 | 实时数字人层可以负责 |
|---|---|---|
| 对话 | ASR、LLM、TTS、提示词、轮次管理和打断规则 | 使用最终已批准的数字人语音音频 |
| 产品智能 | 上下文、检索、客户数据、权限、策略、工具、工作流和业务规则 | 不替代这些系统 |
| 数字人呈现 | 产品内的位置、UI 控件、指标和降级体验 | 按选定集成方式处理音频到动作，并完成本地数字人渲染 |
在 Spatius 的边界里，这并不是抽象的分工：Motion Server 将数字人语音音频转换为动作数据，AvatarKit 利用这些动作数据在客户端渲染。数字人层不会变成你的智能体、智能体编排系统、视频生成系统，或产品数据的事实来源。
这个划分会改变“自建还是采购”的讨论。你不是在“有控制权”和“没控制权”之间二选一，而是在判断：控制哪一层最能创造客户价值，哪一层更适合通过清楚、可验证的集成边界来获得。
什么情况下优先考虑集成
当数字人只是包裹在既有产品能力之上的体验层时，集成通常是更强的起点。例如试用引导、产品讲解、支持流程、练习与模拟，或产品内助手。产品的独特性仍来自你自己的业务工作流和上下文。
此时更值得问的是：
- 数字人能否接收现有应用或智能体产生的语音？
- 我们能否继续掌握客户上下文、权限、工具和工作流决策？
- 已文档化的集成路径是否适合现有客户端和后端架构？
- 产品团队能否在不把数字人运行时变成独立平台项目的前提下迭代用户旅程？
选择专门的能力层不等于把它当成黑盒，而是有意识地分工：应用负责对话和产品策略，数字人层负责它所说明的动作与渲染职责。
什么情况下自建才是战略投入
如果动作或渲染系统本身就是客户购买的、可持续差异化的一部分，自建更有依据。比如你必须拥有独特的呈现方式，需要某种已文档化集成无法满足的运行时模型，或者团队已经具备长期维护这类能力的组织基础。
在决定自建前，请把下列责任写下来：
- 首个版本之后，谁负责运行时路线图？
- 谁维护客户端兼容性、回归测试、监控和事故响应？
- 面向实际用户旅程，动作和渲染必须达到什么质量标准？
- 当智能体、语音链路或客户端体验变化时，哪些新要求会变成团队自己的维护工作？
如果没有团队长期拥有这些答案，“自建带来更多控制”往往只是一种表面上的控制。
先定所有权，再选集成方式
“实时”并不是单一架构。确定了希望保留哪些责任、语音音频在何处产生之后，再选择集成模型。
Direct Mode：在客户端呈现数字人
在 Direct Mode 中，后端创建 Session Token。客户端里的 AvatarKit 使用该 Token 通过 WebSocket 连接 Motion Server，发送数字人语音音频、接收动作数据，并在本地渲染数字人。后端负责签发 Token，但不是这条音频和动作运行时链路的中继。
如果你的产品已经能产生数字人要呈现的语音，并希望数字人位于客户端体验中，这种方式值得评估。其他架构应从 文档地图 开始，选择与实际应用相符的已文档化路径，而不是根据泛泛的协议标签做决定。
比较完整的运营面，而不只是原型
原型可以证明数字人是否适合某个用户旅程，但它没有覆盖当该旅程成为长期维护的生产能力后，团队需要承担的所有工作。
请用真实的产品条件比较两种方案：
| 领域 | 应回答的问题 |
|---|---|
| 初始实现 | 谁设计客户端集成、鉴权、状态管理和错误表现？ |
| 产品集成 | 正确的语音、产品上下文和用户权限状态如何抵达相应系统？ |
| 质量保障 | 谁针对受支持的产品流程测试打断、重连、客户端生命周期变化和降级？ |
| 持续运营 | 谁负责兼容性、监控、支持排查和事故响应？ |
| 产品迭代 | 当工作流演进时，脚本、UI 控件和数字人行为能多容易地变化？ |
| 商业评估 | 已批准的使用假设、内部工程成本、采购需求和支持预期是什么？ |
不要用泛化的价格、基础设施、带宽或性能说法代替上述分析。这些判断应来自你的已批准方案和具有代表性的产品测试。
用决策记录替代口号
下表用于引导内部讨论，而不是承诺某个方案总是更便宜或更简单。
| 决策因素 | 集成数字人层通常更适合… | 自建通常更适合… |
|---|---|---|
| 差异化 | 客户价值主要来自工作流、智能体或数据。 | 动作和渲染就是核心差异化 IP。 |
| 所有权 | 希望有清晰边界，让团队专注于其他层。 | 需要掌握完整运行时路线和实现细节。 |
| 架构 | 有已文档化路径适配现有产品模型。 | 关键约束无法由可用集成路径满足。 |
| 运营 | 希望减少团队直接维护的运行时范围。 | 有专门团队准备长期拥有运行时。 |
| 学习 | 需要先验证一个聚焦用户旅程。 | 已验证场景，且明确知道为何必须定制实现。 |
先试点一个明确的工作，再决定平台方向
从数字人有明确职责的用户旅程开始：帮助试用用户完成关键设置、提供与上下文相关的产品演示，或支持受控的练习场景。定义用户应该完成什么，以及应用要衡量什么。
在扩大范围前，写清：
- 交互中每一步由哪个系统负责；
- 正在评估哪条集成路径和客户端生命周期；
- 产品如何处理鉴权、用户控件、打断、错误和人工交接；
- 产品内容、上下文、权限和工具如何治理；以及
- 什么证据足以支持把体验扩展到下一个工作流。
这样做能让后续的自建或集成判断回到事实，也能避免把视觉呈现层误当成产品本身，却没有定义真正关键的客户工作流。
常见问题
集成数字人层会替代我们的 AI 智能体吗？
不会。应用仍然负责 ASR、LLM、TTS、上下文与检索、产品数据、权限、工具、工作流、决策、分析和人工交接。Spatius 提供已文档化的音频到动作及本地渲染层。
Spatius 会返回一个完成的视频文件吗？
不会。Motion Server 接收数字人语音音频并返回动作数据，AvatarKit 在客户端本地渲染。当前产品边界请查看 Spatius Docs Map。
Direct Mode 会把我们的运行时逻辑迁移到 Spatius 后端吗？
不会。在 Direct Mode 中，后端创建 Session Token，AvatarKit 通过 WebSocket 与 Motion Server 完成数字人音频和动作链路，而应用仍然拥有智能体、产品逻辑和数据责任。实现细节请参考 Direct Mode 文档。
用一个真实产品流程来讨论
下一步不该是泛泛的自建/采购评分，而应围绕一个团队已经了解的工作流，梳理语音链路、客户端体验、数据边界和希望保留的责任。
预约演示，讨论实时数字人层如何进入你的 SaaS 产品。