面向嵌入式与 IoT 系统开发的技能型 AI 智能体（Skilled AI Agents for Embedded and IoT Systems Development）

本文翻译整理自 arXiv:2603.19583（CC BY 4.0），原文作者为杜克大学团队。

摘要

大型语言模型（LLM）和智能体系统已展现出在自动化软件开发方面的潜力，但将它们应用于硬件在环（HIL）嵌入式及物联网（IoT）系统仍面临挑战，这源于软件逻辑与物理硬件行为之间的紧密耦合。成功编译的代码在实际设备部署时仍可能因时序约束、外设初始化要求或硬件特定行为而失败。为应对这一挑战，我们提出了一种基于技能的智能体框架用于 HIL 嵌入式开发，并引入了 IoT-SkillsBench——一个旨在系统评估 AI 智能体在真实嵌入式编程环境中表现的基准测试。IoT-SkillsBench 涵盖三个代表性嵌入式平台、23 种外设和 42 个任务（分为三个难度级别），每个任务均在三种智能体配置下进行评估（无技能、LLM 生成技能、人类专家技能），并通过真实硬件执行进行验证。在 378 次硬件验证实验中，我们证明简洁的人类专家技能配合结构化专业知识能够在各平台实现近乎完美的成功率。

1. 引言

大型语言模型（LLM）和智能体系统的最新进展已展现出在协助软件开发方面的潜力，包括自动化代码生成、调试以及复杂文档推理。这一能力激发了将基于 LLM 的智能体应用于硬件在环（HIL）嵌入式系统和物联网（IoT）应用开发的浓厚兴趣。然而，与在云端或本地环境中运行的纯软件智能体系统不同，为与真实物理硬件交互的嵌入式和 IoT 系统设计智能体框架引入了根本不同且显著更复杂的挑战。

挑战一：嵌入式生态系统高度碎片化

微控制器（MCU）依赖于多样化的厂商特定工具链和实时操作系统（RTOS）环境（如 ESP-IDF、Zephyr、AVR-Libc），外设交互跨越多种通信协议（如 I2C、SPI、UART、无线协议栈）。除异构性外，与物理硬件接口需要严格遵守底层约束，包括精确的时序、初始化顺序、中断处理和引脚复用。此外，嵌入式平台表现出硬件与软件的紧密耦合，智能体必须跨越硬件特定配置和软件行为进行导航，即使微小的配置不匹配也可能导致系统静默失败。

现有方法通过扩展智能体的内存（附加库文档或数据手册），或通过状态流图分析解决头文件/API 与其使用之间的冲突来缓解这一挑战。然而，它们大幅扩展了所需的上下文窗口，从而产生显著的 token 开销。

挑战二：编译成功 ≠ 运行正确

对于嵌入式系统而言，成功编译并烧录到设备并不能保证正确的运行时行为。因时序违规、外设配置错误或硬件特定边界情况，无错误的代码仍可能表现出意外行为。这种差距产生的原因是硬件行为无法通过纯软件验证技术完全或确定性验证。虽然存在 QEMU 和 Wokwi 等硬件仿真框架，但它们存在外设保真度有限、时序模型不完整以及对真实传感器-执行器交互支持不足的问题。因此，许多硬件故障无法在纯数字仿真环境中捕获。依赖编译器在环或烧录在环范式的现有工作仍存在局限，因为它们未能纳入物理执行过程中出现的行为错误。

本文贡献

为解决这些挑战，我们提出了面向嵌入式系统和 IoT 应用开发的基于技能的智能体框架。与将大量 SDK 文档或数据手册注入提示词不同，每个技能都将特定外设、MCU 或框架组合的必要编程模式、初始化约束和已知故障模式提炼为紧凑、可读的文档。这使智能体能够在受限且经过验证的知识集上进行推理，而非原始文档或 API，显著减少了 token 开销同时提高了可靠性。

基于技能的设计随嵌入式生态系统增长而自然扩展：支持新平台、外设或框架仅需编写相应技能，而智能体管道和评估框架保持不变。

为评估结构化硬件知识在智能体嵌入式开发中的作用，我们引入了 IoT-SkillsBench——一个涵盖多个 MCU 平台、开发框架和任务复杂度的 HIL 基准测试。IoT-SkillsBench 涵盖三个代表性平台-框架组合（ATmega2560+Arduino、ESP32-S3+ESP-IDF、nRF52840+Zephyr），包含 42 个任务，分为三个难度级别：基本外设控制、协议级通信（如 I2C、SPI）以及涉及中断和多设备协调的系统级集成。每个任务在三种智能体配置下评估：无技能、LLM 生成技能和人类专家技能，从而在原始 LLM 知识、自动合成知识和精心策划的领域专业知识之间进行受控比较。总计 378 个评估实例在各平台、任务和技能条件下通过真实硬件执行和行为测试进行验证。

