HiMe 精读

问题 · §1

VLA 只看当下，能记事的大模型又太慢

主流 VLA 按马尔可夫假设建模 p(a_t | o_t, l)：动作只取决于当前观测和指令。长程任务里，决定下一步的信息常常已经不在画面里：盒子里装了什么（看过一眼就盖回去了）、碗里已经放了几勺、桌上的玩具原来摆在哪。论文把这类任务称为 non-Markovian。

作者认为现有两条路线各有硬伤：

训练式记忆：给 VLA 加历史 token、辅助损失或记忆库（引言举的是 SAM2Act 等，相关工作把 MemoryVLA 也归在这类策略层记忆里）。受上下文窗口限制，跨几百步优化长程因果依赖也很难。
让大 VLM 当记忆容器：由 LVLM 存取历史轨迹（MemER）。可实时控制就要低延迟，能部署的 VLM 规模就有上限；模型越小，世界知识和零样本能力越弱。

论文把这对矛盾叫作 frequency-competence paradox（正文另一处写作 frequency-capability paradox）：推理强的模型慢到进不了控制回路，快到能进控制回路的模型推理又不够。它的突破口是一句观察：大部分记忆操作本身不需要高级推理，也不需要广泛的泛化。「这个子任务做完没有」只需一个中等 VLM 看几帧就能判断；真正需要大模型的「记什么、改什么、下一步做什么」只在子任务切换时才发生。于是按时间尺度分层，让最贵的模型调用得最少。

原文图 1：左为找 Alice 玩具的示例，记忆随子任务更新；右为三层记忆与三个模块的对应关系 — **原文 Figure 1**左：用户说「找到 Alice 所有的玩具」。机器人先存下文本记忆「Alice 的玩具是鸭子」和视觉记忆「1 号箱是空的」；用户把鸭子放进 1 号箱后，视觉记忆被更新为「1 号箱里有鸭子」。底部的工作记忆只记「子任务 1 完成」「子任务 2 完成」这类进度。右：三种记忆各对应一个模块，Planner（大 VLM，慢思考）读写情景记忆，Sentry（小 VLM，快思考）管工作记忆，Executor（VLA）只用瞬时记忆。

论文还认为，光有静态的分层不够。真实的人机交互有两个特点：一是多模态信息丰富，指令里带着纯视觉轨迹抓不到的约束和偏好，比如「那个红杯子是 Alice 的」；二是高度动态，任务目标和环境状态都会变。只会追加的记忆会堆积过时、互相冲突的条目，所以记忆要能 Add、Update、Delete。

频率阶梯：每一层多久动一次

对数时间轴。圆点为 P50，横线延伸到 P99，竖短线是 P90。控制、推理、Sentry 间隔来自 §4.1；Planner 延迟来自附录表 11；子任务平均时长是我们按附录表 4 的总动作步数 ÷ 子任务数 ÷ 10 Hz 算的。

解读悖论是被「错开」了，不是被消除了

HiMe 没有让 GPT-4o 变快，而是让它的调用频率对齐到子任务的时间尺度。但附录表 11 显示，GPT-4o 单次调用中位 38.59 秒，比一个子任务的平均执行时长（17.1–24.2 秒）还长；换成本地 Qwen3-VL-30B 也要 6.83 秒，约占一个子任务的三到四成。所以「慢」被推到了子任务交接点上。交接时机器人是停下等新子目标，还是继续做别的，论文没有说。

方法 · 三层结构 · §3.1–3.4

三个模型，四种记忆

问题设定：时域 T ≫ 1 的部分可观测序列决策。理想情况下第 t 步的最优动作依赖完整历史 h_t = (o₀, a₀, …, o_t)，但连续处理 h_t 算不动，所以用一个分层策略 π(a_t | o_0:t, l) 来近似。三层从「不带记忆的执行层」到「长程推理层」，逐层用频率换上下文容量。

原文图 2：HiMe 架构，Executor、Sentry、Planner 三行，右侧为情景记忆的上下文记忆和过程记忆 — **原文 Figure 2**从上往下看三行。Executor 行：子目标 + 当前图像 → 动作。Sentry 行：最近若干帧 → Done / Active，同时把观测写进 Buffer。Planner 行：从 Buffer 里**均匀采样 8 帧**（注意不是最近 8 帧）→ Reasoning → Query → 检索到的记忆 → 记忆编辑（Add / Update / Delete）→ Planning。右侧情景记忆分两块：上下文记忆（图文节点，如「Alice likes …」「Toys should be placed …」）和过程记忆（带 [DONE] / [ACTIVE] / [PENDING] 的子任务表）。虚线回路把新计划交回 Sentry 继续监视。

Executor π_e

模型: π0.5，从 DROID 检查点微调
频率: 推理 2 Hz；每次预测 10 个动作（10 Hz），开环执行前 5 个
读: 第三人称 + 腕部两路 RGB，末端位姿与夹爪状态，子目标 τ_t
记忆: 瞬时记忆 𝒯_t = o_t，自身无状态
训练: 60 条示范微调，唯一需要训练的一层

Sentry π_s

