闭环评测嵌入式软件智能体

大语言模型智能体用于嵌入式软件开发的闭环评测

Jorge García-Carrasco、Sergio García-Carrasco、Alejandro Maté、Juan Trujillo。

单位：Lucentia Research，软件与计算系统系，阿利坎特大学，地址 Ctra. de San Vicente del Raspeig s/n，03690 Sant Vicent del Raspeig，西班牙；材料技术大学研究所（IUTM），瓦伦西亚理工大学，地址 Plaça Ferrándiz i Carbonell，03801 Alcoi，西班牙。通讯作者：jorge.g@ua.es。

发表于 Journal of Systems Architecture 179 (2026) 103937，https://doi.org/10.1016/j.sysarc.2026.103937。© 2026 作者。由 Elsevier B.V. 在 CC BY 4.0 许可下出版。

译注：作者姓名、期刊名、卷期、DOI、街道门牌与许可名称 CC BY 4.0 均保留原文；单位、城市与出版说明按原文直译。通讯邮箱保留原文，此段不改写专名。

###### 摘要

大语言模型（LLM）越来越多地被部署为编码智能体：它们编辑文件、运行构建和测试、检查执行结果，并迭代地修复软件。嵌入式固件是一个要求很高的对象，因为正确性取决于在传感、时序和安全约束下的闭环行为，而不仅仅是静态源码质量。然而，嵌入式智能体评测仍然有限，而且常常强调一次性综合或离线正确性。

我们提出一个用于嵌入式编码智能体闭环评测的基准。每项任务提供一份纯文本的工程描述、受约束的工作区，以及可见的构建与运行表面。智能体必须把需求翻译成实现步骤和自我验证步骤，然后迭代，直到达到所要求的设备行为。该套件包含五项嵌入式控制任务和四种反馈场景：一次性生成、现实的自我验证、持续集成式的红绿反馈，以及预言机式的详细反馈。

实现针对模拟的 ESP32 固件，以保证可复现。我们在五项任务和四种场景上评估七种 GPT 家族与 Qwen 家族配置，每种条件重复三次，共 420 次运行。gpt-5.4 在所评估配置中通过率最高，但并没有把基准做饱和；qwen3.5-27B 是观察到的最强本地模型；更小的本地模型在通过率和搜索效率上急剧变差。这些结果表明，有能力的本地嵌入式编码智能体正在出现。

关键词： 嵌入式软件，大语言模型，语言模型智能体，软件工程基准

要点。

• 我们提出一个面向嵌入式固件编码智能体的闭环基准，也就是能够自主执行有界的构建–测试–调试循环的、使用工具的大语言模型系统。
• 该基准针对的是智能体为何对嵌入式工作重要：任务从纯文本的工程交接开始，并要求可见的构建、测试、运行、修复和停止决策。
• 评测覆盖五项任务、四种反馈机制、七个模型、三次重复，合计 420 次运行。
• 模型集合把两个托管的前沿系统与五个本地 Qwen 变体结合起来。
• 在所评估配置中，gpt-5.4 的观察通过率最高，而 qwen3.5-27B 是观察到的最强本地模型，并指向可行的本地部署嵌入式智能体工作流。

1 引言

在非常大的自然语言和源代码语料上训练的大语言模型（LLM），如今在广泛的任务上表现出很强的能力 [1]。在软件场景中，它们可以解释需求、概括仓库状态、生成候选实现、解释失败，并提出修复 [2]。然而，单凭它们自己，通常只是单轮文本生成器。智能体式编码系统用持久工作区和显式工具使用来扩展它们 [3]，使模型能够读取和编辑文件、运行构建和测试、检查日志，并在多个步骤上修订一个部分解，而不是只回答一次。换句话说，编码智能体不只是建议代码；在一个有界的工具环境里，它可以自主地对仓库采取行动，观察后果，并继续工作，直到它决定停止或提交。

从一次性生成转向迭代的、由反馈驱动的工作，对软件工程中的实际自动化是核心的。最近的基准工作表明，现实的测量必须考虑模型能否处理失败信号，并在重复尝试中改进一个解 [4, 5]。面向智能体的系统和评测进一步强调规划、工具使用、执行，以及在现实开发环境中的迭代修复 [6, 7]。因此，智能体这一框架是有用的，因为许多工程任务的瓶颈并不是产生一个初始候选，而是验证、调试并修复该候选，直到它满足预期行为。嵌入式软件是这类评测特别有说服力的对象：固件正确性取决于与传感器、执行器、时序约束和安全联锁形成闭环时的行为，所以成功所要求的多于静态的源码级质量。

因此，嵌入式软件开发在性质上不同于标准的代码生成任务。一个控制器在代码评审里看起来合理，一旦与异步传感器流、滞回、超时处理或顺序控制交互，仍然可能失败。出于同样的原因，仓库级的问题求解基准也没有完全覆盖嵌入式场景：它们捕捉迭代的软件工作，但没有捕捉面向硬件的闭环，而固件正确性取决于动态行为。

尽管近来有兴趣把现代编码智能体用于嵌入式和邻近硬件的领域，主导的重点仍然是静态综合、组件级检查或离线正确性 [8]。较少被探索的，是使现代编码智能体在实践中有用的完整智能体循环：从一份关于必须实现什么的纯文本规格出发，制定测试，实现固件，运行它，从反馈中学习，并迭代直到系统行为与需求匹配。

这引出本文的中心问题：

一个智能体能否从所需设备行为的纯文本规格出发，迭代地编写测试和固件，在目标环境中执行该固件，并通过一个闭合的反馈环收敛到所要求的嵌入式行为？

我们认为这个问题值得有自己的基准，因为所关心的能力不是一次性的固件生成，而是迭代的嵌入式工程。我们提出的基准旨在评估：一个智能体能否从一份散文体的工程简报出发，把该简报翻译成实现和验证动作，并最终在闭环中满足一份行为契约。因此，这一设计以散文为先、与契约对齐，并围绕嵌入式工程师实际执行的真实开发步骤：实现控制器、编写或改进测试、运行构建、探查运行时行为，并在失败信号上迭代。

在当前的参考实例中，我们用运行于 QEMU [9] 的 ESP32 固件目标，以及为受控过程建模的确定性被控对象仿真器，来实现这一方法。我们同时仿真微控制器和被控对象/任务，因为一个基准首先应当安全、可重复，并且易于大规模运行。这使评测可复现，并适合系统比较，同时仍然操练传感、控制、执行和验证这一核心嵌入式循环。在这一参考栈中，物理的传感器/执行器边界被有意通过固件与仿真器之间的 UART 协议虚拟化，从而抽象掉与具体电路板有关的电气集成，同时保留基准所要测试的闭环控制逻辑。因此，ESP32/QEMU 栈是基准的一个具体载体，而不是方法本身的边界。

##### 贡献。

本文做出下列贡献：

