🤖 AI

Coordinated Networking for On-Device Agent-Augmented Real-Time Communication

本文提出了 HFS，这是一个利用应用引导的多流传输方法来有效管理端侧智能体增强型实时通信中实时视频与智能体上下文流量之间网络争用的框架，从而显著提升了视频质量并降低了智能体响应延迟。

原作者： Goodsol Lee, Juheon Yi, Jinglu Wang, Haowen Xu, Saewoong Bahk, Yan Lu

发布于 2026-07-28

📖 1 分钟阅读☕ 轻松阅读

原作者： Goodsol Lee, Juheon Yi, Jinglu Wang, Haowen Xu, Saewoong Bahk, Yan Lu

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象你正身处一场热闹的数字派对，每个人都试图同时做两件事：进行一场生动、面对面的交谈，并借助一个超级聪明的机器人助手，共同完成一个庞大且复杂的项目。在计算机科学领域，这被称为“实时通信”（Real-Time Communication, RTC），它是驱动 Zoom 或 Teams 等视频通话的技术。通常情况下，这些视频通话只是关于人类交谈的。但一波新的技术浪潮正在引入“AI 智能体”（AI agents）——这些是能够为你阅读文档、寻找事实并撰写草稿的智能程序。科学家们提出的一个大问题是：当你的视频通话正试图传输你的脸部画面，而你的机器人助手又试图传输大量数据来完成工作时，会发生什么？如果它们争夺同一个互联网连接，其中一个很可能会陷入停滞，导致视频卡顿或机器人响应极其缓慢。

这篇论文介绍了一个名为 HAFS（人类-智能体流调度，Human-Agent Flow Scheduling）的巧妙新系统，用以解决这个交通拥堵问题。研究人员发现，当你尝试直接在自己的设备（如笔记本电脑或手机）上运行这些 AI 智能体，而不是在巨大的云端服务器上运行时，你会获得更好的隐私保护和更低的成本，但也会创造出一种新型的网络流量混乱。他们发现，如果没有一名“交通警察”，机器人的数据洪流会占领道路，导致你的视频出现卡顿和模糊，或者让机器人在等待数据到达的过程中处于闲置状态。HAFS 就像一个超级有序的交通控制器，它准确地知道视频需要多少空间才能保持流畅，以及机器人需要多少空间才能快速工作。通过这种精细的平衡，该系统确保了你的视频保持清晰，同时也让你的 AI 助手以创纪录的速度完成任务。

问题所在：数字双车道高速公路

把你的互联网连接想象成一条双车道的公路。在其中一条车道上，你有“人类视频”，它就像是一群高速赛车。这些车需要平稳且持续地移动；如果遇到交通拥堵，视频就会冻结，对话也会中断。在另一条车道上，你有“智能体上下文”（Agent Context），它就像是一支运送巨大箱子的重型货运卡车车队，负责运送信息。这些卡车试图交付数据，以便 AI 能回答诸如“总结这份 1000 页的法律合同”之类的问题。

问题在于，在目前的视频通话系统中，这两条车道并不互通。当货运卡车（AI）接到一个大订单时，它们就会开始尽可能快地行驶，填满整个公路。这会导致赛车（你的视频）被堵在它们后面的交通拥堵中。视频系统看到延迟后会感到恐慌，认为道路出现了故障，因此会将车辆速度降至极慢，使你的视频看起来充满像素点且质量低下。与此同时，AI 卡车仍然卡在拥堵中，等待道路畅通。

研究人员在 Zoom 和 Microsoft Teams 等真实的视频通话平台上测试了这一点。他们发现，当他们尝试在视频通话中同时发送 AI 数据时，视频质量下降了一半以上。更糟糕的是，一旦 AI 完成任务，视频需要超过 30 秒才能恢复到正常速度。这是一个既混乱又低效的过程，无论是人类还是机器人，都无法很好地完成工作。

解决方案：HAFS，聪明的交通警察

为了解决这个问题，团队构建了 HAFS，这是一个像坐在你的视频通话应用内部一样的智能交通警察。HFS 不再让视频和 AI 互相争夺空间，而是观察整条公路，并决定每条车道应该跑多快。

