仅靠代码的策略能让机器人决策具备状态、从而实现递归自我改进吗？

COAP 用代码取代控制回路中的模型

大多数机器人策略会在控制回路中保留一个模型。视觉-语言-动作模型（VLA）学习从观测到动作的映射，这种映射隐含在模型权重中；Agent Harness 这类方法（如 Agent-as-Policy 或 Harness VLA）则在运行时查询视觉-语言模型（VLM）来做决策，或指挥一个 VLA。论文提出的另一种思路是把具身世界看作一台具身图灵机：纸带是机器人和环境的状态，规则是策略。论文认为，只要这种状态能被准确表示，决策就可以完全用代码写出来。

纯代码策略（COAP）就是这一思路的实现。代码从相机图像和本体感知中测量并跟踪机器人、环境和任务状态，并据此计算每一个动作。同一段程序适用于不同回合，不同任务共享同一个代码库。执行时代码是冻结的：回路中没有 VLM，也没有 VLA。论文把它定位为状态到动作映射的第三条路径，与 VLA（映射隐含在权重中）和 Agent Harness（部分显式，但动作仍由黑箱 VLM 和 VLA 推导）并列。

状态分为三部分，各自来源不同

每一步，基准都会提供一个观测：一条指令、三张 RGB 图像（头部和两个腕部）、关节角度、末端执行器位姿以及夹爪指令回显。代码据此维护一个显式状态，包含三个部分，且在每个任务中形式相同。环境状态记录每个物体的位姿、尺寸和类别，以及物体之间的空间关系（例如一个物体放在另一个物体上），每条记录还保存该测量的误差、来源和时间。机器人状态记录每条手臂的关节角度、末端执行器位姿和夹爪开合度，以及每条手臂可达的位姿。这两部分共同构成纸带。任务状态记录当前阶段、每个物体分配给哪条手臂、重试次数，以及任务必须保留的信息，例如每个杯子下面的颜色——它相当于图灵机的内部状态。

三部分的来源不同。机器人状态每一步都来自本体感知。环境状态由感知层测量，感知层就是普通的 NumPy 和 OpenCV 代码：先用测得的关节角度把机器人网格投影到图像中并遮掉，与桌面颜色不同的像素成为候选区域，再用射线与平面求交把每个候选放到桌面上，然后通过搜索位置和偏航角来拟合已知的三维形状。任务代码在执行过程中更新任务状态。由于相机模型、机器人网格、物体形状和桌面高度都随基准公开、且不随回合变化，它们在代码中是常量，属于规则的一部分；回合之间变化的是状态，每次都要重新测量。

一个代码库让新任务无需重写旧任务

两个设计选择让代码库可以复用。每个任务操作的状态形式相同，因此为一个任务写的模块可以服务其他任务。代码分层且依赖向下：任务程序调用物体相关代码，后者调用抓取、拿起、放置、推动和倾倒等操作代码，再往下调用感知和运动代码。任务代码规定做什么——子目标顺序、任务特定决策、恢复条件——下层代码决定怎么做。一次 transfer 调用会展开为抓取候选生成、逆运动学与碰撞过滤、抓取前重新测量、接近、闭合、带保持检查的短距离抬升、搬运、放置、释放和最终验证。论文报告 83% 的代码行在任务间共享。

新任务通过三种方式之一扩展代码库：组合已有模块；继承已有任务并只覆盖一个决策，例如一个分拣任务复用整套流程，只替换把物体分配到篮子的规则；或者给共享函数增加一个默认关闭的参数，例如一个抬升方向参数让某个任务在篮子壁附近斜向抬升，而默认值保持原有的垂直抬升。默认关闭机制就是兼容性保证：对于任何不传入新参数的任务，其执行轨迹在单元测试覆盖的用例上必须保持不变。论文的分层表显示了这种分布——感知（5.3k 行）和运动（3.3k 行）被全部 40 个任务程序使用，操作（5.4k 行）被 78% 使用，而物体族（28.5k 行）只覆盖 18%，任务程序（23.5k 行）仅覆盖 2.5%。

编码智能体在离线阶段改进代码

改进发生在执行之前。编码智能体分轮工作——论文说明 Claude Opus 5.5 智能体编写了代码库和每个任务的全部代码，运行测试和评估，并自主调试自己的代码。每个智能体检查失败开发运行中记录的状态，定位出错的变量或规则，并提出一个 diff；由此产生的分支都是完整可运行的程序，可以在相同条件下并行评估。进入仿真之前，每个分支要通过两项 CPU 检查：任务代码在一个数值场景上执行，确认每个阶段都到达目标状态；机器人和物体网格在每个路径点上检查逆运动学解和碰撞。

调试和选择使用不同的数据。智能体在自己定义的开发集上调试，观看视频并把测量状态与仿真器真值对比；选择则比较验证集上的成功次数。只有当分支在目标任务验证布局上的成功次数超过当前代码、且超出重跑噪声的余量时，该分支才会被接受；否则当前代码继续部署，diff 不合并。论文认为这样每个被接受的步骤都不会降低性能，改进可以累积；并且由于策略是显式代码，离线测试的行为就是运行时的行为——论文以此对比此前一个机器人 RSI 回路，那里 VLM 仍在做执行决策，通过门槛的改动只是操纵一个黑箱。

