企业官网建设流程全解析

做机器人操作研究的人，最近肯定都有同一个感受：打开arXiv，十个做learning的组有五个在讨论In-Context Learning（ICL）怎么用在机器人上，从VIMA、RT-2聊到OpenVLA，再到最近的π0，每篇都在强调"多模态大模型+上下文示例"的组合，仿佛给机械臂看几段视频它就能学会新任务。可真要自己动手复现和搭建的时候，很多人反而被绕进去了：上下文学习到底在学习什么参数？那些demo是怎么"塞"进模型的？为什么有的任务给几个示例就收敛，有的任务塞满上下文还是瞎抓？

这篇东西我想把这些底层逻辑彻底拆开讲一遍，把我自己实验里踩过的坑、对比过的方案、以及值得关注的工程细节都拿出来聊。不管你是刚接触机器人学习的研究生，还是已经在部署机器人策略的工程师，这篇文章的目标是让你读完以后能自己判断：一个任务到底适不适合用ICL来做，模型内部发生了什么，以及从数据集到部署环境有哪些容易忽略的门槛。

1. 先搞清楚：机器人领域的In-Context Learning到底在学什么

1.1 从"开卷考试"说起：ICL在不同场景下的含义差异

In-Context Learning最早是大语言模型圈子的概念，大家熟知的定义是：不修改模型参数，只通过在输入序列里拼接示例、指令、或者少量demo，让模型在推理时临时"进入"一种新任务状态。通俗讲就像开卷考试——参数是考生头脑里已有的知识，上下文就是考场上翻的那几页参考资料，考完试参考资料一收，脑子里的参数还是原样。

但机器人领域的ICL跟NLP里的ICL有个非常关键的区别：NLP里模型输出的还是词元（token），而机器人模型最终要输出的是动作——关节角度、末端位姿、力控指令、或者导航速度。这导致整个"上下文"的形态也随之改变，不再只是文字，而是图像、点云、语言指令、历史状态、甚至过去的动作序列混在一起的异构序列。

还有一点容易被忽略：NLP里的ICL任务边界很清晰，模型只需要"理解"示例然后生成答案；机器人ICL则必须同时解决三个问题：感知（当前场景里有什么物体）、任务意图推断（示例里展示的是完成什么目标，怎么泛化到新物体/新布局），以及动作生成（输出能闭环执行的低层控制信号）。所以即便同样叫ICL，做NLP那套"把几个示例拼进去就完事"的思维，直接搬到机器人上根本不成立。

1.2 机器人ICL的三条主要技术路线

目前我看到的主流做法可以粗分为三类，理解清楚它们的区别才能看懂论文：

第一类：基于视觉-语言模型的"动作字面化"路线。代表工作是RT-2、OpenVLA、以及后来的不少VLA（视觉-语言-动作）模型。思路是把动作离散成token，作为一种特殊语言"词"让模型输出。比如把机械臂末端轨迹量化成256个码本词，模型生成这些词就等于生成了动作。这类方法里，ICL的上下文就是语言指令、历史图像帧，以及偶尔拼接的少量演示轨迹。

第二类：基于离线强化学习/模仿学习的上下文推断路线。代表是IMRL（In-Context Imitation Learning with Sequential Transformer Models）系列。它把多个任务的演示轨迹拼成一个长序列，Transformer策略根据"前面若干条轨迹"推断出"现在这条轨迹的意图"，然后在新场景里零样本执行类似意图的任务。这类方法强调的是从示踪片段中在线推断任务目标，而不是靠文本指令。

第三类：带环境反馈的在线ICL路线。这是最近开始升温的方向，把环境返回的reward或者成功信号加入上下文，让模型在一个 episode 内部自适应调整策略。相当于没有梯度更新的online RL，但靠上下文里的反馈做调整。严格说这是"in-context RL"，跟前面两类不完全是一回事，但论文里经常混着讲。

所以下次你看到"ICL for Robotics"的标题，先问一句：是哪种ICL？是给模型看演示，还是给模型看文字+图，还是给模型看奖励信号？三种路子的核心技术栈和困难点差异非常大。

1.3 为什么"让模型看几个例子就会做"这么吸引人

这个话题这么火，根本原因是它触及了机器人领域最痛的痛点：任务泛化。传统流程是每个任务单独采集几千条demo、单独训练一个模型，新任务一来全部重来。ICL至少在概念上提供了一条路——训练阶段还是那些数据，但推理阶段你只要换上下文，模型就能切到新任务。我调过不少机器人策略，深知这种"切换"的价值：它意味着部署现场不需要数据采集员，不需要回传云端微调，边缘端设备就能承载多任务扩展。

