← 科研空间 首页
arXiv 2606.24815 · 原版 PDF Pablo Valle · Shaukat Ali · Aitor Arrieta · Lionel Briand · Mondragon / Simula / Ottawa

MANGO：让 AI 给机器人评测写判卷标准

多智能体自动生成细粒度 test oracle——失败不再是一个 0/1，而是第 3 步没完成（arXiv 2606.24815）

版本注记：阅读基于 arXiv:2606.24815v3；2026-10-23 再分析。本次补入跨论文评测栈洞见并复核证据边界；既有实验数字与结论沿用原页，未将系列论文结果合并，也未声称完成新的外部状态核验。

先讲一个故事：评测里最贵的那个人

机器人评测链条上有一个奇怪的角色分工：训练 VLA 要几千张 GPU 小时，跑仿真要几百小时，可到了最后一步——判断"这个任务到底成没成功"——靠的往往是一个研究生手写的一段 Python：if 物体A在冰箱里: success。LIBERO、SimplerEnv、RoboCasa 全是这个模式。任务设计者人肉把自然语言指令翻译成终态检查，一段代码对应一条指令，换个任务就得重写。

上一页我们读的 Metamorphic Testing 绕开了这个问题——不判对错，判关系。但那需要你先知道"什么该变、什么不该变"。这一篇（MANGO）走的是另一条路：既然 VLA 能读懂自然语言指令，为什么评测 oracle 不能也由模型从指令里生成？

MANGO 的答案是三级流水线 + 三个角色。先从一批复杂指令里提取一个"原子任务库"（Open、Pick、Place、Close 这样的参数化模板）；再给每个原子任务生成一个仿真器可执行的检查函数；最后把新指令分解成原子序列，将对应的原子 oracle 组合成"细粒度 oracle"——不只判终态，而是逐步骤判定：失败不再是一个 0/1，而是"第 3 步 Pick(Bottle) 没完成"。

数字口径：LIBERO_10 + RoboCasa Humanoid Tabletop 两个基准、2,814 条执行做一致性对照、336 条失败执行做失败定位人工抽检。生成出的细粒度 oracle 与人工写的符号 oracle 判定一致率 91%（LIBERO_10 上 98%），失败定位准确率 78%（LIBERO_10 上 100%）。

图 1（Approach_overview）：MANGO 三模块总览——Module I 从复杂指令集蒸馏原子任务库，Module II 为原子任务生成仿真器可
图 1（Approach_overview）：MANGO 三模块总览——Module I 从复杂指令集蒸馏原子任务库，Module II 为原子任务生成仿真器可执行 oracle，Module III 分解新指令并组合出细粒度 oracle。

故事与技术如何对应

故事元素 论文概念 性质
if 物体A在冰箱里: success 符号 end-state oracle：O_s(s_{n-1})∈{Pass,Fail}，只查终态 被替换对象
"第 3 步 Pick(Bottle) 没完成" 细粒度 oracle：D(I)=⟨a_i(θ_i)⟩ 原子分解，O_F(I)=∧O_{a_i}，逐步骤判定 论文贡献
三级流水线 + 三个角色 Module I 原子任务库 → Module II 原子 oracle 库 → Module III 细粒度 oracle；Generator/Assessor/Judge 多智能体迭代 方法核心
一致率 91%/98%、定位 78%/100% RQ2：与基准自带符号 oracle 的 agreement + 失败定位抽检（Cochran 抽样 336 条） 论文实证
10 条指令 → 3.1 条 RQ4：(1+1)EA 原子库缩减——少量复杂任务即可生成同等原子库（similarity 1.000） 论文实证

先给结论

它是什么

一个用多智能体（Generator/Assessor/Judge）自动生成"可执行细粒度 oracle"的框架。输入是自然语言任务指令集，输出是能逐步骤判 Pass/Fail 并定位失败步的仿真器代码。它不评测某个 VLA 的好坏——它生成"评测工具"本身，被测对象是 oracle。

三个数

① RQ2.1：2,814 条执行上与人工符号 oracle 一致率 0.91（precision 0.91 / recall 0.95 / F1 0.93）；LIBERO_10 达 0.98，RoboCasa 0.87。② RQ2.2：336 条失败执行的人工抽检定位准确率 0.78；LIBERO_10 完美（1.00/96），RoboCasa 0.70/240。③ RQ4：复杂任务集可缩到 3 个左右（TRR 0.69–0.854）而原子库语义等价（similarity 1.000）——固定成本是一次性的，之后近乎免费复用。