主要发现

IoT-SkillsBench 的实验揭示了三个关键洞察：

1. 现代 LLM 在简单任务上表现良好，但在复杂任务上迅速下降。 在文档完善的平台（如 Arduino）的简单嵌入式任务上已表现良好，但随着任务需要协议级推理或系统集成，性能迅速下降。
2. LLM 生成技能效果不稳定，甚至可能降低性能。 通常强化错误的平台特定假设，同时显著增加 token 使用量。
3. 人类专家技能大幅提升可靠性。 在各平台和任务级别实现近乎完美的成功率，同时保持适度的 token 开销。

这些结果表明，智能体嵌入式开发的有效性不仅取决于是否提供技能，还取决于技能质量和对真实硬件行为的扎根程度，说明结构化、专家策划的硬件知识对于可靠的 HIL 软件生成仍然必不可少。

IoT-SkillsBench 已开源：https://github.com/iot-agent

2. IoT-SkillsBench：平台、任务与技能

2.1 嵌入式系统平台与外设

我们考虑三个平台-框架组合，每个平台指特定 MCU 开发板与其对应的嵌入式框架：

选择这些平台以覆盖不同 MCU 架构（AVR、Xtensa、ARM Cortex-M4）、HAL 范式（Arduino 风格抽象、裸机寄存器访问、RTOS 驱动）以及开发工具链生态系统。

我们考虑 23 种外设，涵盖从简单执行器和指示器到传感器的各种硬件接口：

这种外设多样性确保基准测试任务能够练习硬件-软件接口的深度。

2.2 嵌入式与 IoT 开发任务

我们精心构建了一个包含 42 个任务、分三个难度级别的基准测试：

• 级别 1（12 题）：基本外设控制，包括 GPIO 翻转、ADC 采样和 UART 通信
• 级别 2（16 题）：协议级通信，需要对 I2C、SPI 和 1-Wire 总线进行推理，包括正确的初始化序列和时序约束
• 级别 3（14 题）：系统集成，如中断驱动工作流、多传感器/执行器集成和任务调度

每个任务由以下要素定义：

1. 基于自然语言的任务描述（可选指定外设/传感器和需实现的逻辑）
2. 目标硬件平台和框架（如”nRF52840 + Zephyr”），以及所有连接外设的目标引脚分配

注意，不同平台的引脚引用约定不同（例如 ESP-IDF 使用数字 GPIO 编号，Zephyr 使用设备树别名），这些平台特定的引脚描述符已提供给智能体，确保其能直接生成可编译的代码而无需自行解析硬件映射。每个任务均已在物理硬件上人工验证，参考答案已确认可产生正确的 HIL 测试结果。

2.3 技能规范

我们构建了两组技能供智能体使用：

LLM 生成技能： 使用现代 LLM（Claude Sonnet 4.6）针对每个任务及其对应的平台-框架组合进行提示生成。要求 LLM 仅凭参数化知识总结相关的嵌入式编程知识，不访问数据手册、错误日志或外部文档。

人类专家技能： 由具有目标平台和外设实际操作经验的嵌入式系统专家精心编写。目标是产出覆盖多样化硬件平台和外设、同时保持紧凑、有针对性且对智能体直接可用的技能。

在技能编写过程中，人类专家获得了无技能时 LLM 生成的嵌入式代码、对应的编译器错误日志以及观察到的运行时行为，从而获得 LLM 生成嵌入式代码典型故障模式的扎根视角。专家被指导以简洁的方式编写技能，偏好描述性文字而非代码片段，每个技能聚焦于单一外设或框架特定组合。

两组技能均遵循统一的格式（受 Agent Skills 规范启发），每个技能文件包含 YAML 头部（描述名称、目标平台、外设等元数据）和 Markdown 正文。这种结构化格式使智能体能高效扫描技能头部进行检索，而无需加载完整技能正文，从而保持较低的 token 开销。

2.4 基准规模

3. 智能体设置与评估协议

3.1 智能体架构

我们使用 LangGraph 实现智能体，采用三节点架构：

