ZIWU 文档

问题：终局分数掩盖了失败的位置#

今天的具身智能基准通常只回答一个问题：这一条 episode 成功了吗。于是一次评测被压缩成一个布尔值和一段录屏。这个数字可以横向比较模型，却无法回答任何一个工程问题——策略是在抓取阶段失手，还是抓到了却对不准；是对准了插不进去，还是插进去以后把容器打翻；是真的不会，还是被步数上限截断。

更麻烦的是，同一个数字可能来自完全不同的原因。在 fill_pen_holder 任务上，我们记录到三条原生 fail 的轨迹，失败机理彼此毫无关系：一条 3/4 支入筒、第 4 支横卡在筒口（深度谓词满足、TIP_DOWN 为假）；一条 2/4 后在开爪瞬间把笔筒打翻（is_axis_up 翻假）后反复扑救；一条从头到尾没有把笔筒稳住，在同一处开合夹爪十几次直到超时。把它们并成一个 success=false，等于把三份可操作的诊断信息扔掉。

做法：把轨迹还原成任务图上的因果路径#

ZIWU 的核心对象不是视频，而是逐步因果轨迹（causal step trajectory）：每一步记录观测、动作、预测的下一状态、实际的下一状态、奖励与终止位。在这个结构之上，平台再做三件事：

1. 规范任务图：把任务写成一张与策略无关的状态图（抓取 → 对准 → 插入 → 计分闸门 → 最终验收，以及回退、重抓、超时等分支）。同一张图对所有策略、所有 seed 保持不变。
2. 轨迹投影：把一条真实执行投影到这张图上，得到一条会生长的彩色路径——推进、尝试、回退、停滞循环、超时终局各有颜色。失败因此有了位置，而不只有布尔值。
3. 证据绑定：路径上的每个锚点都绑定回原始证据——三路同步视频的具体帧、逐步谓词的翻转步号、RunBundle 里的原生 _result.json。任何一个结论都能一路点回它的来源。

这就是站点上 任务图数字孪生 页面在做的事：一张规范任务图、七条已录制的 GPU 仿真 Episode trajectory，以及一条可选的 LIVE 仿真轨迹。

云原生：评测是一次可复现的作业，不是一台机器上的手工操作#

「云原生」在这里有具体含义，不是形容词：

• GPU 后端可替换：同一次评测请求可以落到 RunPod（RTX 4090）或 Modal（L40S）；平台、策略模型、步数上限是三个相互正交的旋钮，由触发服务的 catalog_v2 在运行时下发，页面不硬编码。
• 产物是可移植的 RunBundle：一次运行的全部证据（run-manifest.json、原始快照 raw/、逐步轨迹 anchor_steps.jsonl、规范化的 anchor-trace-v1、报告）打成一个自包含目录，可以在任何一台没有 Isaac Sim 的机器上重新分析。
• 失败也要产出可诊断的 bundle：执行、trace、分析任一阶段失败，仍然要 finalize 出一个能被诊断的 bundle，而不是留下一地临时文件。
• 实时可观测：运行中的作业通过 SSE 推送流水线阶段、policy tick、双臂末端轨迹点、监督 Agent 注释、头部相机帧与物理穿模侧写，浏览器端边跑边看。

谁会用它#

从这里开始#

• 想先跑起来 → 快速开始
• 想搞清 RunBundle、锚点、计分闸门这些词 → 核心概念
• 想知道页面上那张图到底做了什么 → 任务图数字孪生 · 产品说明
• 想参与开发 → 参与贡献