1. 一种面向嵌入式固件任务上大语言模型智能体闭环评测的基准表述，从散文规格开始，到行为级验证结束。
2. 一种以与契约对齐的任务包、可见的自我验证可供性、五级难度阶梯，以及反馈可见程度不同的四种评测场景为中心的基准设计。
3. 一个带有五个确定性被控对象模型的参考 ESP32/QEMU 仿真实例，使安全、可复现的闭环评测能够在硬件部署之前进行。
4. 一项汇集的 420 次运行评测，覆盖五项任务、四种反馈场景和七个横跨托管与本地智能体的模型，表明该基准可执行且能区分模型；gpt-5.4 的观察通过率最高，但在重复测量下并没有使套件饱和；qwen3.5-27B 是观察到的最强本地点，而更小的本地模型在准确性和效率上都急剧变差。

本文其余部分结构如下。第 2 节回顾相关工作。第 3 节给出基准目标、契约和设计原则。第 4 节描述评测设置，并报告跨任务、反馈场景和模型的结果。第 5 节讨论含义、局限和基准设计上的教训。第 6 节作结并概述未来工作。

2 相关工作

关于软件工程评测的先前工作已经确立：现实的测量所要求的多于一遍代码生成。SWE-Bench 及其后续等基准表明，测试模型能否与仓库交互、处理失败信号，并在多次迭代中修订解，是重要的 [4, 5]。与此并行，SWE-agent [6]、Agentless [7] 以及相关的程序改进框架等面向智能体的系统和评测，强调了在现实开发环境中的规划、工具使用、执行和迭代修正 [10]。合在一起，这条工作提供了我们所采用的一般评测视角：实际能力不仅是综合代码的能力，也是在开发循环中有效使用反馈的能力。

与此同时，HumanEval [11]、MBPP [12] 和 RepoBench [13] 等以综合为重点的基准仍然重要，因为它们隔离了核心的功能性代码生成能力。这些数据集对局部正确性和模式级编码技能提供了很强的信号。然而，它们并不能完全代表嵌入式固件工作。在那里，正确性常常取决于有状态的执行、异步输入、目标约束、低层验证问题 [14]，以及扰动下的行为。在嵌入式场景中，孤立看起来合理的代码，一旦被编译、在目标上执行，并在时间和安全约束下被操练，仍然可能失败。

关于大语言模型用于嵌入式和邻近硬件编程的文献也增长很快。最近的基准工作明确针对嵌入式系统开发和面向微控制器的评测，帮助把固件工程确立为现代模型的一个严肃目标 [8]。补充性研究在微控制器驱动的物联网应用中，对用于嵌入式系统编程的大语言模型做了基准测试，进一步拓宽了该领域的经验基础 [15]。综述工作也更广泛地回顾了基于 Transformer 的源代码生成，覆盖编码模型架构、调优策略、数据集和评测指标 [16]。邻近的低层工作考察了面向硬件描述和综合的代码生成，包括与模型在近硬件工程领域中的能力这一更广问题相关的、以 Verilog 为重点的基准 [17, 18]。相关的系统工作还研究了边缘设备机器学习基准测试 [19]，以及从定点仿真和硬件协同设计角度的端侧大语言模型部署 [20]，同时智能体式推理架构也被探索用于逻辑代码仿真任务 [21]。这些工作在把嵌入式软件和相关低层领域确立为现代模型的相关目标上是有价值的。然而，现有证据的很大一部分仍然集中在静态综合、组件级检查、离线正确性，或狭窄的领域特定推理任务上。相对较少的注意力被给予完整的智能体工作流：模型从一份散文体工程简报出发，编写或改进自我验证，在目标环境中运行固件，解释分阶段的反馈，并迭代直到行为级需求得到满足。

最后，仿真和模拟长期以来一直是机器人学 [22]、系统研究 [9] 和固件分析——包括从固件逻辑做中断建模 [23]——的基础评测基底，因为它们使可复现性、受控实验和有成本效益的压力测试成为可能。对嵌入式智能体研究而言，仿真提供了反复闭环执行的实际好处，而没有立即做物理部署时的脆弱性、安全风险和运维开销。与此同时，仿真并不能替代真实设备验证。在本文中，我们把它用作一个有意的方法学台阶，支持今天对智能体行为的严格比较，同时为将来转向硬件在环和真实机器研究提供信息。

合在一起，先前工作促使我们提出这样一个基准：它接纳学术界和工业界如今为现实评估嵌入式开发中的大语言模型智能体而常用的智能体评测工作流。

3 基准设计

这一基准评估大语言模型智能体能否从一次自然语言的工程交接出发，执行一个现实的嵌入式开发循环。对每项任务，智能体收到所需行为的纯文本规格，并被期望把该规格翻译成实现和验证动作。在实践中，这包括编写固件、创建或改进测试、调用构建和检查、解释失败，并迭代直到行为满足所述需求。

基准围绕模拟任务来设计，使实验保持安全、可重复，并且可以跨模型比较。仿真允许在一致的任务条件下做许多受控运行，同时仍然操练对嵌入式自动化重要的核心工程工作流。详细接口、执行机制和评估器行为在随后各小节介绍。

3.1 基准目标

基准被设计来评估：一个智能体能否从一次现实但受控的工程交接完成一项嵌入式固件任务。这次交接包括所需设备行为的散文描述、受约束的实现表面、可见的工具可供性，以及一个可以反复执行的目标环境。重点在智能体能力，而不仅仅在最终源码质量。

更具体地说，基准旨在回答三个问题：

1. 智能体能否从一份简单的纯文本规格出发，把它变成有用的本地验证，而不是依赖一份基准特有的结构化契约或隐藏评分器的细节？
2. 智能体能否迭代地编写或改进固件和测试，构建目标代码，运行本地检查，对着目标环境执行控制器，并利用由此产生的反馈改进实现？
3. 智能体能否用这个循环达到一份最终的正确提交，既满足名义控制需求，也满足安全关键需求，例如过期输入处理、联锁、超时行为和顺序恢复？

在更高的层面上，基准在问：现代编码智能体能否做一件既有实际重要性、在嵌入式软件中又仍然探索不足的事——从一份散文体工程交接开始，构建自己的验证循环，并一直迭代到行为上正确的固件，而不是仅仅产生看起来合理的源代码。这在科学上有意思，因为它把评测目标从静态综合移到闭环工程表现；这在实践上有意思，因为那正是嵌入式自动化会在真实开发工作流中变得真正有用的层次。

在当前实现中，这些问题被实例化在运行于 QEMU [9]、并耦合到确定性被控对象模型的 ESP32 固件目标上。这一具体栈之所以重要，是因为它使跨模型的可复现、受控比较成为可能。然而，主要的科学贡献是基准方法本身：一个以散文为先的闭环评测框架，可以迁移到其他嵌入式目标和仿真环境。

3.2 基准工作流与契约

本基准所评估的主要工作流是 realistic_self_verify 设定。在这一设定中，智能体收到一份散文体工程简报，在受约束的工作区里操作，并使用可见的本地工具在决定是否提交给隐藏评估器之前验证自己的工作。在这一主要条件中，隐藏评估器并不是本地修复循环的一部分：智能体依据可见证据迭代，而不是依据隐藏的失败消息。图 1 概括这一工作流。第 3.5 节稍后描述的一次性和更丰富反馈设定是有用的比较条件，也会被探索，但这一以自我验证为中心的工作流才是基准的主要目标。

图 1：基准所评估的主要智能体工作流。智能体在可见证据上本地迭代，明确决定是否提交，只有在那之后才触发一次隐藏的行为评估。