1. “帧级”监视器
HAFS 的第一个职责是密切监视视频车道。它不仅仅看平均速度，还会观察每一帧视频之间的微小间隙（就像翻页书里每一帧之间的间隔）。系统知道视频可以容忍极短的等待，但只能达到特定的限度（约 150 毫秒）。如果 AI 卡车开始将视频赛车推向那个限度边缘，HAFS 会立即命令卡车减速。但如果路上有额外的空间，HAFS 会告诉卡车加速，填满空闲的车道。通过这种方式，视频保持流畅，同时 AI 也能利用所有可用的额外空间而不引发碰撞。

2. “预测性”调度器
第二个职责更加聪明。有时，AI 需要一次发送许多辆卡车来回答一个问题。在旧系统中，这些卡车会像在收费站排队一样一个接一个地等待，这非常缓慢。然而，HAFS 会观察每辆卡车携带的箱子大小，并预估一旦到达后拆解它们需要多长时间。然后，它会以完美的顺序排列这些卡车，使得当一辆卡车到达并开始拆解时，下一辆已经停靠在卸货码头旁了。这被称为“流水线作业”（Pipelining）。这就像一位厨师在第一道菜还在煎的时候，就开始切第二道菜所需的蔬菜，从而确保没有任何环节处于闲置状态。

结果：更快、更清晰的未来

研究人员在包括 MacBook Pro、三星 Galaxy 手机和一台名为 Jetson 的小型计算机在内的真实设备上测试了 HAFS。他们进行了不同类型的 AI 模型和网络速度（从 Wi-Fi 6 到 5G）的模拟实验。

结果令人印象深刻。与传统方法相比，HAFS 使视频质量提升了 1.5 倍。同时，它将 AI 的响应时间缩短了 31%。在某些情况下，由于不再被困在交通拥堵中，AI 完成任务仅需 16 秒，而通常则需要 105 秒。

论文指出，这种方法是让 AI 助手成为我们视频通话常态化组成部分的一种极具前景的方式，且不会破坏使用体验。通过让人类和机器人和谐共处，我们可以拥有高质量的视频通话，同时 AI 始终准备好提供帮助，就在你的本地设备上，既保护了你的隐私，又保证了互联网的顺畅运行。

技术摘要：面向设备端智能体增强型实时通信的协同网络技术

1. 问题陈述

AI 智能体的兴起正在驱动一种新的实时通信（RTC）范式：智能体增强型 RTC（Agent-Augmented RTC）。在这种模型中，AI 智能体在用户设备本地运行，以自主检索、分析和生成信息，从而支持人类协作（例如，共同编写法律文档或总结会议日志）。

虽然设备端智能体在隐私（保持敏感数据端到端加密）和成本（减轻云端 GPU 推理负担）方面具有显著优势，但它们也引入了一个关键的网络挑战：异构流量流之间的竞争。

人类视频流： 要求低延迟（<150 ms）和高质量，通常由基于延迟的拥塞控制（如 GCC）管理。
智能体上下文流： 涉及流式传输大型键值（KV）缓存（压缩后高达 80 MB），以实现快速 LLM 推理。这些流量使用基于丢包的拥塞控制（如 SCTP）来最大化吞吐量，从而激进地填满网络缓冲区。

核心冲突： 当这些流量共享网络时，智能体上下文流的激进特性会导致人类视频产生排队延迟。这会触发基于延迟的视频控制器大幅降低比特率（例如，VMAF 分数下降 53%）且恢复缓慢（>30 秒）。此外，当多个智能体针对单个查询同时流式传输上下文时，标准的轮询调度会导致排队延迟增加和计算资源利用不足，使智能体响应时间增加高达 56%。

2. 方法论：HAFS 框架

作者提出了 HAFS（Human-Agent Flow Scheduling，人类-智能体流调度），这是一个协同网络框架，旨在同时确保高视频质量和低智能体响应延迟。HAFS 作为一种应用引导的多流传输层，运行在标准 WebRTC 和 llama.cpp 之上，无需修改底层网络基础设施。

2.1 系统架构

HAFS 采用了现代 RTC 中常见的**选择性转发单元（SFU）**架构。它在发送端和 SFU 两端引入了两个运行在应用层的协调器：

人类-智能体流协调器： 共同控制视频（RTP）流和智能体上下文（SCTP）流的发送速率。
多智能体流协调器： 调度并发智能体流的传输顺序，以最小化总响应时间。

2.2 关键设计组件

A. 人类-智能体流协调

为了解决视频与智能体流量之间的竞争，HAFS 采用了帧级排队感知速率控制机制：

