从“听懂语音”到“跨网络执行”：多智能体 AI 眼镜系统论文解读 - sdk社区

论文名称： An Intelligent AI Glasses System with Multi-Agent Architecture for Real-Time Voice Processing and Task Execution
研究方向： AI 眼镜、多智能体系统、实时语音识别、RAG、MCP、RTSP、RabbitMQ、眼动追踪
核心关键词： Dual-Agent、Whisper.cpp、Ollama、MCP、ChromaDB、RTSP、RabbitMQ、Eye Tracking

1. 前言

近年来，AI 眼镜逐渐从“显示信息的可穿戴设备”发展为能够理解语音、感知环境并执行任务的智能终端。

在工业自动化、医疗辅助、设备维护和企业协作等场景中，用户往往希望通过免手操作完成以下任务：

用语音查询设备故障；
调取技术文档或维修流程；
打开地图并进行导航；
控制浏览器或启动应用；
将任务发送到远程计算机执行；
结合用户视线判断“这个”“那里”究竟指向什么。

但要真正实现这些能力，并不是简单地把一个大语言模型接入眼镜即可。

一个可运行的 AI 眼镜系统至少需要同时解决：

实时语音识别；
自然语言意图理解；
外部知识与工具调用；
音视频跨网络传输；
远程任务调度与执行；
多平台兼容；
眼动数据采集；
网络中断、延迟、续航和隐私问题。

论文《An Intelligent AI Glasses System with Multi-Agent Architecture for Real-Time Voice Processing and Task Execution》提出了一套完整的 AI 眼镜系统原型。

它的核心思路是：

将系统拆分为两个职责明确的智能体：Agent 01 专门负责实时语音识别，Agent 02 负责意图理解、知识检索、工具调用与任务编排，再通过 RTSP 和 RabbitMQ 打通眼镜、模型服务与远程执行主机。

这篇论文的重点并不是提出新的基础模型，而是验证一套由语音识别、本地 LLM、RAG、MCP、流媒体、消息队列和眼动模块组成的系统是否能够真正运行起来。

2. 解决什么问题

2.1 实时语音处理

AI 眼镜需要持续接收用户语音，并尽快将其转成文本。

但现实环境中可能存在：

工业设备噪声；
用户说话音量不稳定；
中英文混合命令；
连续音频流；
静音片段占用计算资源；
音频分段导致句首或句尾丢失。

因此，系统不仅要有 ASR 模型，还需要流式音频抽取、缓冲、滑动窗口、重叠分段、降噪、增益控制和 VAD 等完整处理链。

2.2 智能任务解释

语音识别只能得到文本，却不能直接决定系统应该执行什么任务。

例如：

“帮我看看 UR10 为什么故障”

系统需要进一步判断：

这是设备技术支持请求；
需要检索 UR10 相关技术文档；
需要调用 RAG；
最终要把诊断结果显示在 AI 眼镜上。

再例如：

“I want to go to NCHC.”

系统需要识别为导航意图，生成地图地址或 URL，并把显示命令发送到眼镜端。

因此，文本转写之后还需要：

意图识别；
上下文理解；
文档检索；
工具调用；
参数组织；
任务路由。

2.3 跨网络通信与远程执行

AI 眼镜本地算力有限，很多任务必须由远程服务器或其他执行主机完成。

系统需要支持：

局域网直接连接；
广域网端口转发；
NAT 穿透；
企业 VPN；
网络中断后的自动重连；
消息持久化；
Windows、macOS 和 Linux 跨平台执行。

因此，AI 眼镜实际上只是系统入口，真正的计算和执行资源分布在不同设备和网络中。

3. 为什么使用双智能体架构

论文没有把 ASR、LLM、RAG 和任务执行全部放入一个大型进程，而是设计了两个相互协作的 Agent。

Agent 01：语音识别智能体

负责：

接收 RTSP 音频流；
使用 FFmpeg 抽取音频；
进行滑动窗口分段；
通过 VAD 过滤静音；
使用 Whisper.cpp 完成中英文转写；
把文本交给 Agent 02。

Agent 02：智能任务处理智能体

负责：