因此，这一工作流引出一份简单契约。对每项任务：

1. 智能体收到一份描述所需行为的纯文本规格文件。
2. 智能体只能编辑预定的实现表面。
3. 智能体可以反复使用可见的构建、测试和运行时工具，以决定是继续在本地迭代，还是提交。
4. 隐藏评估器只在提交时被咨询；在主要工作流中，它不提供用来驱动本地循环的详细失败反馈。
5. 只有当一份已提交的实现满足完整的行为契约时，任务才算被解决。

这份契约是有意的。目标是测量一个智能体能否从一次自然的工程交接出发，迭代直到设备行为满足该交接。因此，基准默认以散文为先：内部的结构化任务定义保持隐藏，对基准特有模式的熟悉不应该是成功的主要来源。

3.3 设计原则与构建过程

上面的工作流描述的是智能体在评测期间所经历的事情。接下来我们解释基准本身如何构建，使难度来自嵌入式控制问题，而不是来自偶然的基准制品。下列设计原则同时指导任务设计，以及评估器、仿真器和公开任务包的构建。

基准遵循五条设计原则。

1. 闭环优先： 基准应当评估迭代开发，而不只是最终的代码发出。
2. 契约对齐： 隐藏检查必须追溯到散文交接中的可见需求。如果一条隐藏断言重要，它就应当写在公开任务包里；否则就不应当计分。
3. 任务特有的失败： 如果智能体失败，失败应当可以归因于控制问题，例如错误的状态转移、过期传感器策略或超时规则，而不是归因于基准设置错误，例如任务交接中不正确的构建说明。
4. 可见的自我验证可供性： 现实的自我验证需要可见的工具、测试位置和运行时钩子；仅仅告诉智能体去自我验证是不够的。
5. 栈可移植性： 基准设计在概念上应当保持独立于当前的微控制器和仿真器选择。

这些原则针对的是基准效度。一次失败应当可以被解释为嵌入式开发问题上的失败，而不是隐藏的基准琐事上的失败。同样，一次成功应当反映闭环中的真正收敛，而不是偶然匹配一份暴露过度的评分契约。

我们通过套件中每项任务的一条固定构建流水线来操作化这些原则，使任务难度来自嵌入式控制问题，而不是来自偶然的基准制品。过程从任务设计开始：首先写出一份工程级控制计划，使之规定预期行为、安全约束、非名义情形和验收标准。这份计划同时是公开交接和隐藏评估器的来源，从而使基准契约在可见部分和私有部分之间保持对齐。

下一阶段是仿真和执行框架的构建。对每项任务，我们实现一个确定性过程仿真器，并把它连接到固件目标，使控制器在真正的闭环中被评估。如前所述，在当前参考栈中，固件在 QEMU 里的 ESP32 目标上运行，过程仿真器通过 UART 与该目标交换传感器和执行器信号。我们首先使用仿真，因为它更安全、可重复，并且对大规模比较扫描是实用的，同时仍然保留传感、控制、执行和运行时反馈这一核心嵌入式工作流。

仿真器稳定之后，我们编写用于评分的隐藏真值测试。这些测试源自同一批需求，并覆盖名义轨迹、边界条件，以及过期输入处理、超时策略和联锁等安全关键行为。隐藏套件定义最终的通过/失败状态，并保持私有，使模型不能过拟合评估器内部。隐藏评估器的反馈只在两种反馈丰富的评测场景中返回，用以评估这些额外信息是否帮助智能体更好地、更快地收敛。

与此并行，我们准备面向智能体的任务包。智能体收到的是一份纯文本的自然语言交接，不是机器可读的契约，也不是隐藏测试。工作区暴露构建、本地验证和运行时探查所需的工具，但编辑被约束在预定的实现表面上。这一约束由测试框架强制执行，使比较保持公平，并集中在指定的固件开发范围上。

在评测期间，智能体必须把散文简报变成可执行的验证和实现步骤：编写或改进测试、修改固件、运行构建、解释失败，并在仿真中迭代。测试框架记录分阶段结果，例如逻辑测试失败、构建失败、运行时失败或行为失败，而最终成功只由隐藏的真值评估器决定。这一设计同时测量智能体式开发行为和端到端的行为正确性。

3.4 任务套件

当前任务套件包含五项任务，被安排成一条有意的难度阶梯。每项任务都从所需行为的纯文本规格开始，并要求智能体通过迭代验证收敛到一个正确的控制器。难度被设计为来自控制问题本身：更多的传感通道、决策之间更强的耦合、显式的安全状态行为，以及最终一个完整的顺序控制问题。所定义的任务如下：

表 1：五项任务难度递进的紧凑视图。

1. tank_fill_drain： 一项基线的单传感器任务，有一路液位流和一个泵执行器。任务简报要求简单的阈值控制，但不是无状态的阈值控制：控制器必须在低于 30 时打开泵，在高于 80 时关闭泵，并在 30–80 带内保留先前的安全输出，而不是在中间区域强制一条新命令。它还必须区分正常的短空闲间隙和真正的超时行为，并在畸形输入或超过 1000 毫秒的过期数据上故障安全到泵关闭。因此，这项任务建立散文规格、精确的 UART 可见执行、超时处理，以及运行时自我验证的基本模式。
2. thermal_chamber_hysteresis： 一项单回路温度控制任务，被控对象有滞后，加热器为二值执行。控制器必须在低于 47 时加热，在高于 52 时关闭，在名义带内保留先前的安全状态，并在温度于 50–52 区间上升时做预见性关断。散文简报明确把这种预见性的加热器关闭当作有效的保持行为，而不是故障，因此智能体必须对趋势推理，而不只是瞬时阈值。该任务还包括畸形输入和过期传感器的故障安全行为，以及 56 °C 的闭环硬上限，这意味着一个控制器可以满足可见的阈值逻辑，如果忽略被控对象滞后，仍然会失败。
3. pressure_vessel_interlock： 一项双传感器联锁任务，把压力调节与门安全逻辑结合起来。压力新鲜度和门新鲜度是独立的，控制器必须保持在安全的排气打开状态，直到两个信号都被有效地观察到。一旦初始化，它必须在密封且低于 40 时加压，在高于 60 时泄压，在带内保留先前的安全输出，并立即服从门打开的优先权。该任务还要求控制器永远不要同时命令压缩机打开和排气打开，使它成为阶梯中第一项同时强调显式执行器互斥和异步输入有效性的任务。
4. mixing_tank_fill_heat： 一项耦合的液位与温度任务，传感器新鲜度独立，并有低液位加热器保护。控制器必须在低于 60 时打开入口，在高于 75 时关闭入口，每当液位降到 55 以下就把加热器保持关闭，并且只有在安全加注窗口内、温度仍低于工作带时才加热。靠近温度上沿时，它必须再次对温度趋势推理，并在温度上升时提前关闭加热器。因此，该任务结合了多传感器有效性、跨两个执行器的耦合决策，以及 51 °C 的闭环硬上限。
5. filter_tank_sequence： 一项顺序控制任务，有两个传感器、两个执行器，以及过滤、静置、排空和完成的显式阶段转移。控制器必须只用有效的浊度输入来计数一段清澈连续，在三次清澈采样且液位仍然足够高之后进入静置，至少等待 400 毫秒再打开排水，然后从静置或排空期间到来的扰动中正确恢复，办法是重新开始过滤并重置进度。它还必须在剩余液位降到最低阈值以下时检测完成，并回到全关状态。这是当前阶梯中最强的任务，因为正确性取决于状态推进、时序、证据累积和扰动恢复，而不是一条单一的局部阈值规则。