模型: Qwen3-VL-8B，本地 1×H100，vLLM，temperature 0.6
频率: §4.1：每 10 个执行步查询一次；§3.4：n_m = 5（单位都没写清，见第 3 节）
读: 工作记忆 𝒲_t（h_s = 8 帧，每帧是腕部 | 第三人称的拼图）+ 当前计划表
输出: <status>done / not_done</status>，即门控 u_t
训练: 零样本，靠提示词

Planner π_p

模型: GPT-4o（OpenAI API）；附录换成 Qwen3-VL-30B（2×H100）
频率: 事件触发：u_t = 1 时调用；另有固定间隔兜底，间隔未披露
读: 指令 l、子任务期间的 8 帧、检索出的记忆、当前计划
写: 上下文记忆（CRUD）+ 过程记忆（计划表）
训练: 零样本，靠提示词

记忆	谁管	存什么	寿命	形式
瞬时 𝒯_t	Executor	当前观测 o_t	一步	原始图像 + 本体状态
工作 𝒲_t	Sentry	最近 h_s = 8 帧观测	滑窗	原始帧，不加工；用于判断子目标是否完成、是否突然失败
情景 · 上下文 𝓔^c	Planner	物体状态变化、空间约束、用户偏好	整个任务，不设上限	多模态键值库：tags + 文字 + 图像路径；按文本键检索
情景 · 过程 𝓔^p	Planner	有序的语言子目标列表	整个任务	纯文本，每行带 done / current / pending

四个公式把三层串起来。Executor 在给定子目标 τ_t 时假设局部马尔可夫：

a_t ~ π_e( a_t | o_t, τ_t )(1)

Sentry 是一个只在 t ≡ 0 (mod n_m) 时开口的门控：

u_t = 𝐈[ π_s(𝒲_t, τ_t) > δ ]　若 t ≡ 0 (mod n_m)；否则 u_t = 0(2)

u_t = 0 时直接跳过高层推理，情景记忆原样保留 𝓔_t+1 ← 𝓔_t。u_t = 1 是一次「交接」，表示当前子目标完成或已失效，Planner 分两步更新：

q_t = f_enc( l, 𝒲_t ),　ℳ_ret = TopK( 𝓔^c_t, q_t )(3)

( 𝓔^c_t+1, 𝓔^p_t+1 ) ← π_p( l, 𝒲_t, ℳ_ret, 𝓔^p_t )(4)

上下文记忆的更新由三种显式操作完成：Add 插入新观察到的事实或用户偏好，Update 修订过时条目，Delete 删掉陈旧或冲突的信息。同时 Planner 合成新的计划 𝓔^p_t+1，从中取出下一个活动子目标 τ_t+1 交给 Executor。

实现（§3.4）：检索后端是向量数据库，用 OpenAI text-embedding-3 编码文本查询，多模态条目和它们的 caption 嵌入一起存，按余弦相似度检索；K 未披露。h_s = 8，n_m = 5。

解读记忆只以一句话的形式到达动作模型

π0.5 不读任何历史，所有记忆都被压缩进子目标 τ_t 这一句话（例如「place the toy duck in left box」）。所以 HiMe 解决的是「下一步该做什么」依赖历史的情况（箱子里有什么、数到第几份、东西原来在哪），而不是「这个动作该怎么做」依赖历史的情况，例如按钮按下前后外观几乎一样（MemoryVLA 的 Push Buttons 例子）。后者在 HiMe 里只能靠 Sentry 判断子任务是否完成来间接处理。

疑点公式和实现有两处对不上

① 式 (2) 写的是「分数超过阈值 δ」，但附录的 Sentry 提示词要求模型直接输出 done 或 not_done 的 XML 标签，temperature 设为 0.6。分数从哪来、δ 取多少都没写。② 式 (3)(4) 里 Planner 用的是 𝒲_t，即最近 h_s 帧；图 2 和 §4.3 却说 Planner 拿到的是整个子任务期间均匀采样的 8 帧，并用这一点解释 HiMe 与 HiMe w/o Sentry 的差距。缓冲区按什么帧率存帧也没写。

交互 · 多频率时间轴

拖动时间，看谁在什么时候读写哪种记忆

下面按论文给的频率模拟一次 Object Search（流程取自原文图 3：先检查左、中、右三个箱子，再把玩具鸭、零食放进对应的箱子，最后按用户偏好把毛绒玩具拿到桌上）。附录表 4 写这个任务有 6 个子任务、约 1450 个动作步。各子任务的时长和记忆条目的具体内容是我们编的示意，字段格式按附录的 Planner 提示词；频率、窗口、调用延迟、召回率是论文数字。

一次 Object Search 里的三层触发

频率 §3.4、§4.1 · 召回率图 7 · 延迟表 11 · 调用次数表 2

Planner 何时被叫醒

Sentry 判定

Sentry 查询间隔（论文写法有三种读法）

Planner 单次延迟

Executor 推理（每 0.5 s 一次） Sentry：not_done done 漏检误报 Planner 调用该次调用读取的 8 帧已完成但未检出等 Planner（假设机器人停住）

放大：光标前后 8 秒。方块 = 一个 10 Hz 动作步，三角 = 一次 Executor 推理；实线括号 = 本次预测里执行的 5 步，虚线 = 预测了但丢弃的 5 步

过程记忆 𝓔^p · 计划表

上下文记忆 𝓔^c · 记录（示意）

解读理想情况下每个子任务只该叫一次 Planner