1. 管理器节点（Manager）：作为项目规划器，接收技能列表和任务要求，选择相关技能传递给编码节点
2. 编码节点（Coder）：作为专家嵌入式工程师，接收技能内容作为适用标准、任务要求作为用户消息，生成固件代码
3. 组装节点（Assembler）：将 LLM 原始输出格式化为可编译项目，提取干净代码并生成所有必要的平台特定脚手架

当不提供技能时，跳过管理器节点，任务提示直接传递给编码节点。

我们刻意采用这种最小化结构，以隔离技能的影响，排除多步规划、工具使用、迭代调试或反思循环等复杂机制的干扰。通过将智能体限制为单次传递管道（仅含一个可选规划阶段），我们的评估专门聚焦于技能对 HIL 系统的贡献。

3.2 评估协议

• 骨干模型： 所有实验使用 Claude Sonnet 4.5
• 重复次数： 每个任务-技能-平台组合执行 5 次
• 编译： 所有生成项目文件夹使用完全相同的工具链命令和相同的编译器配置手动编译
• 验证： 编译后的固件烧录到物理目标硬件，由人工评估员记录和验证

由于 HIL 性质，完整评估约需 100 小时的人工在环验证。

3.3 性能指标

每次任务尝试导致以下三种结果之一：

• 编译失败（CF）： 生成的固件无法编译或无法烧录到目标设备
• 行为失败（BF）： 固件编译并烧录成功，但未能通过硬件行为测试（包括设备挂起或触发看门狗复位）
• 行为正确（BC）： 固件编译、烧录并产生经 HIL 测试框架验证的正确可观察硬件行为

除 {CF, BF, BC} 分解外，我们还考虑两个聚合指标：

• pass@1： 首次尝试即达成 BC 的任务比例
• pass@5（BC@5）： 五次尝试中至少一次达成 BC 的任务比例

同时记录每次 LLM 调用的 token 使用量。

4. 实验结果

4.1 无技能基线

无技能时，智能体通过预训练知识解决简单的级别 1 任务：

• Arduino：12/12（完美）
• ESP-IDF：12/12（完美）
• Zephyr：11/12（略差，因 Zephyr 预训练数据较少）

随着任务难度增加，各平台性能均显著下降。级别 3 任务中，仅 7/14（ESP-IDF）和 6/14（Zephyr）被解决。

此基线的 token 消耗极小，平均每任务约 300 输入 token 和 1,200 输出 token。

4.2 LLM 生成技能

LLM 生成技能的效果参差不齐。对于文档完善的平台（如 Arduino），几乎无额外价值。对于复杂平台（如 ESP-IDF），LLM 合成技能有时强化了对 ESP-IDF 特定行为的错误假设，导致性能明显下降。Zephyr 的级别 3 任务略有改善，但整体收益不稳定。

代价： 平均每任务约 8,500–9,500 输入 token 和 1,500–2,000 输出 token，是三种配置中最高的。模型经常在输出最终代码前重复或推理技能指南。

4.3 人类专家技能

这两个失败代表根本性的硬件歧义，而非智能体能力不足。

token 消耗： 平均每任务约 650–2,900 输入 token 和 1,700–4,600 输出 token，在性能和效率之间取得了更好的平衡。

4.4 结果对比总览

关键结论： 紧凑的人类专家技能在所有平台和任务难度级别上始终实现近乎完美的性能，显著优于 LLM 生成技能，同时保持合理的 token 开销。

5. 结论

本文提出了 IoT-SkillsBench——一个经硬件验证的、用于评估嵌入式和 IoT 系统开发智能体系统的基准测试，以及一个将结构化程序性知识整合到代码生成管道中的基于技能的智能体框架。

跨多个 MCU 平台和任务难度级别的广泛 HIL 评估表明：

• 仅靠 LLM 的原始能力不足以实现可靠的嵌入式开发
• 紧凑的人类专家技能大幅提升可靠性，在各平台实现近乎完美的任务成功率，同时保持适度的 token 成本

这些结果强调，扎根的领域知识——而非仅仅是更大的模型——对于硬件约束环境下的智能体编程至关重要。我们希望 IoT-SkillsBench 能成为未来 AI 辅助嵌入式开发、HIL 智能体评估以及物理系统编程的可扩展知识表示研究的基础。

附录 A：23 种外设完整列表

附录 B：LLM 生成技能的提示词

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Prompt: LLM-based Skills Generation

