通过技能-装置演化的自演化具身智能体

TL;DR SHAPER 让冻结基础模型在零训练下，通过环境 rollout 演化可复用技能与上下文代码执行框架，在 VLABench 和 ESI-Bench 上实现自进化具身智能，性能超越微调与测试时扩展基线。

问题

问题背景

Embodied agents 正逐步构建为围绕 foundation model 的系统，其性能不仅取决于模型权重，还取决于外部技能、上下文、动作接口和执行 harness 等非参数组件。

现有方法局限

• 参数更新路线：通过 supervised fine-tuning 或 reinforcement learning 适配新环境，需要额外收集数据、设计奖励函数并多次训练，成本与工程负担高，且模型部署后难以持续更新。
• train-free 代码中心路线：许多方法依赖可编程机器人 API（如直接生成可执行代码操控机器人），但在固定接口设置（例如仅提供离散动作空间或闭环控制器）中，这些 API 不可用或无法修改，导致方法失效。
• 两者均未系统优化 agent 周围的技能与执行框架，导致改进无法跨任务复用，每次迁移都从零开始。

为什么这个问题难/重要

具身场景中，模型训练往往昂贵、数据稀缺，或部署环境不允许更新权重；同时不同平台的动作接口高度异构，环境反馈稀疏且可能只有成功/失败信号。如何在不触碰模型参数的前提下，通过环境 rollout 积累可复用资产，让 agent 自主改进，是当前具身智能落地的关键挑战。SHAPER 让同一冻结模型同时充当 planner 与 optimizer，通过 rollout 引导的文本诊断和两阶段技能-harness 演化，把改进沉淀到外部技能与 context-code harness 上，为这一问题提供了可泛化的实用路线。

行业类比

类似 LLM 编码 agent 在软件工程中积累可复用工具与上下文代码片段、无需微调即可在固定 CI 环境中持续提升任务成功率，SHAPER 将这条思路迁移到具身动作空间，但需同时应对低层动作接口的多样性与闭环控制约束。

核心洞察

• SHAPER 的核心洞察是将模型参数更新与智能体能力演化解耦，通过冻结基础模型，转而优化围绕模型的可复用技能和上下文代码线束，实现免训练的自演化。这一设计摆脱了对额外训练数据、奖励信号和训练算力的依赖，同时避免了代码中心方法对可编程机器人 API 的硬性要求，使得在固定动作接口环境下也能进行自主改进。与 **SFT** / **RL** 相比无需参数更新；与 code-centric train-free 相比不依赖 API 可编程性，填补了中间空白。
• SHAPER 让同一个冻结模型同时充当规划器和优化器，通过 rollout 引导的文本诊断，迭代生成和优化技能与线束，形成闭环自演化。这一设计与测试时缩放（如投票、验证器选择）不同，后者只是在推理时反复采样而不修改系统组件；SHAPER 则直接修改 agent 的非参数外部记忆与执行逻辑，积累跨任务的改进，因此优化成本可以摊销，并带来持续的性能提升。

方法

输入与整体流程

SHAPER 接收目标环境中的 rollout 轨迹（含任务描述、环境观察、动作序列与奖励信号），以及初始的 非参数化技能集合 和 context-code harness（执行上下文代码）。整个流程保持基础模型参数冻结。

关键模块

1. Train-Free Agent Factorization
   将 embodied agent 分解为 frozen foundation model（负责规划与优化）与 可进化外部组件：可重用技能（skills）和 context-code harness。技能封装可复用的行为模式或知识，harness 管理动作接口与执行逻辑。

2. Rollout-Guided Textual Diagnosis
   利用 rollout 轨迹生成文本诊断报告。模型读取轨迹中的观察与动作序列，输出失败原因、缺失技能或 harness 缺陷等自然语言反馈，作为进化信号。

3. Two-Stage Skill-Harness Evolution
   基于诊断结果，同一冻结模型作为 optimizer 分两阶段迭代更新：

   • 技能进化：生成新技能或修改现有技能，解决诊断出的能力缺口。
   • Harness 进化：调整 context-code harness，优化动作接口适配与执行流程。
     两者交替或按需触发，通过新 rollout 验证改进。

输出

更新后的 技能库 和 context-code harness，使 agent 在新环境中表现提升，全程无需梯度更新或额外训练数据。

与依赖可编程机器人 API 的 train-free 代码方法不同，SHAPER 直接进化技能与执行 harness，适用于固定动作接口的 embodied 场景。

实验

实验设计

SHAPER 在 VLABench 与 ESI-Bench 两个具身基准上评估,覆盖不同底层动作接口。对比方法包括:

• 纯执行(pure execution) 作为 train-free 下界;
• 监督微调(SFT) 作为参数更新代表;
• 测试时扩展 基线:无验证器选择与投票。

所有方法保持基础模型冻结,仅优化外部技能库与 context-code harness。

关键发现

1. SHAPER 通过 rollout 引导的文本诊断与两阶段技能-harness 演化,在两类接口上均优于纯执行,且部分设置下接近或超过 SFT。
2. 在场景偏移下仍保持泛化,并展现出 actor-aware 恢复能力;在 ESI-Bench 上利用 evidence-aware 视觉记忆改善行为。
3. 无需额外训练数据或奖励标注,同一冻结模型同时担任 planner 与 optimizer。

与基线对比解读

相比 SFT,SHAPER 无需参数更新与奖励工程,部署更轻;相比测试时扩展(投票/选择),SHAPER 通过显式积累可复用技能减少重复探索,优化效率更高。这为参数训练昂贵或不可行场景提供了实用的自演化路径。

行业影响

落地场景

SHAPER 适用于任何以基础模型为核心的 具身智能体：机器人操作、仓储物流、服务机器人、自动驾驶交互等，尤其是动作接口固定但环境多变、无法重新训练模型的部署场景。例如 电商仓储拣选机器人 在不同仓库货架布局下，利用 rollout 自动演化出新的抓取/放置技能和 harness 代码，无需重新收集标注数据或微调模型；家庭服务机器人 也可在用户家中通过少量交互自进化出个性化操作习惯。

商业价值

核心是降本增效：

• 省去 SFT / RL 训练成本（GPU、数据采集、人工标注），缩短从部署到适配新任务的周期
• 通过自进化提升任务成功率，减少远程干预和停机时间
• 支持 边运行边优化，使模型资产持续增值；相比投票/选择等 test-time scaling，SHAPER 的优化结果可沉淀为可复用技能库，长期边际收益更高

与现有产品/工作流接口

可作为 非参数适配层 嵌入现有 agent 系统：在推理 loop 外挂接 skill library 和 harness 配置，rollout 日志经诊断器/优化器（同一冻结模型）更新这些外部组件。与现有推理框架（vLLM、Ray Serve）和机器人 middleware（ROS 2）兼容；不改变模型 checkpoint，易于版本管理和回滚；可先 train-free 快速上线，后续有数据时再无缝切换到 SFT/RL。

局限

• **依赖成功信号与文本诊断质量**：**SHAPER** 的演化循环需要从 rollout 中提取可判定的失败原因，其核心是 rollout-guided textual diagnosis。在 **VLABench**、**ESI-Bench** 这类具有明确任务完成判定的模拟环境中，成功/失败信号容易获取；但在真实机器人或开放式任务中，奖励往往稀疏、噪声大或难以程序化定义，文本诊断可能退化为“猜测式归因”。此外，演化过程依赖多次 target-environment rollout，每个优化轮次都需要额外的环境交互预算，若环境重置成本高或实时性受限，实际部署时的总开销可能超过训练一个小型适配器。工程上需要更鲁棒的自动验证机制或人工反馈兜底。
• **实验覆盖与接口扩展性有限**：论文在两个模拟环境 **VLABench** 与 **ESI-Bench** 上验证，二者动作接口虽不同，但都属于相对结构化、可文本描述的离散/低维动作空间。真实 embodied 系统的硬件接口、传感器噪声、连续控制频率、异步执行等远为复杂，**SHAPER** 生成的 **skills** 与 **harness** 能否直接迁移到高维连续控制或需要实时闭环的 task 尚未得到验证。同时，与 **SFT** 的对比基于特定基座模型与数据预算，未说明数据规模扩展到更大时的公平性；不同模型家族对 skill 描述的敏感度也可能影响收益，论文未做跨模型消融。在实际工程项目中，需要先在目标环境上验证该 train-free 优化路径是否比少量 SFT 更具性价比。
• **对比基线中 test-time scaling 覆盖不足**：论文对比了 **verifier-free selection** 和 **voting** 等测试时扩展方法，但未包含近年更成熟的反思/重规划框架（如 **Reflexion**、**LATS** 或带验证器的 search 策略）。这类方法同样可以在不更新参数的前提下利用多次 rollout 改进决策，与 **SHAPER** 的 skill-harness 缓存思路存在更直接的竞争关系。缺失这些基线可能导致对“self-evolving”增益的评估偏高。另外，**SHAPER** 的优化过程本身引入了多个 LLM 调用（judger、summarizer、optimizer 等），其 token 开销与延迟成本在论文中虽有所涉及，但未与端到端训练一个轻量 policy 的长期摊销成本做细粒度对比。对资源敏感的场景，需要更完整的成本-收益模型。