如果 Sentry 每次都准时报 done，6 个子任务加上开头一次初始规划，共 7 次调用，平均每子任务约 1.17 次。表 2 里 HiMe 的实测是 1.8、2.6、1.4 次。多出来的调用可能来自 Sentry 误报、定时兜底，或用户新指令触发的重规划，论文没有拆分。切到「固定间隔」模式可以看到 Flat Memory 一类做法为什么调用多：Planner 不管进度，按时被叫醒，大部分调用的结论只是「保持当前子任务」。

疑点Sentry 到底多久看一次

§3.4 写「monitoring interval n_m = 5」，§4.1 写「Sentry is queried after every 10 execution steps of π_e」。前者没给单位；后者的「执行步」既可以理解为 10 Hz 的动作步（每 1 秒一次），也可以理解为 Executor 的推理次数（每 5 秒一次）。上面的切换把三种读法都画了出来，召回率低时差别很明显：间隔 5 秒、连续漏检 3 次，就是 15 秒的空转。

方法 · 记忆怎么写 · 附录提示词

一条记忆长什么样，Planner 怎么改它

情景记忆的读写完全靠提示词约束 GPT-4o 输出结构化 XML。附录给出了 Sentry 和 Planner 两段完整提示词，要点如下。

PLANNER 提示词

记录字段：id、tags、data（type, value）、image_path。每条 2–5 个 tag，分三类：物体（toy_duck、left_box）、位置（table、inside_left_box）、用户偏好（user、lily、likes）。
两轮交互：第 1 轮只能发 QUERY，计划表必须为空；第 2 轮根据查询结果发 CREATE / UPDATE / DELETE，并输出最终计划表。
证据规则：记忆只能来自用户明确说过的话或直接的视觉证据；不许编造记忆，信息不够时优先安排一个 inspect 子任务。
状态变了怎么办：CREATE 一条新记录，再 UPDATE 旧记录把它标成「过去」。UPDATE 本身只用于纠正或细化、不改变时间含义；DELETE 要少用，只删重复或错误。
计划表：每行一个子任务，[done] / [current]（只有一个）/ [pending]，可在括号里附一句目的。动作只有两种写法：inspect …，或 pick up <object> <source> and place it to <target>。
查询策略：优先按 tag 查，每次只查一个 tag。

SENTRY 提示词

角色：EXECUTION OBSERVER，唯一的工作是判断当前子任务是否完成。
输入：计划表（带 done / current / pending）+ 最近若干帧拼图，每张左半是腕部相机，右半是第三人称。
判定规则按原语写死：Inspect 在机械臂位于箱子上方或伸进箱子、腕部画面能看到箱内物品和黑色箱底时算完成；Pick & Place 在物体已在目标处松开，或机械臂在箱子上方且能看到黑色箱底时算完成；Reset 在机械臂回到 home 姿态时算完成。
场地配合：箱子内底衬了黑色背景，专门为了提高检测对比度。
输出：只能是 <status>done</status> 或 not_done。

按提示词格式写出的一次第 2 轮输出大致如下（内容是我们按原文图 3 编的示意，字段和标签结构取自附录；图 3 里的子任务写法更简短，如 place the toy duck in left box，这里按提示词规定的格式写）：

<memory_operations>
  <operation><type>UPDATE</type><id>3</id><tags>middle_box</tags>
    <text>(past) middle box was empty</text><reason>user just put a toy into it</reason></operation>
  <operation><type>CREATE</type><tags>middle_box, plush_toy</tags>
    <text>a plush toy is inside the middle box</text><image_path>5</image_path>
    <reason>new object observed in frame 5</reason></operation>
</memory_operations>
<plan_list>
[done] inspect left box
[done] inspect middle box
[done] inspect right box
[done] pick up toy duck table and place it to left box
[current] pick up snack table and place it to right box
[pending] pick up plush toy middle box and place it to table (Lucy likes plush toys)
</plan_list>

解读「Update」其实是「打墓碑」，这解释了消融里差距为什么小

论文正文说的是 Add / Update / Delete，提示词里对应 CREATE / UPDATE / DELETE，外加 QUERY。按提示词的规则，状态变化时不覆盖旧记录，而是新建一条、把旧的标成过去；DELETE 只删重复和错误。所以 HiMe 的记忆实际上接近一份带时间标记的追加日志。消融里的 No Management 只支持 Add 和 Retrieve，把所有观测都追加进去；它和 HiMe 的差别在于没有「过去」标记、也不做取舍，平均只差 4 分（86 vs 90）。和 FIFO 的差距（68 vs 90）才是大头，也就是「别丢早期信息」比「把记忆整理干净」更重要。

解读inspect 把「获取记忆」变成了一个动作

提示词明确要求「不许编造记忆，信息不够就先规划一个 inspect 步骤」，inspect 也是 Sentry 判定规则里写明的三个原语之一。这样，记忆的写入不只发生在「碰巧看到」的时候，而是由 Planner 主动安排机器人去看。这和同专题 SOMA 用可动头部相机先扫描再建记忆、ActiveVLA 主动选视角是同一类思路，只是 HiMe 把它放在了子任务这一层。

疑点检索到底靠向量还是靠 tag

