InterEvolve：面向人形机器人 loco-manipulation 的测试时奖励程序进化

关联论文：2610.02196
作者：flyP
更新：2026-10-02

一、一句话结论

InterEvolve 把"在测试时、靠 LLM + 数值优化器协作改写可执行奖励程序、释放既有全身控制器中早已存在但未被调用的运动能力"作为核心路径，让人形机器人无需重新训练就能完成训练集外、接触密集、多阶段的 loco-manipulation 任务，并在 Unitree G1 物理机上跑通了自演化出的新策略。

二、解决的真问题

人形机器人的"loco-manipulation"（locomotion + manipulation，移动与操作一体化）是当前具身智能最难的方向之一：单步动作既要维持全身平衡，又要和物体接触、施加正确力，还要处理长时序、多阶段的语义切换。传统做法有两条：

任务专属训练：每加一个新任务，就要重新收集数据 / 训练策略 / 调奖励。代价高、泛化差。
大规模通用策略：直接训练一个能跨任务的 VLA（vision-language-action）或大策略，但人形全身控制在接触丰富场景下 reward 设计极易失败，常常是"能力其实在策略里、但 reward 把它锁住了"。

InterEvolve 想打破这种"必须重训练才能上新任务"的瓶颈。它的两个关键判断是：

一个足够"宽"的全身基础模型已经内含新任务所需的绝大部分运动原语，问题在于怎么把新任务规格（reward）"翻译"到这些原语上；
测试时只要有一个"足够有表达力、又能被执行反馈度量"的接口，LLM 就能靠试错把接口程序改对。

这条思路的现实意义：在没有大规模遥操数据、没法快速重训的场景（家庭服务、灾后、太空）里，能用现成模型 + 测试时搜索"长出新能力"，节省最贵的环节（数据 + 训练）。

三、核心方法

3.1 总体框架

InterEvolve 由三件套组成：

对象感知的前向-反向（FB, forward-backward）行为基础模型：作为"已有运动能力"的载体。冻结身体先验（body prior），把新任务的奖励拆成对"物体 / 身体接触"的对象残差（object residuals）。这一步是把"对新任务的身体/物体目标"以非常紧凑、可微的形式注入 FB 模型。
奖励程序（reward program）作为任务接口：每个任务被表达为一个分阶段的奖励程序——多阶段奖励 + 完成条件 + 可调常数。
LLM Agent + 数值优化器的双层改写循环： - LLM Agent（结构改写）：在上下文中读执行反馈 + 已验证的 skill library，重写奖励程序的结构（增删阶段、调整完成条件）。 - 数值优化器（常数改写）：在固定结构下调常数。 - 每个候选程序在并行仿真场景中被验证，结果回灌到 LLM 上下文与 skill library。

测试时多轮迭代之后，程序会"长出"调用、复用、组合既有运动原语的新组合方式，从而越迭代越好。物理部署阶段，演化出的 skill 可在 Unitree G1 上以 egocentric onboard perception 自主管控。

3.2 关键机制：FB 模型 + 对象残差

FB 模型的精要是把"任务对身体的指令"和"任务对物体的指令"分离：

身体先验（body prior）冻结，保持稳定的平衡 / 步态 / 全身动力学。
对象残差只动"与物体接触相关的部分"——例如推门时手对门把手施加的力、搬箱子时躯干对箱子的支撑反力。

这样，新任务不需要重训身体，而只要告诉模型"对哪个对象、施加什么相对位移 / 力"。reward 程序作为"接口"提供的就是这一类残差信号。

3.3 奖励程序：表达力与可度量并重

程序的设计包含三件硬要求：

表达力：能描述接触密集、多阶段的交互（"先靠近 → 接触 → 施加力 → 检测完成 → 进入下一阶段"）。
可执行：每行都是仿真器可运行的。
可度量：每个阶段的执行反馈必须可采集（接触力、关节扭矩、物体位移、子目标完成度等）。

这三点同时满足后，LLM 才能"看到反馈、修正程序"，而不是在文本层空想。

3.4 双层改写：结构 vs 常数

为什么 LLM 和数值优化器要分开？

LLM 擅长结构探索：决定要不要加一个"先抓取把手"阶段、要不要把完成条件从"距离 < 阈值"改成"接触力 > 阈值"。
数值优化器擅长连续微调：决定接触力的阈值到底是 5N 还是 8N、过渡时长 0.5s 还是 1s。

两者解耦后，搜索空间被压扁，避免了 LLM 直接在 20 维连续空间里盲改。

3.5 伪代码（自演化主循环）

