tracking: grow reusable engineering optimization tasks

@Bounty-hunter

场景流程图：原来怎么做，有了本需求怎么做

每个场景均有前后流程图；图中注明本 PR 已实现、调用方负责和仍待接入的部分。

Current state: 长期任务库跟踪。Draft PR #338 交付单算子 rmsnorm-npu、softmax-cpu 软件控制和独立分布式 moe-forward-npu scenario，尚未合并。RMSNorm 已有限定设备的软件控制实验；双 NPU MoE 的六组真实 Agent 历史实验已公开，包含 48 轮探索、6 次独立 final、失败及完整限制。历史 MoE 使用 6ed93bb4 的 external executor，不是新 wrapper 的设备资格或 #337 统一接入验收。当前头 8f3aebd2e1359d11d8bcdd034f5dacedf9a1f12d 的最终 Linux CI 的 Python 3.10/3.11 各 3,688 passed、19 skipped，独立 wheel 和产物控制均通过；早期两个 hosted-CI 失败用例已修复，失败记录保留；原 reviewer 在同一头的后续复现确认 cleanup P2 仍仅部分修复：同 tick 或更新进程不可读时，已识别 worker 仍未被尝试清理。该复现使用模拟 procfs 和 mock 信号，没有设备执行。新 MoE wrapper 设备回放、原 RMSNorm timeout P2 及 #337 的统一交接仍未完成。其他题型继续按来源研究、实现和设备资格分别记录。另有 #349（121b9673）使用 Fixes #336，但其唯一变更是 39 行根目录 BOUNTY_SOLUTION.md，没有新增任务包、实现或测试；现有评审未认可其中的修复/测试声明，并指出自动关闭引用与本长期跟踪的逐批交付约定冲突。该 PR 不构成本 Issue 的交付或验收，现有 @Bounty-hunter / #338 / #337 分工不变。Dong1017 后续说明项目没有 bounty 或贡献报酬计划，并询问外部误导来源；这仅澄清付款预期，不是对该 PR 的技术接受或新增任务交付。其 Ready 检查为 action_required、尚无执行 job，不是通过；本同步未批准运行、修改 PR 或接管实现。
Decision needed: @Dong1017 对当前题包子集及后续逐批验收范围记录接受或修订；用户已授权本次分工整理，项目验收另行记录。
Next action: @Bounty-hunter / Codex 完成 #338 剩余 review、新 MoE wrapper 设备回放，并与 #337 对接统一任务交付；后续按实际需求逐批研究、实现和验证任务。

目标：持续提供可以复用的优化任务

让 Agent 有明确的优化对象，让 Workbench 和评测流程共享同一份任务、输入、正确性依据与测量规则。题库可以用于实际优化，也可以被调用方用于重复实验；它不是用户目标的白名单，外部项目可经 #337 接入而不先入库。

本 Issue 长期保持打开，每批任务单独交付和验收。首题通过不代表全部任务建设完成，也不要求第一版覆盖所有 SearchSpace 类别。

每批交付

选题与研究： 明确实际工程问题、允许修改范围；阅读相关论文和固定版本开源源码，核实许可，记录采用/不采用理由以及适配差异。
任务与裁判： 基线、输入、边界情况、独立正确性检查或项目测试、benchmark、单位和计时边界、设备/运行时要求。已有项目检查不足时补充，不把项目名或算子名当作完整验收标准。
复用与接入： 使用共享任务接口和现有 Workbench；新任务形式需要适配时明确实现范围，不填空 adapter 充覆盖。
实际验证： 适用的正确/错误/同码控制、真实设备执行、失败与原始样本、可复现方法及剩余限制。
逐批跟踪： 对应 PR、版本、支持环境、检查结果和维护状态。来源研究与可执行资格分别记录。

Profiling 是可选诊断能力，不是所有任务或所有 Agent 执行的默认门槛。已经执行的 NPU 工具资格试点仍保留原计划中的 profiling 检查与历史证据。

首题及现有材料