§3.4 说检索用 text-embedding-3 嵌入 caption、按余弦相似度取 TopK；提示词却要求「优先按 tag 查询，每次查一个 tag」。两者怎么配合、K 取多少、tag 查询是精确匹配还是也走嵌入，都没有交代。

实验设置 · §4.1–4.2 · 附录 A–B

一台 WidowX，三个长程任务，每格 20 次

项目	设置
平台	WidowX-250（§4.1 写作 WidowX-250s）+ 平行夹爪；前置 Intel RealSense D435 第三人称相机 + 腕部相机；ROS 集成
控制	控制回路 10 Hz；Executor 2 Hz 推理，每次预测 10 个动作，开环执行 5 个
Executor 训练	π0.5 DROID 检查点 → OpenPI 标准配方微调；共 60 条示范（50 条常规 + 10 条 corner case），主从遥操作采集；AdamW（β 0.9 / 0.999，weight decay 0.1），梯度裁剪 1.0，cosine 衰减，warmup 10k 步，峰值学习率 5×10⁻⁵，batch 256，EMA 0.999，30k 步，动作长度 10
数据处理	两路 RGB 以 25 Hz 采集，缩放到 224×224，时间下采样到 10 Hz，转成 LeRobot 格式
Sentry / Planner	Sentry：Qwen3-VL-8B，1×H100，vLLM，temperature 0.6，max model len 8192。Planner：GPT-4o（API）；补充实验 Qwen3-VL-30B，2×H100，temperature 0.6，max model len 16384
试验	每任务每方法 20 次
指标	Task Progress：完成的子任务占比（正文和图注称「success rate」）；API Calls：平均每个子任务的 Planner 调用次数；Memory Hit：Planner 被调用时所需信息是否在记忆里

三个任务

任务	设置	考的记忆能力	子任务	动作步
Object Search	三个看不见内部的箱子 + 桌上的物品。先检查箱子推断内容，再按内容归置物品；执行中用户往箱子里加新玩具；最后结合偏好取出正确物品	部分可观测下靠主动检查形成记忆；环境变化时持续更新	6	~1450
Counting	几盘食材 + 一张写着配比的菜谱。先读菜谱，按用户要的份数多轮取料；之后用户提出新偏好（换一种豆子），要结合记住的菜谱给出定制配料	持久的语义记忆；跨多轮的累计进度跟踪	7	~1200
Rearrangement	先把桌上散落的玩具收进箱子清洗，过一段时间再放回原处；用户的摆放偏好事先给出	长时保持原始空间布局；执行过程中的一致性	6	~1035

三个任务都额外加入了用户偏好约束（偏爱的物品、不喜欢的食材、摆放规则）。数字来自附录表 3、表 4。

原文图 3：三个任务的用户指令、子任务序列和机器人观测 — **原文 Figure 3**三行分别是 Counting、Object Search、Rearrangement。每行上方是两段用户指令，蓝底标出需要写进**文本记忆**的信息（如「David prefers mung beans to red beans」「Lucy likes plush toys」「the toy bread should be next to the toy croissant」）。中间是子任务序列，灰框是不需要记忆的步骤，绿框是需要记忆才能做对的步骤。下方是腕部（上）和第三人称（下）观测。Object Search 行中段标出了「Update Memory」和「Human Add Obj.」：用户在执行途中往箱子里放了新物体。

六个对照（表 1）

所有设置固定同一个 Executor 和同一个 Planner 骨干，只改 Planner 拿到的记忆上下文和被调用的频率。

设置	触发	Planner 的记忆	说明
Transient Memory	定时	当前观测	按固定间隔 n_m 调用无记忆的 Planner，代表 Hi Robot 一类分层 VLA
Transient Memory w/ Sentry	Sentry	当前观测	加 Sentry 门控，Planner 仍无记忆；考察门控本身带来的规划稳定性
Flat Memory	定时	最近帧 + FIFO	最近 8 帧 + 一个它自己挑过的历史关键帧 FIFO 队列，类似 MemER
HiMe w/o Sentry	定时	最近帧 + 关键帧	完整记忆设计，去掉 Sentry，按固定频率调用
HiMe	Sentry	最近帧 + 关键帧	完整方法
Human High-level	Sentry	人工	每一步由人给出正确子任务，是固定 Executor 能力下的上限

原文图 8：WidowX 机械臂、RealSense 相机、三个收纳箱和实验物品 — **原文 Figure 8**真机布置：前方是 WidowX 机械臂，右上是 RealSense D435，中间三个白色收纳箱，左下是实验物品（毛绒玩具、玩具鸭、零食包、豆子盘）和一张菜谱纸。

解读对照是「同骨架换配置」，不是复现原方法

「类 Hi Robot」「类 MemER」都是作者用同一个 π0.5 + GPT-4o 搭出来的变体，没有用原论文的模型和训练。这让比较更干净（只差记忆和触发），但不能读成「HiMe 胜过 Hi Robot / MemER」。另外，Flat Memory 与 HiMe 同时在触发方式和记忆结构两处不同。

结果 · §4.3–5 · 附录 C

主结果、效率、两组消融和三个附录实验

主结果（图 4）

任务进度（%），每任务每方法 20 次

数字读自原图柱顶标注。「平均」是三个任务的算术平均；原图在平均栏上画的误差线与三个任务之间的标准差吻合，不是试验间的置信区间。

