基于GPT-6 Astra+的具身上下文学习框架：长时序机器人任务实战

1. 项目缘起与核心问题拆解

1.1 一个让人又爱又恨的现实：大模型在机器人上“水土不服”

过去一年多，我一直在折腾把视觉语言大模型往真实机器人上搬。说实话，第一次看到大模型能“看懂”桌面上的物体、能听懂“把红色杯子拿过来”这种指令时，我是真兴奋。但兴奋没持续多久，问题就来了：让它连续完成“先把桌上的螺丝刀放进工具箱，再把散落的三个螺母收进零件盒，最后把工具箱推到架子第二层”这种长时序任务时，它就开始犯迷糊——要么中途忘了第一步做过什么，要么把“第二层”理解成“第二格”，要么干脆在某个中间步骤卡死，反复执行同一个动作。

这不是个例。我后来跟几个做具身智能的朋友聊，大家遇到的坑高度一致：大VLM在单步感知和短指令理解上表现惊艳，但一旦拉长任务链条、提高精度要求，就暴露出三个致命短板。第一是时序记忆断裂，模型没有持久的任务状态跟踪机制，每一步都像重新开始；第二是空间精度不足，VLM输出的往往是“大概位置”，而机器人抓取需要毫米级坐标；第三是上下文窗口浪费，大量token被消耗在重复描述场景上，真正用于任务推理的容量被挤占。

RoboICL这个项目，就是冲着这三个短板去的。它的核心思路很直接：不重新训练大模型，而是通过具身上下文学习框架，把机器人的历史动作、当前观测、任务进度编码成结构化上下文，让GPT-6 Astra+在推理时“带着记忆和精度意识”做决策。说白了，就是给大模型配一个“任务工作台”，而不是让它每次从零开始猜。

1.2 为什么是“上下文学习”而不是“微调”

这里得解释一个关键选型。很多人第一反应是：既然大模型在机器人上表现不好，那就拿机器人数据微调呗。我试过，也看过别人的尝试，结论是：微调成本高、泛化差、迭代慢。机器人数据采集本身就贵，一条高质量的长时序演示轨迹，从遥操作到标注，没个把小时下不来。而且微调后的模型容易过拟合到特定场景，换个桌面布局、换套物体，性能断崖式下跌。

RoboICL选择上下文学习路线，逻辑在于：大模型本身的推理能力已经足够强，缺的不是知识，而是“当前任务的状态摘要”和“精度校准信号”。就像你让一个经验丰富的工程师去装配零件，他不需要重新学机械原理，但你需要给他一张清晰的工序卡和一把卡尺。具身上下文学习框架扮演的就是“工序卡+卡尺”的角色，把机器人执行过程中的关键信息压缩成模型能直接消费的上下文，引导它做出高精度、长时序的决策。

这个选择带来的好处很明显：零样本迁移能力强，换场景只需要调整上下文编码方式，不需要重新训练；迭代速度快，改上下文模板比改模型权重快几个数量级；可解释性好，你能看到模型是基于哪些历史信息做出的决策，排查问题有迹可循。

1.3 适合谁来读这篇总结

如果你正在做机器人操作、具身智能、或者任何需要把大模型落地到物理世界的项目，这篇内容应该能帮你省下不少试错时间。特别是以下几类朋友：一是刚入门具身智能的开发者，想了解大模型和机器人结合的真实难点在哪；二是正在搭建长时序任务系统的工程师，需要一套可复现的上下文管理方案；三是对GPT-6 Astra+能力边界感兴趣的研究者，想知道它在具身场景下的实际表现和优化空间。

我下面会从整体设计、核心细节、实操过程、问题排查四个维度展开，尽量把每个决策背后的“为什么”讲清楚，把踩过的坑和绕过的路都摊开说。你不需要有GPT-6 Astra+的API权限才能读，但如果有，跟着操作应该能复现出七八成效果。

2. 整体设计：具身上下文学习框架的架构思路

