从“对讲机”到“打电话”——实时音视频技术在 Agent 上的应用与实践

文章概要：

• 智能语音 Agent 的应用场景：AI 社交、儿童陪伴、AI 助手、教学、客服、智能硬件

• RTC 技术在 Agent 上的重要性，包括超低延时-更流畅、智能打断-更自然、抗弱网-更可靠

• RTC 在处理实时视频流的场景以及优势——在持续传图场景下比传输图片更省流量，按需抽帧更灵活

• RTC 在处理多人多 Agent 的场景以及优势——基于房间的多人多 agent 管理

录播回放：https://www.volcengine.com/live/event/force-2412-developer，01:41:20-01:57:30

以下内容来自「火山引擎 2024 冬 Force 原动力大会开发者主论坛」上的演讲，演讲嘉宾：杨若扬

今天和大家分享的话题是 RTC，也就是实时音视频在 AI 智能体上的应用与实践，我们从一个简单的转变说起——从“对讲机”到“打电话”，这个看似微小的转变，背后蕴含着技术的巨大飞跃。而 RTC 技术，在这个过程中起到了非常关键的作用。

上个月底，WebRTC 的早期创建者之一 Justin Uberti 宣布加入 OpenAI，并且领导 Real-Time AI 项目的开发。而就在昨天（12 月 18 日），OpenAI 发布支持通过 WebRTC 接口来连接 Realtime API，这意味着 RTC 技术越来越深入扎根到 AI 领域，对于 AI 的应用场景会带来飞快的拓展。

Justin Uberti 认为，语音和视频的交互是 AI 的未来，他会用他在 RTC 领域的专业能力推动人与 AI 的交互从文本框走向更自然的音视频对话。火山引擎其实在今年 8 月份就发布了 RTC 与方舟结合的「实时对话式 AI」方案。上个月，扣子上线了集成火山 RTC 的智能语音功能。我今天分享的主题，正好踩在这个时代的趋势上。

我们先来看一下，结合了 RTC 技术之后的智能体能在哪些场景发挥作用。

在 AI 社交场景，智能体可以变身成为你的虚拟好友，他/她可以 24 小时提供情绪价值。和这样的虚拟朋友聊天，用打电话的方式比发送语音消息的体验要好得多。

在儿童陪伴场景，智能体可以陪伴小朋友学习、玩耍，还能用小朋友最喜欢的 IP 音色，比如小猪佩奇、小马宝莉的声音，用小朋友的话和他们聊天。小朋友的口齿一般不像大人这么清晰，这在幼儿里面非常常见，有时候大人都不一定听得懂他们在说什么，但 AI 可以听懂。

还有 AI 助手，像豆包 App 就是一个 AI 超级助手，你什么事都可以问它。很多时候，你可能手上正做着事情，这时候用实时语音和它对话的话，你就可以解放双手，让你可以一边处理手上的事情，一边让它在旁边给你提供帮助。

结合了实时语音之后，智能体也可以成为你的同声传译员，和老外交流的时候在旁边给你做双向翻译；他也可以作为你的口语陪练，你不用再请很贵的外教了，口音也不会成为问题，甚至社恐人士也可以大胆和 AI 外教进行交流。

还有 AI 客服，他是一个永远不会发脾气的专业客服，还能为企业降本增效。

这些场景，都需要实时语音。

我们还能把带有实时语音的智能体塞入硬件，这些硬件也就都有了灵魂，它们不再是一个摆设、一个玩偶，而是你的朋友、你的家庭营养顾问。

在以前，要实现上面这些功能，开发起来非常复杂，开发者需要去对接非常多的技术，现在，有了扣子 1.5 的智能语音 API，要实现这些功能就变得非常简单。