Read tasks in tasks/level<X>.txt, please follow these steps:
1. Analyze the task requirements and identify what domain knowledge,
   hardware platforms, or connectivity protocols, etc, are needed.
2. Consider implementation based on three MCU + development framework
   combinations: 1) ESP32 + ESP-IDF, 2) ATMega2560 + Arduino,
   3) nRF52840 + Zephyr.
3. Write modular skill documents that would help solve these tasks.
   Each skill should: focus on a specific MCU, board, IoT tool, protocol,
   framework, or embedded technique; provide code examples and usage
   patterns; be reusable for similar tasks.
4. Save each skill as a markdown file in the skills-llm-generated/
   directory with a descriptive name.

附录 C：各级别示例任务

C.1 级别 1：基本外设控制

任务：带消抖的按键状态读取

读取下拉按键的状态并实现软件消抖以避免多次触发。当按键按下时打印”Button Pressed!”到串口。

任务：TMP36 温度读取

读取 TMP36 温度传感器的模拟输出，其输出电压与摄氏温度成线性比例，将温度值打印到串口。

任务：SOS 摩尔斯电码

闪烁 LED 以摩尔斯电码拼出”SOS”。

C.2 级别 2：协议级通信

任务：MPU6050 数据读取（I2C）

通过 I2C 从 MPU6050 读取原始加速度计和陀螺仪数据并打印到串口。

任务：BME280 数据读取（SPI）

使用 SPI 总线从 BME280 传感器读取湿度和温度值并打印。

任务：LCD1602 显示”Hello World”

设置 LCD1602 显示屏，在屏幕中央显示”Hello World”。

C.3 级别 3：系统集成

任务：带显示屏的保险箱

编写程序从 16 键矩阵键盘读取密码输入（共 8 条线连接 4 行 4 列）。密码设为”1234”。当输入匹配密码时，连接继电器解锁保险箱。

任务：LCD1602 背光自动亮度控制

使用环境光强度（KY-018 光敏电阻）自动调节 LCD1602 背光亮度。读取光敏电阻的模拟值，映射到合适的 PWM 占空比，并据此控制背光亮度。

任务：蜂鸣器联动变频 LED

构建将按键按下与蜂鸣器和定时器 LED 控制集成的程序。系统复位后，每次按下按键：

• 第 1 次：触发定时器以 1 Hz 翻转外部 LED
• 第 2 次：触发定时器以 2 Hz 翻转外部 LED
• 第 3 次：触发定时器以 4 Hz 翻转外部 LED
• 第 4 次：停止定时器，外部 LED 不闪烁

过程循环，LED 翻转频率按 1 Hz → 2 Hz → 4 Hz → 关闭 序列变化。每次按键按下时，蜂鸣器响起，指示按键已按下。按键和蜂鸣器必须连接到不同的 GPIO 引脚。

附录 D：人类专家技能示例

Zephyr 技能：GPIO 最佳实践

• 在设备树中定义引脚极性（GPIO_ACTIVE_HIGH / GPIO_ACTIVE_LOW），不在代码中定义
• 使用 gpio_pin_set(dev, pin, 1) 逻辑 ON 开启；gpio_pin_set(dev, pin, 0) 逻辑 OFF 关闭。让 Zephyr 的 GPIO 驱动根据 DT 标志处理物理 HIGH/LOW 转换。切勿假设物理电压电平
• 使用 GPIO_INT_EDGE_TO_ACTIVE / GPIO_INT_EDGE_TO_INACTIVE 而非 RISING/FALLING——保持极性无关

ESP-IDF 技能：GPIO 最佳实践

• 防止浮空状态： 显式配置内部电阻（.pull_up_en, .pull_down_en）。如果引脚必须默认为 LOW/HIGH，在 gpio_config() 后立即使用 gpio_set_level() 确保在外设上电延迟前有确定的状态
• 精确时序与延迟： 使用 ets_delay_us() 实现微秒级精度；但始终包含 #include "rom/ets_sys.h" 以防止现代 IDF 版本的隐式声明错误
• 中断处理瞬态信号： 对于捕捉快速瞬态状态变化（如 <5ms 脉冲），避免 while(1) 轮询。优先使用 gpio_install_isr_service() 的中断服务程序，并配置边沿触发中断（如 GPIO_INTR_NEGEDGE）

原文出处：https://arxiv.org/abs/2603.19583（CC BY 4.0 许可）。本译文供学习交流。

• Previous
  从不确定性到可能性：乡村女孩的早期计算教育经历（From Uncertainty to Possibility）