不过也别把ICL神化。它解决的是"如何快速指定新任务"的问题，但模型里到底有没有完成该任务所需的先验技能，仍然取决于训练数据覆盖范围。如果模型从来没观察过"拧瓶盖"这种接触操作，上下文里塞一万个示例也白搭。这就是后文要展开的：ICL真正起作用的前提，不是上下文，而是底层的多任务预训练。

2. 为什么是ICL，而不是传统示教或继续微调

2.1 传统示教编程的硬边界

在座做过产线机械臂集成的朋友应该很熟悉：给ABB或者KUKA写新程序，要么用示教器逐点走路径，要么用离线编程软件把轨迹算好再灌进去。这套方式的优势是精确、可重复，但代价是每来一个新工件、新摆放角度，就得重新把轨迹走一遍。尤其当任务不是简单点到点运动，而是需要根据物体当前位姿调整动作时，示教轨迹根本不起作用。难点不在于写程序，而在于让机器人感知到环境变化并改变策略。

传统视觉引导方案（比如2D/3D相机标定、抓取点计算）能解决一部分"变位姿"问题，但任务一复杂就崩：需要堆叠零件分离、需要拖拽线缆、需要做力控打磨……这些场景里固定视觉算法根本覆盖不住丰富多变的物理交互。这也是大家转向learning-based方法的根本原因。

2.2 细看微调路线：效果不错但成本太高

相比之下，基于大模型微调（fine-tuning）的机器人策略去年已经验证了效果。比如在RT-1或RT-2的权重上收集新任务数据做继续训练，成功率能显著提升。但问题在于：每接一个新任务都需要重新训练一轮。这不是普通的几分钟训练，而是涉及几百块GPU、大量数据清洗、以及后续部署的版本管理。做过一次端到端机器人模型微调的人应该都有体会——采集数据、标数据、训练、回灌模型，这个循环的周期是周级别的。

而且微调还存在灾难性遗忘问题。模型学新任务时会逐渐忘掉之前学会的技能。你加一个"开抽屉"任务，可能"推盘子"就没那么稳了。虽然可以用经验回放和正则化手段缓解，但工程复杂度呈指数上升。

2.3 ICL的真正算账逻辑

ICL在这种情况下就显得经济得多。训练阶段专注做多任务通用预训练，推理阶段零样本适应新任务。新任务只要写一句语言指令、或者给几个演示视频，模型参数不需要动。本质上相当于把一个"全栈工程师"预训练好，之后每个新任务只是给他一张新的需求文档，而不是重新培训这个人。

从算力账看：预训练很贵，但可以摊薄到所有下游任务上；部署阶段ICL几乎是免费的。从数据账看：新任务只需要少量（甚至一个）演示示例，而不是上万条样本。从可迭代角度看：现场调整提示词和示例就行，不需要重新发布模型权重，这对实际产品非常有吸引力。

不过关键前提必须说清楚：ICL的效果天花板，完全取决于预训练模型具备的技能广度。如果预训练完全没见过某类操作，示例再高质量也没办法无中生有。所以做ICL不是不做微调，而是把微调看作"扩展底层技能库"，ICL则是"在技能库之上快速指定任务"——两者并不敌对，是不同维度的工具。

2.4 一个直觉化的类比

我经常跟团队这样说：传统示教=给每一道菜写一本精确到毫升的菜谱；微调=把厨师送去新东方进修三个月学新菜系；ICL=带着一个已经会500道菜的大厨，现场给他看两遍新菜的演示，他照着做就完事。前提是他之前积累的刀工火候足够好。这个类比虽然粗糙，但能快速解释为什么我们在决策时选了ICL而不是每任务微调——因为我们要面对的是不断新增的、短平快的操作需求，根本没有时间和人力去做每任务训练。

3. 从输入到输出：机器人ICL系统的最新原理拆解

聊完动机，往下走一层，看看真正动手搭一个机器人ICL系统时，内部各个模块都在干什么。

3.1 输入侧：上下文序列是怎么"拼"出来的

机器人ICL的输入不是一条单纯文本，而是多模态序列。拿一个基于VLA的抓取任务举例，输入可能长这样：

