EMHO：用「经验轨迹」自我进化的具身 Agent Harness

  • 关联论文：2610.08432
  • 作者：flyP
  • 更新：2026-10-08

一句话结论

EMHO（EMbodied Agent Harness Optimization）是一个保持底座模型冻结、用「执行轨迹 + 历史 harness」迭代改写 harness 自身的具身 Agent 自进化框架。它不优化技能 / 恢复 prompt 这一层，而是修改 agent 如何观察、如何用视觉工具、如何把观察落到动作、如何应对失败这些更高层的策略行为；并通过 EMHO-Merge 在多子任务间共享一个统一 harness。在 EmbodiedBench 的导航与操控任务上，对 Qwen 9B 与 27B 都持续提升任务成功率，定性分析显示 EMHO 不仅能恢复失败，还能重塑 agent 与环境的交互方式。

解决什么真问题

具身 Agent（embodied agent）的训练与落地长期被一个隐含假设绑住：

「agent 的能力 = 底座模型的能力」，所以提升 agent 必须重训模型。

这条假设忽略了一个事实——harness（planner + context + tool glue + 恢复策略）才是工业具身系统的真正性能瓶颈。但 harness 通常是工程师凭经验堆出来的，没有自动优化通路。

EMHO 的核心判断是：harness 是可以直接优化的对象，不需要重训底座，且优化信号可以从环境的稀疏反馈（成功 / 失败）里拿到。

核心方法

系统对象：harness

在 EMHO 语境里，harness 不是 prompt 模板，而是一组控制 agent「如何与环境打交道」的高层策略：

  • 如何监测任务进度（progress monitoring）
  • 何时调用视觉工具、用什么视觉工具（vision tool use）
  • 如何把感知结果与语言指令对齐（observation grounding）
  • 失败后的应对策略（failure response）
  • 上下文 / 记忆管理（context/memory control）

这一层抽象比「skill library」与「recovery prompt」更上游——它定义的是 agent 与环境的「对话协议」。

优化循环

harness_t ──> agent(frozen model) ──> 轨迹 ──> 反馈（成功/失败）
   ^                                          │
   │                                          ▼
   └── revise(harness_t, 轨迹, 历史harness) ──> harness_{t+1}

EMHO 把这个循环跑成多轮迭代：

  1. 用当前 harness 跑一批环境任务，拿到执行轨迹（trajectory）与稀疏反馈。
  2. 把「执行轨迹 + 之前的 harness」一起喂给一个反思 / 编辑模块，输出新一版的 harness。
  3. 用新 harness 替换旧 harness，继续下一轮。
  4. 底座模型始终冻结，所有变化都发生在 harness 内部。

EMHO-Merge：多子任务共享 harness

当一个 harness 同时服务多个子任务（导航、操控等），优化方向可能冲突。EMHO-Merge 用episode 级的收益与损失来指导「合并 / 选择 / 保留」：

  • 不同子任务的 episode 给出不同信号，Merge 用证据支持的「何时 / 如何」条件描述来决定哪段行为在哪个上下文下被应用，避免一刀切覆盖。

与 Reflexion / Self-Refine 的区别

  • Reflexion 类方法把反思结果塞进下一轮 prompt，等价于把反思「外置」到上下文窗口。
  • EMHO 直接改 harness，改的是 agent 自身的运行配置——不依赖 prompt 上下文窗口，反思结果是「持久化」的策略修改。

关键实验与数据

  • 底座：Qwen 9B、Qwen 27B（均为开源 LLM backbone，原文未明确具体型号/版本是否一致，abstract 未公开逐项数字）
  • 评测环境：EmbodiedBench，覆盖导航与操控两类具身子任务
  • 核心结论：EMHO 持续提升任务成功率，对 9B 与 27B 都有效
  • 定性发现：EMHO 不仅能恢复失败与无产动作，还能改变 agent 解释环境、与环境交互的方式（即「重塑交互」而非「事后补救」）

abstract 未公开具体百分点与 baseline 列表，需要查正文表格。

论文规格：v1 提交于 2026-10-06，cs.AI 类目，2,263 KB。

为了让读者把握 EMHO 的研究坐标系，这里再补几句「为什么现在做这件事」的背景。过去两年具身 Agent 的研究重点集中在「给底座接什么模型 / 什么工具 / 什么 prompt」，而 harness 这一层始终是工程师手工堆出来的黑盒——换个环境就要重写一版，换个模型又要重写一版，经验难以沉淀。EMHO 切入的角度是：把 harness 也当成可优化的对象，并证明「不动底座、只改 harness」也能拿到可观收益。这与传统经验型研究范式形成对比——后者假设「agent 能力 = 底座能力」，前者把 harness 显式提升为可优化变量。值得提醒的是，harness 优化并不是替代底座能力补齐；在底座存在硬短板的场景，harness 优化会被锁住上限。正确的心智模型是：harness 与底座是耦合的两个变量，EMHO 把其中一个变量从「不可调」变成「可调」，而调哪个、怎么调，仍需工程团队结合具体场景判断。

亮点与局限