2.1 三层上下文编码：让模型“记得住、看得准、不跑偏”

RoboICL的框架设计，我把它概括为三层上下文编码机制。这三层不是简单的信息堆叠，而是有明确的职责分工和压缩策略。

第一层是任务进度层。这一层解决“记得住”的问题。具体做法是维护一个任务状态机，把长时序任务拆解成有序的子目标序列，每个子目标有明确的前置条件和完成判据。机器人每完成一个子目标，状态机就更新一次，并把“已完成子目标摘要+当前子目标+剩余子目标列表”编码成一段紧凑的文本上下文。这段上下文会附加到每次VLM推理的输入前面，让模型始终知道“我从哪来、我在哪、我要去哪”。

这里有个关键设计：已完成子目标不是简单罗列，而是压缩成“动作-结果”对。比如“抓取螺丝刀→成功放入工具箱”比“执行了抓取动作，然后执行了放置动作”信息密度高得多。我实测下来，这种压缩方式能让上下文长度减少40%左右，同时模型对任务进度的理解准确率反而提升，因为冗余信息少了。

第二层是空间精度层。这一层解决“看得准”的问题。VLM直接输出的坐标往往是图像像素坐标或者粗略的归一化坐标，直接给机器人用精度不够。RoboICL的做法是：VLM输出目标物体的语义描述和粗略区域，然后由一个轻量级的视觉定位模块（比如基于深度相机的点云配准或者基于分割模型的掩码提取）在指定区域内做精细定位，把精度从厘米级提升到毫米级。这个精细定位结果再反馈回上下文，作为下一步推理的精度锚点。

第三层是环境动态层。这一层解决“不跑偏”的问题。机器人在执行过程中，环境是变化的——物体可能被移动、遮挡可能出现、光照可能改变。RoboICL会定期（比如每执行完一个子目标）重新采集场景观测，提取关键变化信息，编码成“环境变更摘要”附加到上下文。这样模型不会基于过时的场景信息做决策。

这三层上下文的组合方式也有讲究。我试过几种方案，最终效果最好的是分层拼接+注意力标记：任务进度层放在最前面，用特殊标记包裹；空间精度层紧跟在相关子目标后面；环境动态层作为全局补充放在最后。这种顺序符合模型处理信息的自然逻辑——先明确任务状态，再关注当前操作对象，最后检查环境是否支持操作。

2.2 为什么选择GPT-6 Astra+作为推理核心

市面上能用的VLM不少，RoboICL选择GPT-6 Astra+作为推理核心，我分析下来有几个现实考量。

第一是长上下文窗口的硬需求。长时序任务的上下文编码再压缩，也得好几千token。GPT-6 Astra+的上下文窗口足够大，能容纳完整的任务进度、多轮环境观测和精度反馈，不会因为截断丢失关键信息。我试过用上下文窗口小一些的模型，任务执行到后半段就开始“忘事”，因为早期的上下文被挤出去了。

第二是推理链的稳定性。具身场景下，模型需要做多步推理：理解指令→定位物体→规划动作→检查可行性→输出控制信号。GPT-6 Astra+在推理链的连贯性上表现比较稳，不容易出现“跳步”或者“逻辑断裂”。这一点在长时序任务里特别重要，一步错步步错。

第三是工具调用能力。RoboICL框架里，VLM不只是输出文本，还要调用外部工具——比如调用视觉定位模块获取精确坐标、调用运动规划器检查可达性、调用状态机更新任务进度。GPT-6 Astra+的工具调用接口比较成熟，能稳定地按照框架定义的schema输出结构化调用请求。

当然，这不是说其他模型不能用。框架本身是模型无关的，你换成别的VLM也能跑，只是可能需要调整上下文模板和工具调用格式。我选GPT-6 Astra+是因为它在我的测试集上综合表现最好，尤其是在空间关系推理和长序列任务跟踪这两个维度上。

2.3 框架整体数据流：从指令到动作的完整链路

把三层上下文和推理核心串起来，RoboICL的完整数据流是这样的：

