去年有个项目让我印象很深：一台基于开源VLA做抓取和装配的机械臂，仿真里跑得挺顺，一上真机就露馅。同样的抽屉，今天能拉开，明天偏个几毫米就拉不动；换一种没进过训练数据的物料盒，模型直接开始输出怪动作。最让人烦躁的是，同样的错误它每天犯，因为模型权重是冻结的，它根本不会长记性。后来我反复琢磨标题里这句话：“冻结VLA不闭环，基座模型 物理AI 补上记忆”——问题不出在单个模型准不准，而出在我们把VLA用成了开环控制器。
这篇文章我想把几个关键问题讲清楚：VLA到底是怎么组织的，冻结意味着什么；为什么说机器人系统真正要的是闭环而不是单点精度；记忆这个抽象概念在工程上该怎么落成短期、长期、永久三个层次；以及我实际搭过的“基座模型+物理AI+记忆闭环”最小实现是什么样。适合手里正要做具身智能、VLA部署或Agent记忆体系的工程师，也适合想理解物理AI方向为何都在谈记忆的产品和技术负责人。
1. VLA拆解：一个模型还是两个模型，以及“冻结”意味着什么
VLA是Vision-Language-Action的缩写，视觉输入、语言指令、动作输出三合一。很多刚接触的人第一反应是问：这到底是一个模型还是两个模型？答案取决于你采用哪种工程形态，我见过至少三种主流做法，各有各的道理。
1.1 联合动作Token方案
以RT-2为代表，视觉语言基础模型和动作头是同一个模型。模型输入图像和文本，除了预测普通文本token，还会预测一组离散化的“动作token”，比如机械臂末端位置增量、夹爪开合状态。推理时一次前向传播同时完成场景理解和动作生成，语义信息和动作输出共享底层特征。
这种方案的好处是上下文一致性强，语言描述可以直接调制动作预测。缺点也很明显：动作token会占用模型词表，训练时既要维持语言能力又要学动作分布，很多机器人遥操作数据质量参差，容易把模型带偏。
1.2 分离动作头方案
另一种做法是把VLM作为语义理解层，负责任务拆解、场景描述和子目标规划，真正输出关节角或末端位姿的是一套独立动作策略网络，比如扩散策略、ACT或RDT这类。结构上就是“两个模型”，中间通过自然语言或结构化指令衔接。
这种路线工程上最灵活，视觉语言部分可以换任意基座模型，动作策略可以单独调参和部署。代价是接口处容易信息丢失：VLM说“从左侧靠近杯子”，动作策略可能不知道“左侧”在重力坐标系下是哪个方向，两者各自精度高但合起来经常不对齐。
1.3 记忆增强的分离部署
我实际项目里采用的是第三种，也是后续闭环方案的地基：基座VLM负责理解、规划和记忆查询，VLA策略负责高频动作生成，记忆层独立于二者之外。
这个方案里，模型数量不是一个敏感话题，更重要的是分配责任。基座模型提供常识和逻辑，VLA提供肌肉记忆，记忆层负责把历史经验变成上下文注入。粒度上更接近人脑：大脑皮层做推理，小脑做动作协调，海马体存经历。三者不必是一个模型，但必须是一个系统。
1.4 训练链路和“冻结”究竟改变了什么
VLA的常规训练链路分三步：先在大规模图文数据上预训练视觉语言基座，再用机器人操作数据做行为克隆，最后在真实环境中评估筛选。所谓冻结，就是部署阶段把权重锁死，只做前向推理，不反向传播。
冻结的优点是稳定、便宜、不会越调越差；缺点是模型对训练分布的依赖被完全暴露。训练数据里没出现过的光照、物体、接触力特征，模型只能用预训练时的统计先验去猜。猜对了是运气，猜错了就是刚才说的“每天犯同一个错”。
所以我的判断是：冻结VLA不是错，错在把冻结当终点。它应该是闭环系统里一个可以被调用、被记忆辅助、在必要时被微调的组成部分，而不是摆在现场的一尊雕塑。
2. 从双闭环调速到VLA闭环：什么才叫真正跑通闭环
“闭环”这个词在控制领域一点都不新鲜。如果你学过直流调速，一定记得转速外环加电流内环的双闭环结构：外环盯长期目标，把转速偏差换算成电流给定；内环快速响应电流变化，调节PWM输出。两个环路互相嵌套，才有稳和准。
机器人装上VLA之后，很多人觉得自己已经在做闭环了，因为视觉反馈确实进入了策略。但我要说一个扎心的事实：大部分团队只做了内环的“前馈改造”，决策层依然是开的。
2.1 控制理论视角下的VLA系统
如果把VLA跟双闭环调速做一个映射，会清晰很多：
| 双闭环直流调速 | VLA具身系统 | 作用 |
|---|---|---|
| 转速外环 | 任务规划与长期记忆 | 定义目标、判定成败、沉淀经验 |
| 电流内环 | VLA动作生成 | 把当前状态映射成实时动作 |
| 测速反馈 | 视觉位姿/力觉/关节角反馈 | 告诉决策层实际执行结果 |
| PI调节器 | 记忆检索与策略微调 | 纠正偏差、更新知识 |
绝大多数部署场景里，电流内环对应的VLA动作生成是有的，视觉反馈也接了，但反馈只走到PID控制器或运动规划器，没有回流到任务规划层。模型不知道这次抓握实际偏了多少，不知道上一轮失败是因为物体表面材质还是因为接近角度不对。这些信息如果只停留在底层控制环里，那决策层永远是开环。
真正的VLA闭环至少要有五个环节：任务目标设定、动作生成、物理实体执行、结果评估、经验回流。前三个很多人做，后两个几乎被忽略。后两个恰恰是记忆的入口。
2.2 开环运行的必然结果：反复犯同一个错
开环系统的特征是没有校正机制。VLA在冻结状态下，面对一个未见过场景，会输出一个基于统计先验的动作。动作错了，环境给了负反馈，但负反馈没有进入任何可学习的结构，下一轮还是同样的错。
你可能会说：我们可以用人工去改prompt，或者重新标数据训练。可以，但这不叫系统闭环，叫人工兜底。闭环的语义是系统自身具备“感知结果→调整行为→固化经验”的能力，人工只是例外介入。
2.3 为什么闭环必须要有记忆
你可能也注意到了，闭环和记忆几乎是绑定的。没有记忆，反馈信号只是一次性消息；有了记忆，反馈才能变成可查询、可复用、可训练的经验。
这就是“冻结VLA不闭环”的完整含义：模型锁死，反馈不回，经验不留。一个真正意义上的物理AI系统，应该让每次执行都成为下一次决策的输入。基座模型提供通用知识，物理实体提供真实反馈，记忆提供时间维度上的积累——三者缺一，闭环就是空中楼阁。
3. 记忆工程选型：短期、长期、永久以及“4D”多模态记忆
记忆这个词在Agent和机器人圈被说烂了，但落地时大多数人只想到“给模型加个上下文”。我在多个项目里形成了一套比较稳定的分层方法，按持久化程度和存储形式拆成三层，工程上互相独立，又能在推理时协同。
3.1 短期记忆：当前任务的上下文缓冲
短期记忆对应一个任务执行过程中的全部实时信息：相机帧、关节角、力觉数据、语言指令、已经执行过的动作序列。它的特点是生命周期短、写入频繁、对延迟敏感。
实现上短期记忆最简单，就是控制循环里的状态缓存和历史帧队列，喂给VLA时拼接成多帧输入。需要注意的坑是：历史帧太多会撑爆上下文窗口，太少则模型对动态过程没感知。针对高频控制任务，我会按关键帧加事件触发的策略采样，而不是每一帧都留。
3.2 长期记忆：跨会话的经验库和技能库
长期记忆是跨多个任务、多次会话沉淀下来的知识，比如“这个夹具的释放行程要比标称值多3毫米”“上次这样接近玻璃材质导致打滑”。它通常以文本摘要、图像片段、轨迹片段等方式存储，在执行新任务时被检索出来注入上下文。
工程实现上，最常见的是向量数据库加RAG：任务开始前，用当前视觉状态和语言指令做语义查询，返回最相似的几个历史成功案例或失败案例，拼进prompt。这里有个关键词没搜到但很要命：记忆是包括失败案例的。很多团队只存成功轨迹，这是错误的设计，失败案例往往携带更多信息。
3.3 永久记忆：写进模型权重的微调
当经验足够稳定，检索方式反而变成拖累，就应该把它固化进权重。这里用LoRA再加少量真机数据做低学习率微调，比全参数微调安全得多。
永久记忆的定位是“长期使用的高置信度技能”，不是哪里需要就往哪里塞。更新太频繁会灾难性遗忘，更新太少又追不上场景变化。我的原则是：同一类失败模式稳定出现三次以上，且人工确认数据干净，才触发一次微调。
3.4 多模态记忆到底包不包括4D
“多模态记忆包括4d吗”这个问题我被人问过很多次。在机器人语境下，我的回答是：不仅包括，而且4D是必须的。
常规多模态记忆是说文本、图像、音频、深度图混存。机器人记忆比这更进一步，它需要记录随时间演化的三维空间状态，也就是点云序列或体素时序，加上力觉、关节角、速度等物理量。这些数据天然带时间轴，就叫4D记忆。检索时只靠语言和图像做语义相似度是不够的，轨迹形态相似、接触力模式相似的任务往往在语义上毫不相关。所以我建议做双索引：语义索引服务任务理解，时序轨迹索引服务动作层检索。
3.5 Agent记忆框架选型建议
| 记忆类型 | 数据形态 | 存储方案 | 检索方式 | 适用阶段 |
|---|---|---|---|---|
| 短期记忆 | 图像帧、关节角、力觉序列 | 内存环形队列 | 时间窗口读取 | 控制循环内 |
| 长期记忆-语义 | 文本摘要、关键图像、任务标签 | 向量库（pgvector/Milvus等） | 相似度TopK | 任务规划 |
| 长期记忆-轨迹 | 轨迹点序列、力觉时间序列 | 文件系统+时序索引 | 时间/形态匹配 | 动作策略参考 |
| 永久记忆 | LoRA权重、微调检查点 | 对象存储 | 按任务标识加载 | 高置信技能固化 |
这里想强调一点：小规模团队不要一开始就上分布式向量数据库。几百条经验用SQLite加一个轻量embedding模型完全够，等规模到了万级以上再迁移。记忆系统选型的核心是“能撑住数据回流速度”，不是“组件听起来够新”。
4. 最小实现：基座模型+物理AI+记忆闭环实战步骤
这一节给你一套可以直接抄作业的最小方案。整体结构用文字描述：物理AI实体采集状态→记忆写入模块编码存储→评估模块判定成功失败→记忆检索模块从库中捞出相似经验→基座模型结合经验生成任务计划→VLA执行动作→实体执行后产生新状态，周而复始。
4.1 组件选型和连接顺序
我在实际项目里使用了开源VLM作为基座模型，负责视觉描述、任务规划和成功评估；VLA策略选择了一个支持动作token输出的开源模型，负责将高层意图转为底层动作；记忆层是自己写的，包含一个向量索引、一个轨迹文件目录、一组LoRA适配器。
组件之间不通过复杂消息中间件，就是用标准ROS话题加JSON协议。记忆写入模块订阅状态流，任务开始和结束时生成结构化记录；记忆检索模块在任务启动时向基座模型提供相似案例；评估模块由基座模型加一组规则过滤器完成，确保不会把未识别结果直接当成功。
4.2 核心实现伪代码
下面是一个简化但能运行的结构，对应我项目里闭环主循环：
class ClosedLoopSystem: def __init__(self, base_model, vla_policy, memory, evaluator): self.base_model = base_model # 基座模型：规划、评估、记忆查询 self.vla_policy = vla_policy # VLA策略：动作生成 self.memory = memory # 三层记忆系统 self.evaluator = evaluator # 结果评估器 def step(self, obs, lang_cmd): hint = self.memory.retrieve( query=(obs, lang_cmd), top_k=3, include_failures=True ) plan = self.base_model.plan( lang_cmd=lang_cmd, memory_hint=hint, current_state=obs ) action = self.vla_policy(obs, plan) result = self.robot.execute(action) # 评估与记忆写入 success = self.evaluator.judge(obs, lang_cmd, result) self.memory.record(obs, lang_cmd, action, result, success) # 稳定失败触发微调 if self.memory.fail_count(similar_scene=True) >= 3: self.lora_finetune(self.memory.build_dataset()) return action这段代码省掉了并发、ROS回调、传感器同步等细节，但核心思想都在：每次运行都写记忆，每次规划都读记忆，稳定失败才动权重。基座模型负责记忆的读取和任务的制定，VLA只做一个执行组件。
4.3 装配场景的一个实例
用我们做过的抽屉开关与装配任务来说明。初始状态：VLA模型在抽屉场景成功率大约61%，失败集中在推力方向和把手识别误差上。接入闭环系统后，前三天系统每天积累大约五十条带标签的记忆，其中失败样本占三成。
第四天，基座模型在规划时检索到了前两天的失败案例，自动改变了接近角度，成功率升到84%。一周后团队从标定过的样本里取一部分做了一次LoRA微调，成功率稳定在92%，并且对新出现的同型号抽屉保持了泛化。
这个过程中没有调过VLA的推理代码，变化全部来自记忆注入和一次低强度微调。我认为这就是“物理AI补上记忆”最直观的效果。
4.4 触发微调的判定条件
| 条件 | 推荐做法 |
|---|---|
| 同类失败出现3次以上 | 收集失败轨迹，人工标记，准备微调数据 |
| 新场景成功率低于历史基线 | 先扩充记忆检索库，再看是否要微调 |
| 句段场景语义漂移明显 | 优先微调基座模型的指令理解层 |
| 动作层精度不足 | 优先微调VLA策略，不碰基座权重 |
判定参数不用定死，我习惯用失败计数加成功率滑窗双条件，避免单指标误触发。
5. 避坑清单：记忆污染、上下文过载与灾难性遗忘的实战教训
闭环和记忆概念理顺之后，真正的考验都在工程细节里。下面这些坑我踩过不止一次，每一条都对应过实际故障。
5.1 上下文里塞满记忆，模型反而“失忆”
我一开始为了提升成功率，把TopK从3调到了10，想着案例越多参考越充分。结果真实效果断崖式下跌：模型开始混淆多个案例的细节，甚至把失败案例里的错误动作当成示范。
后来发现，基座模型对上下文里的“记忆段落”敏感度很高，数量一多注意力被稀释。调回Top3到5，约束每个记忆案例必须有明确的“成功/失败”标签和场景摘要，效果立刻恢复。记忆注入不是堆料，而是给模型一张“最值得参考的便签”。
5.2 把失败当成功写进长期记忆，污染整个闭环
闭环系统里最可怕的不是失败，而是失败被标记为成功。有一次评估器的判断标准太宽松，大量打滑后的复位动作被当成成功执行，长期记忆库被污染，后来所有任务规划都开始参考错误的经验，成功率反而比开环时更低。
从那以后，我在评估器前后加了双重校验：基座模型给出语义判定，规则层做阈值过滤，比如力觉超限、位姿偏差超限的一票否决。宁可漏标，不能错标，低质量的记忆比没有记忆危害更大。
5.3 成功评估器不可靠，整个闭环白做
评估器是整个闭环的“传感器”，它不准，所有反馈都是噪声。我见过有团队用一个未经过微调的VLM做成功率评估，结果VLM把机械臂执行过程中的正常抖动误判为失败，导致不停重试，机器人能耗骤增。
我的稳定做法是基座模型评估加限定条件：只在任务结束、夹爪释放、工具回位这三个确定性时机触发评估；过程中间帧不参与成功判定。这样可以避免模型被瞬时异常状态误导。
5.4 永久记忆更新太频繁，灾难性遗忘找上门
有一段时间我追求追最新场景，每两天就跑一次微调。到了第三周发现，模型在最初熟悉的场景上表现严重回退，因为是典型灾难性遗忘。
之后我调整了策略：稳定失败三次以上才微调；微调时用低学习率和少量代表性旧数据混合训练。LoRA适配器按场景分工，比如装配场景一个adapter，移动抓取场景另一个adapter，按任务标识加载。这比把所有场景塞进同一个判断空间安全得多。
5.5 记忆检索的模态错位
语义检索对文本有效，但对轨迹形态、力觉模式很不友好。我们曾经检索“硬质表面抓取”，返回了一堆视觉相似的红色物体案例，但其中一半是塑料轻质件，跟任务实际物理特性完全不同。
解决方案是前面说的双索引结构：语义索引用于任务描述，轨迹索引用动态时间规整做运动形态匹配，两类检索结果都进入上下文但分配给不同字段。基座模型看到的是“语义参考”和“轨迹参考”两个清晰分组，混淆概率大幅下降。
在一线做机器人和具身智能项目，最深刻的感受是：模型能力本身已经不算瓶颈，瓶颈在于系统有没有能力把真实世界的反馈消化成可复用的知识。冻结VLA不闭环，做得再好也只是个知识复读机；基座模型给语义解释，物理AI给真实信号，记忆给时间维度，三者拧在一起才是一个会成长的系统。我在实际运行中保留的习惯是每周抽看一次记忆库中的失败轨迹，重点看新故障模式是否被稳定记录；只要记录在滚动，系统就没有死掉。这套方法你也可以从小规模开始试，先记录五十条经验，再谈闭环和泛化。