意图识别；
本地 LLM 推理；
RAG 文档检索；
MCP 工具调用；
结合历史上下文；
生成结构化任务；
通过 RabbitMQ 发送任务；
协调远程主机执行。

系统可以概括为：

AI眼镜
  ↓
实时语音 / 视频 / 眼动数据
  ↓
Agent 01：听懂用户说了什么
  ↓
Agent 02：理解用户想做什么
  ↓
RabbitMQ：把任务发给正确的执行主机
  ↓
执行结果返回AI眼镜

3.1 双 Agent 的工程价值

减少资源竞争

Whisper.cpp 的持续语音转写和 LLM 推理都需要计算资源。

如果两者放在同一个处理流程中，ASR 和推理可能互相抢占资源。

便于独立优化

可以单独替换：

Whisper.cpp；
Ollama 中运行的本地 LLM；
ChromaDB；
Embedding 模型；
MCP 工具；
RabbitMQ 执行器。

提升可维护性

语音模块出问题时，不必修改任务处理模块；工具调用能力扩展时，也不必重构 ASR 流程。

支持分布式部署

Agent 01 和 Agent 02 可以运行在不同设备上，从而适配企业内部多种计算环境。

4. 系统整体架构

论文的系统由四类组件构成：

AI 眼镜硬件；
双智能体处理模块；
网络与消息通信模块；
远程任务执行主机。

整体流程如下：

AI Glasses
采集语音、视频、眼动
        ↓
RTSP Server
传输实时音视频
        ↓
Agent 01
Whisper.cpp 实时语音识别
        ↓
文本命令
        ↓
Agent 02
本地LLM + RAG + MCP + 意图识别
        ↓
结构化任务
        ↓
RabbitMQ
Topic Routing / Message Persistence
        ↓
Remote Host
浏览器、地图、应用、文件、信息显示
        ↓
执行结果返回AI眼镜

系统并不是所有数据都通过同一个协议传输。

RTSP 主要负责持续音视频流；
RabbitMQ 主要负责结构化消息、眼动数据和任务指令；
VPN 或端口转发 用于不同网络环境下的连接。

5. Agent 01：实时语音识别模块

Agent 01 使用 Whisper.cpp 完成流式语音识别。

其处理流程为：

RTSP Audio Stream
        ↓
FFmpeg低缓冲抽取
        ↓
降噪与自动增益
        ↓
滑动窗口与重叠缓冲
        ↓
VAD过滤静音
        ↓
Whisper.cpp
        ↓
中英文文本

5.1 RTSP 与 FFmpeg

AI 眼镜通过 RTSP 发送音视频流。

Agent 01 使用 FFmpeg 进行音频抽取，并采用尽可能小的缓冲设置，以降低流式处理延迟。

FFmpeg 在这里的作用不是语音识别，而是：

接收 RTSP；
分离音频轨道；
转换音频格式；
将连续音频交给后续处理模块。

5.2 滑动窗口处理

连续音频不能无限增长，因此需要划分为多个处理窗口。

论文将第 (i) 个音频窗口表示为：

$encoding="application/x-tex">W_i=\{A(t):t_{i-1}\leq t\leq t_i\} </annotation></semantics></math>$

其中：

(A(t)) 表示时间 (t) 的连续音频信号；
(W_i) 表示当前语音识别缓冲窗口。

如果窗口之间完全不重叠，单词或句子刚好落在边界处时，可能发生语音截断。

因此，相邻窗口之间保留一定重叠。

窗口重叠比例为：

$encoding="application/x-tex">\alpha= \frac{t_{i-1}+\Delta t-t_i}{\Delta t} </annotation></semantics></math>$

重叠窗口的作用是：

保留边界语音；
减少切片伪影；
让连续转写更加平滑。

5.3 VAD：过滤静音片段

Voice Activity Detection 用于判断当前窗口中是否存在有效语音。

论文结合：

音频能量；
过零率 Zero-Crossing Rate；

进行判断。

可以简化为：

VAD(W_i)= \begin{cases} 1,& E(W_i)>\theta_{energy}\ \text{且}\ ZCR(W_i)<\theta_{zcr}\\ 0,& \text{其他情况} \end{cases}

当 VAD 输出 0 时，系统不将该窗口交给 Whisper.cpp，从而减少静音片段带来的无效计算。

