当 SaaS 团队加入 AI 数字人时，一个常见误区是认为数字人服务商需要完整的对话上下文：用户记录、权限、检索结果、工具输出、提示词和对话记录。
通常并不需要。
正确的数据边界，要从你正在增加的这一层所承担的工作开始。在 Spatius 中，Motion Server 接收数字人语音音频，并返回实时动作数据；AvatarKit 在客户端本地渲染数字人。你的应用、智能体框架或后端仍然负责对话逻辑，包括 ASR、LLM、TTS、轮次管理、权限、知识、工具和工作流。Spatius 不会返回一段完成的视频。关于当前产品模型，请参阅 Spatius 开发者文档地图。
这为产品和工程团队提供了一条直接的设计原则：将客户与业务上下文保留在需要据此进行推理的系统中；只把数字人层呈现已批准回复所必需的信息传给它。
核心结论
- 从数字人层需要的输出开始，而不是从智能体已有的每一个字段开始。
- 在 Spatius 的流程中，核心呈现输入是数字人语音音频；输出是供本地 AvatarKit 渲染使用的动作数据。
- 除非经过单独审查的需求另有要求，否则身份、权限、知识、提示词、工具调用、CRM 数据和产品分析都应留在你的应用中。
- 一段口头回复本身可能含有敏感信息。在它成为数字人语音音频之前，应先应用你的产品控制机制。
- 为每个额外字段记录用途；再视情况与产品、工程、安全和法务相关方共同审查所选的集成路径。
从系统边界开始，而不是从隐私口号开始
“我们不会发送客户数据”本身很少是有用的设计描述。一段口头回复仍可能包含账户信息、排障说明，或客户记录的摘要。更有用的问题要具体得多：
这个组件要完成自己负责的体验，究竟需要哪些数据？
对实时数字人层而言，这和你的智能体决定“说什么”所需的数据不同。智能体可能需要检索、客户状态、基于角色的权限、业务规则和工具结果。但数字人层不需要这些输入，才能为已经由你的应用批准的回复生成动作。
这种区分是实用的，不是表面工作。它让团队保留已经在运行的控制机制：
- **身份与访问：**你的产品决定用户是谁、属于哪个租户，以及他们可以查看或执行什么。
- **对话与知识：**你的智能体决定使用哪些来源、哪些上下文相关，以及如何形成回复。
- **操作与记录：**你的应用负责工具调用、审批、CRM 更新、支持工单和审计记录。
- **呈现：**数字人层接收应当呈现的语音，并生成渲染所需的动作。
结果是更清晰的架构和更清晰的审查流程。加入数字人并不意味着要把产品的智能迁移到呈现层。
Spatius 在核心动作链路中需要什么
在标准的 Spatius 模型中，关键输入是数字人口头回复的音频。Motion Server 将这段音频转换为动作数据；AvatarKit 消费返回的动作数据并在本地渲染数字人。具体连接路径取决于你选择的集成方式，但产品边界保持不变。集成指南介绍了 Direct Mode、平台集成和 Backend Mode。
通常应留在应用内的数据
以下信息通常属于你的产品或智能体层，并非数字人动作服务商的默认输入：
| 数据或能力 | 为什么应由你的应用负责 | 数字人层实际需要什么 |
|---|---|---|
| 用户、账户和租户记录 | 它们决定身份、权限和业务上下文。 | 应用允许数字人说出的最终回复。 |
| 角色和权限 | 授权决策必须留在实际执行授权的系统中。 | 无需用原始角色模型来驱动语音动作。 |
| 系统提示词、对话历史和检索上下文 | 它们会塑造回答，且可能包含内部或客户信息。 | 基于该上下文生成、并已获批准的语音音频。 |
| 知识库文档和附件 | 智能体需要它们进行推理；动作生成不需要。 | 默认不需要文档载荷。 |
| 工具凭据、工具输入和工具结果 | 它们会触发或记录业务操作。 | 应用完成任何允许操作之后的回复。 |
| 产品分析和 CRM 事件 | 它们属于产品的度量与运营体系。 | 仅限你有意实现并审查过的集成遥测数据。 |
这并不是说任何数据都绝对不能传递，而是数据最小化的起点。如果你的架构提出额外字段，应能解释其用途、谁可以访问、需要保留多久，以及为什么没有它数字人体验就无法运行。
口头回复本身也值得单独审查
把数字人语音称为“只是音频”很容易，但在企业产品中，它仍可能包含有意义的内容。应用应在 TTS 生成数字人音频之前，决定哪些内容可以被说出。这可以包括你已经用于文本或语音回复的同类产品控制：
- 在生成回答前应用用户当前的权限；
- 在回复描述或触发有重大影响的操作前，要求确认；
- 将试点范围限制在已批准的话题或工作流内；
- 当产品无法安全回答时，决定如何对回答进行脱敏、摘要或升级处理。
关键在于责任归属：数字人层呈现已批准的回复；它不应成为产品作出授权或工具使用决策的地方。
先选择路径，再映射数据流
相同的数据边界原则适用于不同集成路径，但传输方式和运行时责任会不同。不要把某一种协议视作通用解法。应选择与你团队现有运行时相匹配的路径。
Direct Mode：将现有语音音频从客户端发送到 Motion Server
在 Direct Mode 中，你的后端签发 Session Token，客户端的 AvatarKit 使用 WebSocket 直接连接 Motion Server。客户端发送数字人语音音频、接收动作数据，并在本地渲染。Token 端点不是运行时中继；它不会代理动作连接，也不运行 ASR、LLM 或 TTS。
Direct Mode 是理解数据最小化的好模型，因为连接的用途很窄：为数字人动作链路建立已授权会话、发送数字人语音音频并接收动作数据。你的产品可以把智能体、上下文和工作流逻辑保留在原本所在的系统中。
Backend Mode：更多运行时控制权，不代表应扩大载荷
在 Backend Mode 中，你的后端运行 Server SDK 管线，并选择向客户端的下游传输方式。当架构确实需要这种运行时控制时，它可能是合适的选择。但它并没有改变核心问题：动作层把语音转换为动作，到底需要什么？
对传输拥有更多控制权，并不意味着应当把每个内部对象、对话记录或业务事件都经由数字人路径转发。在后端接口中也要明确保留这条边界。
对每个额外字段进行五问测试
当拟议集成除了口头回复和建立所选路径所需的凭据外，还包含更多数据时，应当有意识地审查该字段。一场紧凑的设计审查，可以避免“以后可能会需要”这种模糊判断演变为永久的数据依赖。
- **这个字段支持什么体验功能？**说明它启用的确切行为。
- **应用能否在生成语音之前完成这个功能？**如果可以，就把该字段留在产品或智能体层。
- **该字段是否会改变授权、检索或工具操作？**如果会，它就属于你的应用边界。
- **更小的数据值能否完成同样工作？**优先传递已批准的口头摘要，而不是原始记录、文档、对话记录或凭据。
- **该路径是否已被审查和记录？**记录用途、数据所有者、所选集成路径，以及未来移除该字段的条件。
对于早期产品试点，相比一开始就使用最复杂或最敏感的客户场景，在非生产环境或经过谨慎限定的数据范围内测试一个有限工作流，通常更容易审查。合适的范围是产品决策，应由负责该工作流的团队共同作出。
为窄而清晰的呈现契约设计
当契约能用一句话说清时，数字人集成的效果最好：
“我们的应用决定数字人可以说什么。我们将生成的数字人语音音频发送到动作层，并在客户端渲染返回的动作数据。”
这个契约也有助于实施规划，让每个团队都拥有清楚的责任：
| 团队 | 负责什么 | 不应假定数字人层负责什么 |
|---|---|---|
| 产品 | 用户时刻、范围、措辞、降级方案和下一步操作 | 某个回答是否对该工作流有帮助或恰当 |
| AI / 应用工程 | ASR、LLM、TTS、上下文、检索、工具调用、策略和人工交接 | 授权某项操作或暴露客户上下文的决定 |
| 客户端工程 | AvatarKit 集成、UI 控件、状态处理和本地渲染 | 用户权限或业务逻辑的事实来源 |
| 安全与法务审查 | 数据处理决策、供应商审查、披露和合同要求 | 仅凭一张架构图作出的泛化营销声明 |
没有任何文章可以取代你自己的供应商、安全、法务或产品审查。要求会因行业、客户协议及应用处理的数据而不同。这个模式的意义在于，让审查对象保持狭窄且可检查。
应避免的常见错误
“以防万一”传递原始检索上下文
检索内容应留在选择和支撑回答的地方：你的智能体或后端。把原始文档传给呈现层，会新增一条需要审查的路径，却不会改进动作转换本身。
将会话标识符视作产品上下文对象
集成可能会使用会话机制进行身份验证或关联。这不代表数字人服务需要直接获取你的 CRM 档案、租户记录或应用层权限模型副本。应有意识地、以最小化方式维护映射与标识符。
假设文本、语音和数字人层具有相同的数据需求
它们并不相同。文本界面可能只需要一段已批准的回复字符串；TTS 层需要文本或语音指令；实时数字人动作层需要数字人语音音频。应为每一层的具体工作设计数据边界。
根据不完整的实施图作出隐私承诺
架构图很有用，但它们不能替代适用于你部署的当前条款、配置、数据处理细节和内部审查。要准确说明所选路径的行为，并让相应负责人批准超出已文档化产品行为的任何内容。
常见问题
Spatius 是否需要我们的完整对话记录？
根据 Spatius 文档中描述的核心数字人动作功能，不需要。Motion Server 接收数字人语音音频并返回动作数据；AvatarKit 在本地渲染数字人。你的应用或智能体框架负责对话逻辑。参见 开发者文档地图。
我们是否应把知识库、CRM 记录或工具凭据发送给数字人服务商？
它们不是动作链路的默认输入。应将它们保留在使用这些信息决定数字人可以说什么或做什么的应用与智能体层中。如果拟议集成需要额外数据，请记录具体用途，并由相应的产品、安全和法务负责人审查。
数字人服务商会接收用户的麦克风音频吗？
已文档化的 Spatius 动作链路以数字人语音音频为输入。用户输入采集、ASR、LLM 推理和轮次管理均由你的应用、智能体框架或后端负责。实施前请确认你选择的集成路径的具体细节。
Spatius 会返回已完成的视频文件或视频流吗？
不会。Motion Server 返回动作数据，AvatarKit 在客户端本地渲染数字人。这一区别是当前产品架构的核心。
在发送任何额外数据之前，我们应当做什么？
写下业务目的，确认该行为不能先在你的应用内完成，尽量缩小数据值，并让所需负责人审查最终实施。不要仅仅因为字段传递起来方便，就把未经审查的字段视为无害。
让数字人层专注于它的职责
最经得起长期使用的数字人架构，并不是移动数据最多的架构，而是将面向客户的智能、控制和记录保留在拥有它们的产品中，并只把呈现层完成工作所需的已批准语音发送出去的架构。
如果你正在为 SaaS 产品评估实时数字人层，预约 Spatius 演示，讨论适配现有应用架构的集成路径。