“AI 数字人 API”和“AI 视频生成 API”听起来相近，解决的却是两类不同的产品需求：前者可以支撑产品中的实时数字人交互；后者通常用于产出可审核、发布或复用的成品媒体资产。
对 SaaS 团队来说，关键不在于哪个标签听上去更先进，而在于：这段用户旅程需要产品内的数字人运行时、一个成品视频资产，还是两条独立的工作流？
Spatius 是实时数字人交互层。Motion Server 接收经过应用批准的数字人语音音频并返回动作数据，AvatarKit 在客户端本地渲染数字人。Spatius 不返回成品视频。应用、智能体框架或后端仍然负责 ASR、LLM、TTS、上下文与检索、权限、工具、工作流、决策和人工交接。当前产品边界请以 Spatius Docs Map 为准。
比较输出，而不是 API 这个标签
API 只是访问系统的方式，并不说明系统最终必须产出什么。先确定用户旅程需要的具体输出。
| 产品需要… | 优先评估… | 决定性问题 |
|---|---|---|
| 在活跃产品流程中响应的数字人讲解者 | 实时数字人交互层 | 应用的语音和上下文如何驱动数字人？ |
| 宣传片、教程资产或生成的场景 | 视频生成工作流 | 团队如何创建、审核、批准和发布资产？ |
| 两者都有 | 两条有关联但独立的工作流 | 每个输出在客户旅程中属于哪里？ |
实时数字人交互层
当一个拟人化的界面是产品体验的一部分时，实时数字人层更相关。应用决定回应内容，生成或选择数字人要呈现的语音音频，并继续控制外层工作流。数字人层只提供其文档说明的动作和呈现职责。
它可以用于引导式上手、互动产品教育、练习对话或面向客户的助手。它是一个界面层，不会替代交互背后的智能或策略。
AI 视频生成工作流
视频生成工作流通常围绕媒体资产展开，例如场景、短片、讲解视频或营销素材。不同服务商的能力不同，但产品契约是另一种：团队创建资产、审核它、存储或分发它，并可能在其他地方重复使用。
这很适合创意制作和发布，但不会自动替代需要参与实时、应用控制交互的产品内数字人。
从用户旅程倒推选择
不从技术分类出发，而从用户实际要完成的工作出发，差别会更清楚。
| 用户旅程 | 更适合的起点 | 原因 |
|---|---|---|
| 试用用户需要在产品中完成设置 | 数字人交互层 | 应用控制步骤和权限，数字人呈现由应用生成的语音。 |
| 市场团队需要可复用的发布素材 | 视频生成工作流 | 关键工作是产出、审核和发布媒体资产。 |
| 学习者需要互动练习场景 | 数字人交互层 | 产品拥有场景、评分、策略和回应逻辑，数字人呈现已批准的语音。 |
| 团队需要多个视觉版本供选择 | 视频生成工作流 | 资产审核与选择才是核心工作。 |
同一个 SaaS 公司完全可以同时使用两种能力。例如，团队可以为发布活动制作视频资产，同时在产品的上手或支持流程中使用数字人层。最清晰的设计是让两类输出各自拥有独立的审批、负责人和衡量方式。
Spatius 在数字人集成中处于哪一层
Spatius 的职责刻意保持在较窄的范围内。这样能在加入数字人的同时，不把产品智能迁移到呈现层。
| 应用、智能体或后端拥有 | Spatius 提供 |
|---|---|
| ASR、LLM、TTS、轮次管理、打断行为 | Motion Server 接收数字人语音音频并返回动作数据 |
| 上下文、检索、数据访问、权限、工具、工作流和人工交接 | AvatarKit 在客户端本地渲染数字人 |
| 产品 UI、业务规则、分析与用户控件 | 适用于所选路径的已文档化集成组件 |
因此，“数字人 API”不能被理解为“智能体 API”或“视频生成 API”。你可以保留原有的语音或智能体栈，只在应用已经批准的语音外增加视觉数字人层。
让集成路径匹配现有架构
正确的传输与连接模型取决于语音在何处产生，以及数字人需要出现在哪里。不要因为某个分类页面把所有实时体验说成一种方式，就为产品选择不合适的架构。
Direct Mode：客户端数字人渲染
在 Direct Mode 中，后端创建 Session Token。客户端里的 AvatarKit 通过 WebSocket 连接 Motion Server，发送数字人语音音频、接收动作数据并在本地渲染。后端签发 Token，但不是音频和动作链路的运行时中继。
如果产品需要不同架构，请从 开发者文档地图 查看当前已文档化选项。目标不是把每个产品强行塞进同一协议，而是让数字人层适配你已经拥有的语音链路和用户体验。
围绕真实输出运行小范围 PoC
最有价值的评估应该有一个明确的工作目标，而不是泛泛地测试“AI 视频”。
对于数字人交互层，选择一个具体时刻，例如上手、产品教育或练习流程，并梳理：
- 用户要完成什么；
- 回应文本和数字人语音音频来自哪里；
- 哪个系统能访问相关上下文和工具；
- 用户能够控制、打断或转人工的哪些部分；以及
- 应用将衡量什么结果。
对于视频生成，则使用真实的内容简报，梳理成品资产的审核、批准、存储和发布路径。两项评估不同，是因为它们的输出、负责人和生命周期要求不同。
简明决策清单
以下情况优先考虑数字人交互层：
- 产品交互中确实需要一个实时的视觉讲解者；
- 应用已经拥有或应当拥有智能体和语音栈；
- 相关输出是用于本地数字人渲染的动作数据，而不是成品视频文件。
以下情况优先考虑视频生成工作流：
- 团队需要一个用于创意制作或发布的成品媒体资产；
- 审核、批准、存储和分发是工作流的核心；
- 体验不依赖于数字人在应用控制的交互中实时回应。
当产品确实同时包含两类工作时，再同时评估两者。清楚地划分边界，能避免团队期待数字人运行时输出成品媒体资产，或让视频创作工作流承载实时产品逻辑。
常见问题
Spatius 会返回一个完成的数字人视频吗？
不会。Motion Server 接收数字人语音音频并返回动作数据，AvatarKit 在客户端本地渲染数字人。请查看 Spatius Docs Map 了解标准架构。
数字人层会替代我们的 AI 智能体或聊天机器人吗？
不会。应用、智能体框架或后端仍然负责 ASR、LLM、TTS、上下文与检索、权限、工具、工作流、决策和人工交接。
一个 SaaS 产品能同时使用数字人层和视频生成工作流吗？
可以。在需要由语音驱动的产品内讲解者时使用数字人层；在需要创建媒体资产时使用视频生成工作流。让每一类输出都有独立的负责人、审核流程和成功指标。
讨论你的产品真正需要的输出
如果你正在为现有 SaaS 工作流评估实时数字人交互层，先从语音链路、产品上下文和现有客户端体验开始梳理。
预约演示，讨论适合你产品的集成路径。