5.4 中英文语音支持

论文验证了系统可以处理中文和英文语音命令，覆盖：

导航请求；
技术支持；
一般信息查询。

但需要客观说明：论文只展示了功能可用性，没有给出 Word Error Rate、Character Error Rate 或噪声环境准确率等定量指标。

6. Agent 02：本地 LLM、RAG 与 MCP 的协同

Agent 02 是整个系统的“任务大脑”。

它整合了：

Ollama 本地 LLM；
规则匹配；
对话上下文；
ChromaDB；
sentence-transformers；
RAG；
MCP 工具；
RabbitMQ 任务编排。

其处理流程可以概括为：

Agent 01输出文本
        ↓
意图识别
规则 + LLM + 上下文
        ↓
是否需要知识检索？
        ↓
ChromaDB / RAG
        ↓
是否需要外部工具？
        ↓
MCP Tool
        ↓
生成结构化任务
        ↓
RabbitMQ发送

7. 意图识别：规则、LLM 与上下文共同判断

论文没有完全依赖 LLM 自由判断，而是采用多阶段意图分析。

意图置信度定义为：

$encoding="application/x-tex">C_{intent} = \omega_p P_s + \omega_l L_s + \omega_c C_{context} </annotation></semantics></math>$

其中：

(P_s)：规则或模式匹配分数；
(L_s)：LLM 对意图的判断结果；
(C_{context})：与对话历史的上下文相关性；
(\omega_p+\omega_l+\omega_c=1)。

这种设计可以理解为：

关键词/规则判断
        +
LLM语义理解
        +
历史上下文
        ↓
最终意图置信度

7.1 模式匹配

对于命令 (c) 和模式集合 (\mathcal{P})，论文使用最大子串匹配比例：

$encoding="application/x-tex">P_s(c) = \max_{p\in\mathcal{P}} \frac{|match(c,p)|}{|p|} </annotation></semantics></math>$

例如，“打开地图”“导航到 NCHC”“我要去 NCHC”虽然表达不同，但可以通过规则与语义模型共同归到导航意图。

7.2 为什么不能只使用关键词

关键词规则速度快，但无法处理复杂语言。

例如：

“我想看看从这里到国家网格中心怎么走”

可能没有直接出现“打开地图”四个字，但语义上仍属于导航任务。

7.3 为什么不能只使用 LLM

完全依赖 LLM 可能带来：

输出不稳定；
工具类型判断错误；
参数格式不规范；
延迟增加。

因此，规则、LLM 和上下文组合更加适合工程系统。

8. RAG：让技术文档进入任务处理流程

当用户询问设备故障、维护步骤或内部知识时，仅依靠通用 LLM 可能无法提供准确答案。

论文使用：

ChromaDB 保存文档向量；
sentence-transformers 生成 Embedding；
余弦相似度检索相关文档。

查询向量 (q) 与文档向量 (d_i) 的相似度为：

$encoding="application/x-tex">sim(q,d_i) = \frac{q\cdot d_i} {\|q\|\|d_i\|} </annotation></semantics></math>$

随后，系统选择 Top-K 相关文档：

$encoding="application/x-tex">R_k(q) = \arg\max_{\mathcal{S}\subseteq\mathcal{D},|\mathcal{S}|=k} \sum_{d_i\in\mathcal{S}}sim(q,d_i) </annotation></semantics></math>$

RAG 的工作过程为：

用户问题
   ↓
生成查询向量
   ↓
ChromaDB相似度检索
   ↓
返回Top-K技术文档
   ↓
与用户问题共同输入LLM
   ↓
生成故障诊断或维修建议

在 UR10 机械臂案例中，系统把技术文档中的故障诊断和维修步骤组织成适合眼镜显示的内容。

9. MCP：让 LLM 获得外部工具能力

本地 LLM 可以理解语言，但不能天然执行地图、浏览器、文件系统或应用启动等操作。

论文通过 Model Context Protocol 接入外部工具。

MCP 在系统中的作用是：

统一描述工具；
定义输入参数；
连接外部数据源；
扩展本地 LLM 能力；
降低工具与模型之间的耦合。

