机器人学会给自己写程序的那天

一、一个尴尬的真相：高分模型为何一碰就碎

过去几年，视觉语言动作模型（VLA）成为具身智能领域的热门方向，各类机构纷纷投入训练自己的版本。实验室里的跑分成绩相当亮眼，不少模型在标准评测集上能拿到九成以上的成功率。但这份成绩单背后藏着一个不太好意思明说的事实：一旦场景发生细微变化——物体被挪动了位置，或者任务描述换了一种说法——成功率会直接跌到接近于零。

有专门的评测基准就是为了暴露这个问题而设计的：在位置与任务指令被扰动之后，部分知名模型的成功率是 0.0%。这不是小数点后的波动，而是彻底失效。

这个结果说明的问题很严重：这些模型并没有真正“理解”任务，它们记住的是训练数据里的特定场景组合。用更直白的话说，模型学到的是一种从像素到动作的统计映射，当输入分布稍微偏离训练分布，映射就崩了。这不是靠堆更多数据、更大参数量就能根治的——因为问题的根源在于范式本身：把一个需要推理和组合的任务，压缩成了一个端到端的黑箱拟合问题。

二、换一条路：让 AI 像工程师一样写代码

有一群研究者选择了另一条路线。他们没有继续加码视觉运动模型的规模，而是回到一个更朴素、也更符合软件工程直觉的做法：直接让通用编程智能体去编写控制机器人的代码。

这个思路被称为代码即策略（Code as Policy）。其核心逻辑可以概括为一句话：机器人领域早已存在一整套成熟的软件接口与工具链，既然人类工程师能用这套接口写程序控制机器人，那为什么不让 AI 也用同样的方式工作，而不是训练一个黑箱模型去“猜”下一个动作？

这个判断有其现实基础。现代机器人软件栈经过多年积累，已经形成了事实上的标准框架：它负责连接传感器、处理数据流、下发控制指令，学术界与工业界沉淀下来的驱动、算法库、调试工具都构建在其之上。换言之，机器人“能被编程控制”这件事，本身就是现成的基础设施。缺的不是接口，而是能自动写出正确程序的智能。

于是系统设计变得异常简洁：给一个现成的通用编程智能体一个工作目录，再给它一份机器人软件框架的使用文档，然后告诉它——去完成这个任务。没有专门训练过的机器人模型，没有手工设计的感知与控制工具库，没有为特定任务调优的中间层。只有一个终端、一堆文档，以及一个会写代码的智能体。

三、系统是怎么跑起来的

理解这套系统的价值，需要先看清它和传统方案在流程上的根本差异。

传统 VLA 流程：采集大量人类遥操作数据 → 训练端到端模型 → 输入图像与指令 → 输出动作序列。整个链路的可解释性弱，出错后难以定位是感知、理解还是控制环节的问题；场景一变，需要重新采集数据并再训练。

代码即策略流程：接收任务描述 → 智能体阅读机器人接口文档 → 编写调用感知与控制接口的程序 → 执行程序 → 根据执行反馈迭代修改代码。整条链路的中间产物是可读的源代码，出错时可以查看是哪一行逻辑写错了，也可以直接修改那一行。

具体到工程实现，这类系统通常包含几个关键环节：

1. 任务解析：将自然语言指令拆解为可执行的子目标，例如“找到目标物体→移动到其上方→调整末端姿态→抓取→移动到指定位置→释放”。
2. 接口检索：智能体在文档中定位所需的能力，包括相机图像获取、坐标变换、运动规划、夹爪控制等，并确认每个接口的输入输出约定。
3. 程序合成：生成一段结构化的控制程序，把子目标串成带条件判断与错误处理的流程。
4. 执行与反馈：运行程序，观察执行结果；若失败，依据日志与视觉反馈定位问题并修改代码，形成闭环。

示意性的伪代码结构大致如下：

任务: 将桌上的红色方块放入左侧容器
步骤1: 调用图像采集接口获取当前场景图像
步骤2: 调用目标检测接口定位红色方块与容器
步骤3: 计算抓取位姿（位置 + 姿态）
步骤4: 调用运动规划接口生成到预抓取点的轨迹
步骤5: 执行轨迹，闭合夹爪
步骤6: 规划到容器上方的轨迹，释放
步骤7: 校验结果，失败则回退并重试