原图数字（图 4）

论文从这张图读出两点。Sentry 本身就有用：即使 Planner 没有记忆，加上 Sentry 平均也从 14 升到 26，因为没有 Sentry 时 Planner 逐帧重新评估，对瞬时视觉噪声过敏，频繁在子任务之间来回切换。记忆是必需的：Object Search 上两个无记忆设置都是 0；Counting 上即使有 Sentry 也只有 23，数过的东西一离开视野就忘了。Flat Memory 虽然存了历史，FIFO 窗口很快被冗余帧冲掉，只有 65。

解读把 90 分拆开看，大头来自 Sentry 这一行

按平均分逐级比较：Transient → 加 Sentry +12；Flat Memory → HiMe w/o Sentry（换成结构化记忆，仍是定时触发）只 +3，Rearrangement 上反而 73 → 66；HiMe w/o Sentry → HiMe +22；HiMe → 人工上限还差 4。也就是说，在定时触发下，结构化记忆和 FIFO 几乎打平，真正拉开差距的是「什么时候叫 Planner，叫的时候给它看什么」。而论文自己也承认，HiMe 与 HiMe w/o Sentry 的差距「很大程度上」来自 Planner 输入从最近帧变成了整个子任务的均匀采样（§4.3），这个消融同时拿掉了触发时机和观测质量两件事。

调用次数与记忆命中（表 2）

HiMe vs Flat Memory

API Call：平均每个子任务的 Planner 请求次数，越少越好。Memory Hit：需要记忆的子任务里，所需信息在记忆中的比例。数字逐字取自 tex 表 2。

HiMe（Sentry ✓ · 记忆管理 ✓ · 不限容量）Flat Memory（✗ · ✗ · 最近 8 帧）

原表数字（表 2）

论文说 HiMe 把 API 调用减少约 3 倍（Object Search 5.4 → 1.8），原因有二：Sentry 把 Planner 从「逐步」调用变成「子任务级」调用；记忆不设上限，不会因 FIFO 遗忘而需要重新探索，Memory Hit 68% → 94%。按表中数字算，三个任务的倍数分别是 3.0×、1.8×、4.4×。

疑点「更低延迟」只有调用次数作代理

§5 Q3 的标题是「为什么 HiMe 延迟更低、调用更少」，正文的论证是「VLM 推理主导延迟，调用少就执行得快」。但全文没有报告任何一个任务的端到端耗时。附录表 11 只给了单次 Planner 调用的延迟，GPT-4o 中位 38.59 秒。表 2 也只比了 HiMe 和 Flat Memory 两行，HiMe w/o Sentry 的调用次数没有给，所以「Sentry 省了多少调用」无法单独读出。

记忆用什么模态（图 5）

只存图 / 只存文字 / 图文交织

数字读自原图柱顶标注。原图纵轴从 50 起画，这里从 0 起画。

Only imageOnly textHiMe（图文）

原图数字（图 5）

两种单模态各有所长：Object Search 需要空间定位和细粒度识别，只存图 86 > 只存文字 74（文字是有损压缩，最初漏看的物体无法再从原图找回）；Counting 需要语义和逻辑，只存文字 91 > 只存图 78。图文结合在三个任务上都最高，但在 Counting（92 vs 91）和 Rearrangement（87 vs 84）上领先很小。

记忆要不要管理（图 6、附录表 9）

FIFO / 只增不改 / 增改删

FIFO：上限 8 条，满了丢最早的。No Management：只支持 Add 和 Retrieve，所有观测都留着。数字读自原图柱顶标注。

FIFO（8 条）No ManagementHiMe

原图数字（图 6）

FIFO 最差（平均 68），说明早期上下文很关键，例如一开始看到的物体位置。No Management 保留全部历史，平均 86，比 HiMe 低 4 分，论文归因于冗余和不一致：过时的状态（物体原来的位置）和当前状态同时在库里，查询时会干扰 Planner。

同样只给 8 条容量时（附录表 9，Rearrangement）

主实验里 HiMe 不限容量，FIFO 限 8 条，两者不对等；附录补了一个同样限 8 条的主动管理版本。

原表数字（表 9）

限容量后主动管理从 87.0 掉到 80.0，但仍比同容量的 FIFO（64.0）高 16 分，说明增改删的收益不只是「容量更大」。

Sentry 看几帧（图 7）

窗口长度 vs 判「完成」的精确率和召回率

以子任务 done 为正类。原图只画了曲线和阴影带、没有数字标注，这里的点是读图的约值；正文写精确率约 76% → 约 82%，召回率约 22% → 约 35%。

PrecisionRecall

窗口从 1 帧加到 8 帧，两个指标都上升：单帧分不清「暂停」和「真的完成」。更值得看的是精确率和召回率之间的大落差，论文称之为 Sentry 的「保守」本性：除非非常确定，否则倾向于判「没做完」。这能避免过早切换，但带来「漏信号」问题，机器人可能做过头或陷入死循环，所以作者加了固定间隔的 Planner 兜底，保证即使 Sentry 一直不触发，循环最终也会被打断。

疑点召回 35% 时，到底是谁在叫醒 Planner

