面向边缘嵌入式AI代理系统的模块化架构

# 面向边缘嵌入式代理系统的模块化架构
来源：https://arxiv.org/html/2606.02862
###### 摘要

大语言模型（LLMs）的兴起使得具备复杂推理和工具使用能力的智能代理 AI 成为可能；然而，在普适计算环境中部署这种自主性仍面临挑战，因为嵌入式微控制器具有严格的内存和能量限制。现有框架通常假设服务器级资源或持续连接，从而在深度嵌入式系统领域留下空白。本文提出了一种面向嵌入式代理系统的模块化参考架构，它弥合了确定性实时控制与智能代理之间的鸿沟。

我们引入了一种分层设计，将**设备端代理**（执行高度压缩的神经网络和基于规则的逻辑，用于低延迟、隐私关键型任务）与**云端增强代理**（利用小语言模型（SLMs）进行更高级别的推理和规划）解耦。一个关键贡献是集成了一个横切**治理层**，确保跨自主设备分布式集群的可观测性、策略执行和安全性。本文不提供纯经验性基准，而是分析关于延迟、能量和在资源受限环境中可靠执行的架构设计原则和权衡。

## I. 引言

由大语言模型（LLMs）和编排框架驱动的智能代理 AI 系统已在推理、规划和自动化复杂工作流方面展现出卓越能力[17, 18]。然而，此类系统的部署主要局限于云环境或高性能数据中心，这些地方拥有充足的内存、计算能力和能量。与此形成鲜明对比的是，物理世界中的普适计算主要由深度嵌入式设备——微控制器（MCU）、传感器节点和低功耗执行器——主导，这些设备在严格的资源约束和通常恶劣的连接条件下运行。

目前，这两个领域之间存在脱节。经典的嵌入式开发优先考虑确定性控制循环、静态固件和硬实时保证。而现代智能代理 AI 则假设动态上下文、充足的历史内存和灵活的工具使用。弥合这一差距并非易事：尽管当前硬件趋势令人鼓舞，但由于“内存墙”[3, 7]，在标准微控制器上运行一个功能完备的推理代理在技术上仍不可行。

为了解决这一问题，我们主张基于硬件层级采用差异化方法。虽然强大的**边缘设备**（例如，网关、MPU）越来越有能力托管量化的小语言模型（SLMs[5]）以进行本地自主推理，但**深度嵌入式 MCU** 缺乏此类模型所需的资源。因此，对于最低层级的设备，目前实现“代理”行为最可行的途径是作为**云代理**的智能接口，或者执行高度优化、非生成式的 TinyML 模型[7, 16]。

本文提出了一种统一这些异构部署模式的模块化架构。我们提出了一个框架，其中“代理”的定义会根据底层硬件进行调整：范围从边缘网关上完全自主的设备端代理，到微控制器上云端绑定的传感器代理。这种灵活性允许系统设计者动态平衡延迟、隐私和推理深度。

具体而言，本文做出以下贡献：

- 我们分析了嵌入式代理的硬件特定约束，区分了支持 SLM 的边缘设备和基于 MCU 的云接口。
- 我们提出了一个**模块化嵌入式代理架构**，将**执行层**（本地 vs. 云）与逻辑代理定义解耦，从而允许混合部署策略。
- 我们引入了一个横切**治理层**，作为管理分布式半自主代理集群的强制性组件，解决可观测性和安全问题。
- 我们提供了三个应用领域（智能农业、预测性维护、智能家居）的概念性权衡评估，说明了本地 SLM 在哪些情况下提供价值，以及云卸载在哪些情况下更优。

本文的其余部分组织如下。第二节回顾了 SLM 和 TinyML 的最新技术现状。第三节详细介绍了统一架构。第四节描述了功能核心模块。第五节分析了概念性权衡，第六节总结全文。

## II. 技术现状

受限设备上 AI 的格局正在迅速演变。为了给所提出的架构提供背景，有必要区分基于微处理器的网关（MPU）上的**边缘 AI** 和深度嵌入式微控制器（MCU）上的 **TinyML**。

### II-A. 边缘网关上的小语言模型