1. 任务初始化：接收自然语言指令，由任务规划器拆解成子目标序列，初始化任务状态机。
2. 上下文构建：编码任务进度层（当前子目标+历史摘要）、采集初始环境观测编码环境动态层。
3. VLM推理：将上下文输入GPT-6 Astra+，模型输出当前子目标的动作语义描述和目标物体粗略区域。
4. 精度校准：视觉定位模块在粗略区域内做精细定位，输出精确坐标和姿态。
5. 动作执行：运动规划器根据精确坐标生成轨迹，机器人执行动作。
6. 状态更新：执行结果反馈给状态机，更新任务进度；重新采集环境观测，更新环境动态层。
7. 循环：回到步骤2，直到所有子目标完成或触发异常处理。

这个数据流里，步骤3到步骤4的衔接是精度提升的关键。VLM负责“理解要做什么、大概在哪”，视觉定位模块负责“精确在哪、怎么抓”。两者分工明确，避免了让VLM直接输出高精度坐标（它做不到）或者让定位模块理解复杂指令（它也不擅长）。

3. 核心细节解析与实操要点

3.1 任务进度层的编码模板与压缩策略

任务进度层的编码质量直接决定模型能不能“记住”任务。我前后改了七八版模板，最终稳定下来的格式是这样的：

[任务进度] 原始指令：把桌上的螺丝刀放进工具箱，再把三个螺母收进零件盒，最后把工具箱推到架子第二层。 子目标序列： S1: 抓取螺丝刀 → 放入工具箱 [已完成] S2: 抓取螺母1 → 放入零件盒 [已完成] S3: 抓取螺母2 → 放入零件盒 [进行中] S4: 抓取螺母3 → 放入零件盒 [待执行] S5: 推动工具箱 → 架子第二层 [待执行] 当前子目标：S3 - 抓取螺母2 上一步结果：成功抓取螺母1并放入零件盒，零件盒位置未变。 [任务进度结束]

这个模板有几个设计要点。第一，原始指令必须保留。我试过只保留子目标序列，结果模型在执行到后面时容易偏离原始意图，因为它看不到全局目标了。原始指令就像“北极星”，让模型始终知道最终要达成什么。

第二，子目标状态用方括号标记，已完成、进行中、待执行一目了然。模型对状态标记的敏感度很高，这种显式标记比自然语言描述“第一个已经做完了”更可靠。

第三，上一步结果只保留关键信息。什么叫关键信息？就是会影响下一步决策的信息。比如“零件盒位置未变”会影响螺母2的放置策略，而“抓取时用了0.5N的力”对下一步就没啥影响，不需要保留。这个筛选逻辑我一开始是手写的，后来发现可以用一个简单的规则引擎自动提取：只保留涉及物体位置变化、任务状态变化、异常事件的信息。

压缩策略方面，我实测下来最有效的是滑动窗口+摘要。当已完成子目标超过5个时，把最早的几个合并成一段摘要，比如“前三个子目标均成功完成，涉及螺丝刀和两个螺母的抓取放置，零件盒和工具箱位置未变”。这样上下文长度不会随任务长度线性增长，而是保持在一个可控范围内。

注意：摘要生成不要用另一个大模型来做，成本高且引入不确定性。用基于规则的模板填充就够了，关键是提取“物体-位置-状态”三元组，然后套模板。

3.2 空间精度层的定位模块选型与参数调优

空间精度层是RoboICL区别于普通VLM机器人方案的核心。VLM输出的粗略区域通常是一个边界框或者一个归一化坐标，精度在5-10厘米量级。要提升到毫米级，需要引入专门的定位模块。