如果每次查询独立、召回 35%，一个已完成的子任务平均要查约 2.9 次才被检出。兜底间隔没有披露，兜底触发和 Sentry 触发各占多少也没有统计。所以主实验里的「HiMe」实际是「Sentry + 定时兜底」的混合体，而「HiMe w/o Sentry」是纯定时。Sentry 用 temperature 0.6 采样输出二值判断，也意味着判定本身带随机性。

附录：换成开源 Planner（图 9，Rearrangement）

Planner = Qwen3-VL-30B 时的三组对比

数字读自原图柱顶标注；柱子顺序与图例相反，按颜色核对过。

原图数字（图 9）

疑点附录说「趋势一致」，但有两处是反的

(c) 记忆消融里 FIFO 70.0 > No Management 63.3，而主实验 Rearrangement 上是 FIFO 64 < No Management 80，正文还据此得出「早期上下文很关键」的结论。(a) 里 Transient Memory 与加 Sentry 的版本都是 25.0（主实验 Rearrangement 是 23 → 56），HiMe w/o Sentry 与 Flat Memory 都是 48.3。HiMe 仍然最高（83.3，GPT-4o 版是 87），但「Sentry 本身就有用」「FIFO 遗忘有害」这两条在开源 Planner 下没有复现。

附录：任务再拉长（表 10）

多轮 Object Search：每轮换一次箱子内容

轮数越多，子任务越多，记忆条数越多。数字逐字取自 tex 表 10。

原表数字（表 10）

三轮时任务进度掉到 66.7%。作者的结论是：长程任务的主要挑战不只是存更多信息，而是在环境变化时保持记忆正确、及时更新。这与 §5 Q3 里「HiMe 维护无限的结构化记忆，避免了遗忘」的说法形成对照：不遗忘不等于不出错。

附录：Planner 延迟（表 11）

模型	P50 (s)	P90 (s)	P99 (s)	平均输出 token
GPT-4o (API)	38.59	49.30	57.28	517.9
Qwen3-VL-30B (local)	6.83	7.93	8.65	532.8
Qwen3-VL-8B (local)	6.10	7.08	11.34	399.0

每次调用包括检索和「生成计划 + 更新记忆」两个阶段，统计的是完整调用的端到端延迟。作者认为差别主要来自部署方式（远程 API vs 本地服务），而不是 token 数。注意表中的 Qwen3-VL-8B 是当 Planner 用时的延迟；Sentry 虽是同一个模型，它的单次判定延迟没有报告。

读懂它

这篇真正说明了什么

关键 insight

1. 大模型的问题常常是「什么时候问」，而不是「问什么」

Transient Memory 的 Planner 没有记忆，只因为逐帧被问，就会在子任务之间来回跳；加一个只会说 done / not_done 的门控，平均从 14 到 26。HiMe w/o Sentry 到 HiMe 又涨 22 分。这些增益都不来自更强的推理，而来自让推理只在该推理的时候发生。

2. 中间层的任务被刻意设计得很窄

Sentry 只判一件事，判定规则按 inspect、pick & place、reset 三个原语写死在提示词里，场地还专门给箱底加了黑色衬底。这是「大部分记忆操作不需要高级推理」这句话的工程落点：把高频的那一层压到足够简单，8B 模型才扛得住。

3. 别丢比整理干净更重要

FIFO 68 → 只增不改 86 → 增改删 90。保留早期信息贡献了 18 分，整理贡献 4 分。限容量时整理才显出更大作用（80 vs 64）。

4. 图和文字各管一类信息

空间、识别类信息丢了文字也找不回，靠图；偏好、配比、顺序这类信息从像素里临时抽很难，靠文字。HiMe 每条记录同时带 tags、文字和图像路径，三个任务都最好，只是在偏语义的任务上图像的增益很小。

容易误解的地方

「90% 成功率」是任务进度。附录表 5 定义 Task Progress 为完成子任务的比例。摘要、结论和图 4 图注都写成 success rate。全部 6 个子任务都完成的试验占多少，论文没有报告。
Sentry 不是记忆本身。工作记忆是一个原始帧的滑窗，Sentry 是读这个滑窗的 VLM。它不总结、不存语义，只输出二值判断，并把帧写进缓冲区供 Planner 采样。
「API 调用减少约 3 倍」只对 Flat Memory。三个任务分别是 3.0×、1.8×、4.4×；Flat Memory 与 HiMe 在触发方式和记忆结构上同时不同。
「弥合与人类的差距」指的是人给子任务的上限。Human High-level 是人替代 Planner 逐步给出正确子任务，Executor 不变，所以 94 是这个 Executor 的天花板，不是人类亲手操作的表现。
「自我纠正知识」没有单独的定量实验。摘要说 HiMe 能按人类偏好自我纠正内部知识，这体现在任务设计里（用户中途加物体、改偏好），没有专门的评测或案例统计。

FAQ

Executor 怎么知道该做什么？

它只接收计划表里 [current] 那一行作为子目标 τ_t，例如 inspect left box 或 pick up snack table and place it to right box。提示词把动作限定为 inspect 和 pick-and-place 两种写法，Sentry 的判定规则里还有一个 reset。Executor 用 60 条示范微调，论文没有说明这 60 条在三个任务、各原语之间怎么分配。

Planner 思考的几十秒里，机器人在干什么？

