去年有一段时间我几乎把全部工作时间都耗在调试一台六自由度机械臂上。抓取任务本身并不复杂真正让我头疼的是每次换个新任务比如从“把黄色积木放到左边”换成“把螺丝按颜色分到三个盒子里”我都得重新采几十条示范轨迹、重新跑一遍微调流程再花小半天盯着它在仿真环境里打滚。次数多了我就忍不住想人换活儿干师傅演示一遍就能上手凭什么机器人换个任务就得“重读一遍书”后来我认真接触了具身智能领域的 In-Context Learning上下文学习之后才真正看到解法给模型看一段视频它可以直接学会新任务全程不更新任何权重。这篇文章就把我理解的原理、踩过的坑、以及实际能落地的边界一次性说清楚。先解释一下标题里的关键词落在哪里。具身智能不是只让模型“看懂”世界而是要让它在真实物理空间里做出动作。In-Context Learning 最早火起来是在大语言模型里给模型看几个输入输出示例它不用改参数就能按示例的规律回答新问题。把这个思路搬到机器人上就变成给模型看几段“视频帧 对应动作”的示范它下一次再看到类似场景时直接模仿示范里的行为输出动作指令。也就是说机器人的“学会”从“重新训练”变成了“重新给上下文提示”。这个概念听起来很美好但落地过程中有不少反直觉的细节。下面我按五个部分拆开讲从为什么需要它到它内部怎么工作再到真正部署时最容易翻车的地方。1. 为什么“看一段视频”能成为机器人学习的新范式1.1 传统模仿学习的闭环到底慢在哪里过去做机器人操作任务主流路线是模仿学习。流程大致是先用遥操作设备控制机械臂完成目标动作同时记录关节角度、夹爪状态和相机画面采集几十甚至上百条轨迹然后离线做行为克隆或者微调一个预训练模型最后再部署回机械臂上验证。这套流程每一步都耗时遥操作采一条轨迹可能要几分钟采完还得人工筛掉失败样本微调一轮怎么也要半小时到几小时部署之后如果发现某个环节不对又得从头再来。更麻烦的是这种“数据-训练-部署”的闭环对每个新任务都完全重来一遍。机器人领域有个很现实的观察真实世界的任务分布是长尾的每个具体任务的出现频率都不高但你又必须都能处理。今天让机器人分拣螺丝明天让它叠毛巾后天让它倒水。如果每个任务都要独立采数据、独立微调那这个系统的边际成本会越来越高最后根本没法维护。1.2 任务切换成本才是真问题我在实际项目中最大的感受是模型精度不够虽然烦人但更致命的是任务切换成本。工厂里换一条产线意味着换一组动作物流场景里换一种包裹意味着换一套分拣策略家庭场景更夸张用户随口提出的需求几乎没有重样。传统微调路线在这种场景下很不划算。你可以用 LoRA 这类参数高效微调省一点算力但数据采集、清洗、验证这些人工环节是省不掉的。每次切换都等于给机器人“重新上了一次学”而不是“换一张答题卡”。一旦任务数量从几个涨到几十个这路子基本就走不通了。1.3 核心转向不改权重改提示In-Context Learning 的做法恰恰绕开了这个瓶颈。它的思路是模型本身已经通过大规模预训练学会了物体识别、空间关系、基础操作模式这些“常识”全部存在权重里。当你要它执行一个新任务时不需要重新教它这些常识只需要在输入里放几个示范告诉它“当前这个场景下你要按这个方式做”。打个比方这就像公司里来了个经验丰富的老师傅你不需要把他送回去重新读大学只需要给他说一句“这批货按昨天的那个流程走只是东西换成了螺丝”。他会自动复用已有的经验而不是从零开始学什么是螺丝、什么是分拣。机器人 ICL 就是这个道理预训练给了机器人“常识”上下文示例给了它“当前任务的提示”。理解了这一层后面看技术细节就不容易迷路。接下来我拆一下模型内部到底怎么把一段视频“变成”动作指令。2. 从“视频”到“动作”VLA 模型里的上下文到底长什么样2.1 大语言模型的 In-Context Learning 如何迁移到具身领域先回忆一下大语言模型里的 ICL 是什么样。你给模型一段话“中文你好英文Hello。中文谢谢英文。”模型就能输出“Thank you”。全程没有梯度更新只是把示例拼在输入前面模型自动按示例的映射规律补全输出。这个能力的基础是模型在预训练阶段见了太多类似的中英对照文本所以上下文示例只是帮它“调出”了已有的翻译能力。具身智能领域的 VLA 模型也就是 Vision-Language-Action视觉-语言-动作模型把同样的事情换了一种模态。输入不再是纯文本而是“图像 语言指令 历史状态”输出不是文字而是机械臂的动作参数。ICL 在这里表现为把“视频帧序列 对应的动作参数序列”作为示例放到真实场景的输入前面让模型“照着示例的样子”输出当前场景的动作。2.2 输入侧视频帧、语言指令、状态观测怎么拼成一个序列一个典型的输入序列长这样先是系统提示词说明“你是一个机器人操作模型”之类的角色设定然后是一段语言指令比如“将红色方块放到蓝色盒子里”接着就是示范内容示范里包含若干帧图像和每一帧对应的动作 token最后是当前真实场景的图像和状态模型需要在这里继续生成动作 token。这个序列在模型内部会被切分成三部分图像帧通过视觉编码器变成视觉 token语言指令通过文本编码器变成文本 token状态信息比如关节角度、夹爪开合度则要么文本化要么通过一个小型 MLP 编码成状态 token。所有 token 拼在一起进入 Transformer 做自回归预测。模型看到的“上下文”就是这些 token 组成的完整序列它要学的规律是看到什么画面下一步该做什么动作。我在实践里用过一种比较稳的拼法把每一条示范切成若干“步”每一步包含一帧图像、一组状态 token、一组动作 token。这样模型看到的不是一段连续视频而是类似于“当前画面 我做了什么”的操作笔记。任务示例越多模型对规律的把握越准但序列长度也会越长这个矛盾后面单独讲。2.3 输出侧动作是怎么被当作“文本”生成的VLA 模型最巧妙也最容易让人困惑的地方在于动作输出。模型本身是 Transformer只能输出离散 token。所以动作参数会被离散化把机械臂末端的目标位置、姿态、夹爪开合度这些连续数值分别映射到有限多个区间里每个区间对应一个离散编号。然后模型像生成一句话一样逐个生成动作 token最后再把 token 解码回连续数值发给机械臂控制器执行。这里有个细节值得注意模型生成的动作是“绝对目标位姿”还是“相对位移”对最终效果影响很大。相对位移往往更稳因为模型不需要从头预测一个绝对坐标只需要预测“从当前位置往哪个方向移动多少”。这和写代码是一个道理增量修改永远比重写整个文件安全。所以我的经验是在把动作离散化之前先把它转换成相对上一时刻的差分再去做分箱。2.4 为什么“放进上下文”比“微调权重”更适合任务切换有人会问直接把所有任务都拿去微调模型不是更省事吗为什么非要用 ICL这里我列一张表对比一下对比维度微调权重In-Context Learning数据需求每个任务几十到几百条轨迹每个任务几条到十几条示范即可算力需求需要 GPU 训练耗时按小时计推理时完成按秒计无需训练任务切换速度重新采集数据、训练、部署流程长换一段上下文提示即可参数变化模型权重被改变可能影响旧任务权重不变旧任务能力不退化风险过拟合新任务遗忘旧任务上下文长度受限复杂任务可能学不会关键结论是ICL 不是用来替代微调的它是用“推理时灵活性”换取“训练时成本”。如果你的任务稳定不变、只追求单任务精度那微调仍然更合适。但如果你追求的是多任务快速切换ICL 的优势非常明显。理解了模型内部的输入输出之后接下来要面对的是最不性感但最要命的环节数据管线。模型结构再先进数据处理不好也白搭。3. 真正决定成败的是数据管线不是模型结构3.1 示范视频怎么变成“上下文”轨迹 token 化的完整步骤很多人第一次上手 ICL 时以为直接把视频丢给模型就行。实际上模型吃不了原始视频你需要先把视频处理成“帧序列 动作序列”的结构化上下文。我建议的流程分四步统一采样频率。采集视频时可能用 30fps机械臂控制周期可能是 50Hz两端不一致。先把示范轨迹重采样到一个固定步长比如每 0.2 秒取一帧画面对应一个动作向量。动作向量归一化。如果动作是末端位姿包含位置和欧拉角量纲完全不同直接分箱会导致姿态维度几乎不变化。先把每个维度缩放到 -1 到 1 之间再离散化成 256 个 bin效果会稳定很多。拼接状态信息。关节角度、夹爪开合度这些本体感知信息要并进去单独靠视觉很难判断夹爪到底有没有夹住物体。截断和打包。把长轨迹切成固定长度的小段每段不要超过模型的上下文窗口上限。我当时用一套很简单的 Python 脚本处理这些步骤核心就是标准化轨迹格式。处理完之后模型看到的“一条示范”就是一组帧-状态-动作三元组和文本 ICL 里的“输入-输出对”是一个概念。3.2 动作坐标系与归一化跨机器人迁移的第一道坎数据管线里最容易被忽略的是坐标系问题。机械臂动作可以定义在关节空间也可以定义在末端笛卡尔空间笛卡尔空间又可以分为机械臂基座坐标系、相机坐标系或者世界坐标系。同一段示范在不同的坐标系下数值完全不同。模型学习的是输入到输出的映射规律如果训练和推理时的坐标系不一致上下文示例不仅没用反而会误导模型。更隐蔽的情况是相机位置发生微小偏移。有一次我把相机支架从左边挪到右边重新录了一段示范没做任何位置校准结果成功率从七成掉到三成。后来排查了半天才发现模型在上下文示例里看到的像素坐标和真实场景的像素坐标之间出现了一个固定的偏差它学的“画面的位置对应动作”规律全都偏了。我的建议是优先把动作统一到机械臂基座坐标系而不是相机坐标系。基座坐标系不受相机位置影响只要机械臂本身没被挪动示例和真实场景就在同一个参考系里。如果必须用相机坐标系那就得每次运行前做一次标定别偷懒。3.3 上下文窗口的长度预算示例数量、帧率和截断策略Transformer 的上下文窗口是有限的图像 token 很占地方。一张 224x224 的图切成 16x16 的 patch一个 patch 一个 token一张图就有 196 个 token。如果你给 10 条示范每条示范 8 帧图像光图像就将近 16000 个 token窗口很容易爆掉。所以上下文预算必须精打细算。我的经验法则是每条示范最多 4-6 帧采样间隔均匀覆盖整个任务过程。动作 token 控制在 128 个以内每条示范代表“一个阶段”而不是“完整轨迹”。任务示例数量控制在 2-4 条超过 4 条对精度的提升开始边际递减反而增加计算量。如果任务本身很长把它拆成多个子任务分别用独立的上下文处理而不是塞进一条超长上下文。这么做背后是有原因的ICL 的本质是让模型提取“任务层面的规律”而不是“逐帧背答案”。示范太多太密模型学到的更多是具体场景的像素匹配而不是抽象的操作意图泛化性反而下降。3.4 数据质量的优先级宁可少而准不要多而杂在微调阶段你还能指望模型从大量数据里自动消除噪声。但在 ICL 阶段上下文里每个示范都是“给定答案”模型会不加区分地模仿。所以数据质量比数量重要得多。我会严格按照三个标准筛选示范任务必须成功完成中途不能有掉落、卡顿、纠正动作。视角和光照必须稳定不要一段亮一段暗模型会把亮度当成规律。物体初始位姿要有一定差异如果所有示范的方块都在画面正中间模型遇到方块在边角时就会不知所措。数据筛选这一步不要省宁可一条示范用三次也别放一条半失败的进去。我踩过最痛的坑就是示范里有一段机械臂在目标位置上反复抖动模型学成“到了位置还要抖动几轮”部署时机器人抓完东西也要抖两下才松手看着像得了帕金森。数据这关过了模型在测试集上的表现一般都不会太差。但真实部署又是另一回事下面讲三个我在跑通整套流程后遇到的坑。4. 我把整套流程跑通后的三个坑和对应解法4.1 坑一相机位置漂移导致所有示范“失效”第一次做完整验证时我搭了一个测试台一台机械臂、一个向下俯拍的 RGB 相机、几块积木。早上的测试结果还可以到了下午成功率突然从 80% 掉到 35%。最初我怀疑是模型泛化能力不行重新录了两条新示范再测结果还是不行。排查到晚上才发现是固定相机的支架螺丝松了相机向下偏移了大概两厘米。两厘米在人眼看来无足轻重但模型从像素里学到的“物体的像素位置与动作的映射关系”全部错位了。这个问题不能靠模型自身解决只能从源头控制。我最后的处理是把相机改成固定支架并用定位销锁死每次开机跑一个标定检查对比棋盘格角点位置偏差超过几个像素就报警停止。从那以后我所有部署环境都强制加了这个标定保护宁可让任务停下来也不让模型在错误参考系里盲跑。4.2 坑二夹爪开合状态没进上下文模型靠“猜”抓取第二个坑很隐蔽。我的示范视频里机械臂去抓方块夹爪收拢然后抬起来。测试时我发现模型经常在“夹爪已经合拢”之后还继续执行“合拢动作”或者明明没有抓住物体却直接进入抬起环节。看画面夹爪手指间有没有缝隙其实是能看出来的但模型没在利用这个信息。问题出在输入序列里只有图像和动作没有夹爪状态 token。模型无法从图像稳定推断夹爪当前的开合状态尤其当光照变化产生阴影时判断错误率直接升高。解决办法很简单把夹爪开合度数值归一化之后作为一个标量 token 拼接在状态序列里每帧更新一次。加上之后抓取环节的成功率从 62% 直接升到 89%。这个改动只花了我半小时效果却异常显著。这个坑给了我一个重要的教训别高估视觉模型的推理能力模态再丰富也顶不上显式输入一个传感器读数。能直接用编码器拿到的状态就不要让模型从像素里猜。4.3 坑三上下文过长时自回归动作“越走越歪”最后这个坑出在推理阶段。当任务比较复杂、示范帧比较多的时候模型生成动作序列越到后面越容易乱。一开始我以为是模型容量不够后来检查生成的动作 token 概率分布发现越靠后的动作 token 置信度越低而且生成轨迹和示范轨迹的偏离在后期明显放大。核心原因是自回归生成本身的误差累积。模型每个动作 token 都基于之前生成的所有 token前面一个 token 有微小偏差后面就会越来越大。尤其当动作表达使用绝对位姿时误差累积得更明显。我的解决思路有两条把动作改成相对位移。模型每次只预测“当前状态下下一步该往哪动”而不是预测一个终点坐标。这一步就把误差从绝对值累积换成了差分累积稳定性高很多。控制上下文长度不追求一次生成整个长任务。我把长任务按语义阶段切开比如“靠近-抓取-抬起-放置”各算一个子任务每个子任务用独立的 ICL 上下文完成完成一个阶段后重新观测状态再进入下一阶段。这两条合在一起基本消除了越走越歪的问题。代价是任务切换时我需要写一个简单的阶段状态机但比起重新微调模型这点代价完全可以接受。5. 判断边界什么样的任务才值得用 In-Context Learning5.1 适合的场景同一本体、任务族内快速切换在我目前的测试里ICL 最适合的场景集中在这几个特征上机械臂和夹爪不变任务属于同一个操作族任务之间的差异主要靠视觉区分接触物体时对力度要求不高。举几个典型的例子分拣不同颜色的零件、把物体摆到指定位置、按形状分类、简单的码放和整理。这些任务用 ICL 的效果都很好因为预训练模型已经具备了抓取和放置的基本能力上下文示范只是指定了“当前要选哪个目标、按什么顺序做”。这类场景里给 2-3 条视频示范就能达到可用水平任务切换只需替换上下文不重新训练非常适合快速原型验证和小批量定制需求。5.2 不适合的场景新本体、强接触动力学、安全关键任务ICL 不是银弹我踩过坑之后对它有了明确的边界认知。以下情况我会主动绕开情况为什么不适合换了一台机械臂或夹爪运动学完全不同上下文里示范的关节动作和目标机器人不匹配模型难以跨本体迁移需要精确力控的任务拧螺丝、插孔、打磨这些任务需要持续接触力和触觉反馈纯视觉做不了ICL 也补不了任务时序极长上下文窗口有限动作链太长必然截断分段又会引入拼接误差安全关键任务ICL 的输出没有形式化保证你无法证明模型在极端情况下一定不会乱动安全相关场景必须加硬约束全新操作模式如果预训练模型从没见过某种工具或某种操作示范给了它也学不会因为权重里根本没有先验在这些场景里该微调还是得微调该上传统控制还是得上传统控制。ICL 应该被当成一个灵活的前端调度器而不是万能的学习器。5.3 我目前推荐的落地路径和取舍经过这大半年的折腾我现在的工作流基本固定成三档第一档任务属于预训练模型已覆盖的常见操作且切换频繁直接上 ICL。先录 2-3 段视频马上部署测试不行就调整示范不碰训练流程。这个方法让我处理任务切换的成本从小时级降到了分钟级。第二档任务有特殊约束或者需要长期稳定但时间也允许我会用 20-50 条轨迹做轻量微调把模型调成一个针对特定任务族的专用模型然后在推理时配合 ICL 示例做实时调整。第三档涉及安全和高精度控制我会在模型外面包一层传统控制逻辑比如运动规划、力控、避障模型输出的动作只作为上层意图不是直接下发给电机的最终指令。还有一个细节无论哪一档我都会保留一个独立的异常检测模块。ICL 模型偶尔会自信地输出错误动作没有异常检测就盲目信任模型迟早出事。我的做法是对输出动作做速度和力矩上限约束超限直接断掉切换到安全停止。说到底In-Context Learning 给了机器人一条从“每个任务重新训练”到“每个任务换个提示”的捷径。这条捷径不是万能的但它在合适的场景里节省的时间和算力非常可观。如果你也正在被任务切换和数据采集反复折磨不妨先录几段视频试一下可能你会发现原来机器人换活儿真的不需要每次都重读一遍书。