我试过三种方案。第一种是基于深度相机的点云配准：VLM给出粗略区域后，在该区域内提取点云，与已知物体的CAD模型做配准，输出精确位姿。优点是精度高，能到1-2毫米；缺点是需要预先有物体模型，对未知物体不适用。第二种是基于分割模型的掩码提取：用SAM之类的分割模型在粗略区域内提取物体掩码，然后计算掩码的质心和主轴方向。优点是通用性强，不需要物体模型；缺点是精度受分割质量影响，大概在5毫米左右。第三种是两者结合：先用分割提取掩码，再用点云配准在掩码内做精细对齐。精度能到2-3毫米，通用性也不错，是我最终采用的方案。

参数调优方面，有几个关键点。分割模型的输入分辨率要足够高，我一般用1024×1024，太低会导致掩码边缘模糊，影响质心计算。点云配准的迭代次数不要设太多，20-30次就够了，再多容易过拟合到噪声上。配准的代价函数用点到平面距离比点到点距离更稳，尤其是对平面物体。

还有一个容易被忽略的点：坐标系转换。VLM输出的粗略区域是在图像坐标系下的，分割和点云是在相机坐标系下的，机器人动作是在基坐标系下的。这三个坐标系之间的转换矩阵必须标定准确，否则精度提升会被坐标转换误差吃掉。我建议每次实验前都重新标定一次手眼矩阵，别偷懒用上次的。

3.3 环境动态层的变更检测与上下文注入

环境动态层的核心任务是：检测场景中与当前任务相关的变更，并把这些变更编码成模型能理解的上下文。不是所有变更都值得注入，比如光照微变、背景中有人走过，这些对任务没影响，注入反而增加噪声。

我的做法是基于任务相关区域的变更检测。具体来说，根据当前子目标和剩余子目标，确定一个“关注区域”——比如当前要抓取的物体周围、下一步要放置的位置周围。只在这个区域内做帧间差分或者特征匹配，检测物体是否被移动、遮挡是否出现、目标位置是否被占用。

变更检测的灵敏度需要调。太灵敏会把噪声当变更，太迟钝会漏掉真实变化。我一般用双阈值策略：低阈值触发候选变更，高阈值确认变更。候选变更会连续观察3帧，如果3帧都检测到变化才确认为真实变更。这个策略能把误报率降到5%以下。

变更信息的编码格式我试过几种，最终用的是结构化文本+相对位置描述：

[环境变更] 变更1：零件盒位置从桌面中央向右移动了约15厘米，当前位于桌面右侧边缘附近。 变更2：螺母3被一个透明塑料杯部分遮挡，可见面积约60%。 变更3：工具箱把手朝向从朝前变为朝左。 [环境变更结束]

这种描述方式模型理解起来很自然，而且比直接给坐标更鲁棒——坐标会随相机视角变化，相对位置描述不会。

实操心得：环境变更层不要每步都更新，那样上下文膨胀太快。我的策略是“事件触发更新”：只有检测到确认变更时才更新，否则复用上一次的环境描述。这样上下文长度能控制在合理范围内。

3.4 上下文拼接顺序与注意力引导技巧

三层上下文都有了，怎么拼也有讲究。我试过几种顺序，最终效果最好的是：

任务进度层 → 空间精度层 → 环境动态层 → 当前观测

这个顺序的逻辑是：先让模型明确任务状态（我在哪一步、要做什么），再给它当前操作对象的精确信息（抓哪里、怎么抓），然后补充环境变化（有没有干扰），最后给原始观测作为兜底。

拼接时用特殊标记分隔各层，比如[任务进度]...[任务进度结束]、[空间精度]...[空间精度结束]。这些标记的作用是帮助模型快速定位信息边界，减少层间干扰。我对比过加标记和不加标记的效果，加标记后模型对任务进度的召回准确率提升了约12%。

还有一个技巧是关键信息重复。当前子目标会在任务进度层出现一次，在空间精度层再以“当前操作对象”的形式出现一次。这种重复不是冗余，而是强化模型对当前焦点的注意力。实测下来，重复后模型输出错误动作的概率降低了约8%。

4. 实操过程与核心环节实现

4.1 环境搭建与依赖准备

