Roadmap: 优化必选的 Manager-Based runtime collector 吞吐并完成 #1042 性能验收

[TATP-233]

当前状态（2026-08-24，以下清单为当前权威状态）

• Evidence / baseline：Benchmark: 测量 go2_joystick_flat / g1_walk_flat / g1_motion_tracking 的 collector 吞吐 #1253、排查：MBA reset / event manager 路径开销定位（reset_done 慢 5-6 倍） #1255、排查：MBA observation / update_state 路径开销定位（2.2-2.4 倍） #1256、排查：mujoco physics_ms 在 MBA 分支系统性偏高（+23-43%）归因 #1257、Benchmark: 固化必选 MBA runtime 的可复核 A/B 基线与性能门槛 #1260 已完成并关闭。
• Reset：perf: 限定 MotionCommand partial-reset 的全量重计算范围 #1261 / PR perf: scope MotionCommand partial-reset recompute to reset rows #1265；R2：perf: ObservationManager partial-reset 稀疏重建 (#1259 R2) #1269 / PR perf: scope partial-reset observation rebuild to reset rows #1270，均已合入并关闭。
• Update：U1 perf: MBA update_state backend state/getter 单相位复用 (#1259 U1) #1272 / PR perf: reuse MBA backend state reads within update phase #1274；U2 perf: 优化 ObservationManager 正常 step 固定管线（#1259 U2） #1279 / PR perf: scan observation finiteness once per term #1280，均已合入并关闭。
• MuJoCo/action：feat(mujoco_uni): BatchEnvPool 单次 dispatch per-substep control callback 能力 (#1259 M1a) #1266、perf: MuJoCo backend 接入单次 dispatch per-substep control (#1259 M1b) #1267 / PR perf: single-dispatch MuJoCo per-substep control via control_callback (#1259 M1b) #1275、perf: state-independent MBA action 跳过 per-substep callback (#1259) #1276 / PR perf: skip substep callbacks for invariant actions #1277 已完成。
• U3 perf: 优化 RewardManager term 累加管线（#1259 U3） #1278 已完成 no-go 评估，因收益不足按 stop condition 关闭，不存在待合入实现。
• chore: 移除 #1259 优化期 MBA profiling 脚手架 #1281：移除 排查：MBA reset / event manager 路径开销定位（reset_done 慢 5-6 倍） #1255/排查：MBA observation / update_state 路径开销定位（2.2-2.4 倍） #1256 引入的优化期 profiling 脚手架，固定 production-like final head。
• Benchmark: 完成必选 MBA runtime 的最终 7-case 性能验收 #1263：在 chore: 移除 #1259 优化期 MBA profiling 脚手架 #1281 后完成最终 7-case A/B、90% gate / Motrix 高漂移 / 例外决定及 dev → main 集成结论。

MotionCommand 正常 step、runtime-aware chunk tuner、tracking sensor 按需 materialization 当前均未激活，不是 final gate 的前置；仅当 #1263 数据未达已确认门槛且 maintainer 选择继续优化时，再各自拆分 issue。原始 roadmap 规划保留如下，历史状态以本节和 #1263 为准。

---

Parent: #1042

Evidence subtree: #1253（含 #1255、#1256、#1257）
Immediate execution children: #1260、#1261、#1262
Final acceptance: #1263

Owner summary

Manager-Based API（MBA）是 #1042 已确认的必选 production 模式，direct 只作历史 benchmark baseline。本 roadmap 把性能恢复拆成五条线：证据基线、partial reset、正常 update_state、MuJoCo backend、最终验收。第一波由 #1260、#1261、#1262 加现有 #1256 并行推进，分别归 benchmark、command/task、backend/upstream owner；后续 getter、observation、reward、MuJoCo adapter 只在前置数据满足启动条件后建 implementation issue。umbrella 本身零代码，预计 4 个已建 child 加最多 8 个条件 child；不改 MBA 语义、runner/IPC/learner，不新增 direct fallback 或长期性能 CI。所有代码 child 在最终提交本地通过 make test-all 后直接向绑定 dev 分支提 PR，不触发或等待远程 CI。需要 maintainer 决定最终门槛及是否承担上游 BatchEnvPool 能力的维护成本。

只优化必选 MBA production 路径内部的重复计算和 backend 固定成本；不把 direct 变成模式、fallback 或第二条 execution path。

不可变前提

1. 本 roadmap 范围内始终通过现有 MBA factory、ManagerBased env lifecycle、manager terms 与 SimBackend 运行。
2. community-compatible per-substep action、observation/reward term 顺序、reset/final observation、RNG、task I/O 和 sim2sim contract 必须保持。
3. main direct SHA 只用于回答“当前 MBA 相对历史 direct 的总差值”，不作为生产候选，也不要求局部 timing 与 direct 同口径。
4. 优化落在 owner layer；benchmark 脚本只组装测量，不承载 task/backend 规则。
5. 建议以 7 个 case 均达到同机 main direct 的 90% 为工作目标；是否成为最终 gate 由 Benchmark: 固化必选 MBA runtime 的可复核 A/B 基线与性能门槛 #1260 后的 maintainer 决定。

已有证据与 tracking 树

• Benchmark: 测量 go2_joystick_flat / g1_walk_flat / g1_motion_tracking 的 collector 吞吐 #1253（正式子树）：7-case branch-level collector A/B；其结果不是纯 manager abstraction overhead。
  • 排查：MBA reset / event manager 路径开销定位（reset_done 慢 5-6 倍） #1255：reset 归因完成；feat: instrument MBA reset path with fine-grained sub-step timing (#1255) #1258 已合入持久 timing。motion reset 的 command compute 占 66%–67%，observation rebuild 占 20%–25%。
  • 排查：MBA observation / update_state 路径开销定位（2.2-2.4 倍） #1256：update_state term/getter 归因已有本地结果，但 patch、原始数据和插桩 A/B 尚未固化，仍是第一波证据任务。
  • 排查：mujoco physics_ms 在 MBA 分支系统性偏高（+23-43%）归因 #1257：MuJoCo 多次 pool dispatch 归因完成；确定不是 physics 数学、worker、decimation 或 chunk_size 噪声。
• Benchmark: 固化必选 MBA runtime 的可复核 A/B 基线与性能门槛 #1260：固定最新 MBA/main baseline、重复运行离散度和 maintainer 性能门槛。
• perf: 限定 MotionCommand partial-reset 的全量重计算范围 #1261：只处理 MotionCommand partial-reset 的 full-batch 重算。
• Research: 单次 BatchEnvPool dispatch 保留 MBA per-substep control 的可行性 #1262：只判断单次 BatchEnvPool dispatch 保留 MBA per-substep control 的能力与成本。
• Benchmark: 完成必选 MBA runtime 的最终 7-case 性能验收 #1263：全部已激活优化完成后的最终 7-case 验收；当前明确 blocked。

执行依赖图

flowchart LR
    E55["#1255 reset 归因"] --> R1["#1261 MotionCommand partial-reset"]
    E56["#1256 update_state 证据收口"] --> U1["计划 U1: state/getter 单相位复用"]
    E57["#1257 MuJoCo dispatch 归因"] --> M0["#1262 upstream 能力决策"]
    E53["#1253 branch A/B"] --> B0["#1260 pinned baseline 与门槛"]

    R1 -. "obs rebuild 仍主导" .-> R2["计划 R2: partial-reset observation"]
    U1 -. "obs 固定管线仍主导" .-> U2["计划 U2: ObservationManager step 管线"]
    U1 -. "reward 固定管线仍主导" .-> U3["计划 U3: RewardManager 管线"]
    M0 -. "能力可行且获批准" .-> M1["计划 M1a/M1b: upstream + adapter"]
    M0 -. "多 dispatch 保留" .-> M2["计划 M2: runtime-aware chunk tuner"]

    B0 --> F["#1263 最终验收"]
    E56 --> F
    M0 --> F
    R1 --> F
    U1 -. "若激活" .-> F
    R2 -. "若激活" .-> F
    U2 -. "若激活" .-> F
    U3 -. "若激活" .-> F
    M1 -. "若激活" .-> F
    M2 -. "若激活" .-> F

Loading

实线是硬依赖；虚线是数据满足条件且 maintainer 单独确认后才建立的 child，不是本 umbrella 自动授权的实施项。

分波次并行执行

Wave 1：现在可并行的三条项目线

项目线	Issue	Owner / 主要落点	与其他线的关系
Evidence	#1260 + 现有 #1256	benchmark、临时 profiling；不保留业务代码	与另外两线无代码依赖；正式跑数共享同一机器，必须串行调度
Reset	#1261	command manager + task-owned MotionCommand	只依赖已完成 #1255；不等 #1256/#1262，可立即独立开发
MuJoCo	#1262	MuJoCo backend / mujoco_uni_runtime 调查	只依赖已完成 #1257；不改 manager，可与 reset/update 线并行

并行要求：#1260 先在任何实现合并前完成 clean baseline；#1261/#1262 的代码或调查可以同时进行，但不能与正式 benchmark 在同一机器上争用 CPU。每条线保留自己的 before/after，不用跨分支混合数字。

Wave 2：第一波结果出来后可再次并行

1. 计划 U1 — MBA update_state state/getter 单相位复用

   • 硬依赖：排查：MBA observation / update_state 路径开销定位（2.2-2.4 倍） #1256 可复核 patch/数据、Benchmark: 固化必选 MBA runtime 的可复核 A/B 基线与性能门槛 #1260 baseline。
   • 主要结果：同一 physics/update phase 的 backend state 只读取一次并安全复用；不同时融合 observation/reward term。
   • Owner：EntityData / manager env state-read boundary；预计 Standard，≤15 文件/800 行/1 PR。
   • Stop：无法明确 physics substep、set_state、partial reset 后的 cache invalidation，或需要新公共 lifecycle/SimBackend contract。

2. 计划 R2 — ObservationManager partial-reset 稀疏重建

   • 条件依赖：perf: 限定 MotionCommand partial-reset 的全量重计算范围 #1261 合并后，mba_reset_obs_build_ms 仍是主要剩余热点且预计收益值得维护成本。
   • 主要结果：只为 reset rows 重建 observation/history，不改变正常 step 管线。
   • Owner：ObservationManager + MBA reset 边界；与 U1、MuJoCo M1 可并行，但不能与 U2 同时实施。
   • 强制确认：现有 observation term 返回 full-batch array；若需 row-aware term/API，这是新的公共 manager lifecycle child，不能用本 roadmap 直接授权。

3. 计划 M1 — 单次 dispatch per-substep control

   • 硬依赖：Research: 单次 BatchEnvPool dispatch 保留 MBA per-substep control 的可行性 #1262 证明可行，maintainer 接受上游 API/版本成本。
   • 拆为两个顺序 child：M1a upstream runtime 能力 → 发布/固定版本 → M1b UniLab MuJoCo adapter 接入；两个仓库各自一个 issue/PR，禁止混成一单。
   • 与 U1/R2 完全解耦，可并行；如果需要新增 SimBackend 方法则停止并另做公共 contract 决策。

Wave 3：只按剩余瓶颈启动

1. 计划 U2 — ObservationManager 正常 step 固定管线优化

   • 依赖 U1；若 R2 被激活，还必须等 R2 合并，因为两者共享 observation_manager.py、noise/history/NaN 语义和测试。
   • 只优化 noise、concat、NaN check、copy/clip/scale 等 observation 管线；不同时改 reward。

2. 计划 U3 — RewardManager term 累加管线优化

   • 依赖 U1；仅当 排查：MBA observation / update_state 路径开销定位（2.2-2.4 倍） #1256 更新后的 reward block 仍达到已确认启动阈值时建立。
   • 与 U2 可并行，因为 owner/file 分离；共享 state snapshot contract 以 U1 为唯一前置。

3. 计划 M2/M3 — MuJoCo 次要项

   • M2 runtime-aware chunk tuner：仅当 M1 未实施或 residual microbenchmark 证明 tuner 仍有独立收益。
   • M3 tracking sensor 按需 materialization：仅当 single-dispatch 后 sensor 成本仍显著；不能与 M2/M1b 同时改同一 backend 分支。
   • tuner 与 sensor 是两个可独立回退的结果，必须分别建 issue/PR。

Wave 4：串行最终验收

#1263 硬依赖 #1260 和所有实际被激活的 implementation child。final SHA 固定后才能运行；验收中不修代码、不改配置、不新增 case。最终由 maintainer 决定 dev → main，而不是由最后一个性能 PR 自动宣称完成。

耦合与合并顺序

必须串行的语义/文件耦合

• perf: 限定 MotionCommand partial-reset 的全量重计算范围 #1261 与任何“MotionCommand 正常 step 优化”共享 command term 状态和文件：先 reset，再基于新 baseline 决定 step 优化。
• R2 与 U2 都修改 ObservationManager compute/history/noise 路径：先 partial-reset contract，再正常 step 管线，不能并行合并。
• U1 定义 state read/cache 失效边界，U2/U3 会消费它：必须先 U1，避免各 manager 私建缓存。
• M1a upstream runtime 必须先发布/固定版本，M1b adapter 才能开始；M1b、M2、M3 都碰 MuJoCo backend，按最终选择串行。

可以并行但最终需 rebase/组合验证

• perf: 限定 MotionCommand partial-reset 的全量重计算范围 #1261（command/task）、Research: 单次 BatchEnvPool dispatch 保留 MBA per-substep control 的可行性 #1262（backend/upstream）、排查：MBA observation / update_state 路径开销定位（2.2-2.4 倍） #1256（profiling）owner 与主要文件不同，可并行。
• Wave 2 的 U1、R2、M1 分属 state boundary、observation reset、MuJoCo backend，可并行开发；若都触及 manager_based_rl_env.py，后合并者只做机械 rebase，不把两个主要结果塞进一个 PR。
• Wave 3 的 U2 与 U3 可并行；最终在组合 head 上重新跑 parity 与 Benchmark: 固化必选 MBA runtime 的可复核 A/B 基线与性能门槛 #1260 口径 benchmark。

共享测量资源耦合

• 同一硬件上的正式 benchmark 不能并发；否则 CPU 利用率、pool worker 和 chunk tuner 结果互相污染。
• benchmark harness/固定字段只由 Benchmark: 固化必选 MBA runtime 的可复核 A/B 基线与性能门槛 #1260 或单独 instrumentation issue 修改；implementation child 复用入口，不各自扩展脚本。
• 每个 PR 同时报告局部 timing 与 collector throughput；最终总收益只由 Benchmark: 完成必选 MBA runtime 的最终 7-case 性能验收 #1263 汇总，避免重复归因。

Child issue scope 摘要

已创建、当前可执行或已明确阻塞

• Benchmark: 固化必选 MBA runtime 的可复核 A/B 基线与性能门槛 #1260 — pinned baseline 与性能门槛：零代码；是所有最终数字的共同起点。
• perf: 限定 MotionCommand partial-reset 的全量重计算范围 #1261 — MotionCommand partial-reset：一个 command/task owner 结果；可与其他第一波项目并行。
• Research: 单次 BatchEnvPool dispatch 保留 MBA per-substep control 的可行性 #1262 — MuJoCo single-dispatch capability：纯能力决策；不自动授权 upstream/adapter 实现。
• Benchmark: 完成必选 MBA runtime 的最终 7-case 性能验收 #1263 — final acceptance：零代码、blocked；只在所有激活 child 完成后运行。
• 排查：MBA observation / update_state 路径开销定位（2.2-2.4 倍） #1256 — update_state evidence closeout：保留原 issue scope，不把优化实现塞回 profiling issue。

条件 child（达到启动条件时再创建）

• U1 state/getter 单相位复用。
• R2 partial-reset observation 稀疏重建。
• M1a upstream runtime + M1b UniLab adapter。
• U2 ObservationManager 正常 step 管线。
• U3 RewardManager 管线。
• M2 chunk tuner、M3 tracking sensor materialization。

这些边界已经划分，但不提前创建空 implementation issue：#1256/#1261/#1262 的结果会决定实际 API、收益和 owner；届时每项按一个主要结果、≤15 文件、≤800 行、1 PR 建 issue。

Non-goals

• 不保留、新增或恢复 direct production runtime、fallback、MBA/direct switch 或平行 env path。
• 不改 collector、runner、IPC、replay、learner、checkpoint 或训练同步协议。
• 不改变 action/observation 维度、obs_groups_spec、reward 权重、termination、reset/final observation、RNG 或 sim2sim contract。
• 不通过 task YAML、control decimation、num_envs、backend identity 或删 case 美化 A/B。
• 不新增常规 CI、长期 dashboard、自动性能 claim 或专属 evidence system。
• 不把 dispatch、chunk tuner、sensor、getter cache、observation、reward 合成一个“大优化 PR”。

规模与永久维护成本

• Roadmap/测量 issue 零 production code；已创建 4 个直接 child，预计最多再激活 8 个条件 implementation child。
• 每个 implementation child 默认 Small/Standard：≤15 文件、≤800 行净手写改动、1 个 PR；达到任一上限立即暂停。
• owner-layer 去重维护 focused parity/performance tests。
• U1 若引入 cache，永久责任是 substep/reset/set_state 的失效规则与测试；R2 若引入 row-aware observation，永久责任是新的 manager lifecycle contract；两者都需单独确认。
• M1 若引入 upstream 能力，永久责任是依赖版本、API compatibility、adapter failure 和两种调用模式测试。
• 不新增长期 benchmark 服务；Benchmark: 固化必选 MBA runtime 的可复核 A/B 基线与性能门槛 #1260/Benchmark: 完成必选 MBA runtime 的最终 7-case 性能验收 #1263 原始结果作为一次性 issue 证据。

开发分支与 PR Gate（#1259 child 的显式例外）

• 绑定集成分支为 dev/issue-1042-manager-based-api。每个 implementation child 从最新 dev 建独立分支，一个 child、一个分支、一个 PR；PR base 必须是该 dev 分支，禁止直接提交实现到 dev。
• 开发中只跑必要的 focused checks；准备 PR 时，在最终提交上运行并通过一次本地 make test-all，随后确认 git status --short --branch 工作树干净。
• 本地 make test-all 未通过且 maintainer 没有明确 override 时，不得创建或更新 PR。
• 本地 gate 通过后直接创建 PR，PR body 必须记录最终 commit、make test-all 结果、适用 benchmark 以及 MuJoCo/Motrix 行为影响。
• Roadmap: 优化必选的 Manager-Based runtime collector 吞吐并完成 #1042 性能验收 #1259 的 child PR 不触发、不要求也不等待远程 CI/Docs；remote status 不属于本 roadmap 的 child merge gate。若仓库自动化意外产生远程 run，也不能用它替代本地 make test-all。
• Benchmark: 固化必选 MBA runtime 的可复核 A/B 基线与性能门槛 #1260、Benchmark: 完成必选 MBA runtime 的最终 7-case 性能验收 #1263 等纯测量 issue 默认零代码、零 PR；若发现必须修改 benchmark/production 代码，按其 Stop conditions 暂停并另开 implementation issue，不能借测量 issue 绕过 gate。
• child PR 的 review、squash merge 与 dev 分支同步继续遵循 Roadmap: 将 UniLab 迁移为社区通用的 Manager-Based API #1042；完成一个 child 不自动授权下一个。
• 此本地-only 例外只覆盖 Roadmap: 优化必选的 Manager-Based runtime collector 吞吐并完成 #1042 性能验收 #1259 下、base 为绑定 dev 分支的 child PR；独立 dev → main 集成 PR 不由本条豁免，仍按 Roadmap: 将 UniLab 迁移为社区通用的 Manager-Based API #1042 和届时仓库完整 gate 执行。

Umbrella acceptance criteria

• GitHub tracking 树、每个 child 的硬依赖/条件依赖/并行关系与实际状态一致。
• 本 roadmap 覆盖的生产任务始终走 MBA factory/lifecycle，无 direct fallback、旁路或模式开关。
• 每个优化只有一个 owner 结果，并在同硬件、同配置、固定 before/after SHA 上给出局部 timing 与 collector 收益。
• 数值、RNG、reset/final observation、term 顺序、backend isolation 和 sim2sim contract 保持。
• Benchmark: 完成必选 MBA runtime 的最终 7-case 性能验收 #1263 完成 7 case × 2 branch × ≥3 runs；未达到 maintainer 门槛的 case 有明确接受或阻塞决定。
• 所有 Roadmap: 优化必选的 Manager-Based runtime collector 吞吐并完成 #1042 性能验收 #1259 child 代码 PR 在最终提交本地通过 make test-all 后直接投向绑定 dev，不运行或等待远程 CI；最终 dev → main 仍按仓库完整 PR gate。

Stop conditions

• 任何方案需要绕过 manager、恢复 direct env、增加 MBA/direct 配置或改变 community-compatible MBA 语义。
• 需要新增公共 contract、env/manager lifecycle、SimBackend 方法、runner/IPC 路径或常规 CI，而 child 未单独获批。
• 一个 backend 的需求向 task、manager、runner 或 learner 扩散。
• child 达到 15 文件、800 行、一个 PR 上限，或出现第二个可独立交付结果。
• 重复运行波动无法区分收益，或收益不足以覆盖 cache/upstream/API 的永久维护成本。
• 并行分支发生语义耦合，无法通过机械 rebase 与组合验证隔离；此时停止并改为串行。

授权边界

批准本 roadmap 和创建 sub-issue 只授权规划与 tracking。开始开发仍只授权 maintainer 明确确认的当前第一个 Small/Standard implementation issue；完成后不自动进入下一个。#1260/#1256 的测量和 #1262 的调查也不能被解释为已批准 M1/U1/R2 等 production 改动。

[TATP-233]

进展报告：Wave 1 Evidence 项目线已完成

交付物

• 排查：MBA observation / update_state 路径开销定位（2.2-2.4 倍） #1256（update_state evidence closeout）— 已收口

  • 插桩 patch 固化：PR feat: instrument MBA update_state with block, term, and getter timing (#1256) #1264（feat/issue-1256-update-state-timing → dev/issue-1042-manager-based-api），13 文件 +436 行。此前"本地未提交"的插桩按原设计重建：EntityData 叶子 getter 计时、Obs/Reward 逐 term + getter 归属、obs 管线相位（noise/clip_scale/nan_check/delay/history/concat）、update_state 七块分解 + getter 归属，块级闭合有测试锁定。
  • Validation：make test-all 全绿（ruff、mypy 243 files、pyright、pytest 2191 passed、benchmark smoke）。ci.yml 只监听 main 目标的 PR，集成分支 PR 无远程 CI，本地 gate 已满足。
  • 插桩 A/B 复测（7 case × 3 runs）与定位结论已发 排查：MBA observation / update_state 路径开销定位（2.2-2.4 倍） #1256 评论；结论与前次一致：重复 getter 占 update_state 5–23%（mujoco dof 为 view、motrix 每次拷贝），obs 固定管线 noise+concat+nan_check 占 obs_compute 29–70%，motion command 块占 47–51%。
  • U1 启动条件（排查：MBA observation / update_state 路径开销定位（2.2-2.4 倍） #1256 可复核 patch/数据）已满足；另一条件 Benchmark: 固化必选 MBA runtime 的可复核 A/B 基线与性能门槛 #1260 baseline 见下。

• Benchmark: 固化必选 MBA runtime 的可复核 A/B 基线与性能门槛 #1260（pinned baseline 与门槛）— 测量完成，待 maintainer 门槛决策

  • 7 case × 2 branch × 3 runs = 42 次运行全部成功，原始 JSON/CSV、完整环境、median/离散度已发 Benchmark: 固化必选 MBA runtime 的可复核 A/B 基线与性能门槛 #1260 评论。
  • Pinned SHA：main direct 60c2ce7c / MBA dev 2a3bcea7；本机 Ryzen 9 9950X3D / RTX 4090（与 Benchmark: 测量 go2_joystick_flat / g1_walk_flat / g1_motion_tracking 的 collector 吞吐 #1253 的 Xeon/RTX 6000 Ada 非同机，绝对值不可跨机比较，已注明）。
  • MBA/main 吞吐 median 0.454–0.809，7 个 case 全部未达 90% 工作目标。
  • branch-level 口径修正已记录：差值可分解为 MuJoCo per-substep dispatch（排查：mujoco physics_ms 在 MBA 分支系统性偏高（+23-43%）归因 #1257）+ update_state manager 开销（排查：MBA observation / update_state 路径开销定位（2.2-2.4 倍） #1256）+ reset_done（排查：MBA reset / event manager 路径开销定位（reset_done 慢 5-6 倍） #1255）三块，不是纯 manager abstraction overhead。
  • 新发现：sac/g1_motion_tracking/motrix 存在批次级漂移（baseline 批 38.1–44.5k steps/s，同代码插桩批 52.0–52.8k，+30%），超过多数单项优化预期收益；已在评论中建议门槛用 median-of-N 并单独标注该 case。
  • 待 maintainer 决定：① 90% 是否成为最终 gate；② motion/motrix 高漂移 case 处置（更多 runs / 例外）；③ 例外清单。

对 Wave 2 的影响

• U1（state/getter 单相位复用）：两个硬依赖（排查：MBA observation / update_state 路径开销定位（2.2-2.4 倍） #1256 可复核 patch/数据、Benchmark: 固化必选 MBA runtime 的可复核 A/B 基线与性能门槛 #1260 baseline）均已满足，可按授权边界单独确认后建 issue。
• R2 / M1 / U2 / U3 / M2：仍按依赖图等待 perf: 限定 MotionCommand partial-reset 的全量重计算范围 #1261、Research: 单次 BatchEnvPool dispatch 保留 MBA per-substep control 的可行性 #1262 及 U1 结果。
• 后续优化 PR 的 before/after 测量可直接复用本机两个 pinned worktree（dev 2a3bcea7、main 60c2ce7c，均已完成 make sync 与冒烟）。

原始数据位置

运行机本地（gitignored）：scripts/benchmark/outputs/offpolicy_collector_active/

• issue1260_{dev,main}_run{1,2,3}.{json,csv}（42 次 baseline 运行）
• issue1256_results_run{1,2,3}.{json,csv}（插桩 A/B）

[TATP-233]

进展：#1261 已完成（PR #1265），并通过第三方机器复测

PR #1265（perf: scope MotionCommand partial-reset recompute to reset rows，fixes #1261）已提交，将 MBA partial reset 路径上 MotionCommand 的全 batch 重算限定到 reset 行。

第三方机器复测（RTX 4090，commit 6c8ab882，baseline 2a3bcea7）

1. 新增专项测试 tests/envs/test_motion_command_partial_reset.py：flip / box 2 个用例全部通过。
2. make test-all：2190 passed, 28 skipped, 1 xfailed，与 PR 报告一致；benchmark smoke 通过。
3. 基准 A/B（sac/g1_motion_tracking，8192 envs，同机同配置前后对比）：

Backend	mba_reset_command_compute_ms baseline → PR	变化
MuJoCo	14.68 → 3.39 ms	-77%
Motrix	24.66 → 6.32 ms	-74%

相对降幅与 PR 报告（-73% / -80%）一致，均远超 ≥50% 目标。一点出入：PR 报告的 Motrix collector 吞吐提升（32.5k → 45.1k env/s）在复测机上未复现（46.6k → 44.6k，噪声范围内），因该机 baseline 吞吐本身较高；核心计时指标的优化效果确认有效。

详细复测过程见 PR #1265 评论区：#1265 (comment)