最大的亮点

① 把"谁写 oracle"从研究生变成模型，且 evalutaion 不再与具体任务耦合——原子任务模板跨任务、跨基准复用；② 263 个不一致样本的逐例归因（这是全文最见功力的部分：97 个 FN 是仿真物理不稳、48 个 FP 是符号 oracle 自己漏检）；③ 消融设计干净：Module I/II/execution reliability 各自的贡献都有统计检验（Vargha–Delaney A12）。

最大的保留

① 评测依赖仿真器状态检查函数的质量——作者自己就修过两个（lift 阈值、proximity 中心），修正前定位只有 0.50；oracle 的上限被仿真器函数表面积卡住。② "与符号 oracle 一致"只证明复现，不证明超越——真正的增量证据只有 48 个"细粒度对、符号错"的案例（约 1.7%）。③ 只测了两个仿真基准的桌面操作；LLM-judge 评估 similarity 用模型评模型。④ 生成成本不低（Module II ~10 分钟/库，Module III ~6 分钟/指令）。

图（Symbolic_oracle）：符号 end-state oracle 的结构——只对终态 s_{n-1} 做一次 Pass/Fail 判定，无法区分「没
图（Symbolic_oracle）：符号 end-state oracle 的结构——只对终态 s_{n-1} 做一次 Pass/Fail 判定，无法区分「没打开冰箱」与「没放进瓶子」两类失败。

动机：oracle problem 的"供给侧"解法

软件测试文献里 oracle problem 的经典表述：判定程序输出正确与否，往往比写程序本身更难。机器人把它推到极端——判定函数要理解"放进冰箱"是什么意思，还得抵抗仿真噪声（物体弹跳、抓取粘滞）。

现有路线各有痛点：符号 end-state oracle（LIBERO/RoboCasa 自带）每个任务一段手写代码，不定位失败步；机器学习裁判（VLATest 的 LLM-judge、Q-DIG 的 judge）每个 rollout 都要跑一次大模型，判定还带噪声；人类评估最准但每条几十秒起步。MANGO 的赌注是：oracle 可以一次生成、永久复用——把 per-execution 的判定成本换成分解一次的固定成本。

注意这里跟上一篇的分工：Metamorphic Testing 判"轨迹之间的关系"（过程质量），MANGO 判"任务步骤是否完成"（语义分解）。两者都不需要人工为每条指令写终态检查，但视角不同。

图（VLA_arch）：VLA 模型架构——视觉、语言、本体状态编码到共享表示，经扩散动作精化输出动作序列；MANGO 的被测对象是评测 oracle 而非 V
图（VLA_arch）：VLA 模型架构——视觉、语言、本体状态编码到共享表示，经扩散动作精化输出动作序列；MANGO 的被测对象是评测 oracle 而非 VLA 本身。

形式化：指令分解 + 原子 oracle 组合

细粒度 oracle 的定义分三层：

  1. 指令分解：D(I)=⟨a_0(θ_0), a_1(θ_1), …, a_{n-1}(θ_{n-1})⟩，每个 a_i 是参数化原子任务模板（如 Place(Bottle, Fridge)），θ_i 是任务参数。序列可以是严格有序、无序或偏序——"开冰箱"和"拿瓶子"无先后（∥），但都必须在"放瓶子"之前（≺）。
  2. 原子 oracle：O_{a(θ)}: s→{Pass,Fail}，检查单个原子任务的效果，如 O_{Open(Fridge)}(s)=isOpen(Fridge, s)。参数化让模板跨对象、跨场景复用。
  3. 组合：细粒度 oracle 是原子 oracle 的合取，再叠加时序约束：
    $$ O_F(I) = \bigwedge_{i=1}^{n} O_{a_i(\theta_i)} \;\; \text{s.t.}\;\; a_j \prec a_k \;\Rightarrow\; \text{step}(a_j) \le \text{step}(a_k), \quad \text{Localization}(I) = \arg\min_i \{ a_i : O_{a_i} = \text{Fail} \} $$
    失败定位 = 序列里第一个 Fail 的位置。

一个设计选择值得肯定：oracle 刻画的是"任务结构"而非"机器人行为"——无序约束允许双臂并行也允许单臂顺序，不替 VLA 决定怎么执行。这让 oracle 是 robot-independent 的。