对于拥有 GB 级 RAM 的边缘设备（例如，Raspberry Pi 5、NVIDIA Jetson 或工业网关），执行**小语言模型（SLMs）** 已成为可行[7, 16]。像 TinyLlama (1.1B)、Phi-3 或 Qwen-1.5B[19, 1] 这样的模型旨在平衡推理能力与减少的参数数量[9]。通过 4-bit 量化和内核优化（例如，通过 `llama.cpp` 或 ONNX Runtime）[7, 16]，这些模型可以在本地以可接受的令牌生成速率运行[8]。在我们的架构中，这些设备作为完全自主的**设备端代理**的主机，能够在没有云连接的情况下进行本地思维链推理。

### II-B. 微控制器上的 TinyML 与智能

相比之下，深度嵌入式 MCU（例如，ESP32、STM32、Cortex-M）通常在严格受限的 RAM（SRAM < 512KB）和 Flash 存储下运行。由于“内存墙”，在此类硬件上运行数十亿参数的模型目前不可行。相反，该层级的智能依赖于 **TinyML**：使用如 TensorFlow Lite for Microcontrollers (TFLM)[7, 16] 等框架，用于分类、异常检测或关键词识别的、高度压缩的专用神经网络。虽然最近的研究探索了用于 MCU 的“皮秒级”生成模型（< 1000 万参数），但其推理能力仍然有限。因此，对于复杂的代理任务，MCU 最适合用作智能接口，预处理传感器数据并将高级推理委托给**云代理**。除了纯推理之外，最近的工作开始探索在这些约束下的设备端训练和自适应。这包括使用数据集蒸馏和模型大小自适应在微控制器上进行持续学习和增量学习[14]，通过动态稀疏性降低设备端训练成本的自适应稀疏反向传播方案[13]，以及基于 Grad-CAM 的流数据优先级排序，有选择地仅保留最有信息量的样本用于本地训练[12]。这些方法与本文的架构视角是互补的：虽然它们优化了学习算法本身，但我们这里的重点是托管这些支持学习的代理所需的系统架构。

### II-C. 嵌入式代理架构

传统的多代理框架（例如，JADE[6]）对于嵌入式部署来说过于重量级。最近的努力如 micro-ROS 将机器人中间件适配到 MCU，利用实时操作系统（RTOS）和基于 DDS 的通信，在受限硬件上实现类似节点行为[11]。然而，micro-ROS 主要关注确定性控制和消息传递，而不是现代 AI 中看到的、由 LLM 驱动的“代理”循环（计划-行动-观察）。我们的工作旨在通过定义一个既支持确定性控制（通过 RTOS）又支持语义推理（通过 SLM 或云）的架构来填补这一空白。

### II-D. 工具集成与通信

现代代理系统依赖于动态工具使用。虽然云代理使用基于 JSON 的 API 或模型上下文协议（MCP[2]），但嵌入式设备通常通过轻量级遥测协议（如 MQTT 或 CoAP[4, 15]）进行通信。核心挑战在于桥接这两个世界：将 LLM/SLM 冗长、文本密集的工具调用映射到电池供电 MCU 所需的二进制或紧凑有效载荷格式。现有解决方案通常依赖于僵化的网关；我们的架构提出了一个更灵活的 **代理交互接口** 来标准化这种转换。

见说明图 1：展示边缘执行环境的参考架构。根据硬件类别，“代理核心”要么运行本地 SLM（网关），要么委托给外部云代理（MCU）。

## III. 模块化嵌入式代理架构

所提出的架构旨在通过为资源受限设备提供一个模块化框架，来弥合经典嵌入式开发与现代智能代理 AI 之间的差距。其设计遵循 **可组合性** 原则，即功能模块可以根据部署上下文和硬件限制进行组合。

为了应对从微控制器到边缘网关的硬件范围，我们区分了两种主要的部署变体（“风格”）：(i) 完全本地的**自主设备端代理**，以及 (ii) **云端绑定代理**，其中嵌入式系统充当智能接口，而智能被卸载。

### III-A. 嵌入式代理的需求

普适环境中的嵌入式代理面临一组与纯云代理完全不同的约束和目标。根据 TinyML、物联网系统和边缘 AI 的文献，以及基于微控制器部署的实践经验，我们推导出以下需求：

