数字孪生“闭环后产量更高”这类结论，只有在能分离出“闭环”这一个变量时才值得看。noteflowai/robot-reel 仓库里的 Factory Twin Lab（本文依据提交 7a1f08f 的说明文档和方法与局限，证据等级 [O]，即项目自述）给了一个可以照着做的审查方式：每次运行都成对进行，一次让孪生的指令真正下发，一次只记录不下发，两次共享全部扰动和传感器噪声；12 对的逐对数值保存在 seeds.json，包括闭环反而少产出的 2 对。
配对隔离了什么
实验里的“工厂”（plant）是一个完全模拟的厂区：一条六工位产线、三台 AMR、车间温控和园区能源，以 1 s 步长从 10:00 模拟到 13:00。数字孪生从这个厂区接收遥测，推断状态，比较候选动作，再发回指令。每个种子跑两种模式：
- 闭环（closed）：指令在发出 5 s 后到达厂区。
- 影子（shadow）：同一个孪生照常运行、记录同类决策，但什么都不发送。
随机数来自一个按种子、数据流和序号取值的计数器式生成器（counter-based generator），所以一对中的两次运行看到完全相同的扰动和噪声样本。文档据此把两者之差定义为“在这个模型里闭合回路的效果”。这句话的范围很窄：它不是对真实工厂的估计，而是对这一个模型、这一组参数的对照。
本站《物理AI实验室 0.1》把物理 AI 描述为一遍遍转“看、想、动”的闭环；这里是同一个闭环放大到车间尺度，而影子模式正好提供了“只看、只想、不动”的对照组。
孪生看到什么，怎么决定
审查一个孪生的决策，先要确认它的信息边界。文档写明孪生从不直接读取厂区状态，只用遥测：
| 步骤 | 孪生做什么 |
|---|---|
| 感知 | 每 5 s 收到 PLC、CNC、电表、车间气候和 AMR 位姿五组数据包；每组有 2–3% 的丢包概率，全部晚到 5 s，数值带噪声和舍入 |
| 同步 | 用每组最后一个数据包镜像工位状态、缓冲区和 AMR 位姿，并记录每组数据的时效 |
| 估计 | 用扩展卡尔曼滤波，根据振动模型 v = 2.4 + 5.5 w² + noise 跟踪 CNC 2 主轴不可观测的磨损 w 与磨损速率；初值取名义参数（初始磨损 0.45、名义速率、阈值 1.0），与每个种子的隐藏真值都不同 |
| 预测 | 当保守（2σ）剩余寿命低于 150 个忙碌分钟时，每 5 分钟用自己的产线模型前向模拟 90 分钟，比较 14 个方案；每分钟预测当前和下一个计费时段 |
| 决策 | 安排维护、降低进给、调高车间设定温度、限制 EV 充电 |
14 个方案是“立即维护、10、20、30、45、60 分钟后维护、不维护”七种时机，各自分降速和不降速。每个方案的价值为：预期良品数，减去提前维护浪费的主轴寿命（每单位磨损折 40 件），方案失败时再减 25 件。只有“立即维护”最优时才发出维护请求；降速开关只在收益超过 1.5 件时切换；需量控制分四级（设定温度 +1 / +2 °C、EV 充电桩限 50%），带滞回，并以 27 °C 以下为舒适约束。
这些权重（40、25、1.5）是为演示选定的。审查时应把它们当作决策的一部分记录下来：换一组权重，同样的遥测可能得出不同的维护时机。
精选班次：收益和代价一起列
文档展示的精选班次是种子 10（10:00–13:00）：
| 影子（只给建议） | 闭环 | |
|---|---|---|
| 良品 | 182 | 202 |
| CNC 2 主轴故障 | 1（维修 45 分钟） | 0（一次 15 分钟计划维护） |
| 废品 | 10 | 2 |
| 15 分钟需量峰值 | 560.3 kW | 466.3 kW |
| 超过 520 kW 的计费时段 | 2 | 0 |
| 车间最高温度 | 24.2 °C | 24.8 °C |
最后一行是闭环的一项代价：闭环下车间最高温度高 0.6 °C。调高车间设定温度是孪生控制需量的手段之一，但文档没有拆分这 0.6 °C 的成因。闭环模式另外进行了 1 次 15 分钟的计划维护停机；这只是记录的一项代价，文档没有给出避免故障的完整成本。限制 EV 充电也是闭环控制的一项代价；Robot Reel 文档没有给出种子 10 的 EV 服务指标，工作台维护者针对导入的 v0.18.0 记录报告种子 10 的 EV 服务指标为 74%，不符合工作台的默认标准，但引用材料未证明这套记录与本文所引提交相同。一张只列收益的表会让读者看不到这些交换，审查时应要求两边都列。
12 对全看：包括输掉的两对
在 12 对种子上，文档报告：
- 主轴故障：闭环 0 次，影子 11 次。
- 超限计费时段：闭环 0 个，影子 8 个。
- 良品数：10 对上升，2 对下降；平均 +11.1，范围 −3 到 +20。
平均 +11.1 本身会掩盖那两对。提交 7a1f08f 的文档与 METHODS.md 说明，产出下降的种子 3 和 11 在影子模式下都发生了主轴故障，但发生得晚：45 分钟维修只有 13.6 和 14.5 分钟落在 3 小时窗口内。因此闭环模式的 15 分钟计划维护比晚发生的故障损失更多产出。这是这套演示参数和 3 小时窗口里的交换，不能推广为真实工厂的维护收益。
这与本站《EvalArc：分数变高了，智能体哪里退步了》讨论的问题相同：平均值上升不代表每一项都变好，需要逐项看。本站《Robot Reel》的介绍文章讲的是同一仓库里 SmolVLA 的配对压力实验，Factory Twin 是另一个实验，把配对方法用在了决策回路上。
复核：重放，而不是相信
每对结果都能重新执行。文档称模拟只涉及整数和 IEEE-754 运算，Python 标准库即可逐位（bit for bit）重跑；--verify 用记录的遥测重放孪生，要求估计值和决策完全一致，这也检验了“孪生只用遥测”这一点。
下面是上游文档写明的步骤，本站没有执行。以下两种方式都要求能够调用 robot-reel 命令；本文引用的资料没有列出安装及程序版本绑定步骤，因此这些命令不是完整的环境复现指南。第一种是离线实验：下载并解压项目站点的 experiment.zip 或 GitHub Release 中的 robot-reel-factory-twin-experiment.zip。METHODS.md 示例中的 --output 指向解压后的实验文件夹（示例里名为 factory-twin）；上游资料没有说明应在哪个目录下运行这些命令：
robot-reel factory-twin --output factory-twin --verify # 精选的一对
robot-reel factory-twin --output factory-twin --verify --all-seeds # 全部 12 对第二种是在仓库提交 7a1f08f 的检出目录中运行，按 docs/factory-twin.md 的 Reproduce 一节，输出目录为 docs/factory-twin：
robot-reel factory-twin --output docs/factory-twin --verify # 精选的一对
robot-reel factory-twin --output docs/factory-twin --verify --all-seeds # 全部 12 对PyPI 上未指定版本的 robot-reel 包、项目站点的 experiment.zip 和标记为 latest 的 GitHub Release 都没有固定到提交 7a1f08f，内容可能与本文引用的版本不同；第二种方式的检出目录固定了本文引用的源文件和记录数据，但没有固定实际调用的 robot-reel 可执行程序。
METHODS.md 称这两条命令只需要 Python 3.12 和标准库。
审查时可读的文件：seeds.json 存全部 12 对；trace-closed.json 和 trace-shadow.json 存精选种子的每个样本，包括厂区真值、原始遥测包、孪生快照、带证据和预测的决策日志，以及预测与厂区实际结果的对照。一次维护决策可以从日志里的证据一路追到它当时的预测，再与真值对比。
三维场景和飞行镜头用 Blender 制作，但 Blender 只按记录的样本回放关键帧，不做物理计算；robot-reel factory-twin --verify 只核对 Blender 检查回执的输入哈希，不会重跑 Blender。影片是展示，不是证据。
局限 / 注意
- 整个厂区是模拟的。厂区参数和孪生的代价权重都是为演示选定的，没有针对任何真实工厂校准。文档明确说这些数字只能说明回路按描述工作，不能当作节省的估计。
- 在这个模型里闭合回路有效，不代表在真实工厂里能省钱，也不代表这些指令可以安全地控制真实设备。
- 12 对里良品数有 2 对下降，结论不能简化为“闭环总能提高产量”。
- 本文没有重跑上述命令。上游自带的检查、以及能否下载到发布文件，都不等于独立复现；以上数字均为项目文档自述。
- PyPI 包、项目站点的
experiment.zip和 latest Release 这些下载渠道都没有固定到提交7a1f08f，可能与本文引用的文档不一致；提交7a1f08f的检出目录只固定了源文件和记录数据；实际调用的程序版本还需要另行确认。 - PAI Design Workbench 项目报告了托管工作台的只读评审验收：导入 Robot Reel v0.18.0 的固定记录，先冻结标准再逐种子比较。默认标准拒绝方案，因为种子 3、11 产出下降，种子 10 的 EV 服务指标为 74%，未通过默认标准。引用的工作台文档未定义这个指标的计算方式或给出其阈值，不能把 74% 当作充电电量的比例。该轮托管验收未重跑工厂仿真，也未验证真实设备控制；这是工作台维护者的验收记录，不是本文作者的独立复现。引用的验收记录也未证明 v0.18.0 的文件与本文所引提交
7a1f08f相同。