图（Fine-grained_examples）：细粒度 oracle 对比例子——同一指令分解为原子任务序列后逐步骤判定，失败定位到具体原子步。
图（Fine-grained_examples）：细粒度 oracle 对比例子——同一指令分解为原子任务序列后逐步骤判定，失败定位到具体原子步。

方法：三个模块，三种角色

Module I（原子任务库生成器）：吃进一批复杂任务指令（LIBERO_10 的 10 条或 RoboCasa 的 24 条），产出原子任务模板库——相当于从语料里蒸馏出该域的"动词表"。

Module II（原子任务 oracle 库生成器）：为每个原子任务模板生成对应的仿真器可执行检查函数（调 simulator API 查状态）。这一步是最难的：要把语义谓词翻译成具体函数调用与参数。

Module III（细粒度 oracle 生成器）：分解新指令 → 查库选原子任务 → 组合原子 oracle → 生成可执行代码，含 execution reliability 机制（在仿真器里实际跑一遍验证 oracle 能执行）。

每个模块内部是多智能体协作：Generator 起草，Assessor（多个轻量评估员）分别检查结构、可执行性、完整度、副作用，Judge（推理型模型）汇总裁决并决定迭代还是通过。基座模型经过附录的 8 维人工评测选择——Gemini Robotics-ER 系列（正文写 1.6、附录写 1.5，版本号不一致，两处都保留）；基线用 NVIDIA Cosmos Reason 2。

图 2（Module1）：Module I 原子任务库生成器——Generator/Assessor/Judge 在该模块内的协作回路：候选原子任务经结构、可执
图 2（Module1）：Module I 原子任务库生成器——Generator/Assessor/Judge 在该模块内的协作回路：候选原子任务经结构、可执行性、完整度评估后入库。
图 3（Module2）：Module II 原子任务 oracle 库生成器——为每个原子任务模板生成调用仿真器 API 的检查函数。
图 3（Module2）：Module II 原子任务 oracle 库生成器——为每个原子任务模板生成调用仿真器 API 的检查函数。
图 4（Module3）：Module III 细粒度 oracle 生成器——指令分解、库检索、参数实例化与 execution reliability 验证
图 4（Module3）：Module III 细粒度 oracle 生成器——指令分解、库检索、参数实例化与 execution reliability 验证回路。

实验设计：被测的是 oracle，不是机器人

这个设定容易误读，先说清楚：MANGO 论文里没有 VLA 模型对比实验。仿真执行（每条约 200 秒仿真时间）只是用来产生带失败标注的数据集；所有 RQ 的被测对象都是 oracle 生成本身。

结果：四张体检表

RQ1：生成质量全面压过单智能体

MANGO 在两基准上 validity 0.990/1.000、executability 0.800/0.933、similarity 0.912/0.947；单智能体基线各指标显著更差。代价是生成时间：Module II 约 638s/222s、Module III 约 347s/350s（每库/每指令一次性成本）。

RQ2.1：一致率 0.91，且分歧大多不是 MANGO 的错

2,814 条执行上总体 acc 0.91 / F1 0.93；LIBERO_10 0.98，RoboCasa 0.87。263 个分歧逐例人工检查后：LIBERO 仅 8 个是 MANGO 翻译错误；RoboCasa 的 97 个 FN 源自仿真物理不稳（物体放进容器又弹出来、抓取后粘手），48 个 FP 反而是符号 oracle 漏检——柜门关上把瓶子弹进柜内这种"流程错误"只有细粒度 oracle 能看见。

RQ2.2：定位 0.78，但两个基准差距悬殊

336 条抽检：LIBERO_10 100%（96 条），RoboCasa 0.70（240 条）。作者坦承修正了两个仿真器函数（lift 高度阈值相对地面→相对桌面、proximity 用手部中心），修正前定位只有 0.50。定位能力被仿真器状态函数的表达面积硬性限制——这是"oracle 依赖仿真器 API"这一架构选择的直接代价。

RQ3+RQ4：每个模块都不可少；库是一次性投资

去 Module II 后 executability 从 0.933 崩到 0.013（RoboCasa）——原子 oracle 库提供实现级知识，没有它 Module III 反复迭代也不收敛。去 Module I 出现耐人寻味的假象：LIBERO executability 反升到 0.990，但那是退化成了 end-state 检查（只查终态自然容易可执行），similarity 掉到 0.687 暴露真相。去 execution reliability 生成时间快 4.4–6.7× 但三指标全降。RQ4：(1+1)EA 把任务集缩到 3 个左右（TRR 0.69/0.854）原子库仍语义等价——边际成本趋零。

