三个实验。第一个证明零样本泛化:纯 Engineer 基线在 50 个 RoboTwin 任务上解出 9 个, 加上 Planner→Engineer→Reviewer 三角色与自进化技巧库后解出 36 个。 第二个是单任务的时序曲线——同一个任务反复尝试,勾会不会变密。 第三个是审计:成绩一度被报成 68%,因为仿真的成功判据顺着任务 wiki 流进了提示词。 页面上的每一个数字都是清理并重测之后的。
同一批 50 个 RoboTwin 任务,同一个仿真判据。左边是纯 Engineer 单角色基线, 右边是三角色管线加自进化技巧库。橙色格子是基线一次都没做成、而框架做成了的任务。
基线每个任务实际只跑了 1–3 次,且 181 次运行中有 86 次死于基础设施故障(其中 45 次是我后来才修掉的 600 秒硬超时);框架这边多数任务跑满 10–20 次。任务数不能直接并列,更可比的是每次运行的成功率: 9.5% → 18.1%。
另外「三角色」和「技巧库大小」这两个变量是刻意混在一起的——被测对象是整个系统,没有做消融。
每一行是一个任务,方块按时间从左到右排列——一次尝试一个方块,成功填绿,失败留空。 技巧库在两次尝试之间持续积累。若自进化起作用,绿块应越往右越密——先说结论:并没有。 橙框标出该任务第一次成功的位置。
前半段 → 后半段的成功率。这一组的判据从未泄漏过,时间线上没有被我的清理干预过。
这一组反而下降——因为它们前期的成功是靠读判据得来的,我在时间线中途把判据拿掉了。 这个下降是我的干预,不是系统退化。
最该成立的预期是:一个任务连败很多次后突然成功,说明它学到了东西,之后应该继续成功。 我按这个口径查了每个任务首次成功之后的表现, 结果恰恰相反——翻盘最深的几个,翻盘之后全是 0:
place_empty_cup 前 11 次全败 → 之后 0/7
handover_block 前 12 次全败 → 之后 0/6
adjust_bottle 前 8 次全败 → 之后 0/9
open_microwave 前 7 次全败 → 之后 0/2
stack_bowls_two 前 5 次全败 → 之后 0/3
其中从未被污染的三个(place_empty_cup、open_microwave、stack_bowls_two)
翻盘后合计 0/12。这是干净数据。
败十来次、蒙中一次、继续败——这是运气,不是习得。
反过来,首次成功之后稳定的那些(click_bell 4/4、press_stapler 4/4、
click_alarmclock 3/3)全都是第一次就成的简单任务,压根不存在「学会」这个过程。
还要说明一点:「首次成功之前 0%」是定义决定的(首次成功之前当然全败), 所以那个数字不能当证据用。
结论:自进化在本次数据里没有得到证明。 技巧库确实在长(103 条落地),单任务也确实出现过翻盘,但翻盘不持久, 且同一时间窗内还修了三个 bug。要证明它,需要一次消融——同样的任务和种子, 一组挂技巧库、一组不挂。这个消融还没跑。
每段视频都是仿真判据认可的成功回合——失败回合的录像会被自动丢弃,不会留下。 右侧是同一回合的完整工具调用序列。
2026-07-03 有一次专门提交,把三个角色改成只能看相机:删掉 13 个读仿真状态的工具, 把读判据源码的函数改成返回空串。它封住了代码路径,但没有清理已经沉淀的记忆—— 而任务 wiki 是 Planner 的最高信任输入。判据就这样以原文形式回到了提示里。
place_phone_stand 的 wiki:手机功能点须落在支架座点的
eps [0.045, 0.04, 0.04] 之内、
且双爪都张开 —— 与仿真源码逐字一致。
shake_bottle 的 wiki:「已核判据:只要求
bottle_z > 0.8 ——
不需要任何 shake／摆动」。
这句话没有任何可疑符号,指纹扫描抓不到,却把整个任务定义交了出去。
每一条泄漏都自带免责声明:「仅用于诊断」「不喂位姿」「此为感知核验非真值」。 写的人不是恶意,是真的认为自己那条是安全例外。 所以最后的处理不是逐句删改,而是按作者整条隔离——污点在进程上,不在字符串上。
含判据的 wiki 条目移出到 Manager 私有库,在所有 agent 可读路径之外。
曾判为解出且 wiki 被改动过的全部重跑;13 个照样解出,3 个跑满 20 次全败。
接在 wiki 进 Planner 的唯一咽喉上,投毒测试通过;103 轮自进化后复检仍然干净。