三个实验。第一个证明零样本泛化:纯 Engineer 基线在 50 个 RoboTwin 任务上解出 9 个, 加上 Planner→Engineer→Reviewer 三角色与自进化技巧库后解出 — 个。 第二个是单任务的时序曲线——同一个任务反复尝试,勾会不会变密。 第三个是审计:成绩一度被报成 68%,因为仿真的成功判据顺着任务 wiki 流进了提示词。 页面上的每一个数字都是清理并重测之后的。
同一批 50 个 RoboTwin 任务,同一个仿真判据。左边是纯 Engineer 单角色基线, 右边是三角色管线加自进化技巧库。橙色格子是基线一次都没做成、而框架做成了的任务。
基线每个任务实际只跑了 1–3 次,且 181 次运行中有 86 次死于基础设施故障(其中 45 次是我后来才修掉的 600 秒硬超时);框架这边多数任务跑满 10–20 次。任务数不能直接并列,更可比的是每次运行的成功率: 9.5% → 29.2%。
另外「三角色」和「技巧库大小」这两个变量是刻意混在一起的——被测对象是整个系统,没有做消融。
每一行是一个任务,方块按时间从左到右排列——一次尝试一个方块,成功填绿,失败留空。 技巧库在两次尝试之间持续积累。若自进化起作用,绿块应越往右越密——先说结论:并没有。 橙框标出该任务第一次成功的位置。
只取跑够 10 次的 — 个任务,每个位置都由同一批任务贡献, 避免「后期只剩难任务」造成的假性下滑。曲线是平的。
任务一旦被攻克,后续维持在四成多,高于全局平均——但不再继续上升。 是一次性的水平跃迁,不是持续爬升。
预期是:一个任务连败多次后成功,说明学到了东西,之后应该继续成功。数据里没有这个模式—— 翻盘最深的几个,翻盘之后大多回到 0。我去查了原因,发现问题出在我自己的实验设计。
跑批是 8 张卡并行的,分片按 pair 序号取模,而 pair 列表按任务排列—— 于是一个任务的 10 个 seed 被分到 8 张卡上同时开跑。核对时间戳:
相邻尝试:并行重叠 477 对 · 严格先后 70 对 —— 87% 是并行的
stack_bowls_three:seed0 04:36→05:25,而 seed9 在 04:49 就开跑了
也就是说:「第 7 次尝试」从来没见过「第 6 次尝试」学到的东西。 它们几乎同时在跑——Reviewer 的提案还没写完、Manager 还没审批、技巧库还没更新,下一次就已经开始了。 横坐标上的「尝试次数」只是按完成时间排的记账顺序,不是因果顺序。
所以这条曲线画不出上升,不能推出「自进化无效」——只能推出这个实验没有给它留出生效的通道。 要测,必须串行:同一任务的第 N+1 次尝试,得等第 N 次的提案审完、技巧库更新之后再启动。 并行只能跨任务,不能跨同一任务的连续尝试。串行实验尚未进行。
每段视频都是仿真判据认可的成功回合——失败回合的录像会被自动丢弃,不会留下。 右侧是同一回合的完整工具调用序列。
没有人手写这些改动。每一条都由 Reviewer 从一次运行的 trace 里诊断出来、自己写成补丁, 经 Manager 闸门与 harness 测试,通过后落成 git 提交,下一次运行的 Engineer 就用上了新版本。 本次共 — 条落地、— 条被驳回。
回合结束后,Reviewer 读 trace 和图像,判定根因。它是盲的——没有判据、没有物体位姿,只有一个成败布尔值。
若判定为能力缺口或工具缺陷,Reviewer 直接写出补丁——精确到 old_string / new_string,或整份 policy.py。
Manager 审。有 harness 覆盖的必须跑测试且 PASS;没有覆盖的由 Manager 自己判断并声明。驳回率超过一半。
通过则写入仓库并生成 git 提交。技能目录随之更新,Planner 下一轮组装计划时看到的就是新描述。
下面四块来自同一次运行,未经改写。
注意它是从自己的测量得出结论的——三个方块的 x 坐标、y 方向离散度、 夹爪开合状态,全部来自感知工具的返回,不是判据告诉它的。
驳回比通过更能说明闸门在工作:124 条被拒 vs 103 条落地。 Reviewer 会过度自信,「机械上确定」这种措辞本身就是需要警惕的信号。
压倒性地集中在抓取原语——这与失败分析一致: 93 条是对现有技能打补丁,10 条是整份重写。系统在反复修的,正是它最常失败的地方。
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 轮自进化后复检仍然干净。