个人评价（明确标注：这是我的判断）

做对的事：把评测自动化的对象从"输入生成"（fuzzing、场景生成——VLATest 那一路）挪到"判定生成"，这是评测链条上最后一块纯手工领地。263 例分歧的逐例归因是全文最扎实的部分——大多数论文只会报一个 agreement 数字，这篇把它拆成了"仿真物理不稳/符号 oracle 漏检/生成错误"三类，其中"符号 oracle 漏检"48 例实际上是在说：ground truth 本身不 ground。RQ3 消融里"executability 反升是假象"的分析也体现了对指标语义的敏感。

我的批评：① agreement 高主要证明"能复现"，增量价值（定位 + 漏检）的样本量其实很小——48 个漏检案例对 2,814 条只有 1.7%，且集中在 RoboCasa 少数任务的特定物理交互；论文标题级的"fine-grained 更好"叙事比证据跑得快。② 对仿真器状态函数的依赖是结构性软肋：MANGO 的能力上限就是 simulator API 的表达能力，真机部署（没有 isOpen() 这种函数）完全没有触及——论文只在 future work 里提了一句。③ LLM-judge 评 similarity 是模型评模型，与 RQ2 用同一族 Gemini 做判定，循环风险没有讨论。④ 生成成本报告口径是每库/每指令的秒数，但没有跟"人工写 oracle 的工时"做对齐换算——这个对比本来是最有说服力的。

系列视角：Q-DIG 用失败方差找"该测什么"，MT 用轨迹关系测"过程好不好"，MANGO 生成"判定工具"。三者拼起来是一条完整的评测自动化栈——但每篇都只在仿真里成立。真机评测的 oracle problem（没有状态 API、物理不可重置）依然无人认领。

One more thing：评测工具的成本结构革命

RQ4 里藏着这篇论文最容易被忽略的经济学：原子任务库的生成成本是一次性的，且可以用 3 个复杂任务就"蒸馏"出来。这意味着评测工具的边际成本趋近于零——第 101 条指令的 oracle 生成不再需要人，只跑 Module III（约 6 分钟）。

对照现实：基准维护者写 oracle 的速度是瓶颈。LIBERO 130 条任务、RoboCasa 更新到 humanoid tabletop，每条背后都是工程师时间。如果 MANGO 这套可行，"基准"的定义可能改变——不再是任务+人工判定，而是任务+原子库，判定由库自动组合。当然，这一切的前提是仿真器愿意暴露足够丰富的状态检查函数，而仿真器设计者现在的激励（渲染好看、物理稳定）恰恰不朝这个方向。

跨论文洞见：评测自动化不是单一指标，而是分层接口

  1. 输入覆盖与判定构造是互补瓶颈。 VLATest 关注测试场景/输入的 fuzzing，而 MANGO 把自动化推进到 oracle 生成；前者扩大“测哪些情形”，后者改善“如何判断每一步”。因此不能把场景多样性直接当作判定可靠性证据，完整评测流水线需要分别验证两端。
  2. 关系型 oracle 与步骤型 oracle 回答不同问题。 Metamorphic Testing 用轨迹间应保持/改变的关系检查行为，MANGO 则把指令拆成原子步骤并检查完成情况；前者可暴露变换下的不一致，后者提供任务步骤级定位。二者可互补，但不互相替代：关系成立不必然意味着任务成功，单条轨迹步骤通过也不证明跨条件稳健。
  3. 把安全红队结果接入 oracle 仍是待验证的接口。 ERT 与 Q-DIG 的系列页面分别指向具身/指令层的红队测试问题；与 MANGO 拼接的研究设想，是让红队发现的失败条件转化成可执行的逐步检查。但这是跨论文的设计假设，不是 MANGO 已实现或验证的能力，需单独检验安全语义覆盖及误报漏报。

证据边界：前两条只综合各论文页面所述的问题层级；第三条明确属于后续研究假设。各论文基准、模型和指标不同，以上不构成跨论文定量比较或共同实验结论。

Other Discussion Roles / 其他讨论角色

以下七个角色使用 MIT MAS.S60 课程原始 prompt，从不同责任位置审视同一篇论文。

Scientific Peer Reviewer

