灵枢 Agent Mesh：如何依赖 MCU 做一个可靠的 Agent？

项目定位：ESPAgent 是一个把 LLM Agent Runtime 直接落到 MCU 上的项目——让设备自己具备理解任务、调用工具、请求权限、结构化返回结果、跨节点协作的能力。整套核心控制链路最终跑在成本不足百元的 ESP32-S3 上。

灵枢 Agent Mesh 节点终端

灵枢 Agent Mesh 可视化界面

发展脉络

本项目基本完全由我个人设计，鉴于开源资料少之又少，本项目的设计过程也历经了三个阶段：

  • 单板 Agent：一块 ESP32-S3，把硬件能力封装成工具交给 LLM 选择——LLM 返回结构化 tool call，固件执行 GPIO、舵机、传感器读取等真实驱动。Skills 放 SPIFFS，用 cache 减少重复构建上下文，飞书长连接接入。
  • 四板 Mesh：四块 ESP32-S3 按职责拆成 Coordinator（理解调度）/ Sensor（感知）/ Control（执行）/ Guardian（权限审计），补上 OutputMessage 闭环与 Guardian policy gate。
  • 系统化：四角色稳定下来，Guardian 从布尔判断走向风险评分与审计，ESP32-P4 显示终端接入，manifest + Lua 两层受控动态扩展，benchmark 开始回归验证。

技术栈

ESP-IDF · FreeRTOS · MQTT Mesh · ReAct / Tool Calling · subagent · Lua · LVGL · SPIFFS · React + TypeScript · ESP32-P4/C6 · Raspberry Pi

核心难点

跨节点闭环：从「发指令」到「知道结果」

这里的关键结构是结构化 OutputMessage（espagent.output.v1），它携带 node_id / command_id / trace_id / status / result，让 Coordinator 能按 command_id 等待同一命令的远端结果，再让 LLM 总结——从「推理 → 下发」变成「推理 → 下发 → 等结果 → 再推理 → 回复」。

安全边界

当 AI 开始控制硬件，安全比显示更早成为主问题。第四角色从「显示」改成了 Guardian：Coordinator 下发 mesh 命令前必须先过 policy_check → policy_decision，Control 本地还会二次校验，关键事件生成 audit，并维护 StateBoard 与 watchdog。安全问题，我们不能只是在 prompt 里面一再强调，LLM 毕竟是一个 Black Box ，任何一款实际的产品都不能寄希望于模型本身有多么“聪明”。

受控动态扩展

如果每接一个新硬件都要重写 C、重新编译、重新烧录，对于我们的后台架构还是太死板了。本项目落地的扩展分两层：**manifest primitive ** 基于通信协议完成的（结构化 JSON 描述设备通信方式、参数、权限边界，固件校验 version / permissions / SHA-256）和 Lua runtime（lua_run_source 等，但脚本必须走 espagent.call_capability → capability/tool registry → sandbox → Guardian → 硬件）。

创新点

把原本只在 PC / 云端 / 代码 Agent 上常见的概念，迁移到了 MCU 边缘系统：ReAct、tool calling、subagent、OutputMessage、sandbox、policy gate、audit、dynamic extension、benchmark、timeline visualization。这些能力一旦在边缘端建立起稳定边界，我想打造的不仅是一个只能娱乐的聊天机器人，也不是只能做一些简单任务的小demo，我希望依赖这一套Agent理念，能够做到真实地参与到一些产品使用场景中。

对 Agent 架构的认识

  • 闭环比功能多重要：硬件 Agent 最怕的不是功能少，而是不知道发生了什么。policy_check / policy_decision / OutputMessage / timeline / StateBoard 这些结构，本质是让系统做到可追踪、可回归、可扩展三大特性。
  • 安全是有层级的：prompt 约束是最弱的一层，真正的边界要靠固件路径强制（Guardian gate + Control 本地二次校验 + audit）。