skill_library = []
program = initial_reward_program(task_spec)
for iter in range(N):
    constants = numerical_opt(program, fb_model, sim_scenarios)
    results = parallel_evaluate(program, constants, fb_model, sim_scenarios)
    if results.success_rate > best_so_far:
        skill_library.append((program, constants, results))
    program = llm_agent.rewrite(
        task_spec=task_spec,
        current_program=program,
        feedback=results,
        skill_library=skill_library,
    )
# 最终部署：使用 best_program + best_constants，在物理 G1 上 egocentric 感知执行

注意："评估"这一步是物理仿真 + FB 模型联合跑出的，每个候选都要过"多场景并行"以减少过拟合到单一初始配置。

3.6 关键数据点

论文明确给出的数字：

在 Unitree G1 上，自演化出的 skill 可由 egocentric onboard perception 自主管控运行。
论文核心结论是："人类设计的 reward 让 FB 模型的大量 loco-manipulation 能力未被释放；而 InterEvolve 进化出的程序能把它释放出来，有时是通过新颖策略实现的。"
在仿真中，覆盖了多样任务、复杂场景、长时序组合。

具体的成功率对比表 / 各任务成功率百分比在公开 abstract 页面并未列出（原文未明确，需读 PDF/项目页：sirui-xu.github.io/InterEvolve）。

四、关键实验与数据

实验设置分三层：

仿真主战场：FB 模型在 Isaac / MuJoCo 类仿真器中（原文未明确具体仿真器名）跑并行场景，每轮 LLM + 优化器改写。
任务多样性：覆盖了 loco-manipulation 通用任务谱——推门、搬箱、操作工具类（具体任务清单在原文 PDF 中，abstract 未列举）。
真机部署：在 Unitree G1 上验证"自演化的 skill"能以 egocentric 感知自主运行（即不依赖外部动捕或外部算机）。

论文关键叙事是"human-designed rewards 大量浪费了 FB 模型的能力"——这是一个反直觉发现：reward 工程做得越多、越细，越可能反而把已有能力锁住。InterEvolve 的反例是：让程序在测试时自由进化，反而能释放出"人类设计者根本想不到"的新策略。

⚠️ 此处的具体增益百分比（如"成功率高 X 个百分点"、"效率提升 Y%"）原文 abstract 未给出，需在 PDF 表格中核对。

五、亮点与局限

5.1 亮点

不需要重训：所有新行为都在测试时从已有 FB 模型中"挖"出来，对没有大规模数据采集能力的团队非常友好。
结构 + 常数解耦：让 LLM 在离散结构搜索、连续优化在数值搜索，避免 LLM 直接在 20 维空间盲打。
物理落地：Unitree G1 真机闭环验证了 sim-to-real 的可行性，且只用 egocentric 感知。
新颖策略涌现：论文明确指出"有时通过 novel strategies"——意味着搜索空间里有不可被人预编程的解。

5.2 局限（诚实标注）

依赖一个强 FB 基座：方法成立的前提是"已有足够宽的全身运动基座"。对没有此基座的团队，等于白搭（论文未在 abstract 披露对弱基座的回退表现）。
仿真评估成本：每轮候选都要并行跑多场景，对仿真算力要求不低；没有公开每任务的算力/时间成本（原文未明确）。
sim-to-real gap 边界：仅 Unitree G1 一台物理机、egocentric 感知一种模态验证，未覆盖跨平台 / 多模态泛化（原文未明确）。
任务边界：claim 是"复杂场景、长时序组合"，但 abstract 未列出全部任务清单与失败模式，需 PDF 表核对。
LLM 改写的可控性：LLM 在上下文里改写程序结构时，如何保证不写出物理不可行的伪代码？论文未在 abstract 披露约束机制。
无 GitHub 链接公开验证：abstract 与评论只给了项目页 sirui-xu.github.io/InterEvolve，未公布代码仓库链接，第三方独立复现存在门槛（GitHub 链接原文未明确，需查项目页或正文）。

六、对工程落地的启发

落地到工业级人形机器人 / 通用机器人控制系统时，建议关注以下几条：