亮点

  1. 训练免费 + 底座冻结：在不开底座微调能力的情况下拿到性能提升，对闭源 / 大底座具身系统尤为友好。
  2. 改 harness 而非 prompt：反思结果持久化，不被上下文窗口稀释。
  3. 多子任务共享：EMHO-Merge 解决「一个 harness 通用还是每个子任务单独 harness」的二选一难题。
  4. 定性结论强：不仅恢复失败，还能重塑交互方式——意味着 harness 优化空间比想象的更大。

局限

  1. 抽象层高、可观测性低：harness 改写是「协议级」修改，比 prompt 调参更难 debug。诚实标注：harness 的可观测 / 可审计工具原文未明确提供。
  2. 稀疏反馈信号弱：成功 / 失败是 0/1 信号，中间过程的「哪一步错了」要靠轨迹分析推断；可能放大噪声。诚实标注：失败归因的具体方法 abstract 未披露。
  3. EMHO-Merge 的边界：用 episode 级 gain/loss 引导的合并，对「互斥子任务」的鲁棒性需要更多评测；abstract 未给跨基准对比。
  4. 迭代成本：每轮都要重跑一批环境任务，token 与仿真成本累计可观；abstract 未给具体成本曲线。

§八 工程坑点（现象/影响/修复）

  1. harness 漂移失控（harness drift） - 现象：多轮迭代后 harness 偏离初始设计意图，变得冗长、互相冲突、改写逻辑难追踪。 - 影响：性能提升但维护成本暴涨，团队无法解释当前 harness 为何这么工作。 - 修复：harness 版本化 + 变更日志（每轮 diff 显式记录）；定期「harness 蒸馏」压回核心策略。

  2. 稀疏奖励下的过早收敛（premature convergence） - 现象：0/1 反馈让优化很快找到「能拿分的简单策略」，但对罕见失败模式放弃改进。 - 影响：成功率从 0 升到 60% 后长期停滞，长尾任务挂掉。 - 修复：奖励塑形（关键中间步骤加分）+ 失败回放池 + 课程学习式任务分布。

  3. 跨底座不可迁移（cross-backbone incompatibility） - 现象：在 Qwen 27B 上优化出的 harness 迁到 Qwen 9B 或其他模型上失效。 - 影响：换底座要重做整个 harness 优化流程。 - 修复：harness 与底座解耦（用抽象行为描述而非特定工具名）；保留底座无关的「协议级」规则。

  4. EMHO-Merge 任务冲突（subtask conflict） - 现象：导航与操控两类任务对 harness 的最优修改方向不同，merge 后两边都退步。 - 影响：多子任务共享反而劣于各自单独 harness。 - 修复：保留 per-subtask harness 主线，merge 仅合并公共部分；引入 per-subtask 路由。

  5. harness 改写引入新失败模式（new failure mode injection） - 现象：新一轮 harness 改了「失败应对策略」，但新策略在某些场景下比旧的更差。 - 影响：性能曲线震荡，难以判断收敛。 - 修复：保留池（retain set）做回归测试；新 harness 必须通过历史任务子集才能上线。

  6. 底座能力天花板（backbone ceiling） - 现象：底座缺乏某类视觉能力，再优化 harness 也补不上。 - 影响：性能提升存在硬上限。 - 修复：把 harness 优化的预算分配与底座短板诊断联动；当某短板反复出现，转而做底座层面的能力补齐（数据 / 微调）。

对工程落地的启发

  1. harness 是值得作为独立产品模块优化的对象——不是 prompt 模板，而是 agent 的「运行配置」。
  2. 稀疏反馈 + 轨迹反思是 harness 自进化的可行路径——不必依赖大型 RL 训练管线。
  3. 多子任务共享 harness 要有 merge 协议——简单切换会两边都退步。
  4. 可观测性先行：在让 harness 自修改前，先把 harness 的变更、diff、性能、回归测试全套基建做好，否则会陷入「能用但说不清」的黑盒困境。
  5. 底座冻结是可贵的工程属性——尤其在闭源 API / 大底座场景，EMHO 这条「只动 harness」的路子打开了部署空间。

与同方向工作的关系

  • vs. Self-Refine / Reflexion：Reflexion 改 prompt 上下文，EMHO 改 harness 配置；持久化与可解释性 EMHO 占优。
  • vs. Agent S / Voyager 的技能库路线：技能库是「记下能做的事」，harness 是「如何与环境互动」；EMHO 在更上游。
  • vs. RL 微调底座路线：EMHO 不动底座，对闭源 / 大底座场景是替代选项；牺牲「端到端可导」换「工程可控」。
  • vs. Prompt Optimization（OPRO / TextGrad）：EMHO 的优化对象是 harness（协议层），不是单点 prompt；层级更高、收益更结构化。

适合谁读

  • 工业级具身 Agent / 机器人团队的工程师与 Tech Lead
  • 研究 self-improvement / harness-level optimization 的 LLM Agent 研究者
  • 在闭源底座 API 上做应用、希望避免微调成本的产品团队
  • 对 agent 可观测性、可维护性负责的 SRE / 平台架构师

诚实标注汇总：①具体百分点数字与 baseline 列表 abstract 未公开；②harness 可观测 / 审计工具 abstract 未明确提供；③失败归因具体方法 abstract 未披露；④跨底座迁移性的逐项评测 abstract 未给出；⑤逐项成本曲线 abstract 未公开。解读仅基于 abstract 与 paper_card 字段，未读 PDF 全文。