先说一下我的实验环境，你不需要完全一样，但大致配置可以参考。机器人用的是六自由度协作机械臂，末端配二指夹爪，腕部装RGB-D相机。计算平台是一台带独立显卡的工作站，用来跑分割模型和点云处理。GPT-6 Astra+通过API调用，不需要本地部署。

软件依赖方面，核心是这几个：点云处理库（用来做配准和坐标转换）、分割模型推理框架（用来提取物体掩码）、运动规划库（用来生成机械臂轨迹）、状态机库（用来管理任务进度）。版本选择上，我建议用较新的稳定版，别追最新版，具身场景下稳定性比新特性重要。

环境变量配置有个坑：API调用的超时时间要设够。长时序任务里，VLM推理加上工具调用，单次请求可能耗时好几秒。我一开始用默认超时，经常在任务后半段出现请求超时，导致任务中断。后来把超时设到30秒，问题解决。

4.2 任务初始化与子目标拆解

任务初始化阶段，最关键的是子目标拆解的粒度和顺序。拆得太粗，模型不知道每一步具体做什么；拆得太细，子目标数量爆炸，上下文管理复杂。

我的经验是：每个子目标对应一个“抓取-放置”或“推动-到位”的原子操作。比如“把螺丝刀放进工具箱”拆成一个子目标，而不是拆成“移动到螺丝刀上方→下降→闭合夹爪→抬起→移动到工具箱上方→下降→张开夹爪”这么细。后者是运动规划器的事，不需要VLM操心。

拆解顺序也有讲究。有依赖关系的子目标必须串行，比如必须先抓螺母才能放螺母。无依赖关系的子目标可以并行或重排，比如三个螺母的抓取放置，顺序可以灵活调整。RoboICL的状态机支持这种灵活性，如果某个螺母被遮挡暂时抓不到，可以跳到下一个，等遮挡解除再回来。

子目标拆解目前是用规则模板+GPT-6 Astra+辅助生成的。规则模板处理常见任务类型（抓放、推拉、开关），GPT-6 Astra+处理模板覆盖不了的复杂指令。这种混合方式比纯规则灵活，比纯模型可控。

4.3 单步推理与动作生成的完整代码路径

单步推理是RoboICL运行频率最高的环节，我把它拆成几个函数来实现。下面用伪代码展示核心逻辑：

def execute_single_step(task_state, env_observation): # 1. 构建三层上下文 progress_ctx = encode_task_progress(task_state) precision_ctx = encode_spatial_precision(task_state.current_subgoal) dynamic_ctx = encode_environment_changes(env_observation) # 2. 拼接上下文 full_context = f""" [任务进度]{progress_ctx}[任务进度结束] [空间精度]{precision_ctx}[空间精度结束] [环境动态]{dynamic_ctx}[环境动态结束] [当前观测]{env_observation.raw_description}[当前观测结束] """ # 3. 调用GPT-6 Astra+推理 vlm_output = call_gpt6_astra( context=full_context, tools=[locate_object, check_reachability, update_state], temperature=0.1 # 低温度保证稳定性 ) # 4. 解析VLM输出 action_semantics = vlm_output.action_description target_region = vlm_output.target_region # 5. 精度校准 precise_pose = visual_locate(target_region, env_observation.depth_image) # 6. 运动规划与执行 trajectory = motion_plan(precise_pose, action_semantics) execution_result = robot.execute(trajectory) # 7. 状态更新 task_state.update(execution_result) return execution_result

这段代码里，温度参数设0.1是经过多次实验确定的。温度太高，模型输出不稳定，同一场景两次推理可能给出不同动作；温度太低，模型缺乏灵活性，遇到异常情况不会变通。0.1是我找到的平衡点。

工具调用的schema定义也很关键。我定义的工具包括：locate_object(object_name, rough_region)返回精确位姿；check_reachability(pose)返回是否可达；update_state(subgoal_id, status)更新任务状态。这些工具的输入输出格式必须严格定义，否则模型可能生成不合法的调用请求。

4.4 异常处理与任务恢复机制