1. 一条语言指令："把红色杯子放到托盘上"
2. 过去T帧的相机图像（可能是第三视角+腕部视角）
3. 二值化的机器人状态（关节角度、夹爪开合）
4. 可选的额外示踪信息：成功轨迹的观测片段或者目标位置的标注

这些数据在送入模型前，必须被转换成统一的token序列。图像通常用视觉编码器（比如CLIP的ViT）切成patch token；语言直接用LLM分词器；机器人状态和动作则另做专门编码。

3.2 统一token空间：所有模态都变成一串向量

我最想强调的一点是：做机器人ICL，本质上就是在解决模态对齐问题。你必须让图像token、语言token、状态token、动作token在同一个语义空间里"相互看得懂"。不同工作有不同的做法：

• RT-2的做法很直接：动作经过离散化后变成类似文本的词元，用词表ID表示动作块，语言模型的交叉熵损失直接监督动作词元。相当于模型把动作当作"外语"来生成。
• VIMA的做法是把所有轨迹也当作一种token流，在预训练时使用多任务演示数据，让模型学会"看完演示token流后接着生成机器人token流"。
• π0这类模型则不完全走离散token路线，而是在transformer后面接一个流匹配（flow matching）头，直接输出连续动作分布。

这个设计选择对结果影响极大。离散化动作的好处是训练稳定、可以直接复用语言模型的loss；坏处是动作分辨率受限，精细操作容易失真。连续输出头（比如diffusion、flow matching）动作精度更高，但训练难度和推理耗时都上升。

3.3 上下文记忆从哪里来：站在Transformer的注意力机制上

ICL的理论根基仍然是Transformer的自注意力。当模型看到一串包含示例的序列时，注意力机制会把任务指令、示例中的状态动作对、当前观测三者之间建立关联，等效于在推理图里"动态生成"一个任务映射。没有梯度更新，但通过前向传播的attention路径就实现了某种意义上的"参数化记忆"。

这里有个实操中很容易踩的坑：上下文长度与KV Cache占用。做图像输入时，一张224x224的图像patch化后就有196个token，再堆8帧历史图像，直接干到1500+ token。而预训练时很多模型的上下文窗口并不大，训练和推理时上下文长度一旦不一致，注意力分布会发生偏移，效果可能断崖式下降。我自己在部署OpenVLA时就发现，训练用的上下文是7帧，推理时如果改成9帧，成功率跌了十几个点。所以测ICL时，示例数量、帧数、prompt长度必须严格复现训练时的配置，不要随手改。

3.4 输出侧：动作时域、频域与分辨率的设计

机器人ICL的输出设计非常硬核，值得单独展开。通常有两种输出粒度：

• 高层动作（action chunk）：一次输出未来H步的动作块，而不是单步动作。比如VIMA输出长度为16-32的动作序列。这种做法的好处是策略具备一定的开环规划能力，减少复合误差；坏处是遇到环境扰动时不够灵活，需要靠后续重规划覆盖。
• 低层步进控制：每步输出一个关节速度或末端增量，实时性更强，但容易陷入局部振荡。

我的经验是：如果任务本身是长程多阶段操作（比如"整理桌面"），用action chunk；如果任务是接触力敏感型（比如"插USB口"），用步进控制更好，因为需要频繁根据接触状态调整。两者也见过混合方案——先预测动作块，然后再用一个小网络精修到步进控制信号。

3.5 一个最小ICL策略的流程拆解

为了让你对整体流程有个画面感，我给出一个简化版伪代码，不是某个具体的模型，而是机器人ICL策略的通用骨架。这种结构在不少开源项目中都能看到：

# 伪代码：机器人ICL策略前向流程 class RobotICLPolicy: def __init__(self, model, tokenizer, action_vocab_size=256): self.model = model # 多模态Transformer self.tokenizer = tokenizer self.action_vocab_size = action_vocab_size def build_context(self, instruction, demo_obs_list, demo_act_list): # 1. 语言指令token化 lang_tokens = self.tokenizer.tokenize(instruction) # 2. 历史示例逐帧变成图像token demo_tokens = [] for obs, act in zip(demo_obs_list, demo_act_list): obs_tokens = self.visual_encoder(obs) # [num_patches, d_model] act_tokens = self.discretize_action(act) # 动作离散为特殊token demo_tokens.append(concat(obs_tokens, act_tokens)) # 3. 当前观测帧 current_tokens = self.visual_encoder(current_obs) # 4. 拼接成完整上下文序列 return concat(lang_tokens, *demo_tokens, current_tokens) def predict(self, context_tokens, temperature=0.8): # 前向推理，生成动作token for step in range(self.num_action_steps): next_token = self.model.generate_one(context_tokens, temperature) context_tokens = append(context_tokens, next_token) # 反离散化为连续动作 action = self.undiscretize(context_tokens[-self.num_action_steps:]) return action