首先，扣子本身就是新一代 AI 应用开发平台。开发者用扣子的可视化工作流、知识库、记忆、搜索插件等功能来很快捏一个智能体，把它发布为 Agent as API；然后集成 RTC SDK，调用“创建房间”接口创建一个 RTC 房间；然后再把刚才捏好的智能体加入 RTC 房间。这样，只要你的用户也加入到同一个房间，他就可以和智能体进行实时语音对话了。这个过程就和我们加入视频会议一样，不同的人加入到同一个会议，就可以相互交流。

这里所说的“实时对话”，和标题说的一样，是说像和真人打电话那样，而不是实时对讲机。“对讲机”模式可以理解为微信语音消息，就是按住一个按钮说话，说完了松开，把语音消息发给出去，对方听完过几秒再回过来一句话。这种方式，与“实时对话”的体验差距是非常大的。

而 RTC 就是为极低延时的网络传输而生的技术，它采用了全双工模式的通信技术，通信双方可以同时进行双向数据的发送和接收，这样可以显著地提高通信效率。而且，火山引擎 RTC 在全球有 3000 多个优质网络节点，这 3000 多个节点组成了一张全球范围的网络高速公路，让音视频数据始终跑在最快的通道上进行传输。RTC 的端到端传输一般只需要 100ms，再加上大模型、ASR、TTS 的计算耗时，可以让用户和智能体对话的端到端延时最低降至 1 秒。

像和真人“打电话”的另一个特点是，在对话过程中你可以随时打断它。我们可以用语音和智能体说“你这个话题我们先跳过”，或者说“我刚才那句话不是这个意思”，你甚至可以在他说话时和他说“直接用英文回答我这个问题”，这些都可以用语音来控制，而不需要通过手按按钮让它“别说了”。这个功能依赖 VAD 技术 ，也就是语音活性检测，它的复杂点在于，我们采集到的音频很多时候会带有环境噪声，当这些噪声存在的时候，可能 VAD 会造成误打断，所以我们要解决噪声的问题；除此以外，还有回声的问题，因为在双向通话时，对方在说本地还在采集，这时候会产生回声，所以还要解决回声的问题。这些音频上的算法要处理好还是非常麻烦的，除了要加上刚才说的这些算法以外，这些算法本身还和硬件设备有很大的兼容性的依赖关系。现在线上手机型号就有上万款，再加上一些 IoT 的智能设备，型号就更多了，适配起来很麻烦。火山引擎 RTC 已经在抖音、飞书、以及即将要上线的豆包上已经做了非常充分的技术积累，可以让我们的开发者不用操心这些麻烦的问题，把精力留在自己最关键的业务上。

还有一个不得不提的关键细节是弱网环境。我们都是通过互联网来和 AI 交流的，如果你所处的网络信号不好，或者网络发生了波动，这种情况我们称之为弱网，如果出现弱网就会出现网络丢包，丢包就可能会丢字，如果你说的一句话中的关键字丢了，大模型的理解可能就会谬之千里。弱网在我们的生活中其实很常见，如果你的用户多到一定程度，弱网引发的问题就会越来越突出。所以，对抗弱网的能力在这里相当重要。火山引擎 RTC 拥有丰富的丢包重传和前向冗余等抗弱网策略，可以在 80% 丢包的环境下依然保持流畅的通话，确保大模型在各种网络环境下的表现。

说完语音，我们再来说说视频。

昨天的发布会上，豆包大模型正式发布了视觉理解模型。当我们的智能体能看见之后，我们和大模型的交流体验就又升级了！

这里我分享两个场景，第一个是在 AI 社交中，如果你的虚拟朋友它能够看见你的影像，那会发生什么？

我们看到，虚拟朋友可以通过你的表情或动作，会推测你不开心，即便你不说“我不开心”，他也会主动送上关心，这和真人体验就更接近了一步。

再看一个场景，当我们用智能体去实时捕捉我们的电脑桌面，这时候又能出现什么新的玩法？

我们在玩游戏的时候，智能体可以实时分析我们的游戏画面，给我们提供及时的游戏信息和打法建议。

讲完场景，我们再聊聊实现。

大家可能会问，传视频流的话是不是很费流量，是不是传图片流就可以了？我们的答案是，不一定。

