不更新权重，只重写外壳：RoboArchitect 让冻结策略在新场景上提升 4.5 倍

同一个机器人策略，放进不同的”外壳”里，表现可以差出好几倍。这里的外壳不是模型的一部分，而是一段控制代码：它决定什么时候调用策略、什么时候调用视觉工具、什么时候直接给机械臂下指令。过去这类外壳靠人手工写，换一个机器人、换一个 benchmark 就要重写一遍。RoboArchitect 想做的事很直接——把外壳设计本身变成一个可以自动优化的对象。

核心创新

把”策略”与”调度”彻底分开。 论文的前提是：很多失败案例里策略本身没有坏，坏的是调用它的方式。策略只在被问到的时刻输出动作；至于什么时候该问、问之前要不要先调整视角、抓空了要不要先抬一下手臂，这些都属于外壳的职责。RoboArchitect 冻结全部模型权重，只让一个编码模型读 rollout、诊断失败、然后改外壳代码。

用失败驱动搜索，但不在失败的 episode 上收工。 外壳在一组 episode 上迭代演化，随后在留出的场景和任务上评测。这个划分很关键：如果只针对失败的那批 episode 改，外壳很容易退化成对这些具体场景的硬编码；留出集上的数字才是真实收益。

自动写出”像人一样”的控制逻辑。 摘要给了两个例子：手臂卡住时先把它抬离障碍；上方被挡住时改从水平方向接近。这两条都不是模型学出来的动作，而是外壳层面的决策——先改变条件，再调用策略。这说明搜索确实触到了有意义的操作常识，而不只是在调几个阈值。

外壳自己也带记忆。 演化出的外壳维护一份持续记忆，把学到的经验（例如有效的抓取深度）带到后续决策中。系统因此在同一任务族上越用越顺，不必每次从零开始。

实验结果

• 不更新任何权重，未见场景平均成功率从 9.7% 提到 43.3%，约 4.5 倍；未见任务从 12.7% 提到 40.2%，约 3.2 倍。
• 跨多个 benchmark 与多种策略验证，不是单点结果。
• 提升幅度在”benchmark 离策略训练分布最远”的地方最大。
• 以通用策略为底座时，演化出的外壳常常超过在该任务上微调过的专用版本。
• 自动发现的策略包括抬离卡死手臂、遇到上方遮挡改为水平接近，以及把抓取深度等经验写入持久记忆。

“通用策略 + 外壳”打赢”微调专用策略”，是全文最值得注意的结论。微调需要目标域数据、需要重训、还要为每个机器人保存一份权重；外壳只需要 rollout 和一次代码搜索。对产品侧而言，这是两种完全不同的迭代成本结构。

局限性

摘要没有给出搜索成本：需要多少条 rollout、多少轮迭代、调用编码模型多少次，这些都缺席，而它们直接决定这套方法是否真的比微调便宜。43.3% 的未见场景成功率仍远低于可部署水平，说明外壳能补上一部分泛化缺口，但补不完。评测集中在 benchmark 上，真实机器人上的验证在摘要中没有展开。外壳是生成出来的代码，它的失败模式、可读性与安全性都未讨论；当外壳直接给机械臂下指令时，“代码写错了”会变成物理风险。持久记忆能否跨机器人、跨任务迁移，也没有量化。

行业影响

这篇论文把机器人落地的成本重心从”训练”挪到了”集成”。过去换一个工位、换一种来料，常见做法是采数据、微调、回归测试；RoboArchitect 提出的路径是保留同一个冻结策略，让编码模型针对新工位重写调度代码。前者需要 ML 工程师和数据管线，后者更接近传统自动化集成商的工作方式——而集成商恰好是机器人行业里数量最多、离客户最近的一环。

第二个影响在评测。如果外壳能带来数倍差异，那么”某策略在 benchmark 上得多少分”就不再是一个可比的数字，必须连同外壳一起报告。这对论文复现和采购选型都是提醒。

第三个影响在记忆的形态。把”有效抓取深度”这类经验存在外壳里而不是权重里，意味着经验可以像配置文件一样被复制、审查和回滚。对需要审计的工业场景，这比一个黑箱权重更有吸引力。