The paper has not been published yet and is currently submitted to a top conference where you’ve been assigned as a peer reviewer. Complete a full review of the paper answering all prompts of the official review form of the top venue in this research area (e.g., NeurIPS). This includes recommending whether to accept or reject the paper.

📋 审稿人：证据强度分项评级

主张 1（自动生成可行）：强支持。RQ1 三指标 + 统计检验 + 10 次重复，基线对比完整；executability 0.8-0.93 的水平对代码生成任务可信。主张 2（与符号 oracle 等效甚至更优）：中等支持。agreement 0.91 高，但"更优"仅由 48 例漏检支撑（1.7%），且集中在 RoboCasa 特定物理交互；"等效"部分受循环风险（Gemini 判 Gemini 生成物）影响打折。主张 3（失败定位能力）：中等支持。LIBERO_10 的 1.00 很漂亮，但 RoboCasa 0.70 且依赖作者修正仿真函数（修正前 0.50）——定位能力对底座函数质量敏感，这个敏感性本身是重要发现但削弱普适宣称。主张 4（模块必要性）：强支持。消融 + A12 效应量齐全，"去 Module I 后 executability 假升"的归因分析质量高。主张 5（库可从小种子生成）：中等支持，RQ4 的 similarity 1.000 由 LLM-judge 评出，无人工确认。

缺失的对照：① 人工写 oracle 的工时基线（成本对比是卖点却没量化）；② LLM-judge 每次判定 vs 一次生成 oracle 的成本/精度帕累托对比（现有叙述默认 oracle 复用必赢，但判 100 次的 LLM-judge 也许更准）；③ 粒度敏感性分析。威胁分析（threats_to_validity.tex）覆盖了仿真局限与外部效度，是合格的，但未触及循环评估威胁。总体：方法论文的合格线以上，"fine-grained 优越性"的叙事应在讨论中被证据规模约束。

Archaeologist

This paper was found buried under ground in the desert. You’re an archeologist who must determine where this paper sits in the context of previous and subsequent work. Find and report on one older paper cited within the current paper that substantially influenced the current paper and one newer paper that cites this current paper.

🏛️ 考古学家：从 "Test What You Instruct" 到 MANGO

论文主 TeX 文件的注释层保留了三次改名：v 系列早期叫 "Test What You Instruct: Instruction-Driven Automatic Fine-Grained Oracle Generation…"，后来砍掉 "Instruction-Driven"，再后来整体缩写化为 "MANGO: Automated Test Oracle Generation… via Multi-Agent Foundation Models"，最终定稿是 "MANGO: Automated Multi-Agent Test Oracle Generation for Vision-Language-Action Models"。标题的演变方向很清楚：从描述技术机制（指令驱动、细粒度）转向品牌化缩写（MANGO）+ 方法家族归属（multi-agent）——这是投稿打磨的典型轨迹。

团队谱系比标题更有信息量：这是 Mondragon（Valle/Arrieta）+ Simula（Ali）+ Ottawa/Lero（Briand，IEEE Fellow）的延续性合作——Briand 是经验软件工程和测试领域的宗师级人物，Simula 与 Mondragon 在搜索软件工程上有长期合作脉络。本系列第 3 篇（Metamorphic Testing，2602.22579）同一团队，同批资助（巴斯克政府 PRE_2025_2_0252、MCIU PID2023-152979OA-I00、挪威 Co-tester 314544），但两篇的资助清单不完全相同——MANGO 多了 EGONLABUR 2026、Elkartek KK-2025/00102、欧盟 FRAME、Research Ireland/NSERC，对应 Briand 的加入与项目周期推进。

时间线：arXiv:2606.24815 v1 于 2026 年 6 月下旬，本页阅读基线 v3 含大量 \revision 标注（投稿轮修改痕迹），IEEE 期刊模板（IEEEtran journal format），Lionel Briand 挂 Fellow 头衔——这个组合暗示目标是 TSE/TOSEM 一类的软件工程旗舰刊，而非机器人会议。检索日（2026-10-20）未见录用声明，发表状态按"arXiv v3 修订版"处理，不预写"已发表"。

Academic Researcher

You’re a researcher who is working on a new project in this area. Propose an imaginary follow-up project not just based on the current but only possible due to the existence and success of the current paper.

🎓 研究者：为什么这是软件工程论文而不是机器人论文