双重反馈估计器： 它通过结合 RTP 反馈（数据包延迟）和 SCTP ACK 来估计排队延迟。SCTP ACK 密集地填充在视频帧之间的空闲间隔中，这使得系统能够测量专门由智能体流量引起的排队，而不会干扰原生的 RTP 流量整形（pacing）。
联合速率控制（MI/AI-MD）： 系统不断提高聚合发送速率，直到帧级排队延迟接近但不超过应用指定的截止时间（例如 150 ms）。
- 乘性增加（MI）： 当队列为空时，快速增加速率。
- 加性增加（AI）： 当队列正在构建但低于截止时间时，温和地增加速率。
- 乘性减少（MD）： 如果接近截止时间，则降低速率。
带宽分配： 一旦确定总速率，系统会严格为实时视频预留所需的比特率，并将剩余的“松弛（slack）”容量分配给智能体流。
智能体探测带宽： 由于智能体流通常以高于视频的速率进行探测，系统利用观察到的智能体吞吐量来估计可用带宽，从而使视频控制器能够从拥塞中快速恢复，而不必等待缓慢的基于延迟的反馈循环。

B. 多智能体流协调

为了处理多个并发的上下文流，HAFS 将调度问题视为一个两机流流水作业问题（网络传输后接 LLM 解码）。

流水线感知调度： 系统预测每个流的传输时间（ $T_{net}$ $T_{n e t}$ ）和计算时间（ $T_{comp}$ $T_{co m p}$ ）。它应用 Johnson 规则 来确定最优传输顺序：
- 对于 $T_{net} \le T_{comp}$ 的流，优先调度（按 $T_{net}$ 升序排列）。
- 对于 $T_{net} > T_{comp}$ 的流，最后调度（按 $T_{comp}$ 降序排列）。
预测策略： 由于在解码前无法知晓 LLM 的输出长度，HAFS 使用预构建的 KV 缓存进行轻量级单步 LLM 解码，以预测响应长度。该预测仅用于相对排序，使系统对绝对预测误差具有鲁棒性。
鲁棒性机制：
- 动态优先级更新： 如果网络带宽发生显著波动（>20%），则重新评估优先级。
- 重叠预填充（Overlapped Prefill）： 如果网络传输比本地预填充慢，系统会抢先流式传输原始文本上下文，以保持接收端的计算资源处于忙碌状态。

3. 核心贡献

识别了一种新的网络范式： 本文强调了在设备端 RTC 中，由于延迟敏感型视频与高吞吐量智能体上下文流共存而产生的特定竞争问题，这是传统 RTC 或基于云端的智能体架构未曾解决的场景。
应用引导的多流传输： HAFS 引入了一个统一的应用层编排器，通过利用基于 SFU 的 RTC 架构中的短 RTT，实现了类似于网络层级的精确流调度，避免了对路由器层级的修改。
新型速率控制机制： 设计了一种帧级排队估计器，利用 SCTP ACK 来隔离智能体诱发的排队与视频流量，从而实现视频质量与智能体吞吐量的同步优化。
计算-网络流水线化： 将多智能体流调度建模为流流水作业问题，利用轻量级 LLM 预测来最小化端到端响应延迟。

4. 实验结果

作者使用 WebRTC 和 llama.cpp 对 HAFS 进行了原型设计，并在多种环境（MacBook Pro, Samsung Galaxy S25, NVIDIA Jetson Orin Nano）和网络（Wi-Fi 6, 5G）下进行了评估。

视频质量： 在智能体流活跃时，与基准测试（Zoom, Teams）相比，HAFS 实现了 1.5 倍更高的视频质量（通过 VMAF 测量），有效地将视频质量维持在与仅视频流传输相当的水平。
智能体延迟： 与最先进的基准测试相比，HAFS 将智能体响应时间降低了 31%。
可扩展性： 该系统在不同数量的并发智能体流、不同 LLM 模型（Qwen, Llama 系列）以及不同网络条件下均能保持性能增益。
开销： 该框架在功耗、CPU 和内存使用方面的开销可以忽略不计。

5. 意义

论文声称 HAFS 为下一代协作 AI 应用提供了一个实用的、可部署的解决方案。通过实现设备端智能体增强型 RTC，它解决了隐私（避免数据暴露给云端）和成本（减少对云端 GPU 的依赖）的双重挑战，同时也解决了此前使此类系统难以实现的固有网络竞争问题。这项工作表明，通过协调的应用引导传输策略，可以在不损害用户体验的前提下，支持高带宽、延迟敏感的 AI 工作负载与实时人类通信并存。