AI Avatar 可以让产品交互更像一场对话，但它无法消除不确定性。
当一个回复需要更多处理、某项依赖不可用，或用户需要人工协助时，产品仍然必须回答几个基本问题：事情正在进行吗？已经完成了什么？我能否停止或换一种方式继续？下一步由谁负责？
这些问题应由 SaaS 产品来回答，而不应留给一张会动的脸、一个旋转指示器，或“请稍等”之类过于乐观的提示。在当前的 Spatius 架构中，Motion Server 会将 Avatar 的语音音频转换为实时动作数据，AvatarKit 则在本地渲染 Avatar。你的应用、Agent 框架或后端拥有对话逻辑，包括 ASR、LLM、TTS、轮次控制、工具、工作流状态和人工交接。Spatius 开发者文档地图说明了这一边界。
这种分工有助于体验设计。应用知道任务是否在等待、能否安全重试、是否被权限阻断，或是否已准备好转交给同事。Avatar 则可以呈现与该状态对应、并经过用户批准的消息与动作。
核心要点
- 围绕清晰的产品状态设计体验，而不是围绕 Avatar 当下是否正在动。
- 你的应用应负责任务状态、工具执行、用户输入、恢复、升级处理，以及是否引入人工的决定。
- 有效的等待状态会解释正在处理的工作范围，保留用户离开或改变方向的能力，并且不会虚构完成时间。
- 错误提示应保留任务上下文，并提供有意义的下一步：重试、换一种方式继续、补充信息或请求帮助。
- 在 Direct Mode 中，如果 Motion Server WebSocket 在最初 15 秒内失败，文档所述的纯音频回退可以让 Avatar 音频继续播放。这是一个有限的渲染回退，而不是产品错误或人工交接设计的替代方案。
从面向用户的状态模型开始
技术事件并不等同于面向用户的状态。“工具调用已开始”“令牌已过期”或“连接丢失”或许对日志很重要，但它们并不能告诉客户下一步能做什么。
先为用户能够识别的状态命名。状态集合要足够小，这样整个团队才能在产品文案、分析、客服与 QA 中始终如一地使用它。
| 面向用户的状态 | 产品需要回答的问题 | 有用的 UI 行为 | 应由应用保留的所有权 |
|---|---|---|---|
| 就绪 | 这个助手在这里能提供什么帮助？ | 提供一个与当前场景相关的起始操作和退出路径。 | 使用资格、功能范围和权限。 |
| 响应中 | Avatar 是否正在回答当前请求？ | 展示回答，并在相关场景中提供可见的打断、静音或切换模式方式。 | 轮次控制以及是否生成回复的决定。 |
| 处理中 | 产品正在做什么？我还能操作吗？ | 以恰当的细节说明任务；当工作流允许时，保留取消、返回或替代路径。 | 工具调用、工作流进度和任务取消。 |
| 需要输入 | 产品继续之前还缺少什么？ | 提出明确问题，展示必填字段或选项，并保留此前上下文。 | 校验以及是否需要更多输入的判断。 |
| 恢复 | 什么没有完成？我现在能做什么？ | 使用平实语言，尽可能保留任务，并提供下一步操作。 | 错误分类、重试策略和状态保留。 |
| 人工交接 | 谁将接手？我的任务会怎样？ | 说明交接路径和用户下一步操作，但不要暗示一位尚不可用的人已在回复。 | 路由、人员安排、权限和交接记录。 |
| 已完成 | 发生了什么变化？我接下来该做什么？ | 确认可见结果，并指向下一个有用的产品操作。 | 任务完成的事实来源。 |
Avatar 不应假装知道得比产品更多。如果外部系统尚未确认某项变更，就应使用反映这一边界的语言。例如，“我正在准备该请求以供审核”与“你的请求已完成”并不相同。
将任务状态与 Avatar 呈现分开
避免令人困惑的 UX，最简单的方法是将两种模型分开：
- 应用任务模型决定工作流中正在发生什么。
- 呈现模型决定用户如何看到和听到与该任务有关的信息。
Spatius 属于该模型的呈现侧。产品可以使用其已决定让 Avatar 说出的语音音频；Motion Server 返回动作数据，AvatarKit 在本地渲染结果。产品的 Agent 栈仍负责决定何时调用工具、等待结果、重试、请求输入或引入人工。选择集成路径也做了同样的区分：Spatius 是仅提供 Avatar 的服务，而对话逻辑和轮次控制由应用或所选 Agent 框架拥有。
| 层级 | 它应决定什么 | 示例问题 |
|---|---|---|
| 应用与 Agent 层 | 用户权限、请求意图、知识与工具访问、工作流状态、恢复和路由。 | “该用户可以提交这个请求吗？下游系统是否已接受它？” |
| 体验层 | 当前任务状态适合哪种状态、控件、文字或音频消息。 | “用户此时应该看到进度提示、表单，还是交接选项？” |
| Avatar 呈现层 | 如何在视觉上呈现已批准的 Avatar 语音。 | “我们选择播放的语音音频应配合什么动作？” |
这不只是工程图。它能避免一种常见产品错误：真实任务处于未知状态时，却让 Avatar 做出模糊的“思考中”行为。用户首先需要产品事实，其次才是个性化表达。
让等待状态具体，但不要过度承诺
等待可以是工作流的正当组成部分。用户可能正在要求应用查询产品记录、准备草稿、运行获准的工具，或等待有自身规则的业务流程。目标不是叙述每一个内部事件，而是与用户建立可信的约定。
一个好的等待状态由三部分组成：
- **范围：**以用户能理解的层级说明正在处理的工作。
- **控制权：**展示用户仍然可以做什么——等待、取消、切换至文本、补充缺失信息，或在工作流支持时离开后返回。
- **结果边界：**在应用能够验证前，不要承诺结果、时间或操作已经完成。
撰写真实的状态文案
不要把 Avatar 当作装饰性的加载动画。措辞应反映应用实际能够观测到的状态。
| 应用识别到的情形 | 更好的面向用户消息 | 为什么有效 |
|---|---|---|
| 获准的任务正在进行 | “我正在核对这个请求的详细信息。” | 为用户提供有意义的范围，不宣称结果。 |
| 产品需要一个值或选择 | “我还需要一项信息才能继续。” | 将暂停转化为具体的下一步。 |
| 请求需要审核或审批路径 | “此事项需要同事审核后才能继续。” | 设定边界，但不假装人工已介入。 |
| 用户无需 Avatar 也可继续 | “此视图暂不可用时，你可以继续通过文本完成操作。” | 提供替代交互，不暗示整个任务已经失败。 |
不要仅因为日志中有详细内部状态就把它展示给用户。“正在调用第 4 个 API（共 7 个）”这样的消息可能会令用户焦虑，却没有提供可操作的信息。反过来，如果产品即将要求用户作出决定，“正在处理”又过于模糊。请选择能帮助用户决定下一步怎么做的、最精简且真实的说明。
在等待期间保留用户自主权
某个控件是否可行取决于工作流，但设计时始终应提出以下问题：
- 用户能否打断当前回复？
- 他们能否在无需从头开始的情况下更正或补充信息？
- 他们能否使用文本而不是语音或动画？
- 他们能否离开当前视图，并回到一个持久化的任务状态？
- 如果任务已经触发外部操作，产品能否清楚展示该操作仍在等待、已完成，还是需要审核？
答案都是应用层的决定。Avatar 应反映这些选择，而不是隐藏它们。
围绕任务而非传输层设计恢复
用户很少能从原始连接错误或模型错误中受益。他们真正需要知道的是：请求是否已收到、是否发生了变化，以及还有什么可行路径。
请围绕用户原本想完成的任务设计恢复。产品可能需要区分呈现问题和工作流问题，但不应迫使客户去调试底层架构。
| 受影响的内容 | 产品首先应确定什么 | 有用的恢复选择 |
|---|---|---|
| 回复或任务没有开始 | 应用是否收到请求，且现在重试是否安全？ | 重试、编辑请求，或使用另一条受支持的渠道。 |
| 工具或下游步骤未完成 | 操作的任何部分是否已被接受或完成？ | 展示已知状态；询问必需信息；在适当时提供审核或交接。 |
| Avatar 呈现不可用 | 用户能否在另一个界面中继续使用相同、已批准的内容？ | 如产品支持，可继续使用文本或音频；不要把 Avatar 视图当成事实来源。 |
| 用户缺少访问权限或审批 | 这是权限边界、缺少角色，还是需要人工处理的工作流？ | 说明下一个获授权路径，而不是要求用户重复请求。 |
准确使用文档中的 Direct Mode 回退
当前 Direct Mode 文档说明：如果 Motion Server WebSocket 连接在 15 秒内失败，SDK 会进入纯音频回退，音频会在没有动画的情况下继续播放。当你选择 Direct Mode 时，这是一个值得理解的渲染路径行为。
这并不是完整的错误体验。你的应用仍决定用户的任务是否可用、展示何种状态、如何恢复失败的工作流步骤，以及是否适合人工交接。不要把技术回退转化为关于服务可用性或用户结果的笼统承诺。
将人工交接视为工作流，而不是一句话
“让我为你转接人工”只有在产品知道下一步会发生什么时，才是有用的文案。人工交接是一套包含路由、上下文、所有权和用户可见预期的工作流。
应用应决定何时提供或发起交接。常见触发条件可能包括用户明确要求人工、任务需要助手没有的角色、某项审批需要审核，或产品有意划出自动化范围之外的工作流。正确的触发条件取决于你的产品和政策；Avatar 不应自行编造。
在设计对话前定义交接约定
| 时刻 | 用户应理解什么 | 应由应用拥有 |
|---|---|---|
| 交接前 | 当前路径为何无法继续，以及有哪些替代方案。 | 资格规则、权限，以及是否可提供交接。 |
| 交接时 | 会发送或记录什么、谁预期采取下一步，以及用户现在能做什么。 | 路由目的地、已批准摘要、任务状态，以及产品需要的任何审核或同意流程。 |
| 交接后 | 去哪里找到请求，以及已知的状态是什么。 | 下一步操作的所有权、更新和事实来源。 |
让上下文可转移、可复核。一份有用的交接记录通常包括用户表述的目标、当前任务状态、用户已提供的信息、产品已确认的操作，以及下一项问题或负责人。这并不意味着应自动复制每一段对话或内部备注。应用应决定交接所需的最少信息、用户应看到什么，以及内部政策有哪些要求。
约束 Avatar 的表述边界
Avatar 可以说产品正在交接、请求审批，或提供支持路径。但除非应用可以验证这些事实，它不应暗示服务级响应时间、保证人工可用，或暗示同事已经审核了某事。
例如：
- 建议：“我可以根据你填写的详细信息，为支持团队创建一项请求。”
- 避免：“专家正在审核此事。”除非应用已确认这一状态。
这种准确性有助于支持和产品团队调查实际发生了什么，也避免打造一种听起来令人安心、却不给用户可见下一步的体验。
分层实现体验
在从聚焦试点中学习前，你不必完善每一种可以想象的失败情况。但你需要一个共享模型，以避免误导性的上线。
1. 定义一套精简的状态词汇
就本文所列状态的名称、进入条件、退出条件和控件达成一致，并在 UI 组件、音频脚本、支持文档和遥测中复用它们。
2. 将真实产品事件连接到这些状态
将应用中的持久事件——而不是动画事件——映射到面向用户的体验。例如，工具结果、权限检查或交接记录都可能改变状态；Avatar 消息随该决定而变化。
3. 准备替代呈现路径
决定语音或 Avatar 呈现不可用时用户会看到什么。这可能是文本、纯音频状态、任务记录或其他产品界面。正确选项取决于你的产品；不要假设视觉 Avatar 是工作流保持可理解性的必要条件。
4. 使用真实任务状态测试恢复
测试尚未开始的请求、部分完成的请求、需要输入的请求、需要审批的请求，以及必须交给人工的请求。不仅要测试消息，还要测试产品是否保留了正确的上下文和下一步操作。
5. 选择符合运行时所有权的集成路径
Spatius 支持 Direct Mode、平台集成和 Backend Mode。集成指南说明了每条路径中哪个组件连接到 Motion Server。选择适合团队现有运行时所有权的路径，然后围绕产品工作流——而非通用协议图——设计面向用户的状态。
上线前检查清单
在向更广泛的受众开放 Avatar 体验前，请与产品、工程、支持团队及底层工作流的负责人一起审阅以下问题：
- 用户能否区分回复、进行中的任务、输入请求和人工交接？
- 每个等待状态是否都有真实的范围说明和至少一个可理解的下一步？
- 如果产品显示“已完成”，哪一个经过验证的应用事件支撑该信息？
- 用户能否在不丢失原本任务的情况下从呈现问题中恢复？
- 重试控件是否避免重复执行或掩盖可能已被接受的操作？
- 人工交接路径是否真实、有人负责，并在创建后对用户可见？
- Avatar 脚本是否避免声称应用无法验证的响应时间、可用性、审批或结果？
- 如果使用该集成路径，是否已将 Direct Mode 的纯音频回退与应用层任务和错误状态分开测试？
应避免的常见错误
将动画视为进度证明
业务工作流暂停、受阻或完成时，Avatar 仍可能继续做手势。应使用产品状态——而不仅仅是动画——来决定告诉用户什么。
让“重试”抹去客户已完成的工作
如果用户已经提供信息或启动了任务，请在安全的情况下保留相关上下文。重试不应在没有说明的情况下，变成要求用户重复整段交互。
用友好人格掩盖错误
温和的语言可以减少摩擦，但不能替代明确的状态和控件。说明已知情况，避免猜测，并让下一条路径可见。
假设纯音频回退解决了工作流问题
Direct Mode 回退涉及的是在一个狭义连接失败后如何呈现音频和动作。它并不能告诉用户工具操作是否成功、请求是否持久化，或同事是否会接手。
提供没有负责人路径的人工交接
如果交接选项不创建记录、没有把用户送往任何地方，或承诺了没人同意提供的响应，它就会令人沮丧。请在撰写 Avatar 台词之前先设计路径和所有权。
常见问题
Spatius 会决定何时显示等待状态或将任务交给人工吗？
不会。Spatius 将 Avatar 语音音频转换为动作数据，并由 AvatarKit 在本地渲染 Avatar。你的应用、Agent 框架或后端拥有对话逻辑、工作流状态、轮次控制、工具和人工交接决策。参见开发者文档地图。
如果 Direct Mode WebSocket 连接失败，会发生什么？
根据当前 Direct Mode 文档，如果连接在 15 秒内失败，SDK 会进入纯音频回退，因此音频会在没有动画的情况下继续播放。你的产品仍应提供自己的任务状态、恢复控件，以及支持或交接行为。
每个等待状态都需要 Avatar 消息吗？
不需要。简洁的文本状态、表单、任务记录或安静的过渡可能比口头叙述更清晰。选择最能支持用户当前任务并保留其控制权的呈现方式。
是否应该将每一个对话细节都传给接手的人？
默认不应该。定义同事继续工作流所需的最少交接上下文，决定用户应看到什么，并与负责产品数据和支持流程的负责人审阅最终设计。
能否将本文作为可靠性、安全或合规政策？
不能。本文提供产品与 UX 指导。请与适当的技术、安全、法务和运营负责人验证你的集成、工作流、客户承诺和审查要求的具体细节。
让下一步清晰可见
最强的 AI Avatar 体验不会试图隐藏延迟、不确定性或升级处理。它们会告诉用户产品已知的信息，保留前进路径，并让 Avatar 清晰地呈现这一事实。
如果你正在为 B2B SaaS 工作流评估实时 Avatar 层，可申请 Spatius 演示，讨论适合你现有应用架构的集成路径。