速评：这篇的东西不在模型排名上。
10 月 8 日挂上 arXiv 的那篇嵌入式 agent 闭环评测，编号 2610.11447，cs.SE 主分类，顺带交叉到 AI、硬件架构和机器学习。但它不是首发——期刊版本早就落在《Journal of Systems Architecture》第 179 卷，文章号 103937，23 页、4 图、5 表。先过评审，再放预印本。
这个顺序值得单说一句。agent 评测这个圈子里，主流打法是先挂 arXiv 占坑，评审随缘，等被人引用了再回头补一行“已投稿某刊”。反过来做的，说明作者在意的不是抢“第一个”，是想让人引用他的方法。野心不一样。
方法上真正值得看的是那个格子的形状。五个嵌入式控制任务，四种反馈条件——一次性生成、贴近真实的自验证、CI 风格的红绿、oracle 式详细反馈——七种 GPT 与 Qwen 配置，每种组合重复三次。420 次运行，是乘出来的不是加出来的：5×4×7×3，每个格子里只站了三次。
三次。这个数我可以挑，但挑之前先说句公道话：agent 跑一轮烧的是真金白银和时间，嵌入式还得编译、得跑仿真，三次在这个领域不算敷衍，勉强够看。问题不在三次本身，在于别拿相邻两名的差距当结论——通过率这种二值指标，三次重复的波动区间宽得能开过去一辆车。
顺带说五个任务这件事。五个控制任务撑一个基准，覆盖面确实窄，换一篇论文这可能是硬伤。但这篇把力气花在了另一个维度上：任务少，反馈档位正交。五个任务×四种反馈给出来的信息，比二十个任务×一种反馈多。数量不是密度的唯一来源，这话对基准成立，对文章也成立。
格子这么一摆，问的问题就换了。多数 agent 基准问的是“模型会不会写”，这篇问的是“模型能被反馈救回来多少”。同一批任务，反馈从一次性换成 CI 红绿再换成 oracle，中间掉多少涨多少，那才是这张表的信息量。一次性那一档测的是裸着能把需求读懂几成；oracle 那一档测的是有人逐句批改能爬多高。两档之间的差，就是脚手架在这类任务上值多少钱。
作者写得很克制：gpt-5.4 在受测配置里通过率最高，但基准没饱和。
这句我读了两遍。基准论文说“我们没饱和”，动机不用猜——饱和了这张表就作废，作者比谁都清楚。所以这句我默认打七折。七折之后还剩三折，剩下的部分我认：最强配置在 oracle 那种把答案喂到嘴边的反馈下都没打满，说明这几个任务不是靠猜能糊过去的。这条给作者记一分。
然后是我真正想拆的地方：模拟 ESP32。
可复现性上这是唯一的选择——真板子跑 420 次，光烧录工具链的版本地狱就够劝退所有想复现的人。代价是真实嵌入式里最难的那一层被整整齐齐剃掉了：供电抖一下、外设抽风、时序在边界上飘、烧到一半掉线、日志里什么都不报。这些不是“工程细节”，这些就是嵌入式开发的主体。所以这个基准测的是嵌入式控制逻辑的闭环行为，不是嵌入式开发。差一个词，差一整层。
作者自己在动机里写得明白：固件正确性不只看静态源码，还要看感知、时序、安全约束下能不能形成闭环行为。这话没错，也正是这篇比“让 AI 写个 LED 闪烁”高一档的地方。但闭环里少掉的那段现实噪声，恰好是本地小模型最容易翻车的地带。
说到这个。qwen3.5-27B 是这批里最好的本地部署配置，小模型在通过率和搜索效率两头一起掉。作者据此写了一句，大意是具备较强能力的本地嵌入式编码智能体正在逐步成形。
这句结论跑得比数据快。一个 27B 模型，在一个模拟环境、五个控制任务上跑出能看的数字，跟“本地嵌入式 agent”能进产线之间隔着的不是渐近线，是台阶。我读论文最后一段有个习惯，看动词的时态。“正在逐步成形”——进行时，后面通常跟着下一轮经费申请，或者下一版基准。
这跟我前面说给作者记一分不矛盾。夸的是实验设计的诚实，不是结论段的措辞。人是矛盾的，评论员也是。
这里立个 flag：半年之内，一定有人把这张表里最强反馈条件那一列的数字单独拎出来，配一句“某模型在嵌入式闭环任务上达到 X%”，把“oracle 详细反馈”这个前缀省掉。**带脚手架的分数被当成裸模型能力去宣传，一轮一轮地循环，每次都要等社区自己去原文里把条件找回来。**这剧本，眼熟。到时候我回来收。
最后一问：一个基准最有价值的产出，到底是榜首那一行，还是那张同一批任务、四种反馈的对照表？
我的答案是后者。但榜单会被截图转发，对照表不会。做评测的人共同的倒霉之处，大概就在这儿。