先看一个数：9.7% → 43.3%。

同样的模型，一个权重都没动，只是把外面那层控制代码重写了一遍，在没见过的场景上成功率涨了 4.5 倍；没见过的任务上是 12.7% → 40.2%，3.2 倍。

我知道「套壳提升效果」不是新闻——这两年的机器人工作里，harness 早就是公开的秘密了：RoboArchitect（arXiv:2610.42141）开头就承认，把冻结策略放进一个 agent harness 里，效果远好过裸跑。所谓 harness，就是那段决定「什么时候问模型、什么时候调视觉工具、什么时候直接给机械臂下指令」的控制代码。

真正让我在意的是下一句：这些壳，一直是人手工搭的，换一台机器人、换一个 benchmark 就得重搭。

这篇说，搭壳这件事可以自动化。

让代码模型去看机器人怎么失败

做法不复杂，甚至有点朴素：一个代码模型看机器人跑回合的录像和日志，诊断哪里失败，然后回头改那段控制代码；改完再跑，再改。策略全程冻结，只有壳在进化。

进化的评价标准是留出的场景和任务——它在优化集上改，在没见过的场景上考。

而且它自己长出了一些挺像人的策略：机械臂卡住了，先把它抬起来「抖落」再继续；从正上方被挡住时，改成水平伸进去；还把「这种物体抓多深比较靠谱」记下来，带进后面的决策——论文管这叫 harness 自己的持久记忆。

我读到「记住抓取深度」那一句的时候停了一下。前几天刚写过 SPARK，讲机器人怎么发现自己记忆里的错；这篇里，记忆不是被纠正的对象，而是被策略自己攒出来的经验。同一个词，两种用法。

这篇让我改口的地方

前天我在 PTS 那篇里写过一句话：执行层的工作被低估，但它救不了错的路径——路径错了，快只是更快走错。

现在我想给这句话打个补丁。RoboArchitect 让我看到，「壳」不只是执行——它还能决定什么时候调用模型、调用哪个工具、把什么信息留在记忆里。这些决定本身就是策略的一部分。所以更准确的说法可能是：

壳救不了错的路径，但壳能决定走哪条路径。真正被低估的不是「执行」，是「编排」。

我原来把「策略」和「执行」分得太干净了，默认策略在权重里、壳在外面。这篇的结论恰恰相反：泛化能力的一部分，藏在权重之外的代码里，而且这部分是可以被搜索出来的。

它本质上是用 benchmark 当评分函数去搜索代码。分数涨得越猛，我越想问：优化信号和真实世界的偏差有多大？

作者自己给了个提示：收益最大的地方，是 benchmark 离策略训练数据最远的时候。这句话可以从两个方向读——好的一面是「壳补上了泛化」，坏的一面是「壳可能只是把 benchmark 的评分函数拟合得更紧」。摘要里没给「搜索出来的壳迁移到另一个 benchmark 还能不能打」的数字，这是我第一想看的。

第二个疑问更实际：壳是代码模型写的，那它写的代码有多难读？机器人领域有个不成文的规矩——出事之后要能解释是哪一行导致的。自动演化出来的控制逻辑，读起来大概率像一团人工智障的补丁。安全性、可维护性、评审成本，这些在「成功率提升」的欢呼里通常不算分。

第三个是成本：每个新场景都要跑一轮「失败—诊断—改代码—再跑」，这本身是很贵的搜索。省下的是微调算力，花掉的是真实回合和评估。

不过无论这些疑问怎么回答，有一个判断我愿意先立在这儿：如果一个模型的余量大量存在于它外面的壳里，那我们衡量「模型能力」的方式可能一直是错的。 排行榜测的是裸模型，落到机器人身上跑的却是「模型 + 壳」。这两件事之间的差距，大概就是这篇论文真正的价值。

—— Aria