可以将三者关系理解为：

LLM：理解用户意图并决定做什么
RAG：提供回答所需知识
MCP：提供完成任务所需工具

例如：

查询设备故障：调用 RAG；
打开地图：调用地图或浏览器工具；
启动应用：调用执行主机工具；
显示结果：生成适合 AR 界面的内容。

10. 网络通信：RTSP、端口转发与 VPN

AI 眼镜可能运行在不同网络环境中，因此论文设计了多种连接方式。

10.1 局域网

在同一局域网内，系统可以直接使用 RTSP 连接。

优点：

网络路径短；
延迟较低；
配置相对简单。

10.2 广域网

跨公网连接时，系统可使用端口转发和 NAT Traversal。

10.3 企业 VPN

在企业环境中，语音、视频和任务数据可能涉及内部敏感信息，因此系统支持 VPN 加密隧道。

网络管理器会检测可用连接方式，并在不同网络条件下调整参数。

10.4 网络方法选择

论文使用延迟、带宽和可靠性共同评价网络方法：

$encoding="application/x-tex">Score_{method} = \frac{\omega_1}{L+\epsilon} + \omega_2B + \omega_3R </annotation></semantics></math>$

其中：

(L)：延迟；
(B)：带宽；
(R)：可靠性；
(\epsilon)：防止分母为零；
(\omega_1+\omega_2+\omega_3=1)。

系统希望选择延迟更低、带宽更高、可靠性更强的连接方式。

10.5 自适应码率

可用带宽下降时，系统动态降低流媒体传输速率。

论文给出的形式为：

$r_{max} \cdot \min \left( 1, \frac{B_{available}(t)}{B_{required}} \right) \cdot \exp(-\lambda L(t)) </annotation></semantics></math>$

其直观含义是：

带宽不足时降低码率；
延迟升高时进一步抑制发送速率；
避免网络拥塞导致系统完全失效。

11. 眼动追踪：为语音命令补充视觉指向

用户在使用智能眼镜时，经常会说：

“打开这个”；
“查看那里”；
“这个设备怎么修”；
“帮我显示那一个”。

仅靠语音无法确定“这个”指向哪个目标。

因此，论文加入了眼动追踪模块，为 Agent 02 提供更多上下文。

11.1 数据采集

系统通过 Ganzin 眼动硬件和 Android Native API，按照 30 Hz 采集双眼 gaze vector。

11.2 双眼视线融合

左右眼视线根据置信度和噪声进行加权：

$encoding="application/x-tex">g_{combined} = \frac{w_Lg_L+w_Rg_R} {w_L+w_R} </annotation></semantics></math>$

其中：

(g_L,g_R)：左右眼 gaze vector；
(w_L,w_R)：对应权重。

权重为：

$encoding="application/x-tex">w_i = \frac{c_i^2} {c_i^2+\sigma_i^2} </annotation></semantics></math>$

其中：

(c_i)：眼动跟踪置信度；
(\sigma_i)：噪声方差。

置信度越高、噪声越低，权重越大。

11.3 世界坐标变换

融合后的 gaze vector 需要转换到现实世界坐标系：

$encoding="application/x-tex">p_{world} = R\cdot g_{eye}+t </annotation></semantics></math>$

其中：

(R)：标定旋转矩阵；
(t)：平移向量。

这样，系统可以把“用户正在看哪里”转化为可用于任务理解的空间信息。

需要说明的是，论文主要介绍了眼动模块的实现方法，并未提供复杂的语音—眼动联合消歧实验。

12. RabbitMQ：连接任务理解与远程执行

RTSP 适合连续音视频流，但不适合负责可靠任务调度。

因此，论文使用 RabbitMQ 传输：

任务命令；
眼动坐标；
时间戳；
JSON 数据；
结果消息。

12.1 Topic-Based Routing

系统根据任务类型把消息发送到不同执行主机。

例如：

navigation.* → 地图或浏览器主机
ur10.*       → 技术支持服务
display.*    → AI眼镜显示端
file.*       → 文件系统执行器
app.*        → 应用启动执行器

这种方式使 Agent 02 不需要知道每台主机的内部实现，只需向正确 Topic 发送任务。

12.2 消息持久化

当网络短暂中断时，RabbitMQ 可以保存尚未完成的消息，恢复连接后继续投递。

这比直接使用临时 HTTP 请求更加适合分布式任务执行。

12.3 命令处理与执行解耦

Agent 02 只负责生成任务，具体执行由远程 Host 完成。

这样可以避免：

LLM 阻塞等待执行；
某个主机失败导致整个系统崩溃；
所有工具必须部署在同一台设备上。

13. 分布式任务调度

论文使用优先队列管理任务。

任务优先级随着等待时间进行动态变化：

$encoding="application/x-tex">Priority(T_i) = \frac{ U_i\cdot e^{-\alpha(t_{current}-t_{arrival})} } {D_i} </annotation></semantics></math>$

其中：

(U_i)：任务初始效用；
(t_{arrival})：任务到达时间；
(D_i)：任务衰减因子；
(\alpha)：防止任务饥饿的参数。

调度过程可以概括为：

初始化优先队列
      ↓
选择最高优先级任务
      ↓
检查执行资源
  ┌───┴────┐
资源可用   资源不足
  ↓          ↓
执行任务    等待资源
  ↓
更新资源状态

Task Executor 支持：

Windows；
macOS；
Linux。

任务类型包括：

浏览器控制；
应用启动；
文件系统操作；
信息显示；
地图导航；
技术文档展示。

14. 端到端案例一：地图导航

用户发出语音：

“I want to go to NCHC.”

系统执行过程为：

用户语音
   ↓
Agent 01：Whisper.cpp转写
   ↓
Agent 02：识别Navigation Intent
   ↓
生成Google Maps URL与显示任务
   ↓
RabbitMQ发送Map Request
   ↓
AI眼镜接收并显示地图

论文展示了：

Chatbot 端生成地图请求消息；
AI 眼镜端显示国家网格中心的位置与地图信息。

这个案例证明系统能够把自然语言转换为跨网络可执行任务。

15. 端到端案例二：UR10 机械臂故障诊断

用户提出 UR10 机械臂故障查询后，系统执行：

用户问题
   ↓
Agent 01转写
   ↓
Agent 02识别技术支持意图
   ↓
RAG检索UR10技术文档
   ↓
LLM生成结构化故障诊断
   ↓
RabbitMQ发送显示任务
   ↓
AI眼镜展示中文维修建议

论文中的 AI 眼镜界面显示了：

故障诊断；
检查流程；
维修建议；
结构化技术信息。

与普通聊天机器人相比，这个案例更加贴近工业现场：

一线工作人员不需要放下工具去查看电脑，而是可以直接在眼镜中看到维修指导。

16. 实验结果：论文验证了什么

论文主要进行了功能验证，而不是严格的定量模型评测。

16.1 系统实现

论文报告所有主要模块已经成功运行：

双智能体；
RTSP 流媒体；
Whisper.cpp；
本地 LLM；
RAG；
MCP；
RabbitMQ；
眼动模块；
远程执行器。

16.2 多语言处理

系统能够处理中文和英文命令。

16.3 跨平台执行

执行器可以在 Windows、macOS 和 Linux 上完成：

浏览器控制；
应用启动；
文件操作；
信息显示。

16.4 网络验证

系统支持：

不同网络配置；
自动连接检测；
网络中断重连；
消息持久化；
RTSP 和 RabbitMQ 协同运行。

17. 如何客观看待论文实验

这篇论文证明了：

多个成熟组件可以被组合成一个真实可运行的 AI 眼镜闭环。

但是，论文没有充分报告以下指标：

ASR 准确率；
不同噪声环境下的识别效果；
平均端到端响应时间；
RTSP 传输延迟；
RabbitMQ 吞吐量；
RAG 检索命中率；
意图识别准确率；
眼动定位误差；
功耗与续航时间；
长期稳定性；
用户体验评估。

因此，不能将“功能成功展示”直接理解为“性能已经达到商业部署标准”。

更加准确的评价是：

论文完成了系统可行性验证，但缺少系统级定量性能验证。

18. 论文的主要贡献

18.1 双智能体职责拆分

将实时 ASR 与智能任务处理分离，降低资源竞争，并提升模块化程度。

18.2 本地 LLM、RAG 与 MCP 组合

系统不仅能生成文本，还能够访问技术文档和外部工具。

18.3 RTSP 与 RabbitMQ 分工

RTSP 负责持续音视频；
RabbitMQ 负责可靠任务消息。

18.4 跨网络与跨平台执行

支持局域网、端口转发、VPN，以及 Windows、macOS 和 Linux。

18.5 眼动数据集成

为未来语音、视线和手势联合交互提供基础。

18.6 完整系统闭环

从用户语音输入，到任务理解、知识检索、远程执行，再到眼镜显示，形成了端到端链路。

19. 论文的局限性

19.1 网络依赖

分布式执行需要稳定网络。

断网或高延迟会直接影响：

ASR 数据传输；
LLM 调用；
RAG 检索；
远程任务执行；
结果显示。

19.2 累积延迟

系统采用顺序处理链：

音频采集
→ ASR
→ 意图识别
→ RAG / MCP
→ 消息发送
→ 远程执行
→ 结果返回

每一步都可能增加延迟。

论文指出，该架构可能难以满足要求低于 200 ms 响应时间的场景。

19.3 电池压力

持续运行以下模块会增加功耗：

摄像头；
麦克风；
眼动传感器；
网络传输；
AR 显示；
本地计算。

19.4 隐私风险

语音和视频跨网络传输可能包含：

用户对话；
企业设备信息；
内部技术文档；
地理位置；
眼动数据。

因此需要更强的加密、访问控制和本地处理。

19.5 实验量化不足

论文没有给出足够的准确率、延迟、吞吐、功耗和用户研究数据。

20. 未来研究方向

20.1 边缘计算

将部分 ASR、RAG 或小型 LLM 部署到边缘节点，减少网络往返。

20.2 隐私保护

可以进一步采用：

端到端加密；
本地语音处理；
敏感信息脱敏；
联邦学习；
数据最小化保存。

20.3 动态模型切换

根据任务复杂度选择不同模型：

简单命令 → 小模型 / 规则
复杂推理 → 大模型

从而降低功耗和延迟。

20.4 语音、眼动与手势融合

未来系统可以同时结合：

用户说了什么；
用户看向哪里；
用户手指向哪里。

这将减少“这个”“那里”等指代歧义。

20.5 5G 与边缘基础设施

5G 和边缘计算可以进一步降低延迟，为更加复杂的实时多模态任务提供算力。

21. 与单体 AI 助手相比，这套架构有什么不同

单体 AI 助手往往试图让一个模型完成：

听；
理解；
检索；
调工具；
执行。

而论文采用模块化方式：

Whisper.cpp：听懂
LLM：理解
RAG：补充知识
MCP：接入工具
RTSP：传输流媒体
RabbitMQ：可靠发送任务
Remote Host：真正执行
Eye Tracking：提供视线上下文

这种设计更接近企业软件系统，而不是一个孤立的大模型 Demo。

它的优势是：

各模块可替换；
故障边界清晰；
工具易扩展；
适合跨设备部署；
更容易进行权限控制。

但代价是：

系统复杂度更高；
部署与运维成本增加；
多阶段链路产生累积延迟。

22. 总结

这篇论文提出了一套基于双智能体架构的 AI 眼镜系统。

其核心流程为：

AI眼镜采集语音、视频和眼动
        ↓
Agent 01 使用 Whisper.cpp 完成实时ASR
        ↓
Agent 02 使用本地LLM理解任务
        ↓
RAG提供知识，MCP提供工具
        ↓
RabbitMQ将任务路由到远程主机
        ↓
Windows / macOS / Linux执行任务
        ↓
结果返回AI眼镜显示

论文的价值不在于某一个模块取得了算法突破，而在于将多个成熟技术组合成了一个完整的可运行系统。

它证明了 AI 眼镜可以不再只是“显示屏”，而是成为连接用户、AI 模型、知识库、工具和企业计算资源的轻量入口。

不过，这仍然是一套原型系统。未来要进入真实生产环境，还需要进一步解决：

端到端延迟；
识别准确率；
网络稳定性；
隐私安全；
电池续航；
用户体验；
长期运行可靠性。