论文没有说明。附录只写「Planner 只在需要时调用，所以推理延迟与高频控制回路是解耦的」。可是 Sentry 报 done 之后，Executor 需要新的子目标才能继续，按常理只能停下等，或者继续执行已经完成的旧子目标。同专题的 TIC-VLA 正面处理了这个问题：慢模型异步运行，动作策略从不等待，并把延迟作为输入显式告诉策略。

用户的新指令是怎么进入系统的？

引言写「当 Sentry 检测到显著状态变化或用户意图修订时，Planner 主动更新知识库」，但 Sentry 提示词只判断当前子任务是否完成，不处理语言输入。新指令具体通过什么通道、在什么时刻送给 Planner，论文没有交代。

为什么 Counting 上加了 Sentry 也只有 23？

Counting 要按菜谱和份数多轮取料，需要记住已经取了多少。没有记忆的 Planner 在一轮取料之后看不到累计数量，只能按当前画面猜。Sentry 让切换更稳，但补不上这类持久状态，这正是论文用来说明「记忆是必需的」的例子。

换成开源 Planner 掉多少？

只在 Rearrangement 上测过：Qwen3-VL-30B 版 HiMe 83.3，GPT-4o 版 87。单次调用从 38.59 秒降到 6.83 秒。但同一组附录实验里，几条消融的方向和主实验不一致（见结果部分的疑点）。

局限与疑点

作者承认的，和我们读出来的

论文自己提到的

只在真机任务上评测，没有配套的标准仿真基准，受控比较和基准级可复现性受限。
任务主要依赖 pick-and-place 这类简单原语，更多样、更灵巧的技能还需验证。
虽有记忆规模和开源 Planner 的补充分析，但没有充分刻画超长时域、更大环境、长期部署下的表现。
Sentry 召回低，可能做过头或陷入循环，因此需要定时兜底（§5 Q4）。
任务越长性能越低，三轮 Object Search 掉到 66.7%（附录表 10）。

我们读出来的

疑点Sentry 召回约 35%，兜底间隔和两种触发各自的占比都没报告，「Sentry 门控」的贡献无法与定时兜底分开。
疑点GPT-4o 单次调用中位 38.59 秒，长于一个子任务的平均执行时长；没有任何整任务耗时数据，「延迟更低」只用调用次数代理。
疑点附录换 Qwen3-VL-30B 后 FIFO（70.0）高于 No Management（63.3），Transient 加不加 Sentry 都是 25.0，与正文结论相反，附录却写「趋势一致」。
疑点HiMe w/o Sentry 同时去掉了触发时机和「整段子任务均匀采样 8 帧」的输入，消融把两件事混在一起。
疑点Sentry 间隔有 n_m = 5 与「每 10 个执行步」两种写法，单位不明；𝒲_t 的公式（最近 8 帧）与图 2（均匀采样 8 帧）不一致；式 (2) 的阈值 δ 与二值文本输出对不上。
指标名不统一：正文称 success rate，附录定义为子任务完成比例；平均栏的误差线是任务间标准差，没有试验级的方差或置信区间。
Memory Hit 的判定方式（谁来判断「所需信息在不在记忆里」）没有说明。
检索在 §3.4 是嵌入向量 + TopK，在提示词里是逐个 tag 查询，K 未披露。
对照组是同骨架变体，不是 Hi Robot、MemER 原方法；Executor 只用 60 条示范，三个任务各分多少没写。
单一平台、单臂夹爪、三个自建任务，每格 20 次；代码已开源，但任务场地和物品需要自己搭。

放到专题里看

记忆放在策略之外，以文字和图片的形式

在 Harness for Robotics 专题里，HiMe 属于 Persistent State / Memory 一类，改的是「记什么」。它和同类三篇最大的不同在于：记忆完全在策略模型之外，是一个人能直接读懂的外部数据库（tags + 文字 + 图像路径），由一个通用大模型通过显式的增改删来维护，并且只在子任务切换时写入。动作模型本身不读任何历史，只拿到一句子目标。

	HiMe	MemoryVLA	OptimusVLA	SOMA
记住什么	箱子里有什么、东西放到了哪、用户偏好、子任务进度	每一步的感知细节和认知语义	相似任务的整条轨迹（全局先验）+ 刚执行过的动作块（局部一致性）	场景中每个物体的外观特征和 3D 位置
记忆形式	外部键值库，可读的文字 + 图像路径 + tags；外加文本计划表	潜变量：每条 256 个感知 token + 1 个认知 token	任务嵌入 → 轨迹的检索库；Mamba 隐状态	物体级记忆 token（DINOv3 特征 + 3D 框位置编码）
怎么影响动作	只通过一句语言子目标 τ_t	交叉注意力检索 + 门控融合，条件化扩散动作头	替换流匹配的初始噪声；加性一致性偏置	VL token 交叉注意力检索，注入 DiT
何时写、怎么改	子任务切换时；LLM 显式 CREATE / UPDATE / DELETE	每步写入；超过容量就合并相邻最相似的两条	检索库离线建好；一致性记忆每块更新	扫描时建图，之后每步 EMA 更新；新物体追加，未匹配的保留
训练	记忆部分零样本（提示词），只微调 π0.5 执行层	端到端训练（7B Prismatic + DiT）	三阶段训练（π0.5 式 VLA → InfoNCE 先验头 → 一致性模块）	端到端训练（冻结语言解码器）
时间粒度	子任务级，十几到几十秒一次	每次推理	每次推理	每次推理