这段代码省略了大量细节（比如视觉编码器的具体选择、动作反离散化的方式、训练loss如何形态转换），但核心思路是：所有信息都被编码成同构token流，模型在token序列上做条件生成。

4. 代表工作横向对比：VIMA、RT-2、OpenVLA、IMRL、π0的取舍

这节帮大家把目前最有代表性的几条技术路线放在一张表里对比，然后逐一讲它们的独特设计和我的实际感受。

4.1 VIMA：把"任务描述"玩明白了

VIMA是最早系统化把"多模态提示"引入机器人操作的工作之一。它不只是把文本指令当prompt，而是真的把演示视频、目标物体图像、机器人轨迹全部token化后拼在一起。预训练数据来自一个经过精心设计的仿真环境，包含几十万条多任务演示。我比较欣赏它的实验设计——将样例数量、prompt格式、任务相似度都做了消融，证明了上下文示例对性能的显著影响。

但VIMA之后在真实机器人上落地的案例不算多。根本原因是它过于依赖密集的演示型上下文，而真实世界采集高质量演示的成本很高。它更多是理念验证性的工作，给后续很多研究提供了"演示也可以进入上下文序列"的启发。

4.2 RT-2：互联网知识能不能指挥机器人

RT-2的思路非常"暴力"：把一个8B级别的VLM（在互联网图片和文本上训练的）拿到机器人数据上继续训练，让模型既会做视觉问答又会输出动作token。它最惊艳的一点是能够利用VLMs里学到的概念知识来指挥机器人执行一些训练时没见过的指令，比如把苹果放到红色杯子里——因为模型见过"苹果""红色""杯子"这些概念，只是没见过"机器人抓取"的指令组合。

但RT-2的动作离散化方式比较粗糙，它将动作空间映射成一定数量的bin，对于需要精细控制的任务，比如插入、旋转阀门、装配，表现不够好。而且因为模型本身参数很大，部署到真实机器人上的实时性不太理想，早期版本需要1-2秒才能出一个动作决策，对闭环控制来说太慢。

4.3 OpenVLA：真正能自己跑的开放模型

OpenVLA是2024年最受社区欢迎的开源VLA方案，7B参数，训练自一个大规模机器人操作数据集（Open X-Embodiment的子集），并且支持LoRA微调。我这几个月经常拿OpenVLA做baseline，它的优势非常明显：部署方便，H100上就能跑，而且视觉编码器经过强化学习阶段微调，特征质量高。

它的不足主要在上下文处理上。默认输入的图像数量有限，而且未真正利用长时间跨度的历史帧；另外它输出离散动作的粒度偏向于粗放操作，抓取和放置这种任务没问题，但精密装配需要额外后处理或微调。如果你要搭建自己的VLA系统，OpenVLA是当前最合适的起点。

4.4 IMRL：不靠语言的策略推断

IMRL系列走的是另一条极简路线：不说一句文本指令，直接把多条任务的演示轨迹按token序列拼接，让Transformer在推理时观察上下文里前面几个任务的轨迹如何执行，然后推断当前任务应该怎么做。这其实更像人类学徒——先看师傅做三件事，然后轮到第四件事时你自然知道要做类似的活。IMRL在仿真（MetaWorld, RLBench）里展示了惊人的零样本任务切换能力。

这个路子的优势是不需要语言标注（这在真实世界采集数据时很宝贵，因为标注描述本身的成本不低），而且任务推断完全依赖视觉上下文。缺点是对任务之间的区分度要求较高，如果两个任务的视觉特征非常相似但目标不同，模型就比较容易混淆。另外它目前更多停留在抓取、推动、夹持等行为层，尚未见到长程复杂操作的成功案例。

4.5 π0：动作精度的又一次升级

π0（来自Physical Intelligence团队）是2024年底到2025年初非常受关注的工作。它选了PaliGemma 3B做基础VLM，但动作输出部分采用了流匹配（flow matching）而不是离散token，使得精细接触操作（比如插头、叠衣服、清扫）表现远超前代方案。同时用了一个混合专家结构来保证不同任务共享计算。

