IR + VM：让 LLM 生成的控制逻辑安全运行在超低端 MCU 上

目前进度

关于这套系统我写了一篇论文，已经进入 CCF B 类期刊大修阶段。

我目前大三，专业是软件工程，之前主要学习 Java 后端和 Agent 相关方向。

我一直觉得嵌入式开发太麻烦了------每次都要重新烧录。所以我想让 MCU 也拥有类似 JVM 的执行层：程序不直接绑定硬件，而是运行在一个小型虚拟机上。

这样上层只需要生成逻辑，底层负责执行。

我的想法是，在 LLM 和 MCU 之间增加一个中间层，把上层逻辑和底层硬件解耦。整个系统分为三部分：

整体流程：

IR 让模型生成结构化逻辑。例如：

bash 复制代码

task water_pump {
    require cap(relay1)
    require cap(water_sensor)
    set relay1 = 1
    wait 500ms
    read water_sensor
    halt
}

这段代码表达的是任务逻辑。编译器随后将它转换成 14 字节左右的机器指令。模型负责描述，编译器负责保证正确。

让模型控制物理设备，最大的风险是错误可能直接作用于现实世界。比如系统里只有 relay1，但是模型生成：

ini 复制代码

set relay3 = 1

如果 relay3 对应一个真实设备，可能造成严重问题。

所以 VM 增加了三层限制。

14 条核心指令已证明------任意输入下必然停机，且仅访问授权资源。

核心原则： 无论 LLM 生成什么，VM 保证程序必然终止，且只能操作被明确授权的设备。

适用场景： 计算资源极其受限、但需要被 LLM 动态控制的物理设备------灌溉系统、工业现场、智能家居里的廉价单片机。

以下是编译器把 6 行LIR 压成 14 字节字节码，VM逐指令 trace：每步的PC、栈状态、步数计数器、已授权设备集合全部可见，7步HALT。

以下是手工构造一段绕过编译器的恶意字节码：只授权了relay1，却在 pc=2 试图写relay2。VM在写操作到达驱动前拦截，EXEC_FAULT_UNAUTHORIZED_IO，relay状态未被改变。

现在很多系统已经可以让模型生成代码。但当代码开始控制真实设备时，中间还需要更多工程约束。

如何让一个生成式系统输出的逻辑，经过一套可验证的流程，最终安全运行在资源非常有限的设备上------这是一个比较窄但是有价值的问题。

目前我的系统跑通了，但是学术是学术，在实验室里跑通不代表有工业价值。我觉得距离真正工业部署还有很多问题，例如：

也想请教一下有实际部署经验的朋友：目前工业现场或者 IoT 场景里，如果需要让 LLM 参与设备控制，工程上通常采用什么架构？在类似「LLM 生成逻辑 → 中间约束 → 设备执行」这一套流程里有哪些成熟实践？

如果有团队或者企业正在探索类似方向（系统软件、IoT 安全、LLM+嵌入式），也非常希望有机会参与实际工程实践。