合在一起，这五项任务旨在形成一条有意的、嵌入式控制难度递增的阶梯，如表 1 所概括。进程从简单的单传感器阈值控制器开始，然后加入被控对象滞后和预见性控制、异步多传感器联锁、耦合的多执行器决策，最后是带有显式扰动恢复的定时顺序控制。这一结构之所以有用，是因为它帮助区分模型的，不仅是原始编码能力，还有在控制问题变得更丰富时维持控制器状态、对异步观测推理，以及构建更强自我验证循环的能力。

3.5 评测场景

尽管主要研究目标是智能体必须构建并信任自己的验证循环的那个设定，我们报告另外三种场景来为表现提供语境。具体地说，我们保留一个更简单的一次性基线，以及两种面向指导的设定，使结果可以在一个受控的反馈假设范围内被解释。四种评测场景按反馈水平递增排列如下：

1. oneshot_blind： 智能体被限制为单次提交，不返回隐藏反馈，并且公开的自我验证辅助被有意省略。这几乎完全去掉了迭代搜索，并为从规格直接到代码的表现提供一个下界基线。换句话说，它问的是：当模型被迫几乎完全依赖对任务包的第一遍解释时，会发生什么。
2. realistic_self_verify： 这是主要的基准条件。智能体可以自由迭代，但提交之后不返回隐藏评分器的细节。因此，智能体必须依赖工作区中暴露的可见构建、测试和运行时表面，以及它在该表面下创建的任何自撰检查。这最接近本文的科学问题：智能体能否阅读一份散文体工程简报，构建自己的验证循环，并自行决定解何时可以提交？
3. ci_red_green： 智能体可以迭代并重新提交，但每次提交之后它只看到一个紧凑的隐藏通过/失败结果。这近似持续集成式的搜索信号：模型得知当前尝试是否可接受，但不知道哪一条隐藏断言失败，也不知道需要什么具体修复。因此，它有助于把受益于最少外部搜索指导的模型，与已经能在本地自我验证的模型区分开。
4. oracle_full： 智能体可以迭代，并在提交之后收到详细的隐藏主机测试或集成反馈。这有意比预期的自主使用情形更重于指导，但它是丰富监督下修复的一个有用诊断上界。如果一个模型只在这里成功，那么基准表明的是：当被指向错误时它能够修复，但不必然表明它能自行构建一个可信的自我验证循环。

因此，这四种场景不应当被读成一张单一的单调排行榜。它们是对同样任务的互补镜头。realistic_self_verify 测量核心目标能力，oneshot_blind 隔离第一遍实现技能，ci_red_green 加上 oracle_full 则显示每个模型对逐步更丰富的隐藏指导依赖有多强。合在一起，它们使增益可以被归因于不同机制：规格理解、自我验证质量，以及对外部反馈的依赖。

场景这一轴也提供了对两条属于行为、而不是基准效度约束的设计原则的定向消融：闭环迭代和可见的自我验证。具体地说，oneshot_blind 与 realistic_self_verify 之间的对照保持任务散文、隐藏评估器、工具框架、模型集合和运行预算固定，同时改变智能体能否在提交之前使用可见的构建、测试和运行时表面做迭代的自我验证。相比之下，契约对齐、任务特有的失败归因和栈可移植性是由构建方式强制执行的基准卫生约束：违反它们会引入隐藏的未陈述需求、框架制品或栈特有假设，而不是隔离有用的智能体行为。

3.6 实现细节

用于复现本文结果的全部代码和数据公开于 https://github.com/jgcarrasco/closed_loop_evaluation_agents_embedded 。当前实现把基准实例化在 QEMU 中执行、并耦合到用 Python 实现的确定性被控对象模型的 ESP32 固件目标上。ESP-IDF 提供固件构建系统和目标支持 [24]，QEMU 为嵌入式目标提供可复现的执行基底 [9]，开源的 pi 编码智能体框架处理模型交互和工具中介 [25]。对本地开源权重实验，Docker 提供可复现的环境打包 [26]，llama.cpp 在一个共同的推理栈下服务本地模型 [27]。每项任务在 sim/tasks/ 下有一个任务特有的运行时模块，它定义隐藏场景、推进被控对象状态、发出传感器帧、消费来自固件的执行器命令，并评估由此产生的闭环行为是否满足场景契约。这使基准逻辑对人类保持显式和可检查，同时把隐藏评估器本身留在智能体可见的工作区之外。

共同的运行时框架在 QEMU 中启动固件，通过一个本地 TCP 套接字暴露 UART0，并用换行分隔的 ASCII 帧与固件通信。在被控对象到固件的一侧，运行时发送任务特有的传感器帧，例如 SENSE LEVEL 25、SENSE TEMP 47 或 SENSE DOOR OPEN，以及 FAULT SENSOR_TIMEOUT 这样的显式故障帧。在固件到被控对象的一侧，框架期望精确的任务特有执行器行，例如 ACT PUMP ON、ACT HEATER OFF 或 ACT DRAIN OPEN。这一 UART 边界是真实嵌入式输入输出的仿真替代：同样的控制器逻辑更典型地会读取 GPIO/ADC/总线连接的传感器，并通过 GPIO、PWM、继电器或外设接口驱动执行器。基准有意抽象掉那一层与具体电路板有关的电气集成，使评测保持集中在闭环控制行为、分阶段验证和修复上，而不是集中在某一种特定的硬件布线栈上。因此，这一精确字符串契约是基准的一部分：隐藏检查不对内部辅助函数名或重构计分，但确实对外部可见的控制行为和 UART 可见的执行表面计分。

在概括隐藏评估结果时，我们使用四种结果标签。PASS 表示已提交的实现满足全部隐藏的主机检查和闭环检查。HOST 表示隐藏的主机测试失败：提交到达隐藏评估器，但在 QEMU 闭环被控对象场景被接受之前，就在主机侧构建或单元测试上失败。INT 表示集成失败：提交通过了前面的主机测试阶段，但在基于 QEMU 的闭环评估期间失败，例如因为固件发出了错误的 UART 可见执行器命令、错误处理了时序或过期输入、违反了安全约束，或没有通过任务特有的被控对象场景。NONE 表示该次运行在没有最终提交的情况下结束。

被控对象模型是确定性状态机，而不是随机仿真器。例如，对最简单的 tank_fill_drain 任务，被控对象状态只包含当前液位、泵状态，以及以毫秒计的模拟时间。每一步被控对象以固定节拍推进时间，并按照简单的注入减排出规则更新液位。更复杂的任务加入滞后、耦合传感器、多执行器动态或显式的顺序状态，但它们遵循同一原则：相同的输入应当产生相同的轨迹，使运行在模型之间和重复评测之间保持可复现。在每个隐藏场景期间，运行时记录 UART 交换的完整副本，加上结构化的轨迹样本和汇总指标，这使失败可以诊断，而不向智能体揭示隐藏检查。

