Apple 这次放出的 REFACTOR-VLA，第一眼看上去不是“又刷了一个更大的 VLA”那种路径。VLA 在机器人领域通常指视觉-语言-动作模型，是当前机器人大脑的主流技术方向；但前面加了 REFACTOR，后面追了“类型化运动程序库”，整个项目的意思就变了：它更像是要把 VLA 这种端到端黑盒策略做一次架构级整理，把策略训练过程中隐含的运动能力拆出来，整理成一套可复用、可命名、可验证的运动程序模块，而且这个整理过程尽可能不依赖人工标注。
这不单是一个新模型发布，更代表一种技术路线选择。端到端 VLA 虽然效果好，但调试困难：某个动作失败了，是视觉理解问题、语言语义问题、采样策略问题还是奖励信号问题，很难定位。运动程序库的抽象则把动作分解成相当于软件工程里的“函数”，底层策略可以单独训练，上层任务可以用语言模型做组合规划和调度。这个方向如果成立，机器人策略维护会变得更加接近写代码，而不是维护一个谁也不敢动的黑盒权重。
文章会先拆解 REFACTOR-VLA 的设计意图，再解释“无监督学习”和“类型化运动程序库”是如何配合的，最后给出一套可参考的复现评估方案。考虑到目前公开资料只给出了项目概念和标题级描述，具体参数量、显存占用、是否开放权重、API 路径都还不能确定，文中凡是涉及具体数值的部分我会标清楚是通用参考，避免把猜测当成官方结论。
1. REFACTOR-VLA 核心能力速览
先把已知信息和待确认信息分开。下表左侧是项目概念，右侧是我基于命名和关键词形成的判断，凡是项目面还没有明确公开的内容都标注为“待官方资料确认”。
| 能力项 | 说明 |
|---|---|
| 项目名称 | REFACTOR-VLA |
| 发布方 | Apple，机器人学习研究方向 |
| 主要定位 | 通过无监督学习，将 VLA 策略转换为类型化运动程序库 |
| 核心卖点 | 让机器人技能变得可发现、可复用、可组合，降低对人工动作标注的依赖 |
| 技术关键词 | REFACTOR-VLA、无监督学习、类型化运动程序库 |
| 所属技术栈 | 视觉语言动作模型、机器人策略学习、技能发现、运动原语库 |
| 模型参数量 | 未公开，待官方资料确认 |
| 显存占用 | 未公开，待官方资料确认 |
| 是否支持 CPU | 未确认；通用大 VLA 不推荐 CPU 推理 |
| 启动方式 | 未确认，论文阶段一般没有一键启动包 |
| 是否支持 API | 未确认；若有开源推理服务，后续可能通过 HTTP/RPC 方式暴露接口 |
| 是否支持批量任务 | 未确认；运动程序库天然适合批量轨迹复用，但要看官方实现 |
| 适合场景 | 机器人操作技能学习、长时间任务规划、技能复用、多任务组合 |
这个速览表要说明一件事：REFACTOR-VLA 当前更适合被理解为研究型项目，而不是一个拿到手就能pip install的命令行工具。不过机器人领域这类项目通常会在论文发表后陆续放出模型权重和推理代码，值得后续持续跟踪。
2. 适用场景与使用边界
2.1 适合谁使用
如果后续开放源码，目标用户会很明确。
机器人算法工程师可以在 VLA 策略上增加一层“运动程序库抽象”，把单一模型替换成“技能库 + 规划器”的结构，减少每个新任务都重新微调全量模型的需求。具身智能研究者可以重点看无监督技能发现方法，特别是如何从无标签操作视频中提取稳定运动原语。自动化产线应用开发者则更适合把它当成一个技术验证方向，先在仿真环境里跑通任务组合，再决定是否在真实设备上落地。
2.2 能解决什么问题
这类项目最直接解决的问题是“策略复用难”。传统端到端 VLA 面对新任务时，通常需要采集一批新任务的遥操作数据，然后做全量微调。运动程序库的抽象则更像搭积木：抓取、移动、放置、推、拉这些动作如果已经形成了稳定库，新任务只需要在库层面做选择和排序，不一定要重新训练底层动作。
“类型化”还会进一步解决“哪些技能可以安全组合”的问题。如果每个运动程序都有明确的输入输出类型、前置条件和后置条件，规划器可以在调用前做静态检查。比如pick技能要求夹爪打开、物体在可抓取范围内、动作空间是笛卡尔空间；这些约束不满足时，程序库直接返回错误，而不是让模型硬产生一段不合法的轨迹。
2.3 不适合什么场景
如果只是需要一个简单的“图像 + 语言 → 机器人关节角”套路，传统端到端 VLA 可能更省事。运动程序库方式需要额外维护技能粒度、程序签名、库版本，前期工程成本明显更高。
如果任务本身非常短、动作非常固定，也不需要拆技能库。固定点位搬运任务里，写死的控制脚本比 VLA + 程序库方案更稳定、更快、更便宜。REFACTOR-VLA 的价值集中在任务种类多、动作复用率高、需要长程规划的场合，而不是替代传统工业控制器。
2.4 安全与合规边界
机器人动作只要跑到真实硬件上，就涉及物理安全。无监督学习发现的技能可能不稳定，同一个技能在某个物体表面表现良好，换一个材质却出现异常。真实设备测试前，必须先在仿真环境穷举边界条件，再在隔离区域、限速、急停保护的条件下验证。
操作视频和遥操作数据可能包含真实人物、私有空间、物品和未公开的实验室信息。采集数据前要确认数据来源合法，涉及他人的声音、人脸、物品或场所时，需要获得明确授权。不能把未脱敏的真实环境数据直接丢进无监督管线跑技能发现，也不要发布可能泄露他人隐私的轨迹片段。
3. 理解 REFACTOR-VLA：从黑盒策略到运动程序库
3.1 为什么提复杂任务总绕不开 VLA
机器人操作任务原本是“感知 → 规划 → 控制”三段式流程。视觉模块识别物体位置，规划器在状态空间里搜索轨迹，低层控制器负责跟踪轨迹。问题是三段式流程每层都有误差，传递到最后动作很容易失效。
VLA 的做法本质上是把三段式流程压缩成一个网络：输入当前相机图像和任务语言指令，输出动作序列。用大模型的多模态能力同时理解“看到了什么”和“要做什么”，让视觉信息直接参与动作决策，省掉中间物体姿态估计误差。这个路线在抓取、插孔、叠衣物等任务上都验证过效果。
但端到端 VLA 的主要矛盾是数据成本和可控性。训练需要大量“图像 + 语言 + 机器人动作”对齐数据，也就是遥操作记录；而人类给机器人录轨迹时，很难把动作切分成干净的技能单元。网络内部把感知、推理和动作全部揉在一起，遇到边界案例要补充一个技能时，不得不重新准备数据继续微调全量模型。
REFACTOR-VLA 的关键转折就在这里：不是训练一个更大的 VLA，而是训练一个“能从 VLA 行为中提取运动程序的系统”。无监督学习负责自动发现动作数据里稳定的运动单元，类型化负责给每个单元加上类似函数签名的输入输出规范，最终得到的是一份运动程序库，而不是单一策略。
3.2 Re-Factor 的软件工程隐喻
refactor在软件工程里是“重构”的意思：在保持程序外部行为不变的前提下，通过修改内部结构，让代码更容易阅读、扩展和维护。
如果把这个思想迁移到 VLA 上，含义就很清晰了。策略模型学习到的“内部行为”不一定能被人类直接理解，但理论上它可以被重新组织成一组更基础的运动程序，并且重组后外部的任务表现不能下降。这就是 REFACTOR-VLA 名称里最关键的设计主张。
“类型化运动程序库”则是重构的具体产物。普通技能库只有一个个技能的名字和执行代码；类型化技能库会让每个技能带上一组接口声明。库里的技能不再是“可以用”或者“不可以用”这样的模糊状态，而是能够回答“这个技能在什么条件下可以调用、输出空间是什么、完成后环境状态会发生什么变化”。一旦技能变成这种结构，上层规划模型就可以像普通程序调用库函数一样去选择技能。
4. 无监督学习如何建立运动程序库
虽然官方还没给出详细训练流程，但从“无监督学习 + 运动程序库”这个组合，可以推导出一个非常典型的建模思路：从无标签机器人操作视频中发现离散技能，再对技能做语义和类型标注。
4.1 数据形态与自监督目标
可以假设模型的训练输入是大量“操作片段”。每个片段是由连续图像和机器人状态组成的轨迹，它可能有任务级描述，也可能完全没有人工标注。运动程序库学习的第一步，是让网络在重建、预测、对比等自监督目标下学会区分不同的运动阶段。
一个可行的自监督目标是“时序预测”：给出一段观测历史，让模型预测未来若干步的视觉特征或动作特征。机器人同一个运动意图产生的未来特征是相似的，模型会把“抓住杯子”和“把杯子拿起”分开，因为它们对应的未来动作趋势不同。
另一个常见目标是“对比学习”：把同一段轨迹切出的不同片段视为正样本，把来自不同技能阶段的片段视为负样本，让网络学到能够区分运动阶段的状态嵌入。拿到状态嵌入之后，再做一层聚类，聚类中心就对应运动程序库里的频次原语。这个过程不要求人工标签，因此确实是“无监督”的。
4.2 从连续轨迹中切割技能片段
无监督技能发现有一个天然难点：动作是连续变化的，技能边界在哪并不明确。人类看到“抓取并拿起杯子”可能会把动作切成靠近 → 抓取 → 抬起，但机器人记录里只有连续的位置和服务数据。
解决这个问题需要引入一个“运动程序长度”的先验，或者让网络自己学习动作片段应该持续多长。常见做法是用滑动窗口计算相邻时间步在嵌入空间里的距离，距离突增的位置通常就是技能切换点。当机械臂从“前推”变成“抓取”时，动作指令流会出现跳变，这个跳变可以被检测到。
如果 REFACTOR-VLA 的运动程序库设计更精细，它可能会引入层次结构：底层是几秒级别的运动原语，高层是由原语序列组成的复合运动程序。这样长期任务可以被编码成一段由运动程序单元组成的“程序文本”，方便语言模型理解和执行。
4.3 为技能打上语义标签
无监督聚类只能得到簇编号，比如skill_0、skill_1、skill_2，这时候技能库还不可读。要让技能被上层规划器使用，需要把簇映射到自然语言描述。
这一步可以由预训练视觉语言模型或大语言模型完成。收集每一个簇对应的轨迹片段，把关键帧图和动作信息送给多模态模型，让模型生成简短描述，例如“把物体从左侧移动到中心区域”“打开夹爪”“向下按压”。有了语义标签，运动程序库才真正变成能被语言指令调用的“库”。
类型化是在语义标签基础上再加一层结构约束。skill_3只能描述为“靠近物体”，但它需要知道进入该技能的视觉前提、输出动作空间、结束后物体的位置变化。这层结构约束就是第 5 部分要展开的“类型签名”。
5. 类型化运动程序库：给技能写“函数签名”
类型化运动程序库和普通技能库最大的差异，在于每个技能都配有可检查的程序签名。下面用一个概念示例展示它可能的设计方式，这不是 REFACTOR-VLA 的官方定义，而是帮助你理解这类系统应该有的结构。
from dataclasses import dataclass @dataclass(frozen=True) class MotionProgramSignature: name: str input_observation: str action_space: str preconditions: tuple[str, ...] postconditions: tuple[str, ...] supported_objects: tuple[str, ...] = () SKILL_LIBRARY = { "move_to_target": MotionProgramSignature( name="move_to_target", input_observation="single_rgb", action_space="cartesian_velocity", preconditions=("target_visible",), postconditions=("reached_target",), supported_objects=("object_pose_marker",), ), "grasp": MotionProgramSignature( name="grasp", input_observation="single_rgb", action_space="joint_position", preconditions=("gripper_open", "object_in_reach"), postconditions=("gripper_closed", "object_in_hand"), ), "place": MotionProgramSignature( name="place", input_observation="single_rgb", action_space="cartesian_position", preconditions=("object_in_hand", "target_available"), postconditions=("object_placed", "gripper_open"), ), }这种设计最直接的好处是可以写一个类型检查器，只允许满足前置条件的技能被串联调用。
def can_compose(first: MotionProgramSignature, second: MotionProgramSignature) -> bool: required = set(second.preconditions) provided = set(first.postconditions) if not required.issubset(provided): missing = required - provided raise ValueError( f"无法将 {first.name} 与 {second.name} 组合，缺少前置条件: {missing}" ) return True当上层规划器决定执行grasp → place时，类型检查器会检查grasp的完成效果是否能满足place的前置条件。grasp完成后的object_in_hand正好是place要求的前置条件，因此这条组合链合法。如果把move_to_target直接接在place后面，place要求的object_in_hand在move_to_target的后置条件里不存在，组合就会被拒绝。
这层抽象非常实用。规划器不用完全依赖语言模型的“感觉”去猜测技能是否兼容，它可以先靠程序签名做一轮硬约束检查，明显不能组合的技能直接拒绝，再把合法子集交给执行器。
6. 本地部署与复现前的环境准备
由于 REFACTOR-VLA 尚未官方开源，下面给的不是官方安装命令，而是面向机器人 VLA 项目的通用环境准备模板。后续如果官方仓库发布，再根据真实路径替换即可。
6.1 硬件环境
如果你要跑一个带有视觉编码器的 VLA 模型，最好准备一张支持 CUDA 的 NVIDIA 显卡。设备显存建议至少不低于 16GB，如果要做完整训练甚至在 24GB 以上，具体要看你实际使用的模型版本。
REFACTOR-VLA 如果只是提取运动程序库，推理负载可能比直接跑一个 7B VLA 模型低，因为它不需要每一步都让视觉语言模型输出动作，技能库离线建好之后，线上主要只做技能检索和轨迹生成。但这个判断需要官方模型复杂度确认。
6.2 软件环境
建议使用 Ubuntu 22.04 或同类 Linux 系统。Windows 可以跑部分机器人仿真，但很多机器人仿真库和遥操作驱动优先适配 Linux。需要安装 Python、PyTorch、CUDA 工具链和一个机器人仿真环境。
下面是一份通用依赖安装占位模板。
# 创建虚拟环境，版本按实际项目要求调整 conda create -n refactor_vla python=3.10 -y conda activate refactor_vla # 安装 PyTorch，注意跟本机 CUDA 版本匹配 # 这里只是占位示例，具体版本请以 PyTorch 官网选择器为准 pip install torch torchvision # 克隆项目后安装依赖 # 官方仓库地址尚未公布，下面路径需要替换成真实仓库 git clone https://github.com/your_org/refactor-vla.git cd refactor-vla pip install -e . # 安装常见仿真依赖 pip install gymnasium pybullet安装完成后先检查基础设备信息。
import torch if torch.cuda.is_available(): print("GPU 名称:", torch.cuda.get_device_name(0)) print( "显存总量: {:.2f} GB".format( torch.cuda.get_device_properties(0).total_memory / 1024**3 ) ) else: print("未检测到 CUDA GPU，CPU 模式只适合快速功能验证")7. 安装启动与功能测试验证流程
官方代码没有放出之前，建议先围绕“运动程序库”做功能验证测试。无论最终源码长什么样，核心问题都应该是：从无标签轨迹中发现的运动程序能不能稳定复现、能不能组合、能不能跨场景迁移。
7.1 建立测试集
准备一组机器人操作视频。不需要给每一个视频做时间戳级的技能标注，但至少要保证数据里包含多种基础技能。例如抓取、放置、推动、堆叠、拉开抽屉等。记录每个视频的任务级描述，方便后续对比测试效果。
测试集要覆盖不同光照、不同物体颜色、不同起始位姿。无监督技能发现最怕的是把“光照变化”学成一种技能，而测试集正是用来暴露这种问题的。
7.2 技能一致性测试
对同一种运动，用不同观测角度重复测试，看运动程序库是否返回稳定的技能标识。比如“从桌面上抓取红色积木”重复验证 20 次，如果系统每次给出的运动程序都是grasp，那么技能标识一致；如果一半返回grasp、一半返回push，说明无监督聚类边界不稳定。
技能一致性是无监督系统质量的重要指标。簇边界不稳定会让上层规划器无法可靠调用技能。
7.3 组合任务测试
运动程序库的价值在于组合。设计一个两阶段任务：“把积木推倒，再抓起来放到盒子里”。这个任务需要先执行push，再执行pick，最后执行place，测试库是否能自动生成组合链。
如果系统是基于语言模型做规划，输入指令后要观察它能不能输出合法的运动程序序列，而不是直接输出底层关节轨迹。在这里，类型检查器应该发挥作用，拒绝不满足前置条件的组合。
7.4 长程任务测试
REFACTOR-VLA 如果要做长程任务，还需要看错误累积情况。一个包含 40 步的运动程序链，如果每步成功率是 95%，最终成功率只剩约 13%，这显然不可用；每步成功率要达到 99% 以上，长程任务才有实际价值。
测试可以从第 10 步、第 20 步、第 30 步分别注入干扰，例如移动物体位置、改变背景，看运动程序库能不能重新规划后续动作。这类测试能反映技能库的鲁棒性。
下面是一个评估脚本占位示例。
tasks = [ {"instruction": "push the block aside", "expected_skill": "push"}, {"instruction": "pick the block and place it in the bin", "expected_skills": ["pick", "place"]}, ] for task in tasks: result = evaluate_single_task(task["instruction"]) print(task["instruction"]) print(" predicted skills:", result["skill_sequence"]) print(" success:", result["success"])真正跑起来时，evaluate_single_task会替换为项目提供的推理接口。
8. 接口 API 与批量任务设计
如果 REFACTOR-VLA 最终被封装成服务，比较合适的接口不是让调用者直接传一张图获得原始关节角，而是先返回运动程序序列，再返回轨迹信息。这样调用方可以先把任务计划保存下来，再由执行层决定是否执行。
假设你用 FastAPI 封装规划服务，接口形态大致如下：
import requests server_url = "http://127.0.0.1:8000" payload = { "image_path": "/data/input/table_scene.png", "instruction": "put the red cup on the plate", "max_skills": 10, "return_trajectory": True, } response = requests.post( f"{server_url}/plan", json=payload, timeout=60, ) if response.status_code == 200: data = response.json() print("skill sequence:", data["skill_sequence"]) print("trajectory points:", len(data["trajectory"])) else: print("error:", response.text)批量任务适合用数据表驱动。很多需要验证 REFACTOR-VLA 的场景都有现成的 csv 文件，每一行包含一张图像路径、一条指令、一个期望结果。批量执行时要注意位置：设置重试机制、输出日志、保存失败样例。
import csv import time input_rows = [] with open("tasks.csv", "r", encoding="utf-8") as f: for row in csv.DictReader(f): input_rows.append(row) for idx, row in enumerate(input_rows): print(f"处理任务 {idx + 1}/{len(input_rows)}: {row['instruction']}") for attempt in range(3): try: resp = requests.post( f"{server_url}/plan", json={ "image_path": row["image_path"], "instruction": row["instruction"], "max_skills": 10, }, timeout=60, ) resp.raise_for_status() break except Exception as exc: print(f"第 {attempt + 1} 次尝试失败: {exc}") time.sleep(2)批量任务常见的坑包括：长时间连续调用导致显存增长、某一张异常图像让推理服务崩溃、技能序列输出长度不一致。批量代码里要单独保存失败样例的路径和错误信息，方便后续定位。
9. 资源占用、性能观察与排查方法
显存占用现在没有官方口径，但部署时应做三件事：实时观察显存、记录推理延迟、留出余量防止 OOM。
在 Linux 上可以用下面的命令持续监测 GPU 状态。
nvidia-smi --query-gpu=index,name,memory.used,memory.total,utilization.gpu --format=csv -l 1影响资源占用的因素大概率包括：图像分辨率输入大小、运动程序库的序列长度、是否在同一条轨迹上同时运行多个模型、无监督技能聚类时缓存了多少轨迹片段。图像分辨率翻倍，视觉编码器的显存占用可能翻数倍，测试时先从低分辨率开始。
如果出现显存不足，优先检查以下几项：批量大小是否大于 1、图像输入是否过大、是否同时加载了多个模型权重、是否在 PyTorch 里开启了梯度计算。推理阶段要把模型切换到eval模式，并在torch.no_grad()下运行。
常见的部署问题可以参考下面的排查表。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 服务启动后请求超时 | 模型尚未完全加载，或首次冷启动较慢 | 查看服务日志和 GPU 占用 | 服务启动后先发一次预热请求 |
| VRAM 不足 | 图像分辨率太高或同时跑多个模型 | nvidia-smi查看占用进程 | 缩小输入尺寸、关闭历史进程、用 batch_size=1 |
| 技能序列不稳定 | 无监督聚类种子不同或数据分布变化 | 多次运行相同输入对比结果 | 固定随机种子，统一预处理顺序 |
| 规划器无法组合技能 | 后置条件和前置条件不匹配 | 打印类型检查错误信息 | 检查运动程序库签名定义 |
| 调用接口返回 500 | 输入图像不可读或指令过长 | 查看后端异常堆栈 | 检查图像路径和请求字段 |