- **低且可预测的延迟。** 许多目标应用（例如，控制循环、安全反应、语音命令）需要毫秒级的响应时间和确定性行为。架构必须允许本地感知-行动循环，而不会因网络或过载后端引入不可预测的延迟。
- **能效。** 嵌入式代理通常运行在电池供电或能量收集设备上。本地计算和通信都必须是能量感知的，倾向于轻量级模型、占空比感应和最小化的上行/下行流量。
- **严格的内存和计算预算。** 微控制器通常只提供几十 KB 的 RAM 和几 MB 的 Flash。架构必须允许紧凑的模型表示、静态分配策略和精简的运行时，使其能够适应这些限制，同时仍能提供有用的代理行为。
- **对有限连接的鲁棒性。** 边缘环境中的连接通常是间歇性、有损或昂贵的。嵌入式代理在断开连接时必须保持功能，具有优雅降级和本地备份，同时在链路可用时机会性地利用云。
- **隐私与安全。** 传感器数据可能是敏感的（例如，工业遥测、家庭信号）。架构必须支持尽可能地将数据保留在本地，在数据卸载时强制执行安全通信，并提供认证、授权和完整性保护的机制。
- **互操作性和可扩展性。** 边缘部署是异构的：设备、供应商和云提供商各不相同。架构应分离传输、代理交互和工具访问，以便不同的协议（例如，MQTT、CoAP、HTTP）和工具生态系统（例如，基于 MCP 的服务）可以集成，而无需重新设计代理核心。
- **可观测性与治理。** 在规模上，操作员需要能够洞察嵌入式代理集群，包括监控、日志记录、调试和策略执行。架构必须容纳一个横切治理层，而无需将重型管理逻辑嵌入到每个设备中。

### III-B. 高层参考架构

图 1 展示了所提出的参考架构。其核心是**边缘执行环境**，它托管输入处理、代理核心和输出处理。

该环境旨在根据可用硬件资源支持两种不同的配置或“风格”：

1. **自主网关代理（风格 A）：** 运行在能力较强的边缘硬件（MPU）上。它在本地执行 SLM，以获得最大限度的隐私和自主性。
2. **云端绑定 MCU 代理（风格 B）：** 运行在受限的微控制器上。它依赖云进行推理，但保留本地反射以确保安全。

无论何种风格，该架构都公开了一个**代理交互**接口，以允许通过类似 A2A 或 MCP 的协议进行协作，以及一个**数据传输**接口，用于安全的云同步。一个横切的**治理层**确保所有组件的可审计性。

### III-C. 风格 A：自主设备端代理

此变体在本地执行所有基本组件。它专为高端嵌入式平台（例如，边缘网关、MPU）设计，以提供独立于云连接的自主性和隐私。

**核心逻辑：** 代理集成了一个量化的**小语言模型（SLM）** 或一个压缩的神经网络。这些模型通过剪枝和量化进行优化，以适应设备的内存限制（通常 > 512 MB RAM）。除了 SLM 之外，代理还包含确定性的基于规则的逻辑、一个协调输入和输出的任务管理器，以及一个提供对嵌入式库（例如，信号处理、滤波）访问的本地工具层。

**关键特性：**

- **低延迟：** 感知-行动循环保持本地，避免网络往返。
- **离线能力：** 即使没有互联网访问，也保持完整功能。
- **隐私：** 敏感的原始数据从不离开设备。

**权衡：** 模型容量受限于板载内存。这些代理非常适合上下文感知自动化，但与云模型相比，可能在广泛的开放领域知识方面表现不佳。

### III-D. 风格 B：云端绑定代理（MCU）

在此变体中，嵌入式设备（例如，ESP32、STM32）主要充当智能接口。它捕获输入并使用轻量级协议（MQTT、CoAP）将其转发到云端点，从而减少本地计算负载。

**核心逻辑：** 设备端逻辑被最小化到信号调理、安全覆盖和通信处理。复杂的推理被卸载到云端的**协调器代理**，该代理编排专门的**子代理**和大语言模型（LLMs）。这允许使用强大的工具和超出任何微控制器容量的海量知识库。

**关键特性：**

- **可扩展性：** 智能可以集中升级，而无需重新烧录单个设备。