#### 说明性示例

最容易的任务 tank_fill_drain 是基准契约的一个很好的具体例子。公开任务简报告诉智能体：当 LEVEL < 30 时控制器必须打开泵，当 LEVEL > 80 时必须关闭泵，在中间带保留先前的安全输出，并在畸形输入或超时时故障安全到泵关闭。它还明确指示智能体在提交之前创建自己的可见测试，以及至少一次固件级运行时探查。隐藏的主机检查随后验证这些公开需求是否真的被满足。该任务有代表性的隐藏检查包括：在中间带保留当前的安全 ON 状态，以及在有界超时窗口之后强制泵关闭。

这个例子说明智能体在基准中实际必须做什么。发出看起来合理的控制器代码是不够的。智能体必须编辑受约束的固件表面，编写或改进本地测试，构建固件，并且最好在决定提交之前，通过 UART 可见的运行时路径端到端地操练它。这一区分之所以重要，是因为智能体很容易用不完整的本地测试产生假的绿灯。例如，它可能验证了明显的低阈值和高阈值行为，却漏掉了中间带锁存或精确的超时反应。因此，隐藏测试和隐藏闭环场景是必要的，以便把真正的行为正确性，与一个在本地有说服力但不完整的自我验证故事区分开。

4 评测

我们评估当前编码智能体能否在反复的闭环交互下，把散文任务描述变成行为上正确的嵌入式固件。研究覆盖七个模型、五项任务和四种反馈场景，重复三次，合计 420 次运行。模型集合包括两个托管的前沿系统（gpt-5.4 和 gpt-5.4-mini），以及五个本地开源权重的 Qwen 变体（qwen3.5-27B、qwen3.5-35B-A3B、qwen3.5-9B、qwen3.5-4B 和 qwen3.5-2B）。

本文报告的全部模型评测都通过同一个 pi 框架执行 [25]。这是有意的：保持智能体包装、工具接口、提示表面和运行日志固定，降低把脚手架差异归因于模型差异的风险。我们选择这一模型集合，是为了覆盖部署设定、模型规模和架构形式的一个有用跨度，使评测既捕捉跨家族的能力差异，也捕捉家族内部的本地缩放行为。

托管的 GPT 模型被纳入，是作为前沿规模的参考点，而不是作为一张穷尽的托管模型排行榜。模型集合的主要目的，是在所选配置上评估闭环嵌入式智能体行为，并特别关注本地服务的开源权重模型能否在同一框架下解决这些任务。因此，我们把模型排名的主张限定在所评估的配置上。额外的托管基线，包括 Claude Opus，会是有价值的未来工作，但不在这里所研究的受控模型集合之内。

我们在三项互补分析中报告结果：

1. 第一，我们把 realistic_self_verify 当作主要条件，因为它最接近基准所要测量的自主闭环工作流。
2. 第二，我们用完整的四场景矩阵来研究反馈可见性如何改变模型行为。
3. 第三，我们聚焦本地 Qwen 变体，研究模型规模、表现和计算成本之间的权衡。

关于本地 Qwen 模型，它们全部在一块 NVIDIA RTX 4090 上用 llama.cpp 执行。所评估的家族包括 qwen3.5-27B、qwen3.5-35B-A3B、qwen3.5-9B、qwen3.5-4B 和 qwen3.5-2B。我们有意把这项研究保持在一个共同的 GGUF 4 比特部署机制之内，而不是混合量化和更高精度的检查点，尽管像 9B 这样更小的模型可以在同一硬件上以更高精度装下。所有本地 Qwen 运行都在关闭思考的情况下执行。这使数值精度、服务格式和显式的测试时推理模式不至于成为本地缩放研究中的额外变动因素，从而使家族内部比较在方法上保持受控。本地 GGUF 检查点取自 Unsloth 发布的 Qwen3.5 版本和部署指南 [28]，它们为全家族本地模型提供了一致的公开来源。我们没有评估大于 35B 版本的模型，因为硬件限制。我们也省略了 0.8B 模型，因为 2B 模型在其全部运行中通过次数为零，在最终整理的包里只有八次运行记录了第一次提交，其余时候把大部分预算花在无产出的搜索上。据此，一次 0.8B 运行不太可能在延伸同一失败机制之外增加有用的区分证据。

在全部运行上，我们报告隐藏结果、失败家族、所达到的阶段、总词元、工具调用、隐藏评估次数、构建尝试、自测运行和运行时探查行为。运行被允许迭代直到成功，或达到一小时的墙上时钟限制；oneshot_blind 和 realistic_self_verify 仍然限制为单次提交，而其他场景允许在同一时间预算内重复提交。因为被控对象和框架是确定性的，三次重复旨在测量固定环境下智能体/模型的随机性，而不是随机化的任务变化。这一重复次数旨在暴露主要的行为差异和反复出现的失败模式，而不是分辨相邻模型配置之间的细小差异。在每一项按模型、按场景的分析中，有效的二值样本量为 15 个结果，来自五项任务和三次重复。在双侧 $\alpha=0.05$、功效 80% 下，正态近似的两比例功效计算给出，对基线通过率 0.1、0.2、0.3 和 0.5，最小可检测的绝对通过率差异大约分别为 0.46、0.49、0.49 和 0.44；在 0.7 的基线上，即便一个完美的 1.0 对照，在这一近似下仍然低于 80% 功效。因此，我们把接近的模型排序当作描述性趋势，同时强调跨反馈机制、失败类别，以及本地对托管配置的更大效应量模式。因为 OpenAI 模型运行在托管后端，而 Qwen 模型在本地服务，墙上时钟不在跨后端比较中用作对公平性关键的指标。它只在仅本地的小节中使用，那里所有模型共享同一硬件和服务栈。

表 2 概括评测中使用的推理和框架配置。对托管的 GPT 模型，我们使用 GitHub Copilot 订阅访问路径，以反映一个现实的、面向开发者的工作流；在该设定中，采样参数由提供方管理，温度和 top-p 控制不向框架暴露。对本地 Qwen 模型，llama.cpp 服务器按照 Unsloth 的非思考 Qwen3.5 指导来配置 [28]。提交限制依场景而定：oneshot_blind 和 realistic_self_verify 为一次提交，ci_red_green 和 oracle_full 为墙上时钟预算内的重复提交。在基准框架层，除了一小时墙上时钟预算和依场景而定的提交预算之外，我们没有另外施加工具调用、消息回合或迭代次数的上限。

表 2：所评估模型使用的推理与框架配置。

4.1 主要结果：现实的自我验证

基准的主要科学目标是 realistic_self_verify 条件。在这一条件中，智能体必须构建并信任自己的本地证据，而没有隐藏的失败消息。因此，这是解释模型能力的主要比较。

表 3：realistic_self_verify 在三次重复上的汇集主要场景结果。对所列全部模型，这对应于 15 次运行。通过一列报告汇集次数、通过率和 Wilson 95% 置信区间。跨后端比较强调交互成本，而不是墙上时钟。

译注：表 3 的模型名、分数、词元量和调用次数按原文保留，只译表头。七行依次为 gpt-5.4、gpt-5.4-mini、qwen3.5-27B、qwen3.5-35B-A3B、qwen3.5-9B、qwen3.5-4B 与 qwen3.5-2B。通过列中的分数是十五次运行里的通过次数、通过率和 Wilson 区间。

