比的是什么：给一个目标和一支机器人队伍，谁能选对最小支撑集，并把任务做成

最小支撑集：完成任务最少需要哪几只臂、哪几只可以闲着、桌上哪件东西能顶替一只臂，或者判定做不到并说出缺什么。所有方法用同一套工具、同一个控制端、同一份预算，只在"怎么决策"上不同。

一、评测流水线

任务实例8 个任务 × 5 个实例：exact、surplus、shortfall、borrow、放宽孪生

→

决策（各方法不同）用共用工具看场景、量尺寸、查可达，提交团队计划

→

控制端（共用）program API → check_program（IK + 间距）

→

Isaac 执行（共用）try_in_sim：物理执行，返回关键帧、事件、失败信号

→

评分（共用）团队 = 声明的 ∪ 实际用到的；对照 gold 和任务成功公式

执行失败后，失败报告退回给该方法自己的决策步骤，可以改团队。所有方法都有这次机会，预算相同：每个 case 2 次 probe、5 次运行。

二、对比方法：一句话实现，以及和我们的差异

组	方法	一句话实现	和我们（v5）的差异	预期在哪儿失分
参照	Oracle-脚本	拿 gold 团队和手写参考脚本，直接在 Isaac 回放	不做决策，只用来证明每个版本确实做得到，给出 SR 上限	—
参照	Oracle-团队	把正确团队直接交给共享执行器，写程序并执行	跳过决策，只测执行本身会丢多少 SR	只有执行误差
参照	模式猜测器	一条规则：3 臂以上用西、东、南三只；2 臂且有东西就用最大那件；否则判做不到	不看场景只猜规律。开跑任何模型前它必须接近 0 分，否则题目有漏洞	所有需要测量的地方
参照	盲试	不推理，从最小团队开始逐个在仿真里试，第一个跑通的就是答案	只试不想：会把"没抓住"当成"人不够"	多派人、误判做不到、预算耗尽
参照	LLM + 求解器（v3+）	LLM 把场景翻译成 job 和执行者（臂、臂 + 工具、搬运件、被动件），由精确搜索选出最少	只推理不取证：没有带余量的逐点测量，也没有"拿掉一只再验证"	翻译错：漏 job、余量判错
参照	Claude Code	通用编程 agent，接上我们的工具，自带 Bash 和 Python，用默认提示	工具和预算完全一样，只是没有我们的方法论。v5 最直接的对手	多派人、不肯说做不到、不量余量
文献	SMART-LLM 式	一个 LLM 按"分解 → 按能力组队 → 分配"三步走；技能表换成按臂查询，桌上的东西作为候选	同样是集中式、固定流程，但没有证据规则，也不能根据失败信号回头改团队	少臂、借物
文献	EMOS 式	每只臂开局写一份"能力简历"（工作半径、高度、开口、负载），之后集中开会分工	能力是事先概括的，不能在任务的具体点位上逐点查	厘米级余量、借物
文献	RoCo 式	每只臂一个 LLM，只知道自己够得着什么，互相对话商定方案，可以说"我不参加"	分散自荐，没有全局视角	加臂时多派人
文献	HMAS-2 式	中央 LLM 提方案，各臂的 LLM 审核自己那部分并可以否决	混合式；否决只看各臂自己的可达性	少臂、借物
我们	v5	一个 LLM 按固定流程：列 job → 谁能做 → 只有一只臂能做的 job 去找替代物 → 最少臂 → 逐个拿掉验证；每条结论引用工具记录；执行失败带着失败信号回头改团队	—	—

四个文献方法都只改输入输出、不改推理方式：补上"这只臂不需要""做不到、缺什么""用了 / 拒绝了哪些东西"这几个输出。它们的原样版结构上就答不了这些问题，所以不跑原样版，只在相关工作里列能力对照表。CaP-X 没有选团队这一步，不单列一行；共享执行器就是照它设计的。

三、方法之间的差异

方法	谁做决定	"哪只臂能做什么"从哪来	失败后改什么	执行器
模式猜测器	规则	不看，只看臂数和物体尺寸	—	不执行
盲试	规则 + 仿真成败	不看，只看跑没跑通	换下一个团队	共享
LLM + 求解器	LLM 翻译，求解器决定	翻译时查询	改 job 模型，重新求解	共享
Claude Code	一个通用 agent	它自己决定查不查	它自己决定	自己
SMART-LLM 式	一个 LLM，固定三步	组队时按臂查询	回到组队	共享
EMOS 式	简历 + 集中组会	开局写一次简历，之后不再查	回到组会（简历不变）	共享
RoCo 式	每只臂一个 LLM，对话	每只臂只查自己	回到对话	自己（汇总者）
HMAS-2 式	中央提议，各臂否决	每只臂只查自己	回到提议	自己（中央）
v5	一个 LLM，固定流程 + 证据 + 回环	逐点带余量查询，再用 `who_can`、`check_team` 汇总	带着失败信号回第一阶段	自己

四、固定的工具：所有方法共用

感知与测量

briefing 目标、坐标系、各臂型号和位置；每件东西的粗略质量
look 固定相机或某只臂的腕部相机拍一张图
read_arm 关节角和限位、工具点位姿、夹爪开度、关节力矩
locate 物体或部件的包围盒（有几毫米误差）
can_reach 臂自身的 IK：能不能到、差多少（带余量）
measure 部件和尺寸：长度、高度、开口
heft 抬 2 cm 读力矩，得到较准的质量
probe 在仿真里试一个小动作（每 case 2 次）
note 记下已确认的事实和证据

控制端

