数字人的流式输出不一样：从 Token 到短句的工程落地（含 Fay 代码路径）

• LLM 的“流式”= 按 token 逐步吐字，适合文字界面。

• 数字人 的“流式”= 按 短句 推送，并在句级携带 情绪/边界 标签，适合 TTS 与表情口型协同。

• TTS 不必边收边播。将短句合成为 小音频文件 后入队缓存、顺序播放，听感稳定、成本也更友好。

• 这些在 Fay 中已有完整实现：分句器 → 会话状态标记 → 流管理器 → TTS 合成 → 播放队列。

一、为什么“数字人流式输出”不能照搬 LLM

LLM 的流式传输是为“读文字”的人类优化：每有一个 token 就显示一个。把这种粒度直接喂给 TTS，会产生频繁停顿、回传抖动、情绪割裂的问题。数字人的声音与表情是“句段级”表演，工程上更合理的做法是汇聚成短句再处理：

• 句子是最小表演单元：有标点、有韵律、有情绪走向；

• 句界可以承载控制位：如“首句/末句”、“是否被打断”；

• 句粒度有利于缓存：TTS 走一次合成即得到一个可复用的音频文件。

在 Fay 中，LLM 端的 ChatOpenAI 明确开启了 streaming=True，说明其输出粒度天然是 token 级。而“把 token 变短句、再进入语音与数字人表现”的路径由 Fay 的 分句器 + 状态管理 + 流管理 共同完成（下文详解）。

---

二、LLM 的流式输出=Token：Fay 的配置指向何处

在 llm/nlp_cognitive_stream.py 里，Fay 以 LangChain 封装 OpenAI 客户端，并开启 streaming=True：

• ChatOpenAI(..., streaming=True) → LLM 端按 token 推送。

这一步确保了“上游快吐词、下游再做句级汇聚”，而不是强行在 LLM 层面做句级等待，从而保留了上游响应的及时性。

---

三、数字人的流式输出=短句：分句器与状态机

3.1 分句策略：遇标点即切、最小长度兜底

utils/stream_text_processor.py 中的 StreamTextProcessor.process_stream_text 会扫描标点（中英标点与换行），一旦构成最小句长，就把该句交给流管理器；若文本剩余没有