MANGO 的贡献结构是 SE 社区的标准打法：问题定义（fine-grained oracle 形式化）→ 方法（multi-agent pipeline）→ 系统（模块化设计 + 消融）→ 实证（RQ1-4 + 统计检验 + 效应量）→ 威胁分析。它引用的对话对象是测试社区（oracle problem、search-based SE 的 (1+1)EA），而不是 VLA 社区（没有 baseline VLA 对比实验）。把它读成"VLA 进展"是错位的——它是"VLA 时代的基础设施工程"。

方法上我认为有三处值得学的：(1) 分层复用——原子库跨任务跨基准，RQ4 进一步证明库可以从极小种子集生成，这是把"知识库"当作显式资产管理的思路；(2) execution reliability 闭环——生成物必须在目标环境里真的执行一次才算数，消融显示这一项贡献了最大的质量提升（去掉后 executability 0.933→0.037），这个"生成-验证"循环对一切代码生成任务都适用；(3) 分歧归因——263 例不一致逐例分类，把 agreement 从黑盒数字变成因果清单。

开放问题：细粒度 oracle 的"粒度"没有自适应机制——一条指令分解成几个原子任务是 Module III 决定的，分得过细会把仿真噪声放大成假失败（RoboCasa 定位 0.70 的部分原因），分得过粗又退化成 end-state。论文没有讨论粒度选择的原则。此外 similarity 指标用 LLM-judge，与 MANGO 自身的 Gemini 家族同源——循环评估风险应当用人工双盲对照排除。

Industry Practitioner

You work at a company or organization developing an application or product of your choice (that has not already been suggested in a prior session). Bring a convincing pitch for why you should be paid to implement the method in the paper, and discuss at least one positive and negative impact of this application.

🏭 工程师：能拿来干什么

直接可用的场景：你维护一个内部仿真评测集（哪怕是 20 条任务），每次加任务都要手写 success check。MANGO 流程可以压缩为：用强模型从全部指令提取原子动作词表 → 为每个动作写一个参数化检查函数（人工过一遍，这一步值得花时间）→ 新任务只做分解+查库。按 RQ4 的结论，词表一旦建好，3 个任务的种子就够——增量成本约等于一次 Module III 调用（几分钟级）。

别拿来干的：① 真机 CI——oracle 依赖仿真器状态查询 API，真机没有 isOpen(Fridge)；② 高物理接触任务的失败定位——RoboCasa 的 0.70 定位说明接触丰富场景的 oracle 会被物理噪声拖垮；③ 替代人工审计——论文自己保留了"人审在不可靠仿真器上仍有价值"的结论。成本上要有预期：Module II 生成一个库约 10 分钟推理时间（Gemini Robotics-ER 计费），批量迁移基准时这是主要开销，但一次性。

工程化建议：把 execution reliability（生成后必须真跑一遍）直接内建到你自己的任何 LLM 代码生成管线里——消融显示这是单项贡献最大的机制，实现成本只是"多跑一次"。

Hacker

You’re a hacker who needs a demo of this paper ASAP. Implement a small part or simplified version of the paper on a small dataset or toy problem. Prepare to share the core code of the algorithm to the class and demo your implementation. Do not simply download and run an existing implementation – though you are welcome to use (and give credit to) an existing implementation for “backbone” code.

🛠️ 复现者：multi-agent oracle 生成的最小机制演示

我写了一个玩具演示 MANGO 的核心机制——为什么"原子任务库 + 组合"比"直接生成整条 oracle"更稳。模拟：指令集 6 条（含 2 条复合指令），比较 (a) MANGO 式：先从指令集蒸馏原子库（Pick/Place/Open/Close/Pour…），再分解新指令组合 oracle；(b) 单智能体式：直接为新指令生成整条 oracle。两个"模型"的语法错误率相同，差异只在一个结构假设：原子库里的模板已被复用过多次（每次复用提供一次错误修正机会），而整条生成没有这个积累。 

原子库蒸馏：12 个候选模板 → 修正后 9 个入库（3 个错误被 Assessor 评分过滤）
新指令 "put the butter in the basket and close the drawer"：
  MANGO 式分解：Place(Butter,Basket) ∧ Close(Drawer)——查库命中，参数实例化
  单智能体直接生成：从零写 4 个检查函数，2 个含参数错位
重复 500 次试验（每次错误率固定 + 库修正概率 0.3）：
  MANGO 式 executability  ≈ 0.83 ± 0.04
  单智能体 executability  ≈ 0.43 ± 0.05
  → 差距完全来自"复用放大了修正机会"，与模型聪明程度无关