首先看应用场景，如果你的场景需求只需要一张图，那肯定是传图片就行了。但如果你的场景需求要持续传输连续的多张图片，那就不一定了。

我们做了个计算，对比视频流和图片流分别需要消耗多少流量——左边是传输 1 分钟的 1080p 视频，帧率是 15 帧，也就是 1 秒有 15 张图片；右边是传输 1 分钟的 1080p 图片流，每秒只传 1 张图，相当于 1 帧的视频。这本身是个不公平的对比，15 帧和 1 帧，左边视频流的信息量是右边图片流的 15 倍。但计算下来，视频流消耗的流量却只有图片流的一半，相当于 30 倍的差距。这是因为 RTC 对视频数据做了关键帧编码压缩，对于一段连续的视频，只要开头的那一帧是一张完整的图片数据，后面的每一帧只需要参考前一帧的变化，只对差异进行编码，也就是说，后面的参考帧其实占用的数据量是非常小的，这样做就可以大大减少视频传输的数据量，提高视频传输效率。而相对于图片流来说，相当于每一张图片都是一个关键帧。如果想要让大模型理解连续画面，需要在 1 秒钟内传输多张图片信息的话，视频流是一个更好的选择。

传视频流还有一个好处，有时候，大模型并不是需要理解视频的每一帧，可以根据场景需求来灵活调整抽帧策略。比如刚才说的识别人物表情、动作，这时候不需要太低的抽帧间隔，设置一个高一些的间隔就可以。而屏幕抓取场景就需要一个较低的间隔，尤其是游戏这种高帧率的场景，就需要更低的间隔了。

刚刚我们说的这些场景，目前市面上的产品形态看到的都是 1v1 的，也就是 1 个真人和 1 个智能体对话。但我们发现，市场的需求其实肯定不满足于只有 1v1。

比如在视频会议场景，会议助手不止是服务一个用户，而是要倾听会议中的所有用户，它需要知道谁是谁，谁说了什么，会议的主要结论是什么，ToDo 是什么；还需要去随时响应任何一个用户向它提出的问题和指令。

再比如剧本杀、狼人杀这种多人社交游戏，有时候可能玩家凑不齐足够的人数，像狼人杀至少 8 个人才能玩，以前玩家只能选择和陌生的朋友玩，现在，如果你不想和陌生的朋友玩，也可以让智能体玩家来加入填补空缺。这时候，智能体既需要和真人玩家配合，还需要和别的智能体玩家配合，这里的业务逻辑也会更复杂一些。

还有比如主持啊、调解纠纷的场景。视频里的这个智能体就很忙，要同时照顾到多个真人用户的谈话、情绪，要记忆他们各自的内容，还要注意对话的连续性。

这样的多人场景要做的好，我们需要关注智能体的响应速度、上下文连续性，以及多人多 Agent 之间“连接”的管理。当连接数量越来越多的时候，需要做的管理逻辑也是越来越复杂，“连接”数量也在疯长（相当于 n 平方的数量，n 是用户和智能体的数量），复杂度会大大增加，开发者需要去处理类似“信令风暴”这样很麻烦的问题。而 RTC 把这些复杂的技术问题都解决了——把它封装成一个“房间”，还会在内部做很多的性能的处理，因此我们的开发者就不需要再操心这些麻烦的问题了。

最后，我想 call back 一下开头，借用 Justin Uberti 的一句话来作为我今天分享的结尾。Someday we would talk to AIs like human communication。他原文说的是：我们意识到语音和视频对人类交流的影响，有一天我们也会用同样的方式和 AI 对话。

在 AI 领域，大模型、语音、视频、网络传输这些不言而喻都是非常关键的技术，而 RTC 也将会在这个飞速发展的领域中越来越重要，让人和大模型的交流体验越来越像人与人的交流。这就是 Justin 所坚信的那样，我相信未来的发展潜力是非常无限的。

希望我今天的分享能够给大家带来启发，谢谢大家！