长时序任务最怕的就是中途出错。RoboICL的异常处理分三级：

一级异常是动作执行失败，比如抓取时物体滑落。处理方式是重试当前子目标，最多重试3次。重试时会在上下文里注入“上次抓取失败，物体可能位置偏移”的提示，引导模型调整抓取策略。

二级异常是环境变更导致当前子目标不可执行，比如目标物体被完全遮挡。处理方式是暂停当前子目标，跳到下一个可执行子目标，同时把被阻塞的子目标标记为“等待条件满足”。等环境变更解除后，再回来执行。

三级异常是任务级失败，比如所有子目标都不可执行，或者重试超过上限。处理方式是保存当前任务状态，输出失败原因和已完成进度，请求人工干预或重新初始化。

任务恢复机制的核心是状态持久化。每次状态更新后，把任务状态序列化到磁盘。如果系统崩溃或需要重启，可以从磁盘恢复状态，继续执行。这个机制在实际部署时特别有用，我遇到过好几次因为网络波动导致API调用失败，有了状态持久化，恢复后接着跑就行，不用从头再来。

注意：状态持久化的频率不要太高，每个子目标更新一次就够了。太频繁会影响性能，太少又可能丢失进度。我一般是在子目标完成或异常发生时持久化。

5. 常见问题与排查技巧实录

5.1 模型“忘记”任务进度怎么办

这是最常见的问题，表现是模型在执行到第N步时，行为像是回到了第1步，或者跳过了某个中间步骤。排查思路分三步：

第一步，检查上下文长度是否超限。如果任务子目标很多，上下文可能被截断，早期的任务进度信息丢失。解决方法是启用滑动窗口摘要，把早期子目标压缩。

第二步，检查状态机更新是否及时。有时候机器人执行成功了，但状态机没更新，导致上下文里的进度信息是旧的。我遇到过因为状态更新回调没触发，模型以为上一步没完成，反复执行同一个动作。解决方法是加状态更新确认机制，执行结果必须显式确认后才推进状态机。

第三步，检查上下文模板是否有歧义。比如“已完成”和“进行中”的标记如果不明显，模型可能混淆。解决方法是加粗标记或者用更醒目的符号。

我整理了一个速查表：

5.2 精度不达标：抓取偏移的排查路径

精度问题排查起来比较系统，因为涉及多个环节。我的排查顺序是：从后往前查。

先查运动规划器：给的坐标是精确的，但规划出的轨迹有偏差？检查规划器的精度参数和标定数据。

再查坐标转换：相机坐标系到基坐标系的转换矩阵是否准确？重新标定手眼矩阵，用多个标定点验证。

然后查视觉定位模块：分割掩码是否准确？点云配准是否收敛？可视化中间结果，看看掩码边缘和配准对齐情况。

最后查VLM输出的粗略区域：如果粗略区域偏得太远，定位模块在错误区域内搜索，精度肯定不行。检查VLM的提示词是否清晰，目标物体的描述是否唯一。

我踩过的一个坑是：深度相机的深度图有缺失，导致点云配准失败，定位模块回退到分割质心，精度从2毫米降到8毫米。解决方法是加深度补全预处理，或者换一个视角重新采集。

5.3 上下文膨胀导致推理变慢的优化手段

长时序任务跑久了，上下文越来越长，推理时间从几百毫秒涨到几秒，严重影响任务执行节奏。优化手段有几个：

第一，压缩历史信息。已完成子目标用摘要代替详细描述，环境变更只保留最近3次，更早的合并成“环境基本稳定”。

第二，分层缓存。任务进度层变化频率低，可以缓存编码结果，只在状态更新时重新生成。空间精度层和环境动态层变化频率高，每次重新生成。

第三，按需注入。不是所有层都需要每次推理都注入。比如空间精度层只在涉及抓取放置的子目标时注入，纯移动类子目标可以省略。

第四，限制上下文总长度。设一个硬上限，比如8000 token，超过就触发压缩。压缩优先级：环境动态层 > 空间精度层 > 任务进度层。任务进度层最后压缩，因为它最重要。

