会看图、会写代码的通用 Agent，能完成机器人操作吗？CodeActionBench 发布

从视觉观察到策略生成，再到物理执行与完成判断，CodeActionBench 在统一条件下评测通用多模态 Agent 的机器人操作能力。在双臂仿真评测中，GPT-6 Astra (Codex CLI) 的尝试成功率达到73.3%，Claude Opus 5 在 Reference harness 和 Claude Code 下分别取得49.3%和45.3%。

• 论文题目：CodeActionBench: Evaluating Agentic Code-as-Policy for Embodied Manipulation
• 项目主页：https://codeactionbench.org/
• GitHub：https://github.com/lyhkk/CodeActionBench
• arXiv：https://arxiv.org/abs/2609.33807

图 1｜Astra 根据观察生成代码，再依据执行反馈调整后撤动作，完成堆叠任务。

图 2｜Astra 在抓取未成功后重新观察、修正抓取姿态，随后完成双臂交接与放置。

通用多模态模型能理解图像、生成代码，也能根据工具反馈修改方案。当这些能力进入机器人操作，它们能否共同支持一次完整的抓取、转运和放置？

南洋理工大学研究者与合作者提出CodeActionBench，围绕这个问题建立了 25 个双臂仿真任务，对 9 个模型与运行框架配置进行了 675 次尝试。各配置的尝试成功率从 2.7% 到 73.3%，执行轨迹则揭示了总体分数背后的能力差异。

「让通用 Agent 自己把视觉观察转化为操作策略，并用物理结果检验这段过程。」

Agent 自行选择视觉证据、估计三维目标、编写并修正程序，评测同时检查任务结果、中间进展和完成判断。

共享接口，把任务决策留给 Agent

接口提供多少帮助，直接影响评测什么能力。如果系统已经给出物体位姿、抓取候选或完整技能，模型承担的工作，与自行从观察中构造动作目标明显不同。

图 3｜CodeActionBench 的共享机器人接口与评测流程。

CodeActionBench 基于 RoboTwin 2.0 和 SAPIEN，采用 ALOHA-AgileX 双臂机器人。评测不额外进行任务专属微调，也不提供任务示范、专门的感知或抓取模块输出、特权场景状态，以及预设任务策略。

共享 API 提供 RGB 图像、相机标定、机器人状态、接触反馈，以及几何计算和受限运动执行。Agent 自行选择观察视角与视觉目标，建立三维估计，再构造操作位置和姿态。逆运动学、运动规划和低层控制由共享基础设施承担。

「工具负责计算和执行，任务决策留给 Agent。」Agent 可以直接调用工具，也可以通过 run_code 将计算、分支、循环和多个动作写成 Python 程序，再根据实际反馈重新观察、修正目标或调整动作。

既看成功率，也看任务覆盖

每个任务固定一个场景实例，每个配置在每个任务上尝试三次，共 75 次尝试。任务条件、机器人接口和资源预算保持一致。七个配置使用 Reference harness，另外两个采用 Claude Code 和 Codex CLI。Harness 管理对话上下文，组织工具调用，并将执行结果反馈给模型。因此，比较对象是模型与 harness 的组合。

独立的隐藏 verifier 检查物理结果，评分不返回给 Agent。Agent 的完成判断另行记录，再与实际结果核对。

图 4｜九个 Agent 配置的尝试成功率与任务覆盖率。

图 5｜前三名配置在 25 个任务上的代表性执行片段，优先选取成功尝试。

在共享 Reference harness 的七个配置中，Opus 领先，Gemini 3.6 Flash 以 20.0% 的尝试成功率位居其后。

两项 Opus 配置的成功率相差 4 个百分点，任务覆盖却分别为 19/25 和 14/25。「成功率之外，能完成哪些任务同样重要。」

Astra 的表现，展示了代码构造策略的潜力

Astra 完成了55/75 次尝试，在22 个任务上至少成功一次，其中15 个任务三次全部成功。

图 6｜各配置在每个任务三次尝试中的成功次数。

「不额外训练 VLA 动作头，通用 Agent 也能通过代码完成操作任务。」在这组实验中，Agent 将已有的视觉、推理和编程能力用于目标估计、动作构造和策略修正，在推理时生成程序，再通过共享机器人接口执行。

程序如何组织，也与表现有关。一次程序提交可以组合多个工具调用，只占用一次外部调用额度，内部运动仍消耗仿真时间。程序提交占比指所有计入预算的工具调用中，通过 run_code 提交程序的比例。成功率最高的四个配置，该占比为85.6%至92.6%，其余五个为15.6% 至 35.2%。Astra 的占比最高，代码错误率也最低，仅0.46%（10/2,167）。这里的错误指 Python 异常与沙箱拒绝，和机器人动作失败分别统计。

图 7｜各配置的程序使用比例与代码错误率。

「这里的编程能力，体现在理解机器人工具，并将它们组合成有效的操作策略。」相较 Opus (Reference)，Astra 的总 API 等价成本低 15.1%，单次尝试中位耗时短 60.0%，为 477.2 秒。这些比较基于相同的固定场景，耗时包含模型等待和环境执行。

从「是否成功」到「做到了哪一步」

「最终成败之外，还需要衡量执行过程中的进展。」CodeActionBench 通过中间检查点（checkpoint），从空间到达和子目标完成两个层次分析执行轨迹：空间 checkpoint 记录机器人末端是否进入相关操作区域，子目标 checkpoint 记录阶段要求是否成立。两类覆盖率均按任务等权统计。

两项 Opus 配置的空间覆盖为 73.6% 和 73.4%，几乎相同，任务成功率与任务覆盖却有差异。相近的空间进展，可以对应不同的操作结果。结合物体运动、释放和目标状态，可以继续检查操作在哪个阶段受阻。

研究从未完成或后来失效的子目标出发，结合空间位置、接触、物体运动和释放记录，将每次失败归入最早有证据支持的阶段。491 次失败中，122 次已到达相关区域，却未完成或保持对应子目标。

图 8｜各配置的任务结果与失败阶段分布。

「做完了吗」，也由 Agent 自己判断

自主操作还包括决定何时停止。Agent 需要根据观察与执行反馈判断任务是否完成，或是否已经无法继续，再通过 done 主动结束并报告成功或失败。隐藏 verifier 独立评分，因此Agent 的自我判断和任务的实际结果，可以分别检验。

图 9｜前三名配置的自主终止与完成判断。

Astra 在 75 次尝试中有68 次作出正确判断，包括正确报告成功或失败。更能区分配置的是失败之后的判断：Astra 的 20 次失败中，14 次明确报告失败，3 次错误报告成功。Opus (Reference) 的 38 次失败中，相应计数为 14 和 13。预算耗尽前未作出声明的尝试单独统计，不算作判断错误。

「能执行策略，还需要能识别策略是否奏效。」这让评测进一步考察 Agent 能否依据反馈判断操作结果，并决定何时停止。

CodeActionBench 将任务结果、执行进展与完成判断联系起来，让研究者既能比较总体表现，也能沿着轨迹检查策略如何形成、在哪里停止奏效。后续方法可以在同一接口与协议下，进一步检验空间估计、程序组织和反馈利用的改进。

作者信息

作者包括南洋理工大学的 Yiheng Lyu（第一作者）、Xueying Jiang、Wenhao Li、Shijian Lu（通讯作者），以及独立研究员 Gongjie Zhang（通讯作者、CodeActionBench 项目负责人）。团队关注通用多模态智能体的机器人操作能力，研究视觉理解、代码生成与执行反馈如何支持自主操作。