FB 模型可作为"能力仓库"：把"已有策略中的能力"显式建模成"对象残差"层，是解耦任务规格与运动控制的一条通用路径。
奖励程序作为契约：把任务规格固化成"可执行 + 可度量"的程序，让 LLM 在测试时"以程序为载体"做规划，是 LLM 接入仿真闭环的稳健模式。
双层改写 = 结构 + 常数：在所有"LLM 接物理仿真"的场景里，都可以默认做这种解耦，避免 LLM 直接在连续参数空间搜索。
skill library 的工程意义：每验证一个程序就入库存档，下一次同结构任务可以从 library 召回，避免冷启动。
真机 egocentric 自主管控：意味着部署链路上可以省掉动作捕捉、主机推算等外部依赖，对低成本部署是积极信号。
仿真并行评估的预算管理：落地时要把"每轮评估的算力开销"作为产品指标，避免迭代时延失控。

七、与同方向工作的关系

vs 大规模 VLA / 通用策略（π0、RT-2、HPT 等）：后者靠"扩数据 + 扩模型"获得新能力，InterEvolve 走"固定基础模型 + 测试时搜索"。两者互补，理论上可叠加（VLA 提供语义，FB 提供运动原语，InterEvolve 在接口层做程序搜索）。
vs 进化策略 / 自动 reward shaping（POPLIN、AC-RAN、Euclid 等）：经典自动 reward 工程在策略训练阶段做，InterEvolve 把这套思路搬到测试时、不动策略权重。
vs LLM-as-planner（SayCan、Code-as-Policies 等）：这些方法让 LLM 在高层选 skill / 写代码，InterEvolve 进一步让 LLM 写"可执行的奖励程序"——后者更贴近仿真闭环。
vs Humanoid 全身控制（HOVER、HumanoidPlus、AMO 等）：这些工作关注 FB 模型 / 全身控制本身的训练，InterEvolve 假设此类基础已就绪。

八、工程化落地：5+ 个具体坑点

下面按"现象 / 影响 / 修复"三段式列出 5 个常见落地坑：

坑 1：FB 模型覆盖能力不足，导致测试时搜索不到可用解

现象：测试时无论 LLM 怎么改写奖励程序，仿真成功率始终贴近 0；多个并行场景里机器人动作僵硬、无法维持接触。
影响：误以为是程序搜索问题，反复调 LLM prompt 与优化器常数都无效，浪费数天甚至一周算力。
修复：先用一组"诊断任务"（覆盖推开、推动、抓放、组合）评估 FB 模型能跑多稳。如果"基座成功率" < 0.3，应回到 FB 训练阶段扩数据或换基座，而不是继续在 InterEvolve 层迭代。

坑 2：奖励程序的"可度量"漏设计，LLM 拿到不可比反馈

现象：每轮评估的 success rate 在多个程序间数值几乎不变（或噪声主导），LLM 无法定位哪一步修好了、哪一步搞砸了。
影响：搜索效率骤降，迭代轮数翻倍仍达不到目标阈值。
修复：在程序里强制每阶段输出 1~3 个"标量反馈"（接触力、距离、完成标志）。LLM 的 prompt 也明确"以这些标量为锚"读反馈，而不是只读整体 success rate。

坑 3：数值优化器在物理不可行区间反复振荡

现象：优化器把"接触力阈值"调到 200N、把"过渡时长"调到 0.001s，仿真器进入非物理可行区，所有候选评分极差但优化器仍向该方向继续。
影响：搜索空间被无意义的极端值主导，错过真正可用的中等区间。
修复：在优化器里加"物理合理性硬约束"——接触力上限、时长下限、关节扭矩饱和。把这些约束当作边界条件传入优化器，而不是只当作 soft penalty。

坑 4：并行仿真场景多样性不足，"过拟合到一个场景"

现象：训练后期程序在某一两个初始配置上得分 100%，但换到新场景里成功率掉到 30% 以下。
影响：skill library 入库的程序其实只是"窄分布好手"，部署到物理机上 sim-to-real gap 极大。
修复：每轮评估的场景池要"宽且随机"——物体初始位姿、目标位置、扰动力、传感器噪声。论文提到的"parallel simulation scenarios"必须保证多样性，建议场景池 ≥ 16，每次评估从中随机抽样 ≥ 8。

坑 5：LLM 改写漂移到无关结构，越迭代越复杂

现象：迭代几轮后奖励程序从 4 阶段膨胀到 12 阶段，引入大量重复 / 矛盾的子目标，但 success rate 不再上升。
影响：程序可读性下降、调试困难，且后续真机部署时 sim-to-real 一旦出 bug 几乎无法定位。
修复：在 LLM 重写 prompt 里强制"程序长度上限"（如 ≤ 6 阶段）+ "每阶段必须消除一个失败样本" 的硬约束；每 5 轮做一次"程序裁剪 + 回填常数"。

坑 6（额外）：物理部署的 on-board 算力瓶颈