注意边界：这是机制教学，不是论文复现——论文的 executability 0.800/0.933 vs 单智能体基线的真实数值见 tab:RQ1（单智能体约 0.04/0.53——比我的玩具还惨，因为真实 Module III 要处理更复杂的参数实例化）。论文真正的消融（RQ3）证明的是三个模块各自的必要性，我的玩具只演示"库复用"这一项的机制直觉。

复现材料：论文未提供公开复现包链接（正文与致谢均无 artifact 声明）；仿真器是 LIBERO（开源）与 RoboCasa（开源），FM 是 Gemini Robotics-ER 与 Cosmos Reason 2（API 商用），第三方复现的主要障碍在 API 成本与 prompt 未公开。

Private Investigator

You are a detective who needs to run a background check on one of the paper’s authors. Where have they worked? What did they study? What previous projects might have led to working on this one? What motivated them to work on this project? Feel free to contact the authors, but remember to be courteous, polite, and on-topic.

🕵️ 调查员：来源与身份核查

身份核验：arXiv:2606.24815 = MANGO: Automated Multi-Agent Test Oracle Generation for Vision-Language-Action Models，作者 Pablo Valle、Shaukat Ali、Aitor Arrieta、Lionel Briand，与本页 TeX 源码（论文主文件的标题与作者块、致谢的资助编号）完全一致；本批次 9 篇的 arXiv API 批量身份映射于 2026-10-20 完成。资助共 8 项（巴斯克政府 4 项、西班牙 MCIU 1 项、挪威研究理事会 1 项、欧盟 Horizon Europe 1 项、Research Ireland/NSERC/Canada Research Chair），致谢节完整列出，无利益冲突声明缺失问题。

两个需要标注的内部不一致：① 基座模型版本——experimental_setup.tex 写 "Gemini Robotics ER 1.6"，appendix.tex 的 FM-selection 写 "Gemini Robotics-ER 1.5 achieved the strongest…selected"；同一篇论文两个版本号，页面按"1.5/1.6 两处并存、原文不一致"处理，不替作者仲裁。② 340 vs 336——Cochran 公式算出 340，但 LIBERO_10 Task 4 只有 6 条合格执行，实际样本 336，论文两处口径都有，容易误读为矛盾。

发表状态：IEEE 期刊模板 + \revision 批注 + 无录用声明 → 按"修订中的期刊投稿"呈现；不排除后续被 TSE/TOSEM 接收，页面在参考文献节保留 arXiv v3 为引用锚点。与前作关系：valle2025evaluating（arXiv:2504.04343，VLA 不确定性评估）是同一团队前作，MANGO 的引用列表里出现，但两篇是不同问题（评估 vs oracle 生成）。与 Q-DEG、Q-DIG 的引用关系：无（不同社区）。

Social Impact Assessor

Identify how this paper self-assesses its (likely positive) impact on the world. Have any additional positive social impacts left out? What are possible negative social impacts that were overlooked or omitted?

🌍 影响评估：基础设施层的安全与公平

评测基础设施的偏置会向上放大：MANGO 这类自动 oracle 生成若被广泛采纳，"什么算任务成功"的定义权就从基准维护者转移到 (a) FM 的训练分布 和 (b) 仿真器 API 的表达面积。两者都不是中立表面——Gemini 系对"整理桌面"的理解可能与中文指令的意图错位，仿真器状态函数覆盖不到的动作（如"轻轻放下"的力控语义）会从评测里消失。论文没有讨论这个治理维度。

安全侧有一笔正资产：48 个"细粒度 oracle 正确、符号 oracle 漏检"的案例全部是流程性失败（先错后对、终态偶然达成）。在真机部署语境里，这类"结果对了过程错了"的执行正是安全事故的温床（撞倒东西但最终归位）。细粒度判定把过程合规纳入评测，方向值得肯定——只是当前证据规模（48/2814）还撑不起"安全改进"的强宣称。

成本公平性：自动 oracle 生成依赖商业 FM API，资源充足的大实验室先受益；开源复现包缺失（正文无 artifact 链接）加剧这个差距。学术共同体对评测基础设施的"公共品"属性通常靠开源维持，这篇的选择（不开源、API 依赖）与其"基础设施"定位之间存在张力。

Reference / Evidence

参考文献与证据边界

焦点论文

系列交叉阅读（本站）

关键引用（本页提及）

证据说明（本页如何做出来的）