我在看它的技术报告时印象最深的是两点：一是数据飞轮的闭环——他们自己搭建了一支能采集大量真实数据的机器人硬件平台，强调上下文学习的效果极限是在数据层面被压住的；二是它对训练分布内任务和分布外任务做了系统评估，结果显示ICL提升主要体现在分布内的任务切换上，真正分布外的动作技能依然会崩。这恰好呼应我在第一节说的话：预训练的底层技能库宽度定了ICL的上限。

4.6 对比之后能得出的几条结论

把表格和上面对比放在一起，我自己的取舍建议如下：

• 需要快速部署多任务操作且任务本身是粗粒度（抓取、放置、推、按压），OpenVLA系列的VLA路线最现实。
• 需要高精度接触类操作，关注π0这类连续动作方法，但要做好算力和数据准备。
• 没有语言标注、但任务之间视觉差异明显，IMRL这类纯上下文推断值得试。
• 在仿真阶段做算法验证，VIMA的实验框架仍然是最好的消融平台，因为你完全可控prompt格式、演示数量等变量。

5. 数据、上下文长度与评估口径：部署中卡脖子的三座大山

这节重点讲那些论文里不会写透、但实际工程中绕不开的问题。很多人在仿真里跑得好好的，一到实体就翻车，多半是栽在这几个环节上。

5.1 数据飞轮：ICL系统的燃料到底怎么来

先明确一点，ICL模型不是不需要数据，而是需要更大规模、更多样性的统合数据。想让模型具备"看几个示例新任务就能上手"的能力，预训练数据集必须覆盖足够的任务语义空间。

真实世界采集方案主要三种：

• 遥操作采集：人类操作员通过虚拟现实或主从机械臂完成演示，获取的轨迹质量高，但速度慢，通常一个熟练操作员一天也就能采几百条有效轨迹。
• 自动化标注/自监督采集：让机器人随机推搡物体进行数据收集，然后用算法自动标注成功与否。成本低、规模大，但数据质量波动大，需要大量清洗。
• 仿真数据：在RLBench、MetaWorld、Franka Kitchen这类环境里批量生成演示，再加上Domain Randomization增强视觉多样性。仿真数据量大且标注完整，但sim-to-real gap一直在那里。

从Open X-Embodiment社区的经验看，混合数据池的效果远好于单一来源。你不需要一条完美数据集，但数据多样性非常关键——不同机器人型号、不同相机视角、不同光照条件、不同风格的动作轨迹。上下文学习的泛化能力其实来源于底层表示学习的多样性，而不是上下文本身。

5.2 上下文长度：一个看起来简单但极其致命的设计变量

我之前在第三节提过KV Cache的问题，这里展开到工程层面。多模态transformer的推理时延与上下文长度几乎线性相关，图像token占用的显存也随帧数增长。你在测试环境里感觉"加点帧数效果更好"，于是从4帧加到8帧，结果单次推理时间从150ms飙到500ms——对控制频率要求高的任务直接不可用。

我的建议是：先把上下文长度当作一个受控变量深度调优。可以尝试对历史帧做特征级压缩（比如用一个轻量时序模型把历史图像压缩成固定数量的memory token），而不是无限堆Raw图。有些工作已经在探索让模型只读取"关键帧"而非均匀抽样历史帧，效果类似但推理成本大幅下降。这类优化往往比换更大的模型划算得多。

还有一点容易被忽略：上下文示例的使用率不等于对模型的"友好度"。我在实际测试中发现，塞了8个demo进去，模型并不总能充分利用它们；有些demo之间差异过大，反而混淆了模型的注意力。所以上下文设计不是"越多越好"，而要去留意示例之间的一致性和代表性。给3个有效示例，可能比给8个五花八门的示例效果更稳。

5.3 评估方法：成功率不是唯一指标

机器人learning领域的论文通常只报一个"任务成功率"，但做实际系统的人都知道，这个指标在ICL场景里信息量太低了。一个模型在测试集上平均成功率70%，看起来不错，但可能是在一半任务上100%，另一半任务上0%——这种方差在实际部署里完全不能接受。

我建议项目里至少同时跟进以下指标：