和 MemoryVLA：两篇都借了认知科学的「工作记忆 / 情景记忆」说法，HiMe 在相关工作里把 MemoryVLA 归为「策略层的检索式记忆库」。MemoryVLA 的情景记忆是网络内部的 token，每步检索、每步写回、端到端训练；HiMe 的情景记忆是外部数据库，只在交接点由 GPT-4o 改写。真机实验两篇都用了 WidowX 和前置 RealSense D435。
和 OptimusVLA：OptimusVLA 的全局先验记忆检索的是别的相似任务的轨迹，用来缩短去噪路径；局部一致性记忆只看上一个动作块。它解决的是「动作生成怎么更快更稳」，HiMe 解决的是「下一步做哪个子任务」，两者几乎不重叠，原则上可以叠加：HiMe 的 Executor 换成 OptimusVLA 即可。
和 SOMA：最接近的一对。两者都是物体中心的记忆，都要先主动观察（SOMA 转头扫描，HiMe 规划 inspect 子任务）再建记忆。SOMA 的记忆是几何化的潜变量，擅长「东西在哪」；它在局限里承认记忆只到物体级，分不清抽屉开 / 关这类语义状态变化，扩展到房间尺度还需要跨空间、时间尺度的分层记忆。HiMe 的记忆是语义化的文字和图片，擅长「东西是谁的、状态变了没有」，但没有任何 3D 几何。
和 Context Architecture 一类：TIC-VLA 面对的是同一个「慢推理 vs 快控制」的矛盾，但做法相反：慢模型（InternVL3-1B）持续异步运行，动作策略从不等待，并把推理延迟和自身位移作为输入告诉策略；HiMe 用事件门控减少慢模型的调用，却没有说明慢调用期间怎么办。RA-VLA 也做检索，检索的是专家示范片段，用来适应新任务，HiMe 检索的是本次任务里自己记下的事实。ActiveVLA 主动选视角和放大，决定这一步「看什么」；HiMe 的 inspect 子任务是同一思路在任务层面的版本，决定「先去看什么、再记下来」。
和（3）结构化执行、（4）评估与反馈两类：MotorMind 和 τ₀-VLA 也在高层维护执行记忆，交给执行层的只是一条子任务或一个动作批次，三篇的调度各不相同：HiMe 由 Sentry 判 done 事件触发 Planner；τ₀ 的高层约每 1 s 异步刷新子任务缓存（低层约 30 Hz），置信度低时才做世界模型搜索；MotorMind 主线串行，Memory Manager 在后台把逐动作日志压成便条，不阻塞执行。三篇都卡在「子任务做完没有」上：HiMe 的 Sentry 判 done 召回约 35%；MotorMind 诊断里通用 VLM 的完成判断只有 47.5–82.5%（二分类），扰动设定下 9% 的回合错误宣布完成；τ₀ 则专门用「记忆滞后 / 超前 / 未察觉的失败」三类扰动样本训练记忆纠错。解读τ₀ 承诺的记忆消融没有给出结果，HiMe 在同一层级骨架下比了无记忆和 FIFO 记忆，在「记忆本身贡献多少」上证据更直接。

术语表

读这篇会遇到的词

展开术语表

non-Markovian: 最优动作依赖已经看不到的过去信息，不能只凭当前观测决定。
frequency-competence paradox: 论文的说法：推理强的模型太慢，进不了实时控制；够快的模型推理能力不足。
Executor π_e: 执行层，π0.5 微调而来，输入当前观测和子目标，输出动作块。
Sentry π_s: 哨兵层，Qwen3-VL-8B，按固定间隔看最近几帧，判断当前子任务是否完成，决定要不要叫醒 Planner。
Planner π_p: 规划层，GPT-4o，读写情景记忆并重写计划表。
瞬时记忆 𝒯_t: Transient memory，只有当前观测 o_t。
工作记忆 𝒲_t: Working memory，最近 h_s = 8 帧的原始观测滑窗。
情景记忆 𝓔_t: Episodic memory，持久存储，分上下文记忆 𝓔^c（图文键值库）和过程记忆 𝓔^p（子任务计划表）。
u_t / δ / n_m / h_s: Sentry 的门控输出 / 判定阈值 / 查询间隔（取 5）/ 工作记忆窗口长度（取 8）。
handover: u_t = 1 的交接事件，表示当前子目标完成或失效，触发 Planner。
CRUD: 提示词里的 QUERY / CREATE / UPDATE / DELETE 四种记忆操作，正文称 Add / Update / Delete。
Task Progress: 完成子任务的比例，本文的主指标（正文称 success rate）。
API Calls: 平均每个子任务的 Planner 调用次数。
Memory Hit: Planner 被调用时，所需信息存在于记忆中的比例。
Flat Memory: 对照组：定时调用的 Planner + 最近 8 帧 + 历史关键帧 FIFO 队列，类似 MemER。
Transient Memory: 对照组：定时调用、只看当前观测的无记忆 Planner，类似 Hi Robot。
Human High-level: 由人逐步给出正确子任务，衡量固定 Executor 能力下的上限。
open-loop 执行: 预测出 10 个动作后不再看新观测，直接执行前 5 个。