我实测下来，这些优化能把上下文长度控制在4000 token以内，推理时间稳定在1秒左右，满足大多数操作任务的节奏要求。

5.4 工具调用失败的典型错误与修复

工具调用失败通常表现为：模型输出了调用请求，但格式不对，或者参数缺失，导致外部工具无法执行。

错误一：参数类型不对。比如locate_object期望rough_region是四个浮点数组成的列表，模型输出了字符串。解决方法是在工具schema里明确类型，并在系统提示里强调格式要求。

错误二：调用了不存在的工具。模型有时候会“发明”工具，比如调用move_object而不是locate_object。解决方法是在系统提示里列出所有可用工具及其功能，并强调只能调用列表中的工具。

错误三：调用顺序错误。比如还没定位就调用运动规划。解决方法是在工具schema里定义前置条件，或者在框架层面加调用顺序检查。

错误四：超时。工具执行时间过长，导致整个推理链路超时。解决方法是给每个工具设超时，超时后返回错误信息给模型，让模型决定重试还是跳过。

我一般会在开发阶段打开详细的工具调用日志，记录每次调用的输入输出和耗时，方便排查。上线后保留错误日志就够了。

6. 一些实测数据与效果对比

6.1 长时序任务成功率对比

我在一个包含5个子目标的典型任务上做了对比测试，任务内容是“抓取螺丝刀放入工具箱→抓取三个螺母放入零件盒→推动工具箱到指定位置”。测试了三种方案：纯GPT-6 Astra+直接推理、GPT-6 Astra+加简单历史记录、RoboICL完整框架。每种方案跑50次，统计完全成功率（所有子目标都成功）。

RoboICL的完成时间略长，因为多了精度校准和环境检测环节，但成功率提升明显。从22%到78%，这个提升在具身场景下是质变的——意味着从“基本不能用”变成了“基本能用”。

6.2 精度提升的量化分析

精度方面，我对比了VLM直接输出坐标和经过精度校准后的坐标，与真实抓取点的偏差：

从6.8厘米到0.3厘米，精度提升了20多倍。这个提升主要来自点云配准环节，分割质心提供了不错的初始值，点云配准在此基础上做精细对齐。

6.3 上下文长度与推理延迟的关系

我统计了不同任务长度下的上下文token数和推理延迟：

可以看到，随着子目标增加，上下文和延迟都在增长，但增长是可控的。12个子目标时延迟2.1秒，对于大多数操作任务来说还是可以接受的。如果任务更长，就需要启用更激进的压缩策略。

7. 后续可以继续折腾的方向

RoboICL目前跑通了基本流程，但还有不少可以优化的地方。我最近在试的一个方向是自适应上下文压缩：根据任务阶段动态调整压缩率，任务前期保留更多细节，任务后期加大压缩力度。初步测试显示能再降低20%左右的上下文长度。

另一个方向是多模态上下文融合。现在环境动态层主要是文本描述，我在试把关键帧图像也编码进去，用视觉token代替部分文本token。这样模型能直接“看到”环境变化，而不是通过文字描述间接理解。不过视觉token的压缩和检索还需要调。

还有一个比较实际的方向是异常恢复的自动化。现在三级异常处理里，三级异常还需要人工干预。我在试让模型自己生成恢复策略，比如重新规划子目标顺序、请求重新观测、甚至放弃当前任务并报告原因。这个方向如果跑通，能进一步提升系统的自主性。

最后说一个我踩过的坑：不要试图让VLM做所有事。一开始我想让GPT-6 Astra+直接输出关节角度，省掉运动规划器。结果发现模型对机器人运动学的理解很有限，输出的角度要么不可达，要么会碰撞。后来老老实实让VLM输出语义动作，运动规划器负责生成轨迹，分工明确后系统稳定多了。这个教训是：大模型擅长理解和推理，不擅长精确控制和运动学计算，把合适的事交给合适的模块。