• 任务级成功率：标准metric，但必须按任务分组报告方差。
• 示例敏感性：固定模型，随机换一组上下文示例，跑5次，看成功率波动。好的ICL模型应该对示例的细微变化不敏感。
• 分布外压力测试：把场景的背景、光照、物体颜色做轻微改动，看成功率衰减曲线。这直接反映模型是真正学会了任务抽象，还是只在背训练集样式。
• 动作平滑性：相邻时间步的动作变化幅度。ICL模型因为是在大transformer里做条件生成，偶尔会产生抖动的动作token，对实体机器人非常不友好。

我个人习惯是用一组固定的"黄金测试集"——包含任务类别、难度梯度、干扰因素三个维度的平衡样本。每次模型更新后，先跑一遍黄金测试，再决定是否上实体。

5.4 部署大坑：视觉输入分布变化是最大的敌人

最后说一个我最常踩的坑：训练时用固定相机位姿，部署时稍微挪了一下相机，性能直接腰斩。VLA模型的视觉编码器对相机位姿的敏感度超乎想象。解决办法要么在训练数据里加入大量不同相机位姿的扩增，要么在部署端设计机械固定结构确保相机位姿与训练分布一致。听起来像废话，但很多翻车事故都源于这个细节。

另外推理时延与动作频率的匹配也要提前规划。如果你的动作决策频率需要10Hz以上，但模型推理一次要200ms，那唯一的办法是用异步推理+动作缓存——模型持续生成unrolled的动作序列，底层控制器按时间戳逐条执行。这种情况下，上下文长度又直接跟缓存容量的经济性挂钩了。总之，ICL看似"零样本"，但真正让它跑起来，背后是一整套工程系统的配合。

6. 个人经验：要不要上ICL、怎么起步、未来看点

6.1 什么情况下值得上ICL

如果你正在决策一个项目到底该用传统规划、微调、还是ICL，我的判断标准很直接：

• 新任务是一个已知技能库里的组合变体（比如"把某个物体放到某个新容器""换一种摆放角度执行插入"），那么ICL价值巨大。
• 新任务涉及从未见过的物理接触模式（比如让机器人第一次用剪刀剪东西），ICL不是答案，你需要先扩大技能库，说白了还是得回到采集数据和微调。
• 任务数量少且基本固定，传统视觉引导或手工标注规则可能更快更稳，不必为了赶潮流强行上ICL。

一句话：ICL适合"任务空间大、但技能原子有限"的场景，是典型的多任务转换器，不是新技能生成器。

6.2 从一个最小项目出发的路线图

如果是我现在从头搭一个机器人ICL系统，会按以下顺序推进：

1. 先用开源VLA（比如OpenVLA）在一个已有数据集上跑通预训练和推理闭环，感受动作离散化的精度边界。
2. 搭建一个可控的仿真环境，对"上下文示例数量、上下文长度、示例顺序"三个变量做系统消融，找到自己任务的最佳配置。
3. 设计一个混合数据池：真实遥操作数据（少量）+ 仿真随机化数据（大量），做统一预训练。
4. 在训练时加入相机位姿随机化和视觉增强，确保部署端视觉变化在分布内。
5. 最后才是上实体机器人，先用粗粒度抓取任务验证整体链路，再逐步增加接触密集型任务。

这个路径不一定是最快的，但每一步都留了充分的回归验证点。我自己有过跳过第2步直接上实体，结果花了两周才发现问题出在示例顺序上——早该在仿真里用几小时试完的事。

6.3 未来三个值得关注的ICL方向

• 在线ICL与闭环反思：当前的ICL大都是开环——上下文在episode开始前就固定了。如果能够让模型在episode中加入实时经验反馈（比如上一次抓取了但失败了，姿态偏了2厘米），策略自适应能力会大幅提升，这是真正的"经验学习"。
• 跨形态与跨案例共享：数据稀缺永远是机器人落地瓶颈，如果ICL上下文能够跨机器人型号传递技能（在A机器人上演示操作，迁移指导B机器人执行），数据复用率会有数量级提升。
• 上下文记忆压缩：如何在有限上下文窗口里塞进更多高价值历史信息，是ICL从实验室走向长期部署的必经之路。模型需要学会"遗忘"无关信息而保留关键经验。

最后说点个人观察。其实大家很容易被"上下文学习"这个词带偏，以为模型具备魔法，任何任务看几遍就会了。但实际情况是，ICL能否生效，九成取决于预训练阶段积累的技能覆盖度和表征质量。真正值得投入精力的地方，仍然是数据、数据、数据，以及一个能系统评估泛化能力的实验框架。上下文只是最后的临门一脚，前面的传球和跑位做得不扎实，临门一脚再漂亮也进不了球。