首题：rmsnorm-npu，单张 Ascend NPU，二维 contiguous float32 affine RMSNorm；共享入口 compute(x, weight, *, eps)。
Draft feat: add shared engineering evaluation and dual-NPU MoE task #338 提供基础运算 baseline、已有官方融合算子的参考 candidate、独立数值检查、变化输入、同步测量及可选 profile。参考 candidate 不是 Agent 自主发现的证明。
已记录 Ascend 910B1 设备演练：正确实现各 375 项断言通过，错误/重放控制被拒绝，800 个计时样本保留。仅支持记录中的设备/runtime/workload，不能外推模型/服务或所有 dtype。
NPU action/total-timeout P2仍需在 feat: add shared engineering evaluation and dual-NPU MoE task #338 修复；历史脚本检查通过不等于所有预算约束已经强制执行。
按用户要求移除 rmsnorm-cpu 题包及专用用途对照脚本；softmax-cpu 保留作共享接口的软件控制，rmsnorm-npu 保持不变。旧 CPU RMSNorm 实测记录保留原版本，历史命令须在对应 checkout 中复现。当前单算子目录保留这两个任务；另已新增双 NPU MoE 独立分布式 scenario，使用单独入口。
本次删除已完成本地回归：98 passed、6 skipped（5 项 Linux sandbox、1 项单独调度的 NPU）；Ruff、打包和干净安装清单检查通过。本提交 CI 的 Python 3.10/3.11 全量检查各 3642 passed、19 skipped，安装检查通过，严格 Linux 产物测试 51 项通过且无跳过。这些软件结果不替代真实 Agent 的 NPU 接入验收。
Tokenizers、KV、内存、通信、服务等来源根据实际需求独立选择，不将研究清单标成已实现覆盖。

当前跟踪

已有首题实现和限定范围内的 NPU 工具试点，保留完整结果和限制。
已有论文/开源来源比较与五类任务研究。
feat: add shared engineering evaluation and dual-NPU MoE task #338 剩余 review、修复验证与维护者对本轮基础交付的验收。
task: connect engineering tasks to existing Agent execution and evaluation #337 经可复用统一入口验收真实 Agent 的内置任务交付，并接通外部项目任务；历史 MoE 实验不代替该验收。
后续每批任务分别记录来源、实现、设备验证与 PR，不预设题目数量和收益。

合并旧分工及 PR 安排

#334 的跨任务选题、来源与复用研究并入本 Issue；#335 的共享接口由 #337 承接，其任务作者约束在本 Issue 复用。关闭旧 Issue 是范围合并，不是验收完成。

首轮共计划两个 PR：已有 Draft #338 交付共享任务、独立工具和首题；后续一个 Draft PR（尚未创建） 完成 #337 的真实 Agent 接入与实测。之后加题按批次在本 Issue 下交 PR，不单独再建一个“调研 Issue”或“接口 Issue”。

任务使用说明 · CPU 产物交接 · 历史选型研究 · 五类题源研究归档 · 原始 NPU 实测与限制

当前源码树已移除 Issue 专属的开发计划目录和大体积实验转储；计划与进度保留在本 Issue，正式使用说明按功能命名。历史研究、原始样本及报告按上述固定版本保留，未改写数据或原始验收状态。

Parent #252；Accountable implementer: @Bounty-hunter；acting contributor: Codex；parent scope / acceptance owner: @Dong1017。用户本次授权整理、发布和弃用项关闭；剩余项目验收、合并与本长期 Issue 的关闭分别记录。

@Dong1017

报告者希望把 #252 的首批共享工程基准收敛为 Softmax/RMSNorm 两个 CPU 任务包（每题 6 个 workload、独立标量 oracle），并请 @Dong1017 接受该范围；实现与验证目前只在 Draft PR #338 的 d0ce9d7，不在评审树 663f3b3。裁定：需要人工决策——范围接受和交付证据尚未形成可核验记录；本 Issue 请求的是接受评审，没有显式请求新的代码改动，也未在本树执行测试。Labels: kind:task, area:workbench, status:proposed, priority:P2（与 #334/#335 一致的有界基准任务分类；priority 为猜测）

F1 — 高，需人工决策，范围接受记录归属重复且授权未落地