program API：tool_pose move grip push release open_fingers phase 等；程序只设一个 PLAN
check_program 沙箱运行 → 每条路径解 IK → 间距检查（臂与臂 3 cm、臂与场景 1 cm），逐条报冲突
try_in_sim Isaac 物理执行：关节目标、特权吸附（先查夹爪开口）；返回 4 张关键帧、事件日志、各 job 的失败信号（每 case 5 次）
submit_program 提交最终程序

没有哪个方法能绕过这一层直接控制臂。

输出与评分

submit_team_plan：能不能做、用哪几只臂、闲置臂及理由、用了 / 拒绝了哪些东西及证据、缺什么
评分器：任务自带的成功公式；gold 由各任务声明的 job 和 IK 余量自动算出
团队 = 声明的 ∪ 实际用到的（碰到物体，或工具点进入某个 job 位置 5 cm 以内）

只属于 v5 的

who_can 每个 job 有哪些臂（或臂 + 工具）能做
check_team 检查一支队伍：四类执行者、带余量，报告差多少
证据规则：每个"去掉它就不行"、每个被拒的东西都要引用工具记录
约束监视器；回头改团队的回环

五、一个任务的实际执行过程：以 Rea-01 跨区接力为例

目标（agent 只拿到这一句）：Move the apple from the start area at the far west end of the table into the crate at the far east end.

场景：西端、东端各一台 Piper，南边一台 Franka；苹果在西端外侧，筐在东端外侧，相距 2.1 m；桌子中间立着一块 30 cm 高的玻璃隔板。

手写脚本参考解（不是 agent 跑的）：西 → 垫 A → 南 → 垫 B → 东 → 筐，约 29 s 成功

第一阶段 · 定团队读题：briefing 给出目标、三只臂的型号和位置、桌上每件东西及其粗略质量。
看场景：look 看俯视图和腕部相机，locate 得到苹果、筐、隔板、两个垫子的位置。
列 job：在起点取苹果；把它带过桌子中间；放进筐里。
查谁能做：can_reach / who_can：起点只有西臂够得着，筐只有东臂够得着；隔板挡住了两端臂唯一可能相遇的地方，所以"带过中间"只有南臂能做（它绕过隔板，两个垫子都够得着）。
验证最少：check_team 检查 {西, 南, 东}：通过。逐个拿掉再检查：去掉南臂，两端臂之间找不到共同可达的点，check_team 报出最近还差多少厘米；去掉任一端臂，起点或筐就没人够得着。结论：3 只臂，缺一不可。
提交：submit_team_plan：能做；用西、南、东；每只臂的 job；每条"缺它不行"都引用上一步的工具记录。
第二阶段 · 执行写程序：按阶段写 PLAN：西臂取苹果放到垫 A → 南臂从 A 搬到 B → 东臂从 B 放进筐。
离线检查：check_program 对每条路径解 IK、做间距检查。有冲突就改程序，不动机器人。
真跑：try_in_sim 在 Isaac 里执行，返回 4 张关键帧、事件日志和是否成功。
失败怎么办：如果是"没抓住、撞了"，属于执行问题，就改程序。如果报出某个 job 的失败信号，就带回第一阶段改团队。都受同一份预算约束。
评分判分：实际用到的臂 = {西, 南, 东}，和 gold 一致，算选对；按任务公式判成功（苹果在筐里停留 1 s）；同时记下调用次数、运行次数和费用。

同一个任务的 5 个实例，正确答案各不相同

实例	桌上有什么	正确答案	考的是什么
exact	西、南、东三只臂	3 只都用，各干各的	谁做什么
surplus	再加一只北臂	仍然只用 3 只，多出的那只闲着（gold 由 IK 算出哪些组合可以）	不因为有就用
shortfall	拿掉南臂	做不到；缺的是"把苹果带过中间"	敢说不，并说清缺什么
borrow	拿掉南臂，加一个大转盘和一个小转盘	西、东 + 大转盘：西臂放上去转过去，东臂取下；小转盘两端臂都够不着边，要拒绝	看出东西能顶替臂，并且选对是哪一件
放宽孪生	同一场景，去掉隔板	2 只臂：两端臂能在中间直接交接	靠测量而不是靠"三只臂"的印象

六、公平规则

同一个 backbone：主表用 Opus 5.5，附录用 Qwen-27B
同一套工具、同一个信息档（只告诉臂的名字和位置，能力要自己查）
同样的试验机会：每 case 2 次 probe、5 次运行，失败后都能改团队

同样的调优投入：只在开发池（未入选的任务）上调 prompt，绝不在 8 个任务上调
两种设定都报：一次性（不准试，只靠推理）和同等预算（都能试）
一次失败只有在报出 job 失败信号时才算"人不够"的证据：一个程序失败，不代表所有程序都失败

七、现状与下一步

已有

8 个任务：Rea-01 到 Rea-04、Con-04 在 mrbench 里，参考解两档都在 Isaac 里跑通；Con-01 到 Con-03 是 ruihe 的物理原型，四种情况都录好了
agent 原型 v4.1：第一阶段定团队，第二阶段写程序并在 Isaac 里执行（HA3 端到端跑通过一次）
program API、check_program、try_in_sim、可达性检查（validate --ik --slack）

待建（按顺序）

WP1 gold 自动计算 + 各 job 的失败信号；WP5 评分 v2 + 模式猜测器
WP2–4 加臂、少臂、借物、放宽孪生；WP10 移植 3 个物理原型
WP6 v5 的工具和流程；WP9 各基线行、Claude Code 隔离、吸附开口检查
WP8 跑实验：每行每种设定 120 个 session，同等预算设定最多约 180 GPU·h

风险

模式猜测器现在还压不到 0（多出的臂总能闲置、少臂版桌上没东西、道具总是更大的那件），要靠放宽孪生和干扰物设计改
Con-02、Con-04 是否真的需要三只臂还没证实
LLM + 求解器可能是强对手；v5 要赢在余量测量、取证和失败回环上