本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。
快速摘要
核心结论先说清楚：
Runway 发布的 Characters 功能，是目前市面上实现成本最低、上手门槛最低的实时互动数字人方案之一。 它的底层是 Runway 自研的 GWM-1 通用世界模型（General World Model），只需要一张图——管它是真人自拍、卡通形象还是品牌吉祥物——不用做任何模型微调，就能在约 1 分钟内生成一个可以实时对话的视频智能体。
生成出来的数字人视频以 24 帧每秒（fps）流畅输出，端到端响应延迟约为 1.75 秒，实现这一效果靠的是一套叫做流水线并行（Pipeline Parallelism）的推理架构——在解码上一帧的同时，下一帧的计算已经在并发推进，单帧生成耗时仅约 37 毫秒。
这个数字人不是简单的"嘴巴一张一合"。它能看懂你的摄像头画面，能读取你共享的屏幕内容，能调用外部工具（查天气、翻文档、接 API），还能直接嵌入网页，甚至接入线上会议系统。对开发者来说，Runway 提供了完整的 REST API 和 React SDK，最快 5 分钟就能把一个互动数字人塞进自己的产品。
想看完整拆解，往下翻。
一、数字人赛道：从酷炫玩具到真正能用的生产力工具
说实话，"数字人"这个词在国内已经被讲烂了。从 2022 年前后，各种数字人平台、虚拟主播、AI 分身的产品就一波接一波涌出来，大厂小厂都在蹭热度。我自己折腾过不少，早期那些产品普遍给我的感觉就一个字：假。嘴巴对着音频机械地张合，表情僵硬像戴了面具，说到激动的地方眼睛纹丝不动——跟真人视频通话的体验差了十万八千里。
但 2025 年的今天，这条赛道确实发生了质变。根据艾媒咨询发布的数据，2024 年中国数字人核心市场规模已达 339 亿元左右，预计到 2030 年有望突破 900 亿元。这个数字背后，是技术实实在在往前走了。
过去那些离线批量生成视频的数字人工具，用来录制课程、做品牌宣传片是够用的——但放到实时交互的场景里就完全抓瞎。你跟它说句话，它要在后台算上十几秒甚至几十秒才能给你挤出个回应，这哪叫"对话"，更像是在等对方思考人生。
真正有价值的实时数字人，需要同时解决三个问题：视频生成要足够快、表情动作要足够自然、对话理解要足够智能。这三件事单独做好一件都不容易，同时做好就更难了。
这三个问题背后对应的其实是三个不同的技术领域：视频生成快不快，是推理速度和模型架构的问题；表情动作自然不自然，是视频生成模型的质量问题，特别是对人体动态的建模能力；对话理解够不够智能，是接入的大语言模型和多模态理解能力的问题。过去这三件事分属不同的技术栈，集成在一起本身就是一个巨大的工程挑战。Runway 这次做的事情，是把这三个能力打通，封装成一个开发者可以直接调用的 API，把集成难度从"需要一个 AI 团队"降到了"一个前端工程师下午就能跑起来"。
Runway 这次做的 Characters，是我目前看到的在三者之间平衡得最好的方案之一，所以值得拿出来好好拆解一下。
国内的数字人生态已经相当成熟，从闪剪、有言 AI 到百度智能云、科大讯飞智作，覆盖了从个人创作到政务金融的各种场景。但这些方案大多数仍然是非实时的——先录制或合成好视频，再播放出来。Runway Characters 的出现，是在实时互动视频智能体这个更难的赛道上踢出来的一脚。莫潇羽@源码七号站认为，这个产品对整个数字人行业的技术走向有重要的参考价值。
说到底，数字人这个赛道的"门槛"正在发生根本性的变化。以前做一个像样的数字人，需要专业的 3D 建模师、动作捕捉设备、专业录音棚，光是前期制作成本动辄几十万。后来 AI 把这个成本打下来了，出现了一批"上传照片 + 上传文案就能批量生成视频"的工具，生产效率提升了十几倍。但即便如此，这些工具的产出本质上还是"视频文件"，不是"可交互的实体"。
真正让我兴奋的，是数字人从"内容载体"变成"交互界面"这个趋势。一个数字人如果只是把文字内容念出来，那它跟一个文字转语音工具本质上没太大区别，只是多了个会动的嘴巴。而当它能听、能看、能调用工具、能做决策，它就变成了一个有形象的 AI 智能体——这才是这个赛道真正的终局。
Runway Characters 是朝这个方向走得比较靠前的一个产品。它当然还有很多不完善的地方，后面我会一一说到，但它代表的技术路径是值得认真学习的。
二、Runway 与 GWM-1：这次不只是发了个视频生成工具
想搞清楚 Characters 是怎么做到的，先得知道它底层跑的是什么东西。
2.1 Runway 这家公司
Runway 是一家成立于 2018 年的美国 AI 公司，早年以面向创作者的 AI 视频编辑工具出名，Gen-1、Gen-2、Gen-3 系列视频生成模型一路把它推到了专业视频 AI 工具的头部位置。2025 年初发布的 Gen-4.5，在 Video Arena 的公开评测中超过了 Google 和 OpenAI 的同类产品，算是奠定了它在视频生成这条赛道上的技术地位。
但 Gen-4.5 本质上还是一个离线视频生成模型——你给它一段文字或图片，它生成一段视频片段，整个过程是异步的、批量的。这种模式做短片、做广告很好用，但要做"实时互动"就差得远了。
2.2 GWM-1：通用世界模型的概念
GWM-1（General World Model 1）是 Runway 在 2025 年底发布的第一代通用世界模型家族。简单解释一下"世界模型"是什么概念——
普通的视频生成模型，本质上是在学"图像怎么变化"，它对世界的物理规律没有真正的理解。而世界模型的目标是让 AI 建立起一套对环境的内部表征，能够预测和模拟在不同动作下环境会如何演化——就像人脑对现实世界的建模方式一样。
用更直白的话说：普通视频模型是在"画画"，世界模型是在"做模拟"。
这个区别在数字人场景里体现得很明显。举个例子：你问一个基于普通视频模型驱动的数字人"你现在是什么心情"，它可能会生成一段面带笑容的视频，但那个笑容是从训练数据里采样出来的，跟你刚才说的话未必真的有情绪上的对应关系。而世界模型的目标是让表情、动作、语气这些输出，都是模型对当前上下文"理解"之后的自然结果，而不是从素材库里拼凑出来的。
当然，GWM-1 现在还处于早期阶段，距离真正的"情绪理解"还有相当大的差距。但方向是明确的，这也是 Runway 为什么把它叫做"世界模型"而不只是叫"实时视频生成模型"——后者只是技术手段，前者才是最终目标。
还有一点值得提，很多人拿世界模型跟大语言模型（LLM）来比较，觉得有了 ChatGPT 这样的东西，世界模型有什么特别的价值？Runway 的观点是：语言模型是在文字空间里建立对世界的理解，它能推理、能对话，但它感知不到物理世界的连续变化——它不知道一个球滚下斜面会发生什么，除非有人在训练数据里描述过这个场景。而世界模型是在像素空间里建立对世界的理解，它的输出是可以被看到的视频流，可以被机器人当作感知输入，可以驱动数字人的面部表情和肢体动作。两种模型解决的是不同维度的问题，不是谁取代谁。
GWM-1 是基于 Gen-4.5 架构做的自回归模型（Autoregressive Model）——它以逐帧预测的方式生成内容，每一帧的输出都是基于前一帧的状态计算的，整个过程在实时运行。这种生成方式和传统的扩散模型（Diffusion Model）批量生成一段视频有本质区别：自回归逐帧生成天然支持交互控制，因为每一帧都可以接受新的输入指令。
GWM-1 发布时包含三个分支变体：
GWM-1 通用世界模型
├── GWM Worlds —— 可探索的沉浸式环境生成（用于游戏、仿真）
├── GWM Avatars —— 对话式数字人，即 Characters 功能的底层模型
└── GWM Robotics —— 机器人策略训练与仿真数据生成Runway 的长期目标是把这三个分支最终统一成一个基础世界模型，但目前它们仍然是分开训练的后处理模型（Post-trained Models）。
2.3 GWM Avatars 的技术定位
Characters 功能背后跑的就是 GWM Avatars。它的技术定位是：一个由音频驱动的交互式视频生成模型，能够对任意真实感或风格化角色模拟自然的人体动作与表情。
这里有几个关键词值得拿出来说：
- 音频驱动：角色的口型、表情、头部动作都是由音频信号实时驱动的，不是靠事先录制好的动作库拼接。
- 任意角色：不限于真实人物，卡通、动漫、吉祥物风格同样支持。
- 零微调：给一张图就能跑，不需要专门训练或精调模型。
这三点合在一起，就决定了 Characters 的使用门槛出奇地低。
从竞品的角度看，Synthesia 这类成熟的数字人平台虽然也支持从图片生成数字人，但通常需要一定的训练时间和资源，质量上限高，但准入门槛也更高。Runway Characters 走了另一条路：零微调、即传即用，牺牲一点极端场景的上限，换来极低的启动成本。对于想快速验证产品方向的创业团队或独立开发者来说，这个取舍是非常划算的。
三、Characters 核心功能全拆解
3.1 一张图片生成可对话的数字人
Characters 的入口在 Runway 的开发者平台（dev.runwayml.com）和主站应用界面。创建数字人只需要：
- 一张人物图片（正面照效果最好，支持真实人物、插画、3D 渲染图等各种风格）
- 给角色起个名字、选一个声音、写一段人设描述（支持中文）
- 点创建
大约 1 分钟后，你的数字人就生成好了，可以直接点开进入对话界面。
我自己测试过用手绘风格的形象和照片级写实的自拍分别生成，两种都能跑，口型同步和表情自然度要比早几年的同类产品好一大截。虽然仔细看还是有一些细节瑕疵——比如复杂手势动作下偶尔会有抖动——但在正常的视频通话场景下完全不影响体验。
3.2 24fps + 1.75 秒延迟意味着什么
24fps 是电影的标准帧率，也是人眼感知视频"流畅"的基本门槛。1.75 秒的端到端延迟，意味着你说完一句话，最多等 2 秒不到就能看到数字人开始回应——这已经接近正常视频通话的心理容忍阈值了。
对比一下就知道这有多难得：普通的离线视频生成任务，生成 1 秒钟的视频往往需要十几到几十秒的计算时间，那个时延完全不可能用于实时对话。Runway 这次是怎么把这个差距压缩到可用范围的，我在第四章会详细拆解技术原理。
3.3 视觉感知：它能"看到"你和你的屏幕
这个功能是我觉得最有想象空间的部分。Characters 支持两种视觉输入：
摄像头接入：数字人能实时接收你的摄像头画面，理解你的表情、动作，甚至你手里拿着的东西。比如你拿着一份打印好的文件对着摄像头，数字人能看到并对内容做出回应。
屏幕共享：这个更实用。你在写代码、做设计、看数据表格，直接把屏幕共享给数字人，它能实时看懂你的操作界面，给出具体建议。这已经不是单纯的"聊天"了，而是接近一个能看着你操作的 AI 结对助手。
从实现原理上说，视觉感知功能是通过 WebRTC 的视频轨道（Video Track）实现的，摄像头和屏幕的画面会作为视觉上下文实时传递给数字人背后的多模态模型。这个模型会把视觉信息和你的语音输入结合起来，再驱动数字人生成回应。换句话说，数字人"看屏幕"的能力，本质上是多模态大模型的视觉理解能力，只不过被包在了一个有形象的视频壳子里。
这个设计有一个重要的产品意义：它让数字人从一个"对话窗口"变成了一个"上下文感知的协作者"。以往的 AI 助手是"你描述给它听"，现在是"它直接看到你在做什么"，信息传递效率差了不止一个量级。
有一点要注意：使用自定义声音（克隆声音）的角色，暂时不支持摄像头和屏幕共享功能，只有使用预设声音库的角色才能同时开启视觉感知。这应该是目前的技术限制，后续版本应该会解开这个约束。
3.4 工具调用：查数据、翻文档不是问题
Characters 支持接入外部工具，技术上是通过 API 的 Tool Calling 机制实现的。典型的使用场景：
- 查询实时数据：比如问它今天的天气、当前股价，它能调用你接入的外部 API 拿到数据再回答。
- 知识库检索：把公司内部文档、产品手册上传给它，它能去翻文档后给出准确回答，而不是靠模型本身的记忆在胡说。
- 触发业务动作：比如客服场景里，用户说"我要退款"，数字人可以调用你的业务接口直接发起流程，而不只是嘴上说"好的，我帮您处理"。
这一套工具调用的机制，让 Characters 从一个"好看的聊天机器人"变成了真正有业务价值的智能体前端。莫潇羽@源码七号站觉得，这个方向才是数字人产品真正值钱的地方。
3.5 可嵌入网页、接入会议系统
对于开发者和企业来说，Characters 提供了两种主要的集成路径：
- 嵌入网页：通过 Runway 提供的 React SDK（
@runwayml/avatars-react），几十行代码就能把一个交互式数字人组件嵌进自己的 Web 应用。 - 接入会议系统：支持集成到 Zoom 和 Teams 等主流视频会议平台，让数字人作为虚拟参会者出现在线上会议中，实时回答问题。
四、技术原理深挖：流水线并行是怎么跑起来的
这一章是重头戏，我尽量用容易理解的方式讲清楚。
4.1 传统视频生成"慢"在哪里
要理解 Runway 这次做了什么，先要搞清楚传统视频生成为什么慢。
大多数现有的 AI 视频生成模型用的是扩散模型（Diffusion Model）架构。它的工作方式是这样的：先在一大堆随机噪声里，通过几十到几百步的迭代去噪，最终"雕刻"出一段完整的视频帧序列。这种方式生成质量很高，但整个过程必须等所有步骤都跑完，才能拿到第一帧输出。
用做饭来比喻：扩散模型就像是把所有食材一锅炖，要等整锅炖好了才能上菜。生成一分钟的视频，不管用什么硬件，这个"炖"的过程就是要花时间。
在需要"实时输出"的场景里，这种架构天然是不适合的。
4.2 自回归生成：从"整体批量"到"逐帧流式"
GWM-1 采用的是自回归（Autoregressive）生成架构。它不是批量生成整段视频，而是一帧一帧地预测和输出。
自回归的逻辑可以这样理解：
输入上下文（图像 + 音频 + 对话历史）
↓
预测第 1 帧
↓
把第 1 帧作为新的上下文
↓
预测第 2 帧
↓
...（循环往复）每一帧都是基于之前所有帧的状态预测出来的，这个过程天然是流式的——第一帧生成完就能立刻输出，不需要等后面所有帧都算完。
这也是为什么自回归架构更适合做实时交互：用户随时可以输入新的语音或指令，下一帧的预测就可以把这个新输入纳入进来，响应是连续的、而不是"等一批、播一批"的。
这也是为什么自回归架构更适合做实时交互：用户随时可以输入新的语音或指令，下一帧的预测就可以把这个新输入纳入进来，响应是连续的、而不是"等一批、播一批"的。
当然，代价是自回归架构对计算效率的要求极高——因为每一帧都要在极短时间内算完，否则视频就会卡顿。
还有一点值得补充：自回归模型天然有一个"记忆窗口"的限制。每帧预测都是基于前面若干帧的状态，但这个上下文窗口不是无限长的。对于连续对话来说，模型需要有机制保持对早期对话内容的记忆，否则聊到后面它就会"忘掉"前面说过的事情。Runway 在这方面具体的实现细节没有完全公开，但根据官方描述，Characters 支持较长时间的连续对话而不会失忆，这说明背后有额外的对话历史管理机制（比如把重要上下文压缩后注入到每轮生成的条件里）。
4.3 流水线并行：把"串行"变成"流水线"
实现 24fps 输出，意味着每帧的计算时间必须控制在 (\frac{1000}{24} \approx 41.7) 毫秒以内。Runway 给出的数据是单帧生成约 37 毫秒，已经略低于这个上限。但光靠单帧计算快还不够，还要保证输出是连续不断的——这就是流水线并行（Pipeline Parallelism）的用武之地。
流水线并行的思路来自于 CPU 的流水线执行优化，本质上是把整个视频生成流程拆解成多个阶段，让不同阶段的工作并发执行，而不是等上一步完全跑完再开始下一步。
以视频生成为例，可以把流程大致拆成：
[ 模型推理生成帧 N ] → [ 解码帧 N ] → [ 网络传输帧 N ] → [ 客户端渲染帧 N ]
↓（并行）
[ 模型推理生成帧 N+1 ]
↓（并行）
[ 解码帧 N+1 ]当显卡在计算第 N+1 帧的时候，第 N 帧的解码和传输已经在同步进行。这就好比工厂的流水线作业：切割、打磨、喷漆三道工序同时在不同工件上进行，整体产出效率远高于一件一件串行完成。
这种并行架构让 Runway 在保证单帧生成质量的前提下，把端到端的延迟压缩到了约 1.75 秒这个量级。
4.4 为什么 1.75 秒是个关键门槛
人类在对话中对响应延迟的心理容忍有一个基本的经验规律：
|
延迟时长 |
用户感知 |
|
0～0.5 秒 |
感知不到延迟，非常流畅 |
|
0.5～2 秒 |
可接受，有轻微等待感 |
|
2～5 秒 |
明显感知延迟，用户开始不耐烦 |
|
5 秒以上 |
体验断裂，交互意愿下降 |
1.75 秒刚好落在"可接受"区间的末尾——不完美，但已经跨过了"实用"的门槛。相比于之前很多同类产品动辄 5～10 秒的延迟，这已经是质的飞跃。
4.5 720p 分辨率与帧率的取舍
GWM-1 目前的输出规格是 720p（1280×720）分辨率 + 24fps。这个规格是经过权衡的：
- 分辨率：720p 在视频会议和网页嵌入场景下完全够用，同时比 1080p 节省大量计算资源，有利于控制延迟。
- 帧率：24fps 是"流畅感"的基本门槛，对于对话类场景来说足够了。提升到 60fps 会把单帧预算压缩到约 16.7 毫秒，难度大幅增加。
这是一个明显的工程取舍，但从当前实际使用体验来看，这个规格已经够用。
4.6 音频驱动的口型同步原理
口型同步（Lip Sync）是数字人生成里的经典难题。早期方案是靠音素（Phoneme）映射——把每个发音单元对应到一套预录的嘴型动画上，像播放动画一样拼接。这种方式简单快速，但嘴型和音频之间往往有一种"不对味"的割裂感。
国内早期的数字人产品很多走的就是这条路，直播带货场景里有时候能明显看出嘴型和发音对不上、眼神空洞往一个方向飘，这都是"规则拼接"方案的典型痕迹。用户的大脑对人脸运动极度敏感，哪怕只是几毫秒的嘴型偏差，都会触发所谓的"恐怖谷"效应——感知到有什么地方不对劲，但说不清哪里出了问题，只是觉得"假"。
GWM Avatars 的口型驱动是在模型层面端到端学习的，音频信号直接作为条件输入参与视频帧的生成，而不是后期叠加一层动画。这意味着嘴型的变化是模型对整体运动的预测结果，而不是规则拼接——在处理复杂的音节变化、语气停顿、情绪变化时，表现比传统方案自然很多。
当然，"端到端学习"也意味着系统是个黑盒，出问题时很难定向修复。如果某个特定口型或声调在训练数据里覆盖不足，生成效果可能会有偶发性的失准。这是深度学习驱动的口型同步方案普遍存在的问题，不是 Runway 独有的，只是要在使用时有心理预期。
GWM Avatars 的口型驱动是在模型层面端到端学习的，音频信号直接作为条件输入参与视频帧的生成，而不是后期叠加一层动画。这意味着嘴型的变化是模型对整体运动的预测结果，而不是规则拼接——在处理复杂的音节变化、语气停顿、情绪变化时，表现比传统方案自然很多。
五、手把手上手教程：从零创建你的专属数字人
这一章专门面向想亲自试试的读者，把操作流程讲清楚。
5.1 注册和访问入口
首先你需要一个 Runway 账号，到 runwayml.com 注册即可，目前支持邮箱或 Google 账号登录。
新用户注册后 Runway 会赠送一定量的免费积分（截至本文写作时约 200 多个积分），用来体验 Characters 对话功能完全够用。
Characters 功能的入口在主站应用界面的功能列表里，往下滑能看到"Characters"这个选项。
5.2 两种创建方式的区别
进入 Characters 之后，你会看到两种创建路径：
模板模式：Runway 预置了一些典型角色（比如客服助手、教学导师等），直接用现成的形象和人设，适合快速测试效果或做演示。
自定义模式：上传你自己的图片，自己配置声音、名字和人设，适合正式的产品集成或个性化需求。选自定义的话灵活度高很多，建议从这里入手。
5.3 图片的选择与上传技巧
图片质量对最终效果影响很大，这里说几个我自己踩坑总结出来的经验：
- 正面或四分之三侧面效果最好，避免完全侧脸或角度过大的照片。
- 光线均匀是关键，强烈的侧光或逆光会让生成效果不稳定。
- 分辨率不需要太高，512×512 以上基本够用，太大的图反而会被压缩。
- 背景简洁：纯色或模糊背景比复杂背景效果好，可以先用图像编辑工具把背景处理一下。
- 卡通/插画形象同样支持：不一定要用真实人物照片，手绘风、3D 渲染风都能跑，但真实人物照片的口型和表情自然度会更好一些。
上传完图片之后，系统会显示一个预览，确认形象没问题就继续下一步。
5.4 声音配置
Characters 提供两类声音选项：
预设声音库：Runway 内置了多种声音风格（不同性别、语气、语调），可以直接选用，这类角色同时支持摄像头和屏幕共享功能。
自定义声音（克隆）：如果你需要用自己的声音或品牌定制的特定音色，可以上传声音样本进行克隆。但要注意，使用克隆声音的角色目前不支持视觉感知功能（摄像头/屏幕共享），这是目前的功能限制。
建议初次体验的读者先用预设声音库，功能最全、配置最简单。
5.5 人设（Personality）的配置
这一步是决定数字人"像不像人"的关键环节，但很多人容易忽视。
人设描述不是写得越长越好，而是要把几个关键维度说清楚：
角色名称：孙大圣
性格特点：机智幽默，自信洒脱，偶尔话多，但关键时候靠谱
背景知识：精通西游记的故事，对神话传说有深刻见解，也能聊现代科技
说话风格：喜欢用一点古风语气，但不会说得太文绉绉，接地气一些
禁忌话题：不涉及政治敏感内容格式不重要，重要的是描述足够具体。越具体的人设，数字人在对话中的表现越一致、越有辨识度。
有一个我自己踩过的坑要说一下：如果人设描述里只写了"聪明、友好、有帮助"这类通用形容词，生成出来的数字人对话风格基本上就是个标准 AI 助手的样子，没什么特色。反倒是加上一些有对比性的描述，比如"在解释技术问题时会用大量生活类比"、"不喜欢说废话，每句话要有信息量"，效果会好很多。
另外，人设里可以直接写清楚"不应该做什么"——比如"不要主动询问用户的个人信息"、"遇到不确定的问题要明确说不知道，不要乱猜"。这些约束性描述往往比正面描述更有效，因为它们直接划定了行为边界，模型在做决策时更容易遵守。
最后一点：如果你要把数字人接入自己的产品，人设里可以注入产品相关的背景知识，比如"你是 XX 公司的 AI 助手，专注于帮助用户解决关于 XX 产品的技术问题"。这样数字人在对话里的定位会更清晰，减少跑题的概率。
5.6 创建完成后如何对话
点击创建后，等待大约 1 分钟（具体时间因服务器负载而异），数字人就生成好了，出现在你的角色列表里。
点击"Chat"按钮进入对话界面，系统会请求麦克风权限，允许后就可以开始语音对话了。界面右侧会实时显示数字人的视频流，延迟体感确实控制得不错。
5.7 积分消耗与费用参考
Characters 的对话功能是按时长计费的，目前的定价是每 6 秒消耗 2 个积分。按这个算法，200 积分大概能支持约 10 分钟的连续对话，用来体验是够的。
如果要在正式产品中集成，需要购买更多积分或对接开发者 API 的计费方案，具体价格以 Runway 官网最新公告为准（计费方案会随产品迭代更新，建议直接查官网或 API 文档）。
这里帮大家做一个粗略的成本估算，方便判断是否符合你的预算范围。假设你要做一个每天接待 100 个用户、每个用户平均对话 5 分钟的数字人客服：
- 每位用户 5 分钟 = 300 秒 = 50 个计费单位（每 6 秒一个单位）
- 每个计费单位 2 积分，每人消耗 100 积分
- 每天 100 个用户 = 每天消耗 10000 积分
- 每月（30 天）= 30 万积分
这个量级的积分消耗如果按零售价采购是相当贵的，规模化商用时需要和 Runway 谈企业协议或 API 批量定价。这也是为什么我建议把 Characters 先用于小规模测试和原型验证，等确认了产品方向再评估正式的商务合作。
另外要注意的是：积分是按时长计费，不是按对话轮次。哪怕数字人这一帧只是在静静地听你说话、没有生成任何回应，时间还是在走、积分还是在扣。所以在产品设计上，合理控制会话时长（比如设置空闲超时自动断开）是控制成本的有效手段。
六、开发者视角：Characters API 怎么接
这一章给有开发需求的读者，讲讲 Characters 的 API 接入方案。
6.1 整体架构设计
Characters API 基于 WebRTC 实现实时视频流传输，这是目前浏览器端实时音视频通信的标准协议。整体的调用架构分为三层：
┌─────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 客户端 │ │ 你的后端服务器 │ │ Runway API │
│ (浏览器/App) │ │ │ │ │
└──────┬──────┘ └────────┬────────┘ └────────┬────────┘
│ │ │
│ 1. 请求创建 Session │ │
│────────────────────>│ │
│ │ 2. POST /v1/sessions │
│ │──────────────────────>│
│ │ 3. 返回会话凭证 │
│ │<──────────────────────│
│ 4. 返回凭证给客户端 │ │
│<────────────────────│ │
│ │ │
│ 5. 建立 WebRTC 连接（直接与 Runway 通信） │
│<──────────────────────────────────────────>│为什么要绕一层你自己的服务器？ 因为 API Key 必须放在服务端，绝对不能暴露给前端页面。会话创建的凭证（Session Credentials）由你的后端请求并下发给客户端，客户端再用这个凭证直接建立 WebRTC 连接。
这个设计保证了 API Key 的安全性，也是 Runway 在文档中明确要求的最佳实践。
这里补充说明一下 WebRTC 在这个场景里的作用：WebRTC 是浏览器原生支持的实时音视频协议，Google 主导开发，Chrome、Firefox、Safari 都支持，无需任何插件。它的核心优势是低延迟的点对点通信——客户端浏览器和 Runway 的服务器之间建立的是一条尽可能直连的音视频通道，绕过了 HTTP 请求-响应的往返开销，这也是 Characters 能把延迟压到 1.75 秒的网络层原因之一。
对于不熟悉 WebRTC 的开发者来说，好消息是 Runway 的 React SDK 把所有底层复杂性都封装好了，你不需要手动处理 ICE 候选、SDP 协商这些 WebRTC 的底层细节，直接调用 AvatarCall 组件就能跑起来。坏消息是，如果你的应用不是基于 React 的，就需要用 Runway 的 REST API 自己实现 WebRTC 的接入层，工作量会大一些，但文档里有详细的接入说明可以参考。
6.2 后端：创建 Session 的接口
下面是一个 Node.js 示例，展示如何在你的后端创建一个 Characters Session：
// server.js（Express 示例）
import express from 'express';
import RunwayML from '@runwayml/sdk';
const app = express();
const client = new RunwayML({ apiKey: process.env.RUNWAYML_API_SECRET });
app.post('/api/create-session', async (req, res) => {
const { avatarId, personality, startScript } = req.body;
try {
// 创建 Avatar 实时会话
const session = await client.realtimeSessions.create({
avatar_id: avatarId,
// 可覆盖角色默认人设（用于注入用户信息等动态上下文）
personality: personality || undefined,
// 可覆盖开场白
start_script: startScript || undefined,
});
// 轮询等待 Session 就绪
let credentials = null;
for (let i = 0; i < 30; i++) {
const status = await client.realtimeSessions.retrieve(session.id);
if (status.status === 'ready' && status.credentials) {
credentials = status.credentials;
break;
}
await new Promise(r => setTimeout(r, 1000));
}
if (!credentials) {
return res.status(503).json({ error: 'Session 初始化超时' });
}
// 把凭证下发给前端（注意：凭证有效期，不要缓存太久）
res.json({ 
