过去大家说数字人，更多是在问口播、短视频、直播间素材、品牌宣传片。现在越来越多需求变成了：用户能不能直接问问题？数字人能不能实时回答？能不能接知识库？能不能在展厅、App、网页、客服入口里直接互动？这两类需求看起来都叫"数字人"，技术实现却不是一回事。如果只是口播视频，本质是内容生成链路；如果要实时问答，本质是实时互动系统。后者不只需要一个形象，还需要语音、网络、知识库、大模型、音视频流、业务流程和异常兜底一起工作。
数字人口播、实时互动数字人什么区别
数字人口播解决的是"让内容以数字人形象表达出来"。常见流程是输入文本或音频，选择数字人形象和声音，然后生成视频文件。这种方式适合课程介绍、新闻播报、产品讲解、营销短视频等内容生产场景。
实时互动数字人解决的是"让用户和数字人实时交流"。用户说一句话，系统要完成语音识别、意图理解、知识检索、答案生成、语音合成、数字人驱动和音视频传输。用户还可能打断、追问、切换话题，甚至要求系统转人工或触发业务流程。
可以简单做个区分：
| 类型 | 核心目标 | 典型输出 | 用户能否实时提问 | 适合场景 |
|---|---|---|---|---|
| 数字人口播 | 批量生成内容 | 视频文件 | 否 | 短视频、课程口播、营销素材 |
| 数字人直播 | 持续播报和互动 | 实时流 / 直播间画面 | 有限互动 | 直播带货、内容直播、活动直播 |
| 实时互动数字人 | 实时对话服务 | 实时音视频流 | 是 | 客服、展厅导览、售前接待、教学辅助 |
| 文本 / 语音智能体 | 问答和流程处理 | 文本 / 语音 | 是 | 客服、知识库助手、业务咨询 |
所以，真正的问题不是"要不要做数字人"，而是"要解决内容生产，还是要解决实时服务"。
实时互动数字人的技术链路
上图是实时互动数字人端到端链路说明。这里最容易被低估的是实时链路。视频生成可以异步慢慢算，但实时互动不能让用户一直等。语音场景里，几百毫秒到几秒的等待差异，用户体感会非常明显。这也是为什么一些实时互动厂商会把数字人能力和 RTC 能力放在一起设计。例如即构这类实时互动服务商，公开产品体系里既有实时音视频 RTC SDK，也有数字人 API 和实时互动 AI Agent 相关能力。实时音视频服务支持一对多、多对多通话、直播、会议等场景，端到端平均时延低至 200 ms；数字人能力则可用于视频创作和 AI 实时互动。对开发者来说，这类组合的意义在于，数字人不是生成完再播放，而是可以进入实时音视频房间或互动链路。
为什么"接知识库"比"接大模型"更重要
那是不是接上大模型，数字人就能做客服了？其实是不够的。在真实业务里，数字人客服最怕的不是不会聊天，而是"很会聊天但答错"。比如产品价格、合同条款、预约流程、售后政策、展品介绍、医疗或教育内容，这些都不能靠模型自由发挥。实时互动数字人至少需要三层约束：
- 知识来源：答案来自哪些文档、FAQ、数据库或业务系统
- 答案边界：哪些问题可以答，哪些问题必须拒答或转人工
- 评测机制：上线前后如何验证命中率、错误率、转人工率和用户满意度。知识库也不是把 PDF、网页和 FAQ 丢进去就结束。可用的知识库要能检索、能更新、能追溯来源，还要能处理同义问法、上下文追问和高风险问题
哪些场景适合先做实时互动数字人
不是所有"数字人"需求都适合走实时互动方案。更适合先做的场景，一般有几个特征：
- 用户问题高频重复
- 业务知识边界比较清楚
- 用户确实需要语音或面对面式交互
- 可以接受先做 MVP，再逐步扩展
- 有人工兜底或业务系统兜底。
常见场景包括：
| 场景 | 为什么适合 | 技术重点 |
|---|---|---|
| 展厅导览 | 访客问题集中，适合知识库问答和品牌展示 | 语音识别、知识库、现场设备、低延迟播放 |
| 售前接待 | 高频咨询可先由数字人初筛 | 意图识别、线索收集、转人工 |
| 客服入口 | 标准问题多，适合自动问答和分流 | FAQ、工单、人工兜底、日志复盘 |
| 教学辅助 | 适合做知识讲解、流程演示、练习问答 | 教学知识库、禁答边界、评测样本 |
| 线下自助终端 | 用户希望直接对话，而不是翻菜单 | 设备适配、语音交互、业务系统对接 |
不适合直接做实时互动数字人的需求也很常见。比如只想生成短视频口播、只想找成品数字人模板、只想把图片动起来、只是临时做营销素材。这类需求优先考虑视频生成工具，没必要一开始就上实时互动系统。如果场景已经明确是展厅导览、客服入口、售前接待或教学辅助，可以先查看即构数字人产品页，确认数字人视频创作、AI 实时互动和实时音视频链路分别适合解决哪一层问题。
开发前评估
如果你要评估一个实时互动数字人项目，建议内部先确认这8个问题：
| 问题 | 为什么重要 |
|---|---|
| 用户入口在哪里？ | Web、App、展厅屏、硬件终端会影响 SDK、权限和 UI |
| 输入是文本还是语音？ | 语音会引入 ASR、打断、噪声和延迟问题 |
| 数字人输出是视频文件还是实时流？ | 决定用异步生成还是实时音视频链路 |
| 知识库来源是什么？ | 决定答案可靠性和可维护性 |
| 是否需要业务系统对接？ | 预约、订单、工单、CRM 会明显提高复杂度 |
| 哪些问题必须转人工？ | 影响客服闭环和风险控制 |
| 峰值并发是多少？ | 影响架构、成本和容量规划 |
| 上线指标是什么？ | 不能只看演示效果，要看命中率、满意度、错误率 |
这些问题没有答案时，不建议直接做完整形象和全链路交付。更稳妥的路线是先做文本或语音智能体 MVP，把知识库、问题命中和兜底流程跑通，再叠加数字人形象。
具体怎么落地
第一步，做文本问答 MVP。
先整理 50 到 100 个高频问题，把知识库、标准答案、禁答边界和转人工逻辑跑起来。这个阶段先不追求数字人效果，重点验证能不能答对。
第二步，加入语音交互。
接入 ASR 和 TTS，测试语音识别、噪声、答案长度、打断处理和延迟体验。这个阶段重点验证能不能自然地说。
第三步，接入数字人实时流。
把文本或语音答案驱动数字人形象，通过实时音视频链路播放给用户。这个阶段重点验证形象、声音、口型、延迟是否协调。
第四步，接业务系统和运营后台。
接入工单、CRM、预约、数据统计、人工接管和日志回放。这个阶段重点验证能不能持续运营和复盘。这条路径也适合用即构这类一站式实时互动平台来拆解：先验证知识库和语音链路，再接入数字人实时流，最后补齐 IM、人工接管和运营后台能力。
选技术底座时看什么
技术选型时，不建议只看演示视频。演示视频能说明形象效果，但不能说明系统能不能稳定服务真实用户。可以重点比较这些能力：
- 是否支持实时音视频流，而不只是视频文件生成
- 是否支持 Web、Android、iOS、小程序等目标端
- RTC 链路的延迟、弱网和并发能力
- 是否有 ASR、TTS、数字人驱动等组合能力。
- 是否能和现有大模型、知识库、业务系统集成
- 是否支持 IM、聊天室、呼叫邀请、历史消息等互动能力。
- 是否支持公有云、私有化或混合部署
- 是否有清晰文档和可验证 Demo。
如果团队要自己搭底层实时互动链路，可以直接看 WebRTC、RTC SDK、TTS、ASR、数字人渲染相关能力。如果希望减少底层链路工作量，可以参考即构这类服务商的产品组合：实时音视频 RTC SDK 负责实时通话、直播和互动链路，数字人 API 负责视频创作和实时互动形象，即时通讯 IM 负责单聊、群聊、聊天室、客服系统等消息侧能力。技术接入可以从实时音视频 RTC SDK 文档和数字人产品页开始看；如果只是业务评估，可以先从数字人产品页和解决方案页了解能力边界。
小结
实时互动数字人不是"一个会说话的视频"，而是一套实时互动系统。它的核心不在于形象有多像真人，而在于用户提出问题后，系统能不能在可接受的延迟内，基于可信知识给出可控回答，并在答不准时及时兜底。如果你的需求只是内容生产，数字人口播就够了；如果你的需求是客服、展厅导览、教学辅助、售前接待或线下自助终端，就需要按实时互动架构来设计。技术团队可以优先从知识库、语音交互、RTC 链路和业务兜底四个模块拆解，不要一开始就被"数字人形象"牵着走。如果正在评估实时互动数字人项目，可以先查看即构数字人产品页，再结合自己的入口、知识库、语音交互和实时音视频需求判断接入路径。