表 3 显示了文中最清楚的描述性排序。gpt-5.4 以 14/15 次通过（93.3%）领先主要条件。在非前沿模型中，本地的 qwen3.5-27B 以 9/15（60.0%）取得最高的汇集次数，略高于 gpt-5.4-mini 的 8/15（53.3%）。其余本地模型在这一主要条件中弱得多：qwen3.5-35B-A3B 达到 4/15（26.7%），qwen3.5-9B 和 qwen3.5-4B 各达到 2/15（13.3%），qwen3.5-2B 保持在 0/15（0%）。

这使两点立刻可见。第一，基准并没有被前沿饱和：即便最强的模型在主要条件中也留下一次失手，因此当前的五项任务套件在顶端仍然产生可见的余量。第二，本地智能体并不只是玩具基线：27B 本地 Qwen 模型在基准的主要设定中，汇集通过次数略高于更小的托管前沿模型，尽管重叠的 Wilson 区间表明，这一差距不应当被过度解读为稳定的分离。然而，这种竞争力伴随着可观的搜索成本。相对于 gpt-5.4-mini，qwen3.5-27B 在每次主要条件运行中大约使用 6.7$\times$ 的词元和大约 2$\times$ 的工具调用，才多得到那一次通过。词元总量是 pi 框架记录的提供方/服务器使用总量，在可得时包括所报告的提示/输入、补全/输出和缓存词元。因为分词和推理词元的记账依赖于后端，我们把词元比解释为所报告的交互量，而不是与提供方无关的计算；工具调用比是更干净的跨后端行为信号。

图 2：主要 realistic_self_verify 条件在三次重复上的双面板视图。左面板显示每个模型–任务对在三次重复中的通过次数。右面板显示这些重复中最可能的结果：若通过是众数结果则为 PASS，主机测试失败为 HOST，集成失败为 INT，没有提交为 NONE。

图 2 的左面板报告每个模型–任务对在三次重复中的通过次数，因此它把复现的、逐任务的分离写清楚，而不是只依赖前一张表 3 中的汇集总量。

它的主要结果是：基准所观察到的排序，由少数区分度很强的任务承载。filter_tank_sequence 是最强的分离器：只有 gpt-5.4 在主要条件中通过它，而且即便如此也只在三次重复中的两次。在另一端，tank_fill_drain 是锚定任务：两个托管模型加上 qwen3.5-27B 和 qwen3.5-35B-A3B 在每一次重复中都解决它，即便较弱的本地模型也至少成功两次。中间三项任务造成真正的散布。qwen3.5-27B 是唯一通过 mixing_tank_fill_heat 的本地模型，它也是 thermal_chamber_hysteresis 和 pressure_vessel_interlock 上最强的本地模型。

右面板报告每个格子在三次重复中的众数结果，使用第 3.6 节定义的结果标签，把稳定的通过与最常见的失败机制区分开：主机测试失败、集成失败，或没有提交。

这一结果视图表明，失败机制在模型之间并不均匀。gpt-5.4 仍然压倒性地以通过为主，只在 filter_tank_sequence 上有一次集成式失手。gpt-5.4-mini 在大多数重复中通过 tank_fill_drain、thermal_chamber_hysteresis 和 pressure_vessel_interlock，但 mixing_tank_fill_heat 变成一致的集成失败，filter_tank_sequence 变成一致的主机测试失败。对 qwen3.5-27B，损失集中在两项最难的任务上：tank_fill_drain 和 thermal_chamber_hysteresis 保持稳定通过，pressure_vessel_interlock 在三次中通过两次，而 mixing_tank_fill_heat 通常是主机测试失败，filter_tank_sequence 从未通过。

在 27B 以下，较弱的本地模型大多是在产生候选实现之后失败，而不是因为根本没有投入。对 qwen3.5-35B-A3B、qwen3.5-9B 和 qwen3.5-4B，主机测试失败是 thermal_chamber_hysteresis、pressure_vessel_interlock 和 filter_tank_sequence 上的典型结果，而 mixing_tank_fill_heat 是集成式失败变得常见的任务。最小的模型 qwen3.5-2B 处于完全不同的机制：它从未通过，并且在每项任务上的众数结果都是没有提交。

合在一起，两个面板表明：qwen3.5-27B 以下的主要分离，并不只是更低的搜索有效性。更难的任务暴露出一种更基本的弱点，即产生能通过本地验证的代码；在 2B，这种弱点更早一步表现为根本产生不出可行的提交。

4.2 反馈可见性的效应

完整的四场景矩阵之所以有用，是因为它揭示一个模型的限制是直接的实现质量、自我验证质量，还是对外部搜索信号的依赖。图 3 概括所评估模型集合按场景的通过率。

图 3：所评估模型集合上，通过率对反馈可见性的敏感度，在三次重复上汇集。每根条是该模型和该场景可用的 15 次运行上的百分比，误差条为 Wilson 95% 置信区间。

表 4：完整四场景矩阵在三次重复上的精确汇集通过次数。每个格子报告该模型和该场景在 15 次运行中的通过次数。

译注：表 4 的模型名、场景标识和通过次数字格按原文保留，只译表头。每格都是十五次运行中的通过次数。

另外，图 3 背后的精确汇集次数见表 4，它把完整的四场景矩阵直接列为 x/15 的值。

从这些结果中，有三种模式突出。第一，gpt-5.4 在各反馈机制上表现出高但并不完美的稳定性：它在 oneshot_blind 中达到 13/15（86.7%），在 realistic_self_verify 中达到 14/15（93.3%），在 ci_red_green 中达到 15/15（100%），在 oracle_full 中达到 14/15（93.3%）。因此，重要的一点是相对稳定，而不是饱和：它在每一个场景中都是最强的模型。

第二，qwen3.5-27B 在基准的主要设定中异常地强，而不只是在反馈丰富的设定中。它在 realistic_self_verify 中达到 9/15（60.0%），在 oracle_full 中达到 12/15（80.0%），相对于一次性的 8/15（53.3%）和持续集成式红绿搜索的 9/15（60.0%）。这之所以有用，是因为它表明该模型并不是简单地依赖外部隐藏指导来恢复表现。

第三，较弱的本地模型对反馈敏感得多。最清楚的例子是 35B-A3B 混合专家模型：它在一次性和现实自我验证中都只达到 4/15，在持续集成式红绿反馈下升到 8/15，在预言机反馈下达到 10/15。这表明，一旦隐藏反馈足够丰富，该模型常常能够修复行为，但它在构建自己的本地验证循环上弱得多。9B 和 4B 模型显示同样的定性趋势，尽管总体能力水平更低。2B 模型即使对更丰富的反馈也没有有意义的响应：它在全部 60 次运行上保持为零。

更小的托管前沿模型又有不同的行为。gpt-5.4-mini 在持续集成式条件中以 12/15 达到峰值，而不是在预言机或现实自我验证中。这正是基准应当揭示的那种依场景而定的行为。因此，场景这一轴并不只是一个“更容易对更难”的旋钮。它是一块诊断透镜，看出模型如何使用、或未能使用不同形式的反馈。

4.3 共享硬件上的本地模型