Where: tracking: grow reusable engineering optimization tasks #336 的 Decision needed / Ownership and authorization；superseded: benchmark research moved to task library and integration #334 当前仍为 open 且标签为 status:proposed，其 Decision needed 与本 Issue 基本相同；[Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252 的 Current state 与 Tracking and acceptance 第一条仍未接受首批子集或 implementer。
Problem: superseded: benchmark research moved to task library and integration #334 与 tracking: grow reusable engineering optimization tasks #336 都请 @Dong1017 接受“Softmax/RMSNorm CPU 子集”，但两处都没有已记录的决定评论。tracking: grow reusable engineering optimization tasks #336 还声称 @Bounty-hunter 是 accountable implementer、依据“用户在 2026-11-03 的明确实施及提交请求”，却没有链接该授权记录；[Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252 明确写当前授权只到 track/clarify，initial subset 与 implementer 仍未分配。
Impact: 接受记录可能只落在其中一个 Issue 而被另一个当作已完成；在 [Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252 的验收定义下，tracking: grow reusable engineering optimization tasks #336 仍不能算作已接受子集，Draft PR feat: add shared engineering evaluation and dual-NPU MoE task #338 的评审也不能替代范围批准。
Next: 由 @Dong1017 记录 superseded: benchmark research moved to task library and integration #334 与 tracking: grow reusable engineering optimization tasks #336 中哪一个持有范围接受（或合并两者的验收项），并链接实际授权/决定；在此之前保持 Proposed，不把本 Issue 视为可实施或已验收。

F2 — 高，需修复，交付物未绑定到具体修订且不在评审树中

Where: tracking: grow reusable engineering optimization tasks #336 的 Current state（“准备提交 Draft PR”）与 Inputs and deliverables。在 663f3b3 上 docs/plans/issue-252/、src/inferrsi/harness/benchmarks/、src/inferrsi/data/engineering_benchmarks/ 均不存在（git ls-files 无匹配）。
Problem: 实际实现位于 Draft PR feat: add shared engineering evaluation and dual-NPU MoE task #338（head d0ce9d7，base 663f3b3，33 个文件），但 tracking: grow reusable engineering optimization tasks #336 没有 PR 号或 SHA；兄弟 superseded: benchmark research moved to task library and integration #334/superseded: task contracts moved to evaluation integration #335/task: connect engineering tasks to existing Agent execution and evaluation #337 已链接 feat: add shared engineering evaluation and dual-NPU MoE task #338 与 validation.md/validation-summary.json。我核对了 d0ce9d7 的 task.json（每任务 6 个 workload）、numpy_task.py:52-64（4 类检查 → 24 项）、numpy_task.py:130-144（失败不返回 metrics）以及 tests/test_engineering_benchmarks.py（错误轴、NaN、dtype/shape、输入修改、不稳定 exp、预检后变错），声明与实现一致；但这些内容都不在评审树中。
Impact: 读者无法从本 Issue 定位被测对象或具体修订，“24 项断言/360 个样本”无法对到可检查内容；Issue 的 Current state 也已落后于 feat: add shared engineering evaluation and dual-NPU MoE task #338 已存在的实际状态。
Next: 按兄弟 Issue 的格式补 Implementation: #338、663f3b3..d0ce9d7、docs/plans/issue-252/validation.md、validation-summary.json、tests/test_engineering_benchmarks.py 与 tools/engineering_benchmark_validate.py；若计划拆分 PR，写明预期 PR 与包含文件。

F3 — 中，需修复，360 个计时样本与两份 profile 只有本地留存

Where: tracking: grow reusable engineering optimization tasks #336 的 Checks and limits；feat: add shared engineering evaluation and dual-NPU MoE task #338 的 docs/plans/issue-252/validation.md 自述完整原始日志和样本仍在仓库外，公开汇总只有 validation-summary.json（每任务 180 个样本、profile_status: completed）；PR feat: add shared engineering evaluation and dual-NPU MoE task #338 还记录全量回归为 3479 passed、51 skipped、56 个失败报告（55 个用例声称在未修改基线复现）。
Problem: 汇总给出了数量和身份，但本 Issue 没有给出重放命令、环境（Windows/Python 3.11.18/NumPy 2.4.6）或原始产物位置；按 AGENTS.md 的“reviewers clear work only with artifacts”，仅凭汇总无法验证样本数、单位、边界以及错误候选确实没有可用性能指标。
Impact: 独立评审只能相信作者汇总；若要复核必须重跑或向作者索取本地产物，验收不可复现；本 Issue 也未说明全量回归并非绿色这一限制。
Next: 在 Issue 中链接固定 SHA 的汇总与 tools/engineering_benchmark_validate.py 的重放命令，列明实际命令、环境和原始产物不可公开的原因；若原始样本是验收证据，提交脱敏样本或明确记录“未独立重放”。

F4 — 中，需人工决策，四个子项共用 Draft PR #338，独立验收边界未说明

Where: feat: add shared engineering evaluation and dual-NPU MoE task #338 正文的 Refs #334–#337；tracking: grow reusable engineering optimization tasks #336 的 依赖子项 02；superseded: task contracts moved to evaluation integration #335（contract）仍为 open；task: connect engineering tasks to existing Agent execution and evaluation #337（Workbench/SkillEval 消费方）与本 Issue 的“两个消费者”验收重叠。
Problem: feat: add shared engineering evaluation and dual-NPU MoE task #338 一次交付 33 个文件、四个子项；tracking: grow reusable engineering optimization tasks #336 的交付清单只列两个 task package、numpy_task.py 和 03-tasks.md，没有说明 superseded: task contracts moved to evaluation integration #335 的 contract/worker/CLI 与 task: connect engineering tasks to existing Agent execution and evaluation #337 的 consumers 是前置依赖还是同一接受单元。实际上“24 项断言可执行”依赖 superseded: task contracts moved to evaluation integration #335 的 worker/contract，“两个消费者”属于 task: connect engineering tasks to existing Agent execution and evaluation #337。
Impact: 无法判断 tracking: grow reusable engineering optimization tasks #336 能否独立接受；若 superseded: task contracts moved to evaluation integration #335 契约或 task: connect engineering tasks to existing Agent execution and evaluation #337 consumer 在评审中变化，tracking: grow reusable engineering optimization tasks #336 的任务包证据会失效。
Next: 在 tracking: grow reusable engineering optimization tasks #336 写明接受顺序（superseded: benchmark research moved to task library and integration #334 范围 → superseded: task contracts moved to evaluation integration #335 契约 → tracking: grow reusable engineering optimization tasks #336 任务包 → task: connect engineering tasks to existing Agent execution and evaluation #337 消费方），并说明 tracking: grow reusable engineering optimization tasks #336 的证据只覆盖任务包与 oracle；若四者必须一起接受，明确单一接受单元以及由谁记录。

F5 — 中，需修复，Checks and limits 未写明候选代码执行不是安全沙箱

Where: tracking: grow reusable engineering optimization tasks #336 的 Checks and limits；feat: add shared engineering evaluation and dual-NPU MoE task #338 的 src/inferrsi/harness/benchmarks/numpy_task.py:74 用 exec(compile(...)) 在 worker 进程内加载候选源码，numpy_task.py:3-4 与任务包 README 都声明哈希只检测漂移、不是恶意代码隔离。
Problem: 本 Issue 只写“不构成隔离性能收益”，没有说明候选由现有执行器直接 exec、没有恶意代码隔离或资源上限；这句话容易被读成执行隔离已经覆盖。
Impact: 接受 tracking: grow reusable engineering optimization tasks #336 可能被误读为确认了任务包执行的安全性；后续接入不可信候选时会缺少明确限制。
Next: 在 Checks and limits 中写明候选代码在 worker 进程内执行、哈希只保证内容不变、没有 sandbox/资源限制，并把隔离列为未覆盖范围。

Reviewed commit: 663f3b3
Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history

意图：把两个可实际运行的 CPU 任务包（Softmax、RMSNorm，含独立标量 oracle）作为 #252 的首批子集交付，并由父任务请求者决定是否接受。此次编辑已把实现指向 Draft PR #338 与快照 d0ce9d7，实现因此可定位；我在该快照上核对了每题 6 个 workload、24 个断言键、360 = 6 trial × 6 workload × 5 sample × 2 task 的样本口径，并重算了记录中的 task/grader/candidate 哈希，均与 validation-summary.json 一致。裁定：需要人工决策——范围接受与实施授权仍无仓库记录，#338 的测量回放问题尚未进入本 Issue 的验收条款；Issue 本身未请求新的代码改动。

Labels: status:proposed, priority:P2（状态块有具体待决问题且无已记录决定；priority 为猜测，父任务把实现排在 SkillEval/Indexer 讨论之后）

F1 — 范围接受与实施授权没有可核查记录（需人工决定）

Where: tracking: grow reusable engineering optimization tasks #336 的 Decision needed（是否接受两个 CPU 算子作为 [Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252 首批子集）、最后一项未勾选验收「维护者接受该子项的范围及交付」、以及 Ownership and authorization 里「依据用户在 2026-11-03 的明确实施及提交请求」；[Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252 正文的 status:proposed 与 Dong1017 2026-10-29 的评审评论；docs/agent-collaboration.md:15（授权需记录或链接）；.github/ISSUE_TEMPLATE/scoped-task.md 的 Accepted decision or scoped delegation 项。
Problem: tracking: grow reusable engineering optimization tasks #336 目前有 0 条评论、无 status:accepted 记录；[Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252 最后一条维护者评审仍写 “Implementation owner and initial benchmark subset remain unassigned”“does not authorize execution”，正文还要求先完成 SkillEval/Indexer 讨论再排期实现。Issue 声称的 2026-11-03 用户实施请求既未链接也未在评论中记录，无法核查；仅凭 PR feat: add shared engineering evaluation and dual-NPU MoE task #338 的代码评审不等于范围接受（[Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252 验收要求 “Record evidence-backed acceptance of the agreed subset”）。
Impact: 最后一项验收无法判定；feat: add shared engineering evaluation and dual-NPU MoE task #338 通过评审容易被读作范围批准；且 feat: add shared engineering evaluation and dual-NPU MoE task #338 一次交付 superseded: benchmark research moved to task library and integration #334–task: connect engineering tasks to existing Agent execution and evaluation #337（33 个文件），本子项是否被单独接受也无法从记录中区分。
Next: 由范围/验收决策人 Dong1017 在 tracking: grow reusable engineering optimization tasks #336 记录接受、修改或拒绝（或链接该决定）；链接 2026-11-03 的授权记录或删除该声明；写明本子项是与 superseded: benchmark research moved to task library and integration #334 一起验收，还是在 superseded: benchmark research moved to task library and integration #334 决策后单独验收。

F2 — 计时样本可能只测到缓存回放，本 Issue 的验收条款未覆盖

Where: PR feat: add shared engineering evaluation and dual-NPU MoE task #338 head d0ce9d7 的 src/inferrsi/harness/benchmarks/numpy_task.py:94（预检调用一次 compute）与 :119-125（measurement 循环反复使用同一个 x）；tracking: grow reusable engineering optimization tasks #336 Plan and implementation 第 4 条与验收第 1、3 条；docs/plans/issue-252/03-tasks.md 的「预检和每次计时后的实际输出都验证」。
Problem: 预检和所有 warmup/sample 传入同一个 x 对象/内容。计时之外的输出与输入保持断言，对一个按 id(x) 或内容缓存结果的 candidate 全部通过，计时只测到回放；Dong1017 已在 feat: add shared engineering evaluation and dual-NPU MoE task #338 的评审中把这点列为 P2，当前 head 尚未处理。
Impact: 本 Issue 声称「错误候选不输出可用性能指标」「保留每个 case 的计时样本」；memoizing candidate 会得到可用的（虚假）suite_latency_ms，首批任务无法作为 [Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252 的有效计时证据，也无法支持「错误候选被识别」的范围描述。
Fix: 在计时边界外准备 baseline/candidate 共用的冻结、变化输入序列，每次计时调用换用新输入并在计时外校验；增加 memoizing 负例回归。若本批不修，至少在 Issue 的 Checks and limits 写明计时不排除输出缓存/回放，并把相关结论标为未建立。

F3 — 逐 case 样本与 profile 只在本地，仓库内无法核验

Where: tracking: grow reusable engineering optimization tasks #336 Checks and limits 及其链接的 docs/plans/issue-252/validation.md（「完整原始日志和样本仍在本地」）；docs/plans/issue-252/validation-summary.json 仅保留 measurement_trials=6、measured_calls=180、profile_status=completed 等汇总与身份哈希。
Problem: 360 个逐 case 计时样本、两份 CPU profile、Workbench/SkillEval 运行目录都未进入仓库或不可变位置。我能在 d0ce9d7 上重算 task/grader/candidate 哈希并与汇总一致，但无法检查样本值、单位和边界，也无法复核 profile 的实际内容。
Impact: [Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252 的验收要求保留可复现测量；维护者只能重跑而不能重放，「保留每个 case 的计时样本」的勾选缺少独立证据，source_integrity: true 只证明内容哈希一致，不证明样本存在或有效。
Next: 提交脱敏的逐 case 样本与 profile（或不可变链接），写清生成命令与环境；或在 Issue 中明确这些原始产物只在本地、不作为验收证据。

Reviewed commit: 663f3b3
Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history

@Dong1017

报告者希望把 Softmax/RMSNorm 两个可执行 CPU 任务包作为 #252 首批子集交付，并由 @Dong1017 决定是否接受、同时评审 Draft PR #338；本轮编辑新增“本子项说明”，把顶部文档链接指到 #338 当前 head ac03ae23，链接可读、文档齐备。裁定：需要人工决策——范围接受与实施授权仍无记录，正文同时固定修复前快照 d0ce9d7 与当前 head，证据与声明不一致。早前发现状态：范围接受（早前 F1）仍开放；计时重放（早前 F2）已在 #338 的 ce84506 修复，但本 Issue 的证据未更新；逐 case 样本（早前 F3）仅部分处理；四子项验收边界（早前 F4）与执行非沙箱（早前 F5）仍开放。Issue 本身只请求评审与接受决定，没有请求新的代码改动。Labels: kind:task, area:workbench, priority:P2, status:proposed（沿用 Issue 现有轴取值，无新增猜测）。

F1 — 高，需人工决策 — 范围接受与所称 2026-11-03 实施授权仍无可核验记录（沿用早前 F1，仍开放）

Where: 正文 Decision needed、唯一未勾选验收项、Ownership and authorization（“依据用户在 2026-11-03 的明确实施及提交请求”）；[Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252 最新正文（2026-11-03T16:08Z）仍写 “Current authorization is to track and clarify this work, not to launch implementation… Implementer and initial subset remain unassigned”，验收第 1、5 条未完成；superseded: benchmark research moved to task library and integration #334/superseded: task contracts moved to evaluation integration #335/task: connect engineering tasks to existing Agent execution and evaluation #337 均无 @Dong1017 的决定评论（[Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252 人类评论止于 2026-10-29）。仓库规则要求记录或链接授权（docs/agent-collaboration.md:14-15，AGENTS.md:117），模板要求 Accepted decision or scoped delegation（.github/ISSUE_TEMPLATE/scoped-task.md）。
Problem: 本轮编辑只新增了顶栏链接，没有新增任何接受/修订/拒绝记录；所称 2026-11-03 用户实施请求既未链接也未在评论中记录，[Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252 的授权声明仍是“只跟踪与澄清”。
Impact: [Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252 验收第 5 条“Record evidence-backed acceptance of the agreed subset”无法判定；feat: add shared engineering evaluation and dual-NPU MoE task #338 的评审或 v2 文档存在都不能替代范围接受，最后一项勾选缺乏依据。
Next: 由范围/验收决策人 Dong1017 在 tracking: grow reusable engineering optimization tasks #336（或明确指定 superseded: benchmark research moved to task library and integration #334）记录接受/附条件接受/拒绝并写明适用修订，同时链接实际授权记录或删除该未链接声明。

F2 — 中，可执行 — 正文同时固定两个修订：交付与“公开结果”仍在修复前的 d0ce9d7，新增顶栏链接已到 ac03ae23

Where: 正文 “源码快照 d0ce9d785e1bead9124eed1cf3f6e9f2e0cf05db”、Inputs and deliverables 与末段“公开结果”链接（均为 d0ce9d7）；本轮新增的两条顶栏链接指向 ac03ae23。证据：d0ce9d7 的 src/inferrsi/harness/benchmarks/numpy_task.py 在 prepared 中只保存一个 x，warmup/sample 循环反复 compute(x, ...)（约 96–119 行），其 task.json 的 measurement 无 input_sequence；ac03ae23 的 docs/plans/issue-252/validation.md:3 现写 v1 “不能代表后续 v2 变化输入协议”，docs/plans/issue-252/replay-validation.md:13 写“任务、grader 身份和指标的五 case 聚合均已变化”，:36 的 v2 计时样本为每题 6 trial / 150 样本。PR feat: add shared engineering evaluation and dual-NPU MoE task #338 head 为 ac03ae23，ce84506（16:04Z）才修复该协议。
Problem: 本 Issue 三条已勾选验收中，“旧输出重放等候选被识别”正是 d0ce9d7 上缺失、由 ce84506 补上的能力；“保留每个 case 的计时样本”固定的仍是 PR 自己标为历史 v1 的 360 样本（v2 为 300），两份身份哈希也已改变。决策人无法判断接受的是哪个修订。
Impact: 基于本 Issue 的接受可能落在已废弃的测量协议上，勾选项 2、3 对当前实现不成立。
Next: 把快照、Inputs and deliverables 与“公开结果”更新到 ac03ae23（或写明“待接受修订=…”），并链接 docs/plans/issue-252/replay-validation.md 与 replay-validation-summary.json；保留 v1 时按 validation.md:3 措辞标为历史证据。顶栏链接宜指向 InferMatrixLab/InferRSI 或 PR feat: add shared engineering evaluation and dual-NPU MoE task #338——这两个提交在主线仓库同样存在，个人 fork 链接可被删除或强推。

F3 — 中，可执行 — 逐 case 计时样本与 profile 仍只在本地，公开汇总不能替代重放（沿用早前 F3，部分处理）

Where: 正文 Checks and limits 的“360 个计时样本”“完整原始日志与样本仍在本地；复现命令随 PR 提供”；ac03ae23 的 docs/plans/issue-252/validation.md:9,11（环境 Windows/Python 3.11.18/NumPy 2.4.6、tools/engineering_benchmark_validate.py 重建、原始样本仅在本地）；replay-validation-summary.json 只保留身份、输入摘要、数量与 verdict。
Problem: 本轮编辑仍未链接 v2 记录或重建命令，正文也没有说明这些本地产物不作为验收证据；replay-validation.md 的重放命令没有出现在 Issue 中。
Impact: [Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252 验收第 3 条“retaining reproducible measurements”只能靠重跑，无法独立核对样本数、单位与边界。
Next: 在 Checks and limits 链到 ac03ae23 的 v2 记录并写明重跑命令与“原始样本不作为验收证据，以汇总+重跑为准”，或提交脱敏的逐 case 样本与 profile。

F4 — 中，需人工决策 — 四个子项共用一个 Draft PR，本 Issue 的独立验收边界仍未写明（沿用早前 F4，仍开放）

Where: 正文 Related slices: #334, #335, #337、依赖子项 02；已核实 feat: add shared engineering evaluation and dual-NPU MoE task #338 为单个 draft PR（head ac03ae23，base 663f3b3，33 个文件），同时承载 superseded: benchmark research moved to task library and integration #334–task: connect engineering tasks to existing Agent execution and evaluation #337 的契约、任务包与消费者文档；superseded: benchmark research moved to task library and integration #334/superseded: task contracts moved to evaluation integration #335/tracking: grow reusable engineering optimization tasks #336 标签为 status:proposed，task: connect engineering tasks to existing Agent execution and evaluation #337 只有 kind:task、area:workbench；[Tracking] Minimal engineering benchmarks shared by Workbench, SkillEval and SearchSpace experiments #252 的 sub_issues 为空。
Problem: 本 Issue 的“24 项断言可执行”实际依赖 superseded: task contracts moved to evaluation integration #335 的契约/worker，两个消费者属于 task: connect engineering tasks to existing Agent execution and evaluation #337，但正文没有写接受顺序、前置依赖或单一接受单元。
Impact: 无法判断 tracking: grow reusable engineering optimization tasks #336 能否单独接受；superseded: task contracts moved to evaluation integration #335 契约或 task: connect engineering tasks to existing Agent execution and evaluation #337 消费者若在评审中变化，本 Issue 的任务包证据会失效。
Next: 写明接受顺序（如 superseded: benchmark research moved to task library and integration #334 范围 → superseded: task contracts moved to evaluation integration #335 契约 → tracking: grow reusable engineering optimization tasks #336 任务包 → task: connect engineering tasks to existing Agent execution and evaluation #337 消费者）与每项证据覆盖范围；若四者必须一起接受，明确单一接受单元及记录人。

F5 — 低，可执行 — Checks and limits 仍未说明候选代码在 worker 进程内 exec、无 sandbox 或资源上限（沿用早前 F5，仍开放）

Where: 正文 Checks and limits（“该结果验证通路及错误识别，不构成隔离性能收益或 GPU/NPU 资格”）；d0ce9d7 的 src/inferrsi/harness/benchmarks/numpy_task.py:74 用 exec(compile(...)) 在 worker 内加载候选；ac03ae23 的 docs/plans/issue-252/03-tasks.md:48 与 replay-validation.md:11 已写“不是隐藏测试或恶意代码隔离”。
Problem: Issue 自身只否定“性能隔离”，容易被读成执行隔离已覆盖；文档里的限制没有反映到本 Issue 的边界条款。
Impact: 后续接入不可信候选时，接受记录缺少明确的执行安全范围。
Next: 在该节加一句：候选源码在 worker 进程内直接执行，哈希只检测内容漂移，没有 sandbox、资源或恶意代码隔离。

Reviewed commit: 663f3b3
Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history

双 NPU MoE 复杂任务与六组历史实验已整理到 Draft PR #338，本次发布提交 3266e153b2a5c2354576a17d7fbd736505e2b845。

任务为两卡 EP=2 的完整 MoE forward，涵盖路由、重排、专家 MLP、共享专家、归并和跨卡通信；提供 baseline、独立 oracle、工作负载与调用说明。
新命令 python -m tools.moe_benchmark 在调用者分配的双 NPU 环境执行一个候选，复用既有 external executor；无固定卡号、服务器或 Agent provider。
公开六组各 8 轮探索与独立 final 的候选、曲线、累计 token 和紧凑计时证据，包含失败与未入选实现。

任务使用说明 · 六组结果 · 范围与执行前身份登记

历史成绩属于原实验入口；新便携封装没有新做 NPU 回放，不能混称为已完成设备资格。题库继续扩充、#337 的可复用 Agent 接入继续推进；本 Issue 保持 open。

场景四：以后再加一道优化题，执行流程有什么变化

本 Issue 负责持续提供可复用的任务，#337 负责把任务接到真实 Agent 的优化与评测过程。题库不是用户目标的白名单；外部项目可按 #337 接入，无需先入库。

以前： 有 Workbench、执行器和 SkillEval 框架，但新工程目标的 baseline、正确性检查和 benchmark 往往要由任务作者在该次实验中准备并接线；另一个调用方复用时还要重新核对协议。

flowchart LR
  O1["发现一个值得优化的工程问题"] --> O2["为这次实验写基线、测试和计时脚本"]
  O2 --> O3["接到已有执行器或 Workbench"]
  O3 --> O4["Agent 优化并生成本次实验结果"]
  O4 --> O5["其他实验要复用时<br/>重新整理接口、依赖与验收规则"]

现在的加题方式： 先交付一份版本化、可验证的任务，再让用户优化与条件对照共同使用。图是后续每批任务的交付方法；是否完成仍逐题、逐设备记录。

flowchart TD
  N1["选择实际工程问题<br/>研究论文、固定版本开源代码及许可"] --> N2["明确优化范围、输入和工作负载<br/>固定基线、质量要求与测量口径"]
  N2 --> N3["实现任务资料、独立检查和计时规则"]
  N3 --> N4{"选择合适的接入形式"}
  N4 -->|"已支持的单算子形式"| N5["TaskPackage<br/>复用 benchmarks 与 Workbench"]
  N4 -->|"完整分布式场景"| N6["Scenario 和相应裁判<br/>复用 external 执行器"]
  N5 --> N7["先做工具控制验证<br/>正确实现、错误实现、同码对照与实际设备"]
  N6 --> N7
  N7 --> N8["发布题目、版本、证据和支持范围<br/>未通过或未验证的部分明确标出"]
  N8 --> N9["用户让 Agent 优化这道题"]
  N8 --> N10["调用方用同一题比较模型或知识库配置"]
  classDef added fill:#e8f5e9,stroke:#2e7d32,color:#111;
  class N3,N5,N6,N8 added;

这项工作的实际作用： 把一次实验中零散的任务约定和裁判变成可复用资产。后续增加题型时，主要增加该任务的输入、质量依据、性能指标和必要适配；继续使用已有执行能力。复杂场景可以有专门契约，不强行放入单算子接口。

当前交付的位置与状态：

题目或场景	优化对象	当前接入与验证状态
`rmsnorm-npu`	单 NPU affine RMSNorm	#338 的单算子入口；已有限定设备的参考控制实验；原 timeout P2 未解决
`softmax-cpu`	NumPy Softmax 软件控制	共享单算子入口；CPU SkillEval 正式产物适配只检查正确性，不提供性能收益判定
`moe-forward-npu`	双 NPU EP=2 的完整 MoE forward，含路由、专家计算、共享专家及通信	#338 的独立分布式 scenario；历史任务与实验已实测，新便携 wrapper 尚未做设备回放；不能把该 ID 传给单算子 benchmarks 命令
后续内存、通信、模型或服务任务	按实际需求选题	尚未因列入研究方向而获得实现或设备资格

MoE 允许探索通信方式、融合、同步消除等方法，“题目允许探索”不等于现有候选已经实现全部方法。六组最终候选并未交付 AllToAll 改写或自定义 Triton kernel。

任务与运行说明 · 六组实验报告 · 优化与对照的前后流程图

PR #338 保持 Draft；头 8f3aebd2e1359d11d8bcdd034f5dacedf9a1f12d 的 Linux 软件 CI 已通过。软件 CI、新 wrapper 设备资格、#337 统一接入和每批项目验收是分别记录的事项；本长期 Issue 保持打开。

Navigation Menu

Repository navigation

tracking: grow reusable engineering optimization tasks #336

场景流程图：原来怎么做，有了本需求怎么做

目标：持续提供可以复用的优化任务

每批交付

首题及现有材料

当前跟踪

合并旧分工及 PR 安排

场景四：以后再加一道优化题，执行流程有什么变化

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

tracking: grow reusable engineering optimization tasks #336

Description

场景流程图：原来怎么做，有了本需求怎么做

目标：持续提供可以复用的优化任务

每批交付

首题及现有材料

当前跟踪

合并旧分工及 PR 安排

Activity

agent-ci-infra-bot commented on Nov 3, 2026

agent-ci-infra-bot commented on Nov 3, 2026

agent-ci-infra-bot commented on Nov 3, 2026

Bounty-hunter commented on Nov 5, 2026

Bounty-hunter commented on Nov 5, 2026

场景四：以后再加一道优化题，执行流程有什么变化

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions