AnovaX：一个本地多代理语音助手，具备LLM规划、类型化执行器和自适应恢复

# 一个本地化、多智能体语音助手：基于LLM规划、类型化执行器与自适应恢复机制
来源：https://arxiv.org/html/2607.15367

###### 摘要

桌面语音助手目前仍由云端管道主导，这些管道将原始音频传出机器，并暴露一组固定的技能集。本文介绍AnovaX，一个完全运行在用户计算机上的轻量级本地优先助手，它将桌面本身作为其操作界面。单个Python进程将唤醒词门控、语音管道、LLM规划器（Gemini，输出JSON格式的工具调用计划）、基于白名单和黑名单的安全层、多智能体编排器（将每个计划翻译为带类型约束的子智能体，运行在有限线程池上），以及自适应恢复循环（当核心步骤失败时接管）串联在一起。每个工具对应一个专门的智能体类（AppAgent、TypingAgent、BrowserAgent 及其他六个），具有各自的超时、重试策略和共享资源锁。一个递归的 MetaAgent 让规划器可以将子目标委托回自身，嵌套层级上限为两层。恢复循环使用精简的 ReAct 风格提示，并通过投机执行只读工具来隐藏 Gemini 的延迟。配套的 Flask 服务器通过本地 WiFi 暴露手机友好的远程接口，实时将每个智能体的生命周期事件镜像到手机，并通过 MJPEG 流式传输笔记本电脑屏幕，使用户可以实时查看远程命令的执行过程。该项目的重点不在于与 Siri 或 Alexa 竞争，而是展示一个清晰可读、仅有几千行代码的助手足以完成打开应用、在应用中输入、执行搜索、协调并发动作、从单步故障中恢复，并且完全由另一个房间的手机驱动——整个过程无需 LLM 触碰键盘。

## 1 引言

关于桌面语音助手的有趣问题，在2025年或2026年，已不再是“语言模型能否理解我说的话”。这个问题早已解决。有趣的问题是：助手能否在用户面前的机器上*行动*，并且执行行动的那些组件是否足够简单，让普通人能够阅读、修复并信任它们。大多数广泛使用的助手——Siri、Alexa、Google Assistant、Copilot——并未直接回应这个问题。它们在云端运行，将桌面视为应用商店而非画布，用户既无法看到离开麦克风的转录文本，也无法看到产生回复的推理过程。对于消费级产品来说，这是一个合理的工程权衡，但对于希望同时获得三个特定属性的人来说，这留下了空白：(i) 音频和个人信息保留在机器上，除非用户选择分享；(ii) 助手可以打开真实桌面应用、在其中输入并按下热键，而不仅仅是回答常识问题；(iii) LLM 请求的每一次工具调用在运行前都是可检查、可列入白名单并可拒绝的。

我们构建 AnovaX 正是为了填补这一空白。其早期版本是一个线性执行器：LLM 生成计划，Python 函数逐步执行该计划，仅此而已。代码易于阅读，但有一个特定的脆弱之处——卡住的步骤会阻塞计划的其余部分，并且无法并行化独立操作或从单一故障中恢复。本文描述了当前版本，该版本用一个小型多智能体编排器取代了线性执行器。计划模式中的每个工具现在都由一个带类型的子智能体类支持，具有各自的超时、重试策略和共享资源锁集。计划仍来自单次 LLM 调用，但由 Python 父进程调度、批处理并监督，该父进程从不将键盘控制权交给模型。

该版本还增加了一条自适应执行路径。当静态计划遇到核心故障时，一个自主循环接管：一个精简的 ReAct 风格提示要求 Gemini 提供下一批操作，进行安全检查，然后将其交回同一编排器，迭代直到目标达成或少量预算耗尽。该循环通过投机并行性隐藏 Gemini 的延迟，在规划器仍在决定下一步时要做什么时，预运行只读工具。

该设计故意借用了多智能体文献中的术语——子智能体、编排器、生命周期事件、并行批次——但没有采用其规模。AnovaX 是一个小规模系统，大约 1,800 行 Python 代码和一个 HTML 文件，我们更关心可读性，而非从基准测试中榨取另一个百分点。

#### 贡献。
这是一个系统描述，而非基准测试论文。简而言之：
- • 一个本地化、由 LLM 规划的桌面语音智能体，其执行器为小型多智能体编排器。计划模式中的十个工具每个都映射到一个带类型的子智能体类，具有各自的 TTL、重试策略和共享资源锁。编排器可以根据计划需要生成任意数量的子智能体；作为项目特定阈值，并发度上限为八个工作线程。
- • 一个两阶段安全过滤器——提示级别规则加上 Python 白名单和黑名单——在生成任何子智能体之前，对每个计划（包括递归生成的子计划）运行。
- • 一个基于批处理 ReAct 并带有*投机并行性*的自适应恢复层：当核心步骤失败时，自主循环接管，计划中剩余的只读工具在后台预运行，同时规划器决定下一批操作。
- • 一个三层内存和生命周期事件总线，将每个智能体状态转换镜像到 UI、磁盘上的 JSONL 日志以及移动远程端——后者还通过 MJPEG 将笔记本电脑屏幕流式传输回手机。

第 4 节的评估是定性的。第 5 节记录了当前的局限性和已知故障模式。

## 2 相关工作

#### 商业语音助手。
Siri、Alexa、Google Assistant 和 Cortana 都将唤醒词与云端托管的意图解析器及固定技能目录配对。它们的范围已逐渐向 LLM 驱动的响应扩展（Gemini Team, Google, 2023 (https://arxiv.org/html/2607.15367#bib.bib8)），但操作面仍然狭窄且封闭。用户无法在二十行代码内添加新技能，音频也不是本地的。AnovaX 在这两个选择上都站在相反的一边。

#### 使用工具的 LLM 智能体。
近期有大量文献围绕将 LLM 封装在一个让其调用工具的循环中：ReAct（Yao 等, 2023 (https://arxiv.org/html/2607.15367#bib.bib1)）将推理痕迹与工具调用交织在一起；HuggingGPT（Shen 等, 2023 (https://arxiv.org/html/2607.15367#bib.bib2)）路由到任务特定模型；AutoGen（Wu 等, 2024 (https://arxiv.org/html/2607.15367#bib.bib3)）组合多个 LLM 智能体；Voyager（Wang 等, 2023 (https://arxiv.org/html/2607.15367#bib.bib4)）在 Minecraft 中展示了类似的计划与行动模式；EvoAgent（Yuan 等, 2024 (https://arxiv.org/html/2607.15367#bib.bib9)）通过进化算子自动生成专门的子智能体。AnovaX 有选择地从这些文献中借鉴。默认路径并非 ReAct 循环——LLM 只规划一次，Python 编排器（而非模型）决定哪个带类型的子智能体处理哪个工具，哪些子智能体可以并行运行，以及哪些在其 TTL 之后应被终止。仅当核心步骤失败时，助手才回退到 ReAct 风格的循环（第 3.5 节），即使在那里，循环也是有界的（六轮，总共二十个智能体），并且每一批提议的操作都经过相同的安全过滤器。子智能体类本身是手写的且带类型，而非生成的。这是一个刻意的选择：在桌面规模下，控制代码应足够短以便审计，并且不应信任 LLM 来绕过其自身错误。

#### 桌面和网页 UI 自动化。
在网页智能体方面，WebGPT（Nakano 等, 2021 (https://arxiv.org/html/2607.15367#bib.bib5)）和 Mind2Web（Deng 等, 2023 (https://arxiv.org/html/2607.15367#bib.bib6)）展示了 LLM 驱动的浏览器控制；在手机方面，Android in the Wild（Rawles 等, 2023 (https://arxiv.org/html/2607.15367#bib.bib7)）发布了一个大型任务演示数据集。这些系统通常依赖 DOM 或无障碍树输入来闭合循环。AnovaX 是“盲”的：其类型化执行器通过 pyautogui 触发键盘和鼠标事件，从不检查屏幕。这是一个弱点（第 5 节），但也正是每个执行器保持在五十行以下的原因。

#### 本地化、隐私优先的助手。
开源项目如 Mycroft、Rhasspy 和 Leon 表明，完全本地的语音助手是可行的，尽管它们大多早于 LLM 规划浪潮，并使用手写的意图解析器。AnovaX 位于这些项目和更新的智能体文献之间：它保持本地优先的立场，但使用 LLM 作为意图解析器和规划器，并使用小型多智能体运行时作为执行器。

## 3 系统设计

图 1 (https://arxiv.org/html/2607.15367#S3.F1) 展示了整体架构。除了 Gemini 调用之外，所有内容都在用户机器上运行。即使是 Gemini 调用也是可选的——如果未设置 API 密钥，AnovaX 会回退到覆盖最常见命令的正则表达式意图解析器。

输入：\[麦克风/文本框\] → 唤醒门控 → memory.build_context()

静态路径（快速）：gemini_plan() → safety_check() → Orchestrator.dispatch() → {AppAgent, TypingAgent, BrowserAgent, MediaAgent, InfoAgent, TimingAgent, DialogAgent, MetaAgent} → 结果 {完成, 失败, 剩余}

恢复路径（自适应，仅当核心步骤失败时）：AutonomousLoop.run(goal, outcome)，最多 6 次迭代：
∥ Gemini 决定下一批操作 {思考, 动作, 完成}
∥ 投机性地将剩余计划中的只读工具预运行到缓存中
→ safety_check() → Orchestrator.dispatch() → 与缓存合并 → 循环直到完成或预算耗尽

输出：pyautogui / webbrowser / subprocess → pyttsx3 (TTS) → orb + 实时智能体状态指示器

可观测性与移动端：每个 AGENT_* 生命周期事件 → JSONL 日志 + SSE 流传输到手机；另一个端点通过 MJPEG 将桌面屏幕流传输回手机。

图 1：语音请求通过 AnovaX 的端到端路径。两条执行路径共享相同的安全过滤器和相同的编排器：快速静态路径（LLM 仅规划一次）和自适应恢复路径（仅当核心步骤失败时启用，并通过投机执行只读工具隐藏 Gemini 的延迟）。Gemini 调用是唯一离开机器的步骤，并且可以禁用——正则表达式回退覆盖常见命令。

### 3.1 唤醒词门控与语音输入

唤醒门控的逻辑被有意保持最小化。后台线程通过 SpeechRecognition 库运行 Google 的免费语音识别端点，仅当短语包含 *anova* 以及一小部分触发词之一（*wake up, hey, hello, hi, yo*）时才做出反应。在休眠期间，所有其他话语均被丢弃。这比看上去更重要：房间内的环境噪音不会意外触发操作，并且模型永远不会被要求规划用户未对其说话的内容。一旦唤醒，每个识别到的短语都被路由到单个 on_speech(text) 入口点。在 UI 框中输入的文本进入同一函数，因此桌面和移动输入在规划开始前汇聚。当麦克风不存在（无 PyAudio、无音频设备的 VM）时，这也很有用；AnovaX 仍然可以运行，只是需要文本输入。

### 3.2 计划模式

LLM 看到的系统提示将回复限制为固定的 JSON 格式：
{"steps":[{"tool":"","params":{...}}, ...], "final_response":"", "remember":{"":""} }

工具集被故意保持简短：九个具体动作工具（open_app, type_text, press_keys, web_search, youtube_search, screenshot, get_time, get_date, wait, speak）和一个递归委托工具（plan_subtask），它将自然语言的子目标交回给规划器。任何更丰富的操作——读取当前窗口标题、检查文件、运行 shell 命令——都不在模式中。添加新工具需要编辑三个地方（系统提示、白名单以及 agents.py 中的执行器映射），我们希望这种成本保持可见。

工具进一步分为两个运行时类别。screenshot, get_time, get_date 和 wait 被标记为*可选*：如果其中一个失败，编排器会记录缺失并继续执行。其他所有工具都是*核心*：失败会停止静态计划并将控制权交给第 3.5 节描述的自适应恢复循环。这种区分很重要，因为可选失败通常是无害的（无法保存的截图、锁定屏幕上的时钟读取），不应破坏复合请求的其余部分。

提示还要求规划器在任何 open_app 和随后的 type_text 之间插入 {"tool":"wait","params":{"seconds":1.5}}。这纯粹是一个竞争条件补丁：在冷启动的机器上，Notepad 获得焦点所需的时间明显长于 pyautogui.write() 触发的时间，如果没有等待，文本将输入到之前拥有焦点的任何窗口中。多智能体运行时已通过锁缩小了这一窗口（第 3.4 节），但提示级别的防护仍然保留。

### 3.3 安全：两个独立过滤器

LLM 和操作系统之间有两个部件。第一个位于系统提示内部：一个简短、明确的列表，指示规划器永远不要生成这些动作（删除、格式化、终止、编辑注册表、泄露机密等）。这是一个软过滤器，我们不单独依赖它。第二个是 Python 函数 safety_check()，它对 LLM 返回的每个计划运行——包括由 MetaAgent 生成的每个子计划。它强制执行三个属性：

1. 1. 工具白名单。任何步骤的 tool 字段不在十一个项目的 ALLOWED_TOOLS 集合中，则整个计划被拒绝。
2. 2. 关键词黑名单，同时针对原始用户文本和每个字符串值参数。黑名单涵盖大约三十个模式，涉及文件破坏（rm -rf, format c:）、凭据访问（password, keychain）、权限提升（sudo, runas）以及操作系统级别状态更改（netsh, diskpart, regedit）。任何命中都会拒绝计划。
3. 3. 有界计划大小。每个计划最多八个步骤；每个 wait 最多五秒；plan_subtask 嵌套最多两级；每个用户命令总共最多分派二十个子智能体。

如果计划未通过任何检查，则不会生成任何子智能体，用户会听到一句简单的拒绝。由于同一过滤器在每个递归子计划上重新运行，因此逃逸第一级提示的越狱仍然必须在返回时第二次逃逸白名单。

### 3.4 多智能体编排器

本版本的核心是编排器。当 safety_check() 通过后，计划被交给 Orchestrator.dispatch()，该函数按顺序执行四件事：持久化任何 remember 事实、将步骤列表拆分为顺序批次、为每个步骤生成一个带类型的子智能体，以及在每个批次完成后说出最终回复。编排器本身不决定一个计划可以产生多少子智能体——该数字由 LLM 的计划决定，仅受安全过滤器每计划步骤上限和每个命令的智能体预算约束。*受限的*是并发性：在当前构建中，我们最多同时运行八个子智能体，因为八是我们仍然可以通过肉眼追踪它们之间交互的规模。一个包含三个工具调用的计划生成三个智能体；一个包含二十个工具调用的计划生成所需数量的智能体，但最多同时运行八个。这两个数字都是项目特定阈值，而非架构限制。模式中的每个工具