只有在仅本地的分析里，墙上时钟才变得有意义。本研究中的全部本地 Qwen 运行使用同一个 pi 框架、同一批任务包、同一个基于 QEMU 的基准环境、同一个 llama.cpp 服务栈，以及同一块 NVIDIA RTX 4090。我们也有意把研究保持在一种 GGUF 4 比特部署机制之内，而不是把量化检查点与更高精度变体混合。即便 9B 模型可以在这块硬件上以更高精度装下，我们仍保持量化，使模型规模和架构仍然是比较中的主要变化因素。

表 5：共享硬件上仅本地的 Qwen 比较，跨三次重复汇集。每个模型的通过分母都是 60。通过一列报告汇集次数、通过率和 Wilson 95% 置信区间。n 提交一列报告有多少次运行至少达到一次提交；平均首次提交时间以这些运行为条件。

译注：表 5 的模型名、Dense 与 MoE 标识以及全部数字格按原文保留，只译表头。通过分母为六十次运行。提交列是至少提交过一次的运行数，首次提交时间只在这些运行上平均。

图 4：共享硬件上本地模型的权衡，显示为并排的两个视图。两个面板都使用通过率而不是原始通过次数，使准确性和资源需求共享一个共同刻度。左面板把通过率与平均首次提交延迟联系起来；右面板把通过率与平均总词元需求联系起来。

表 5 表明，最好的本地点是 27B 稠密模型。它是最准确的本地模型，为 38/60（63.3%），并且在交互上略比 35B-A3B 混合专家模型更有效率。35B-A3B 混合专家模型是主要的反例。它达到 26/60（43.3%），在同一硬件上提交得更早，但准确性更低，平均上也略更消耗词元。在这一基准中，35B-A3B 模型因此看起来像吞吐优势，而不是能力优势。一个说得通的解释是：尽管 35B 模型更大，它是一个混合专家（MoE）模型 [29]，推理期间大约只有 3B 参数同时激活。

2B 模型把这个家族的下界划得更清楚。尽管它是最小的检查点，它在闭环使用中并不是最便宜的点：在其 60 次汇集运行上平均，它每次运行消耗 54.95M 词元、716.3 次工具调用和 29.7 分钟，同时产生零次通过。它所报告的 1.3 分钟首次提交时间不应当被读成效率信号，因为在最终整理的包里，它的 60 次运行中只有八次记录了第一次提交。

图 4 以把两条资源轴分开的方式，使同一排名在视觉上可见。左面板表明，首次提交更快的模型并不必然更好：35B-A3B 模型比 27B 提交得更早，但把它可用运行转化成成功的比例更低；而 2B 在少数真正提交的运行里几乎立即提交，却从未把那转化成成功。右面板把词元的故事隔离得更清楚。当模型规模降到实用运行范围以下时，词元需求急剧上升而不是下降：4B 已经远在 27B 和 35B-A3B 的右侧，2B 仍然是极端离群点。换句话说，这个家族低端的失败模式是不受控制的搜索，而不是简单的吞吐损失。

更小的稠密模型仍然急剧变差。9B 模型在 14/60（23.3%）上仍然有意义，但它已经需要比 27B 模型重得多的搜索，平均每次运行 103.5 次工具调用。4B 模型接近当前基准有用下界：它只达到 5/60 次运行（8.3%），却平均使用 11.55M 词元和 179.2 次工具调用。它更短的平均首次提交时间并不是效率的证据；它很大程度上是过早提交、随后又反复做失败驱动搜索的证据。2B 模型位于那条边界之外：在 60 次运行中，它达到零次通过，在任何场景中都没有解决任何任务，并且被长时间的无提交循环支配，而不是有产出的修复。

按任务的模式指向同一方向。filter_tank_sequence 仍然是套件中最清楚的本地分离器：在每个模型–任务对的十二次本地运行中，它只被 qwen3.5-27B 解决过一次，更小的本地模型从未解决。相比之下，tank_fill_drain 仍然是最容易的本地任务，并且直到 4B 的每一个本地模型都至少解决过一次。与部署最相关的比较，仍然是 27B 稠密模型与 35B-A3B 混合专家模型之间。35B 模型只在 tank_fill_drain 上匹配或超过 27B 模型；它在 thermal_chamber_hysteresis、pressure_vessel_interlock、mixing_tank_fill_heat 和 filter_tank_sequence 上更弱。这强烈表明，稀疏参数的吞吐并不会自动转化成更强的自主嵌入式智能体行为。

家族的低端把同一方向指得更尖锐。2B 模型在每项任务上都是 0/12。在全部 60 个汇集格子上，它不产生通过，并且只在八次运行中记录了第一次提交。因此，我们把 2B 当作有用本地范围的下界，而不是排名中的严肃竞争者，并且在当前研究中不继续向下到 0.8B。

5 讨论

评测结果支持三项主要的解释性主张。第一，主要的 realistic_self_verify 条件是判断自主嵌入式智能体能力最有信息量的镜头。第二，反馈可见性这一轴在诊断上有用，因为它把自我验证与外部指导的修复分开。第三，共享硬件的本地研究改变了部署故事，它显示模型规模如何与延迟、词元需求和搜索行为相互作用。

文中最重要的模型分离模式，是在 realistic_self_verify 下观察到的排序。那一条件最接近预期的基准使用情形，因为智能体必须依赖可见的构建、测试和运行时表面，而不是隐藏诊断。在该条件下，gpt-5.4 以 14/15（93.3%）领先，qwen3.5-27B 在非前沿模型中以 9/15（60.0%）取得最高汇集次数，gpt-5.4-mini 达到 8/15（53.3%），35B/9B/4B 本地变体分别达到 4/15（26.7%）、2/15（13.3%）和 2/15（13.3%），qwen3.5-2B 保持 0/15，并且通常根本未能提交。

这一排序作为描述性结果之所以重要，是因为它在基准的主要条件下揭示出清楚的能力梯度。它把能够真正构建并信任本地证据的模型，与主要在外部搜索信号变得更丰富时才恢复的模型区分开。它也突出一个有实际重要性的点：本地开源权重智能体在基准的主要设定中已经是不可忽略的竞争者。最好的本地模型并没有与前沿模型持平，但它清楚地超出了玩具基线。这正是基准被设计来暴露的那种与部署相关的梯度。

场景这一轴最好被解释为诊断工具，而不是一张单一的单调排行榜。gpt-5.4 在反馈可见性上表现出强但并不完美的稳定性，并且在每一个场景中都最强。在该水平之下，模型对额外隐藏反馈的反应非常不同。gpt-5.4-mini 在持续集成式红绿反馈下改进最多。qwen3.5-27B 在 oracle_full 中最强，并在 realistic_self_verify 中保持有竞争力，这表明它的相对优势并不仅仅是对隐藏反馈的依赖。相比之下，35B-A3B 混合专家模型随着隐藏反馈变得更丰富而急剧改进，这表明一旦评估器把它指向正确方向，它常常能够修复，但难以自行构建一个强的自我验证循环。

这对基准设计是重要的。如果论文只报告一次性生成，它就会错过一个模型能否真正进入工程循环。如果它只报告预言机式修复，它就会夸大自主能力。使用全部四种场景，使直接实现技能、自我验证技能和反馈依赖可以被分开。

仅本地的分析增加了第二条实际教训。一旦硬件和服务受到控制，墙上时钟就变得有意义，由此产生的权衡与跨后端的标题数字并不相同。在一块 RTX 4090 上用 llama.cpp，最好的本地点是 27B 稠密模型，为 38/60 次运行。35B-A3B 混合专家模型首次提交更快，但它在这一基准上并不更好。它的行为与吞吐优势一致，而不是与能力优势一致。

更小的稠密模型也有信息量。9B 模型是一个有意义、但明显更弱的嵌入式智能体。4B 模型看起来接近基准的有用下界，因为它为相对很少的成功花费非常大的交互预算。2B 的结果把那条下界放得更稳：尽管它是最小的检查点，它在实践中更慢，也远更消耗词元，因为它落入长时间的无提交循环。如果一个模型不能在套件上产生通过，甚至不能产生常规提交，那么它就低于基准当前的有用运行范围。这一同硬件分析之所以重要，是因为它回答了托管对本地的比较无法回答的一个实际问题：在固定的本地预算下，本地模型家族中的哪一个成员实际上值得部署。

我们把本地研究保持在一个共同的 4 比特 GGUF 部署机制之内，这一选择也是该解释的一部分。我们不希望精度变化伪装成模型规模效应。一次单独的更高精度消融，尤其是围绕 9B 规模，在未来工作中会有用，但它回答的问题与这里所处理的问题不同。

若干基准设计教训直接来自汇集结果。第一，filter_tank_sequence 是当前套件中的主要分离器，即便强模型通过它时它仍然困难，因此它在做正确的那种工作。第二，tank_fill_drain 作为基线锚点功能良好，因为即便弱模型有时也能解决它。

基准仍然有对解释重要的范围限制。它研究的是单一 ESP32/QEMU 参考栈上、输入输出经 UART 虚拟化的确定性模拟被控对象，这是为了可复现性和可比性而做的有意选择，而不是试图覆盖嵌入式部署的全部复杂性。同样，当前套件有意较小并以控制为中心：五项任务足以在阈值、滞回、顺序和联锁上分离模型，但它们尚未覆盖更广的嵌入式工作负载，例如通信栈、存储、电源管理、中断密集的固件，或更长程的任务逻辑。评测也固定了一个智能体/工具表面和一种共同的本地部署机制，因此所报告的排名应当被读成这一设定中的基准结果，而不是全部编码智能体与架构无关的极限。然而，这些范围选择也正是使研究有用的东西：它们把一个嘈杂而困难的问题变成一个可复现的问题，并且已经产生清楚的能力梯度、有信息量的失败模式，以及可执行的部署权衡。据此，我们把本文看作嵌入式智能体能力的一个强基准基础，而不是最终结论，更广、更现实的评测现在可以在它之上构建。

6 结论与未来工作

本文提出一种在嵌入式固件任务上评测编码智能体的闭环基准方法。成功被定义在所观察到的设备行为这一层，而不仅仅是源代码看起来合理。从散文体工程交接出发，基准问一个智能体能否在现实的、以工具为中介的工作流下，迭代地实现、验证、诊断并修复固件。在这个意义上，主要贡献不仅是一个五项任务的套件，而是一种评测框架：以散文为先、以行为为层次，并且明确以目标执行环境中的自我验证为中心。

经验研究表明，这一基准已经在若干维度上有意义。它可以大规模执行，在确定性仿真栈下可复现，并且有足够的区分度，既能按最终通过率分离模型，也能按它们在迭代搜索中如何使用反馈来分离模型。在 420 次运行中，主要的 realistic_self_verify 条件成为自主嵌入式智能体能力最有信息量的镜头，因为它要求智能体构建并信任自己的本地证据，而不是依赖隐藏评估器的指导。在该条件下，gpt-5.4 的观察通过率最高，为 14/15（93.3%），而 qwen3.5-27B 是观察到的最强本地模型，为 9/15（60.0%）。这一结果在实践上值得注意：27B 本地模型在基准的主要设定中仍然真正有竞争力，尽管它运行在比托管前沿系统小得多、资源也更受约束的部署机制中。

第二个结论是，反馈可见性不只是一个便利变量，而是一个诊断变量。四种场景的设计表明，模型的差异不仅在直接实现能力，也在它们构建自我验证循环的好坏，以及它们为了修复失败而对更丰富的隐藏反馈依赖有多强。有些模型在各场景上保持相对稳定，另一些则只在评估器暴露更丰富的搜索信号时才急剧改进。这使反馈这一轴本身在科学上有用：它帮助把第一遍综合、自我验证质量和外部指导的修复分开，而不是把它们塌缩成一个单一的汇集分数。

第三个结论是实践性的。在共享硬件上的一种共同本地部署机制下，本研究中最好的本地点是 27B 稠密 Qwen 模型。与 qwen3.5-35B-A3B 混合专家模型的比较尤其有信息量：混合专家模型更快达到第一次提交，但稠密的 27B 模型在基准总体上明显更强。在这一设定中，这一对照最好被解释为吞吐与有效能力之间的权衡。更快的提交并不会自动转化成更强的自主嵌入式智能体表现，稀疏激活也不能代替维持可靠闭环搜索的能力。

本地家族的低端强化了同一教训。更小的本地模型不仅在通过率上变差，也在搜索效率上变差；2B 检查点表明，当认真对待闭环交互时，更低的名义模型规模并不必然产生更便宜或更可用的智能体。因此，在这一基准中，关键的部署边界并不简单地是一个模型能否发出看起来合理的代码，而是它能否通过反复验证和修订可靠地收敛，而不落入无产出的搜索。

合在一起，这些结果表明，闭环嵌入式智能体评测应当被当作一个独立的基准问题，而不是静态代码生成的一个小变体。前沿表现之下的主要科学差距，不仅是实现质量，还有稳健的自主自我验证：产生本地证据、正确地解释它，并且只在控制器真正就绪时才停止的能力。这正是本基准被设计来暴露的能力。

关于未来工作，最重要的下一步是把同一方法从确定性仿真带到硬件在环，然后再到仔细受控的真实设备研究。这是基准的主要长期目标，尽管它在实验上难得多，因为只有真实硬件才能充分暴露传感器抖动、通信延迟、看门狗行为、启动瞬态、外设交互和部署打包等效应。因此，当前基于仿真的研究的角色是方法学台阶：它建立一个可复现的基线，面向硬件的评测可以由此以受控方式推进。

与此同时，对本地模型的研究对嵌入式智能体工作流尤其有希望，因为它提供对数据和计算的直接控制，这对隐私敏感、本地部署和工业场景高度相关。因此，未来工作应当继续研究本地模型的运行点、精度机制和智能体/工具表面，以及更广的任务扩展，包括更嘈杂和部分缺失的传感器、延迟或漂移的信号、执行器饱和、重启与恢复行为、多速率控制环，以及更丰富的故障管理场景。合在一起，这些方向会把当前基准从一个单一的可复现套件，变成面向可信嵌入式编码智能体的更广评测计划。

译注：致谢、CRediT 作者贡献声明、利益冲突声明、数据可用性与参考文献因单篇长度上限，刊于同日续篇。