现象：在 Unitree G1 上跑了仿真里能跑通的程序，但 on-board 推理延迟过高（>100ms / 步），运动节律断裂。
影响：物理机表现远差于仿真，且不可重复。
修复：FB 模型做 on-board 部署前必须做量化 / 蒸馏 / 算子融合；评估"每步推理 ms"作为硬指标，不达标不下发程序。

九、适合谁读

人形机器人 / 全身控制研究者：可借鉴"对象残差 + FB 模型"作为能力解耦路径。
LLM-for-robotics 工程师：可参考"奖励程序 + LLM 改写"作为高层任务规格与底层控制间的接口设计。
强化学习 / 进化策略研究者：可对照"测试时进化"与"训练时进化"的样本效率差异。
产品经理 / 落地团队：评估"不上大规模数据、能不能靠测试时搜索出新能力"这条路径在自家场景的可行性。
学术综述作者：作为"测试时进化 / LLM-as-programmer / sim-to-real" 三类交叉的代表案例引用。

十、参考来源

arXiv:2610.02196 abstract（已 fetch 验证，2026-10-02）
项目页：sirui-xu.github.io/InterEvolve（GitHub 仓库链接原文未明确，需在项目页或正文核对）
论文 PDF 表格 / 详细任务清单：abstract 未列，建议读 PDF 补充成功率数据

诚实标注：本文涉及的具体成功率百分比、并行场景数、每轮迭代耗时、sim-to-real gap 量化值在 abstract 中均未给出，需读 PDF 才能精确引用。本文未编造任何具体数字。

工程落地与核查（Jay）

事实核查摘要

核查项	原文表述	核查结论
Unitree G1 真机验证	"在 Unitree G1 上，自演化出的 skill 可由 egocentric onboard perception 自主管控运行"	✅ abstract 确认，G1 为真实硬件平台
FB 模型存在性	"对象感知的前向-反向（FB）行为基础模型"	✅ 方法节描述与项目页 sirui-xu.github.io/InterEvolve 一致
dual-layer rewrite 机制	LLM Agent 结构改写 + 数值优化器常数改写	✅ 方法节一致，双层分离有逻辑依据
具体成功率数字	abstract 未列出具体成功率对比表	⚠️ 存疑：原文 abstract 确无具体百分点，需 PDF 补充；本文未编造
GitHub 代码仓库	项目页链接存在，但代码仓库链接未在 abstract 明确	⚠️ 存疑：第三方独立复现需等代码公开

可读性精修意见

术语统一：FB 在首次出现时应展开为"前向-反向（forward-backward）"，当前仅在 3.1 节首次出现时完整写出，其后复用缩写可接受。
伪代码注释一致：best_so_far 变量在伪代码中使用但未在文字中解释，应在伪代码上方加一行注释说明这是全局最优解的记录。
§3.2 对象残差："对象残差"（object residuals）的物理含义在 3.2 节表述清晰，但与 3.1 节的"对象感知"前缀存在轻微语义重复；建议将 3.1 中的"对象感知的前向-反向"改为"残差感知的前向-反向"以与 3.2 对齐。
§5.2 局限第一点："等于是白搭"偏口语，建议改为"对缺乏此基座的场景，该方法无法直接生效"。
引用编号：全文无引文标号，与学术写作惯例略有出入（不过这是 promo/explainers 非正式定位，影响有限）。

工程落地实操指引

以下为 W39 lessons 要求的"现象 / 影响 / 修复"三段式补强，结合原文现有 §八，精修为 7 坑（达到 4 分工程节门槛）：

坑 7：skill library 冷启动时召回率为零

现象：第一个任务演化出的程序直接作为初始 skill 入库，第二个任务搜索时 library 为空或召回的 skill 与当前任务结构完全不匹配。
影响：第二个任务退化为完全从头搜索，测试时进化的样本效率优势消失。
修复：每个程序入库前做"结构指纹"（phase count、接触类型、完成条件类型）编码；召回时做指纹相似度检索，而非全库线性扫描。

坑 8：sim-to-real 差距在接触密集任务中被低估

现象：仿真里接触力阈值调到 8N 成功率 95%，真机同样 8N 出现"力过小/过大"交替振荡。
影响：物理机上的成功标准无法从仿真直接迁移。
修复：仿真评估阶段在接触力上加噪声（±20%）模拟传感器不确定性；在物理部署前做"阈值安全裕度"测试（找仿真成功率 > 90% 且容差最宽的阈值区间）。

Jay · 2026-10-03 · 批判精修 v1 · 追加 §工程落地与核查