70.24% 是代码库层面的数字，不是逐任务平均值

在 RoboDojo 的 42 项双臂任务上，最终代码库在测试时没有模型参与的情况下达到 70.24% 的成功率。这个数字是代码库冻结后、任务更新逐个合并后的总体成功率，每次合并只通过默认关闭参数改动共享代码；总体成功率在每次合并后都上升，从 66.5% 升到 70.24%。它不同于论文其他位置报告的逐任务数字：在有程序的 40 项任务上，标准成功率在验证集为 76.7%、测试集为 74.9%，随机化成功率分别为 55.2% 和 52.8%。把 COAP 与 VLA 基线比较的读者应区分这些分母——42 项任务与 40 项有程序的任务、标准布局与随机化布局、验证集与测试集。

论文还报告旧任务没有退化。在冻结代码库与最终代码之间，自身代码未改动的任务在相同布局上保持了成功率，从 78.4% 到 79.9%（Cochran–Mantel–Haenszel 检验，p = 0.16；没有任务出现显著变化）。把后来清理过代码的任务也算进来，成功率从 80.0% 升到 81.4%。论文明确指出，该检验能检测约 4 个百分点的合并偏移，因此它排除的是大幅退化，而不是每一处变化。对于代码库冻结时还没有程序的四项任务，论文绘制了平均最佳验证成功率随时间的变化，并给出逐任务时间线：首次成功出现在开始后 4.0 到 6.4 小时之间，其中 store_tools_in_toolbox 始终没有获得成功程序，按零计算。

多数失败源于状态测量而非代码逻辑

论文按“能避免该失败的最小改动”对每个失败回合分类，从头阅读轨迹并取第一个未被恢复的错误；这些标签是判断，并对照官方视频核实。失败分为两组。状态测量的限制占 62%：感知错误占 35%，仅用 RGB 输入会让错误数值进入状态（随机化场景中一个飞镖盘被识别成耳机）；接触错误占 27%，状态表示太粗糙，无法判断物体是如何被抓住的（夹爪夹住衬衫下摆，但软布滑出）。代码逻辑的限制占 37%：逻辑不完整占 29%，例如推动只尝试一次就停止，尽管它自己的检查发现方块仍然歪着；代码设计不佳占 8%，例如固定尺寸阈值把一块小手表过滤掉。

这一划分就是论文对其上限的说明：程序表示状态的准确和全面程度，以及代码逻辑的稳健程度。作者指出，可变形物体的接触本身就难以表示，但仍算作状态表示的限制；感知错误在真实场景中可能更严重。他们给出的修复与这一框架一致——感知用更好的估计和工具，接触重新抓取，逻辑不完整就推到检查通过为止，并从场景中推导数值而不是硬编码。

证据止于仿真，开发并非免费

所有结果都在仿真中。COAP 的感知依赖仿真基准公开的配置和资产——相机参数、机器人网格、物体尺寸——论文称这是主要限制；在真实机器人上，这些都需要重新测量，夹爪宽度和搬运速度等接触相关参数也要重新调校。论文还指出，代码的泛化能力可能有限。

第二个代价是时间。在线执行快速且便宜，但离线开发每一轮都需要评估和修改；与可以直接作为策略使用的模型不同，COAP 每新增一个任务都有开发成本。论文自己的时间线说明了这一点：新任务大约需要 2.7 到 7.9 小时才达到首次合并，四项任务中有一项始终没有成功。作者还提出 COAP 可以作为 VLA 和 Agent Harness 的数据引擎，因为同一段代码适用于不同回合，但这是提议，不是证据包中测得的結果。

决定性变量是状态精度而非模型规模

论文最有用的比较是内部比较：62% 的失败来自状态测量和表示的准确程度，37% 来自代码逻辑的稳健程度。这一排序告诉读者，在判断 COAP 式策略能否承载递归自我改进时该看哪里。编码智能体可以通过修改显式代码来修复硬编码阈值或缺失的重试，论文的合并记录显示，在这一机制下总体成功率从 66.5% 升到 70.24%。但仅用 RGB 输入造成的感知错误，或状态无法表示的接触，单靠更好的代码逻辑修不好——它需要更好的测量，论文把这一点列为未来工作，而不是已展示的收益。

因此实际的门槛是：状态表示改善时，COAP 的上限会移动；代码逻辑更稳健时，它的下限会移动。70.24% 这个数字处于一个使用基准提供几何信息的仿真中，覆盖 42 项双臂任务，且每个任务都要付出开发成本。任何把 COAP 与 VLA 或 Agent Harness 比较的人，都应在同一分母上比较——40 项有程序的任务、标准布局与随机化布局——并应把失败中状态测量所占的份额，看作决定该方法能否迁移到基准之外的关键数字。

本文引用的文献