注意这段程序里没有任何“模型猜动作”的成分，全部是对既有接口的编排。智能体做的事情，本质上和人类工程师写脚本没有区别——只是它读文档、写代码、改 bug 的速度更快。

四、难点究竟在哪

看起来这么简单的方案，为什么过去没人这么做？因为“简单”只是表象，真正的难点分布在几个层面。

第一，文档理解与接口对齐。 机器人软件框架的文档往往冗长且风格不一，接口的参数语义、坐标系约定、单位制、时序要求都藏在细节里。智能体必须准确抽取这些约束，稍有偏差程序就跑不通。坐标系搞错一个轴向，机械臂就会往反方向运动。

第二，长流程的可靠性。 一个操作任务往往包含十几个步骤，任何一步失败都会导致整体失败。程序里必须有充分的检查点、异常捕获与重试逻辑，这对代码生成的健壮性提出了远高于“写个 demo”的要求。

第三，感知与控制的耦合。 抓取位姿的计算依赖感知结果，感知结果的质量又依赖相机参数与标定。程序需要把这些环节正确串联，并在数值不稳定时做兜底处理。

第四，迭代效率。 智能体需要根据执行反馈快速定位问题。这要求系统提供清晰的日志、可回放的中间数据和结构化的错误信息，否则“改代码”会退化成盲目试错。

可以说，这套方案的门槛不在于模型能力，而在于工程闭环的设计质量：文档怎么组织、反馈怎么呈现、失败怎么归因，决定了智能体能否稳定地写出可运行的程序。

五、评测数字说明了什么

在面向代码即策略的评测基准上，该系统的成功率达到 99.0%；在专门测试位置与任务扰动的评测集上，成功率为 87.0%。

这两个数字需要放在对照背景下看。前一个数字说明：在标准任务分布内，让通用编程智能体直接写程序控制机械臂，可靠性已经相当高。后一个数字更值得注意——它测试的正是传统模型归零的那类扰动场景，而代码即策略的方案保持了八成以上的成功率。

原因并不神秘：当物体位置变化时，程序里的目标检测与坐标计算逻辑依然有效，只是输入的数值变了；当任务描述换一种说法时，智能体重新理解指令并调整程序结构即可。程序的抽象层天然具备对扰动的鲁棒性，因为它是基于接口和逻辑组合的，而不是基于像素统计的。

一个从未见过这台机器人、没有经过任何专门训练的通用编程智能体，能够当场写出感知与控制程序并完成机械臂操作——这件事的意义在于，它把“机器人能力”的来源从“训练数据覆盖度”转移到了“接口完备度 + 代码生成能力”上。

六、对工程实践的启示

这套思路对做机器人系统与智能体应用的团队有几条直接可用的启示。

把接口做厚，把抽象做薄。 如果希望智能体能接管控制逻辑，前提是底层能力被清晰地封装为稳定接口，并有高质量文档。接口设计的规范性直接决定了自动生成代码的可用性。

保留可解释的中间产物。 代码作为策略的载体，最大的工程优势是可审计、可修改、可版本管理。把每次执行产生的程序与日志留存下来，就形成了一份可复用的任务资产库。

构建反馈闭环比追求一次成功更重要。 让智能体在失败后能读到有效错误信息并自行修正，比要求它第一次就写对更现实，也更有扩展性。

通用能力优先于专用训练。 当一个通用编程智能体加上良好文档就能完成任务时，为每个任务单独训练模型的性价比就需要重新评估。至少在任务种类繁多、场景变化频繁的场合，代码即策略的边际成本更低。

七、结语

机器人学会给自己写程序，听起来像是终点，实际上是一个新的起点。它意味着机器人能力的扩展路径，从“采集更多数据训练更大模型”，部分转向了“完善接口文档 + 提升代码生成与执行反馈的质量”。前者受限于数据与算力，后者受限于工程规范程度——而工程规范，恰恰是可以通过设计来改进的。

当评测中那些让传统模型归零的扰动场景，被一段可读、可改、可复用的程序稳稳接住时，这个方向的价值就已经不言自明了。