Repository navigation
discussion: Knowledge / Workbench / Benchmark 三模块目标架构——现状、原语、交接时序与遗留问题 #362
Description
Current state: 设计讨论。本文整理 OmniRSI #6 四轮评审后收敛的目标架构，以便在本仓按模块拆分开发任务。方案正文以 #6 的三模块架构最终讨论稿 为准；本 issue 补充的是它的证据链、交接时序和遗留问题。
Decision needed: 三模块边界、四个公开接口的最小交接内容，以及第 7 节五个遗留问题的归属，由维护者决定。
Next action: 在评论里记录边界与接口的意见；实施切片另开 task。本 issue 不授权源码迁移、实验、付费调用或合并。
核查基线：main 01c73521，PR #338 固定在 8f3aebd2。本轮为静态源码、文档与调用关系检查，未运行测试、模型或设备实验。
1 仓上现状：问题不在模块怎么命名
把一次真实运行穿过的代码切出来看，会看到几条互不相通的执行通道，每条有自己的控制器、自己的外部端点，也各自强制着一条规则：
| 通道 | 控制器 | 它强制什么 | 外部端点 |
|---|---|---|---|
| KV 编辑 | model/anthropic_edit_agent.py |
receipt 按 revision 失效，同字节写回也失效（:293 递增、:515 抛 stale_or_missing_receipt） |
沙箱内合成 Python 文件 |
| 通用 runner | harness/runner.py |
源码快照三重相等（:101-107），改了又恢复仍判无效；终态提交失败写 termination_failed（:137,151） |
真实推理服务 / 引擎 |
| 预算 | tools/skill_eval_budget.py |
预留即计费，不退款 | 付费模型服务 + Git 账本 |
强制是通道局部的，而且没有任何结构保证一条新通道会继承已有的保证。 这是提出模块化的直接动因，而不是目录名不好看。
两个现成的证据：
一、同一个 PR 里已经长出两套平行实现。 #338 在 8f3aebd2 上有两个内容库（data/engineering_benchmarks/ 与 data/engineering_scenarios/），文件角色几乎相同，入口分成 inferrsi benchmarks <action> 与 python -m tools.moe_benchmark 两套，pyproject.toml 因此加了第二条 package-data 规则；身份冻结也分成两份——harness/scenarios/moe.py 自己写了 _hashes / _prepare / _adjudicate，不导入同一个 PR 早先加的 harness/benchmarks/contract.py。两者保护的对象确实不同，但分叉的理由没有写在未来适配器作者会读到的地方。
二、保障集合从导入关系上看不出来。 四个入口都复用叶子函数 harness/scenarios/external.py 的 execute_trial，而源码快照裁决在包装它的 run_experiment 里：
| 入口 | 执行路径 | 源码快照裁决 | 父进程侧身份复核 |
|---|---|---|---|
benchmarks compare |
runspec() → run_experiment |
有 | 有 |
benchmarks plan |
只返回规格，不执行 | 不适用 | 准备阶段绑定 |
benchmarks grade |
grade_artifact → run_action → execute_trial |
无 | 有：前后两次 task.identity() + assert_unchanged() + 结果内 identity 回显 |
check / measure / profile |
run_action → execute_trial |
无 | 无 |
| MoE | moe.evaluate → execute_trial |
无 | 有，自己的 _prepare / _adjudicate |
缺少 runner 快照不等于缺少该操作所需的保证——grade 直接比对身份，可能本就不需要。但这个差异必须是声明出来的，不能由「复用了哪个函数」推断。
三、本周合入的代码已经出现没有归属的部分。 harness/ 从 13 个文件涨到 23 个，#319 与 #341 新增约 2,737 行：dashboard_data.py 865、optimization_log.py 360、dashboard.py 296、campaign_records.py 248、optimization_trace.py 247、optimization_story.py 230、knowledge_capture.py 169、dashboard_timeline.py 163、dashboard_live.py 126、campaign_trace.py 33，加 dashboard 与 campaign 两组 CLI 子命令。按职责它跨「运行记录」和「结果解释」两边。
值得注意的是这一簇不是日志系统，口径恰好相反：optimization_trace.py 自述「The record is a caller assertion, not proof that an agent consumed its context. It is never populated from raw requests, logs, or the process environment」，dashboard_data.py 自述「log contents are deliberately omitted」，而 optimization_story.py 的职责是列出叙事与留存证据不一致的地方。它是声明加对账层，不是事件流。
2 新架构解决什么
| 现状问题 | 三模块如何处理 |
|---|---|
| 新通道默认不继承任何保证，且无人察觉 | 保障集合成为 ExecutionRecord 的显式字段，由 Benchmark 在判定时核对，而不是由调用链推断 |
| 任务冻结与执行代码同处一包，重构可能顺手改掉基准 | Benchmark 独立：它的职责是不变，工作台的职责是演进，两者对变更的要求相反 |
| 评价目的、执行方式、任务实例混为同级概念 | 系统对照／技能效果是评价目的，本地／云端是执行方式，KV／parser／算子是任务实例，三者不再并列 |
| 「运行成功」与「任务通过」混用 | Workbench 输出执行事实，Benchmark 输出判定；进程退出码为零不能直接变成 PASS |
| 知识读取被实验流程捆绑 | Knowledge 可独立使用，inferrsi knowledge search 已经是现成入口 |
3 三个模块与依赖规则
flowchart TB
USER["人 / Coding Agent"]:::external --> APP["应用入口与装配：CLI / Python / Plugin"]:::thin
subgraph K["Knowledge 知识库"]
direction TB
KR["知识检索与交付"]:::module --> KS["知识资产、版本与受控更新"]:::module
end
subgraph B["Benchmark 评测模块"]
direction TB
BT["任务、输入与参考实现"]:::module --> BG["正确性、测量与判分"]:::module
end
subgraph W["Workbench 实验工作台"]
direction TB
WP["运行计划与实验编排"]:::module --> WE["执行、资源与进程管理"]:::module
WE --> WR["运行记录与结果报告"]:::module
end
APP --> KR
APP --> BT
APP --> WP
WE <--> TARGET["外部运行环境：引擎、服务、项目代码与硬件"]:::external
classDef module fill:#DEEBFA,stroke:#B6C1CC,color:#23354B
classDef thin fill:#FFFFFF,stroke:#0E6C6C,color:#23354B
classDef external fill:#FFF0D6,stroke:#B6C1CC,color:#23354B
style K fill:#EDF4FC,stroke:#B6C1CC,color:#23354B
style W fill:#EDF4FC,stroke:#B6C1CC,color:#23354B
style B fill:#EDF4FC,stroke:#B6C1CC,color:#23354B
linkStyle default stroke:#788A9D
三个模块之间没有任何直线相连，这是本图最重要的一条。 独立性落在依赖方向上，不是只改目录名。四条规则：
- Knowledge 核心独立提供检索、版本读取和受控写入，不依赖 Workbench 或 Benchmark。
- Benchmark 核心定义任务与判分，不导入 KnowledgeReader、Agent 客户端或 Workbench 执行器。评测 Knowledge 本身时，被测检索接口由应用适配器注入。
- Workbench 核心执行已准备的计划，不自行检索知识，也不硬编码某个具体 Benchmark 的数学定义与评分公式。
- 应用层只经三个模块的公开接口组合流程，自身不承载业务判断。
main 上已经有一个符合规则 3 的自发实例：harness/knowledge_capture.py 不导入任何 inferrsi 模块，reader 作为参数注入（capture_context(root, *, context_id, reader, …)）。工作台到知识库的数据流存在，而导入依赖没有反向。
4 原语与公开接口
名称表示设计方向，具体类型在兼容现有契约后确定。四类接口可分别使用。
| # | 接口 | 输入 | 交付结果 |
|---|---|---|---|
| ① | Knowledge.read / collect → KnowledgeBundle |
知识范围、版本、资源需求 | 固定版本内容、来源、选择范围、可读取资源引用。读取不触发实验；更新另走受控接口 |
| ② | Benchmark.prepare → PreparedEvaluation |
任务与 grader 版本、操作、输入、候选格式、采样协议、资源要求 | 冻结的任务／输入／判据，指标单位与方向、计时与聚合规则、各项判定所需证据。候选未生成时明确标注未绑定 |
| ③ | Workbench.execute(ExecutionSpec) → ExecutionRecord |
明确的命令、工作目录、输入输出引用、资源上下文、时限与执行限制；候选引用及预期身份 | 实际输入绑定、运行与尝试身份、状态、退出码、耗时、清理结果、日志、原始产物、实际用量，以及本次实际完成了哪些完整性检查 |
| ④ | Benchmark.assess(prepared, outputs, execution_facts) → EvaluationResult |
冻结任务与协议、实际候选绑定、执行事实、原始产物 | 声明范围内的判定、指标有效性与原因、分数及证据引用。缺证据保留 INCONCLUSIVE；允许离线重算，不隐式启动新实验 |
③ 的最后一项是本提案相对前几版的实质新增。理由就是第 1 节那张入口表：保障集合各入口不同，而差异从导入关系上看不出来，所以必须由记录本身声明「实际完成过什么」。
三个跨模块原语：
- 冻结身份：从实际字节重算身份，与预先绑定的引用比对。各协议保护的对象不同（离线证据包字节、编辑会话内的写入顺序、执行身份与漂移），不预设必须归并；但每处都要说清保护对象、适用操作、身份字段、失效事件、强制检查位置、反例测试和保留消费者。
- 受控执行：owner、时限、预算、清理与释放证据。取消请求与实际退出分别记录。
- 范围化主张：这份证据支持什么命题、适用边界与资格。执行状态不等于判定。
5 交接时序
sequenceDiagram
actor U as 人 / Coding Agent
participant A as apps 应用层
participant K as Knowledge
participant B as Benchmark
participant W as Workbench
participant T as 外部运行环境
U->>A: 声明目标、任务与候选来源
A->>B: ② prepare(task, grader_version)
B-->>A: PreparedEvaluation（任务/输入/判据已冻结，候选未绑定）
opt 需要知识
A->>K: ① read(scope, version)
K-->>A: KnowledgeBundle（固定版本、来源、选择范围）
A-->>U: 交付知识包
end
Note over U: 提出假设、选择方法、编辑候选
U->>A: 提交候选引用
A->>W: ③ execute(ExecutionSpec, 候选引用, 预期身份)
W->>W: 绑定实际候选字节，记录 identity
W->>T: 下发命令
T-->>W: 原始产物与测量
W->>W: 进程清理、用量记账
W-->>A: ExecutionRecord（状态、产物、用量、已完成的完整性检查）
A->>B: ④ assess(prepared, outputs, execution_facts)
B->>B: 核对身份匹配与证据完整性
B-->>A: EvaluationResult（PASS / FAIL / INCONCLUSIVE + 适用范围）
A-->>U: 判定与证据引用
opt 知识晋升
U->>K: 受控更新（显式审阅，与判定分开）
end
三处顺序是有意的：
- ② 在候选存在之前。 任务、输入、判据先冻结，候选后绑定。改候选不会让任务和判据跟着悄悄变。
- ③ 里绑定身份，不在 ② 里。 每次检查或测量前重新捕获并核验实际候选身份，但不修改已冻结的任务与判据。
- ④ 读执行事实，不发起执行。 离线判分可独立进行；需要重验时显式创建新运行，旧记录与原结论保持可追溯。
失败路径同样分开记录：候选错误保留 FAIL，清理失败另记，基础设施失败不洗掉已发生的预算开销，取消请求不等于进程已退出。
6 一个现成的检验：性能上限分析
#303 的 Decision needed 是一个二选一——SOL 模型「extends performance-ceiling-analysis 作为第二个切片，还是成为新的 methods/ owner」。它正文自己点出了症状：
InferRSI already owns both halves of this and connects neither to a number.
optimization-search-policy 的停止规则只能定性引用 headroom，因为没有一个冻结的 distance-to-bound 可比。
在三模块下这个二选一会消解，因为答案是两个都不是：
| 部分 | 归属 |
|---|---|
| 三级上限模型、怎么算、用哪些常数 | Knowledge（读给 agent 看的方法） |
| 冻结的 bound 值、distance-to-bound 判据、跨 flow 的比较规则 | Benchmark（判据必须冻结，变了过去的比较就失效） |
| 实测 F / P / T / B 这些量 | Workbench（执行与测量） |
同理 #348 修的是 Knowledge 侧的条目内容，与冻结判据是两回事。建议把 #303 的范围决定按这三段拆开回答，而不是在原二选一里选。
7 遗留问题
-
本周新增的 dashboard / trace 簇归谁？ 约 2,737 行，职责表里没有「可视化与追溯」这一项。按内容它跨 Workbench 的运行记录与 Benchmark 的结果解释；而且它的证据强度是「调用方主张」而非「捕获的事实」，这一点要写进接口约定，否则会被当成 trace 日志使用。其中
campaign_trace.py是唯一真正 trace-like 的部分，正是 #333 候选 2 要的统一事件信封。 -
第一阶段承诺哪几条不变量？ 「承诺的规则全部需有拒绝路径与测试」比配额严谨，但现有文档把 40 条都写成无条件不变量，没有分阶段承诺清单。
-
谁判定预算 gate 是否必需？ 「必需则整体 INCONCLUSIVE，否则保留观察并降级主张」方向正确，但这个判定尚未分配给任何角色或对象字段。另有一处语义需要分开：「预留即计费、永不退款」对不可逆的外部支出是对的，当成通用预算规则就是错的——金额与 token 花了就是花了，而 wall time、设备时间、并发槽位在取消后确实会被释放。用一个
budget_ref统管五个维度，会逼着设备时间也按不退款算。 -
知识条目的生命周期状态怎么定？
repo_packs下 108 个条目全部status: imported，字段存在但只有一个取值。不建议为此新开 issue——#350 的验收项已经要求「区分已覆盖、待细化、缺失、过时和暂不纳入」并「整理重复、冲突和过时条目」，缺的是把这几个词落成status取值。触发条件应当事件驱动而非定时：知识按上游失效不按时间失效，钉在固定 revision 的条目在上游未变时不会过期。可用触发是「钉住的 revision 与当前上游不一致」与「持续不命中且确实进过候选集」（后者依赖 #344 补的候选集合记录）。#177 已有一套五级成熟度用在外部研究条目上，可直接借用。 -
依赖规则怎么机械检查？
tests/test_module_boundaries.py目前只对 infra / model / harness 的直接导入做 AST 规则检查，没有构建依赖图、没有计算传递闭包，也不覆盖动态导入与经由重新导出间接到达的路径。若要承诺传递依赖检查，需先补依赖图解析。静态导入规则、运行时调用与实验结果校验回答三个不同问题，哪一项都不能替代其余两项。
8 迁移约束（实施前必须知道）
- 目录迁移会让带前缀依赖的知识包装载失败，不只是版本号漂移。
knowledge_operations.py的依赖解析按路径前缀收集成员（path.startswith(dependency + "/")），成员集合变空或变化会直接抛ValueError: Missing dependency或RevisionConflict。所以优先保留逻辑路径与兼容入口；确需迁移时同步重算并更新dependencies里的 pinned revision。 repo_packs/*/pack.json有双重用途。catalog.repository_pack()读它，而infra/inspection.py把结果放进环境检查输出的repository_pack字段。运行目标描述的读取职责应归 Workbench 的环境适配，嵌套的repo_packs/*/knowledge仍归 Knowledge——这棵目录不能整体搬迁。- 已有的真实耦合点。
harness/skill_evaluation.py同时依赖 KnowledgeReader、执行器与工程任务；feat: add shared engineering evaluation and dual-NPU MoE task #338 的TaskPackage.runspec()直接构造 Workbench 的 RunSpec。这两处是拆分的起点。 - 共享 package 内容变化会改变未来实验的源码 hash。 新实验重新冻结，旧实验原记录与原始来源版本保持不变。
9 本提案不授权什么
未授权源码迁移、目录重命名、实验执行、模型或设备调用、付费操作、合并，也不为任何在途 PR 追加合并前置条件。图中出现一个框不代表该能力已具备。第 1 节的入口表与行号为静态源码检查结果，未重跑测试或 CI；#338 相关结论固定在未合并的 8f3aebd2，不能写成 main 已交付的能力。
讨论上下文：OmniRSI #6 四轮评审与一轮全仓清理梳理。该线中四处事实错误已在原处更正未删改，根因均为人工枚举消费者种类或依赖方向时漏项——这也是第 7 节第 5 条的由来。
Activity
amy-why-3459 commentedon Nov 6, 2026
(schema probe - will not use)
amy-why-3459 commentedon Nov 6, 2026
（请忽略上一条误发的短评。）
感谢整理这份架构讨论稿——从「通道局部强制、保障集合不可推断」出发，到四类接口与交接时序，证据链很扎实；也正确地把本 issue 限定在讨论，不授权迁移或合入前置。
对 Decision needed 的几点意见，方便后续拆 task：
1. 三模块边界
同意 Knowledge / Workbench / Benchmark 互不直线依赖、由应用层组合的规则。尤其赞同：
ExecutionRecord显式声明本次实际完成了哪些完整性检查——这正好对上第 1 节入口表里grade/check/ MoE 保障差异「从导入关系看不出来」的问题；2. 四个公开接口的最小交接
KnowledgeBundlePreparedEvaluationExecutionRecordEvaluationResultINCONCLUSIVE；assess不隐式启动新实验时序上同意：② 在候选存在之前；③ 里绑定身份，不改已冻结的任务与判据；④ 只读执行事实。
3. 第 7 节五个遗留问题的归属建议
campaign_trace与 discussion: what trace evidence should InferRSI persist beyond per-run artifacts? #333 候选 2 对齐后再定统一事件信封。证据强度（主张 ≠ 捕获事实）必须写进接口约定，避免被当成 trace 日志用。PreparedEvaluation/ExecutionSpec的显式字段（例如budget_policy），并区分不可逆外部支出与可释放资源（wall time / 设备槽位）；不要用单一budget_ref五维统管。status取值上，并借用 [Research Radar] AI inference performance & RSI — daily categorized insights #177 的五级成熟度；触发用事件驱动（钉住 revision 与上游不一致，或候选集持续不命中），不必新开 issue。4. 与 #303 的关系
同意按三段回答，而不是在原二选一里选：
5. 实施切入点
实施切片另开 task 时，建议：
dependencies前缀解析与repo_packs/*/pack.json双重用途）；harness/skill_evaluation.py，以及 feat: add shared engineering evaluation and dual-NPU MoE task #338 的TaskPackage.runspec()直接构造 RunSpec。我这边可以继续在边界与接口字段草案上跟评论；具体实施 PR 再逐个 review。若对第 7.1 / 7.3 的归属有不同取舍，欢迎直接在本帖拍板。
Dong1017 commentedon Nov 6, 2026
补充 §1 预算行 / §7.3：预算占用不能直接当作实际支出。 在本文固定的
01c73521上，Ledger.charged累加的是worst_case；状态机允许reserved → cancelled，即使未执行也不返还该 PR 的预算容量。actual_cost则单独记录，取消项仍为None。所以“预留即计费”的准确含义是预留即占用预算上限，不是已经发生供应商收费；也不能把未知实付记成零或预留金额。建议公开接口保留三类独立事实：预算预留/占用及其策略、已观测用量/可得账单、活跃资源租约与确认释放。取消后可释放的是后续设备/并发容量，已消耗的设备时间和累计 wall time 仍应保留；不应因设备已释放而回退现有不退款账本，也不应把保守预留放进
ExecutionRecord的“实际用量”。§7.3 的预算 gate 归属仍由维护者决定。这是静态状态机核对和接口语义建议，未运行测试、修改预算规则或授权实施。
Dong1017 commentedon Nov 6, 2026
@zengchuang-hw 请从 plugin / install 的角度看看这份 Knowledge / Workbench / Benchmark 三模块架构方案，给一些建议。尤其想听听模块拆分对插件入口、安装打包、依赖和兼容性有什么影响。
zengchuang-hw commentedon Nov 6, 2026
回复 plugin / install 评审请求。我支持首期在同一个发行包内拆清 Knowledge、Workbench、Benchmark 的边界。建议把以下四项写进后续迁移 task 的验收范围。
保留现有宿主入口和安装身份。 Codex 和 WorkSwarm 各自使用原生清单和安装流程，继续让宿主适配层处理技能定位、会话和本机启动，由共用的
inferrsiCLI／应用装配层调用三模块公开接口。迁移时覆盖原插件 ID、清单与归档根、--plugin-info、既有命令的参数与输出，以及已公开的 Python 导入。WorkSwarm 继续验证紧凑载荷、只读inferrsi_runtime_info定位与 Windows 长路径安装。feat(dsh): add structured iteration form and SSH execution #361 的 DSH 仍是手动安装预览，远端还要执行随包的remote-runtime.zip。SSH bootstrap 直接调用inferrsi.arguments.parser和inferrsi.cli.main，模块迁移需同时核对远端参数解析和仓库路径约束，保留现有会话归属、关闭和重试语义。 Codex 安装 · WorkSwarm 安装 · DSH 远端启动给 wheel 和宿主包核对同一份必需资源。 wheel 通过
pyproject.toml选择 package data，插件构建器单独筛选 Python 文件及data/内的资源。若把任务输入、参考实现、许可证或知识附件移到新包目录，源码测试可能通过，安装包却漏文件。建议第一步保留逻辑 ID 与资源路径，在移动资源的切片里核对各产物都能解析同一份必需资源及其摘要，并沿用当前运行时版本与文件哈希校验。旧冻结记录继续通过原版本或既有快照读取。 Wheel 资源声明 · 插件资源筛选让按功能安装的依赖留在使用点。 当前核心要求 Python 3.10+，基础依赖为空，PyYAML 与图像验证依赖走 extras。启动入口、知识读取和历史报告查询应继续在基础运行时可用。引擎、设备及特定 grader 的依赖，在实际选择对应操作时检查，并给出缺失项和执行位置。DSH 经 SSH 执行时，应在目标机核对目标机的依赖。查询入口保持只读。 运行时与 extras · DSH 安装与远端说明
先验证安装后的兼容性，再迁移物理目录。 复用 Ready 的干净 wheel 检查和 Release 的 Codex／WorkSwarm 成品检查。现有 wheel smoke 安装了
[skills]，建议补一个无 extras、在 checkout 外运行的知识读取用例，再用同版本归档验证入口、代表性资源、历史结果读取，以及旧版本升级到新版本后的行为。原生宿主的安装／选择／升级和 DSH SSH 路径各保留对应证据，避免用构建成功推断宿主行为。 Ready wheel smoke · Release 成品检查本次依据主线快照
1246348和 #361 草稿f404981做静态设计核对。安装、升级和真实宿主运行留待实施切片验证。Dong1017 commentedon Nov 6, 2026
接口细化与讨论收口建议（v0.3）
本轮把三模块方向补成可交接给开发者的接口草案：9 组公开接口、19 组内部职责、18 个验收场景、6 个实施切片。下面先列需要维护者决定的增量，完整契约放在折叠区，其他 reviewer / agent 可以直接读取评论正文。
当前判断：大结构已有明确支持，可以收束；具体接口尚未完成维护者确认。 边界评审、预算语义修正、安装评审分别支持了方向和约束，不能据此把本条新增 DTO / 错误语义称为已达成共识。
1. Apps 到底是不是独立模块？
建议明确写成：三个业务模块 + 一个应用入口与装配层。 Apps 在代码中独立组织，首期可形成
inferrsi.apps包；架构图放在三模块上方，名称用“应用入口与装配层”。首期仍是一个inferrsi发行物，包边界独立不意味着各自发布 wheel。特别澄清“测量”归属：采样、计时边界、重复顺序、聚合和任务 worker 属于 Benchmark；启动 worker、控制进程、绑定输入和留存产物属于 Workbench。 不能因为 worker 在 W 的子进程中执行，就把测量规则也交给 W。优化循环由 W 推进，任务允许的重复/重试仍受 B 冻结协议约束。
三个核心包互不导入；W 所需
CandidateProvider / EvaluationPort / ContextProvider由消费方 W 定义，Apps 实现桥接。各模块拥有自己的 DTO；首期不设通用业务shared/contracts包。内部 19 项是职责边界，只有真实替换点需要 Protocol，并不要求先创建 19 个空接口类。2. 本轮真正补齐的交接内容
CandidateProposal={candidate, inputs, generation_record_ref}；W 的allocate_attempt只分配AttemptContext身份。目标、deadline、BudgetRequest与重试关联原样传递；真正准入、资源获取与启动在execute。encode/decode/validate_prepared；Apps 在评测执行前显式保存完整信封与所需资源，得到PreparedRef。protocol_digest标识规则语义，protocol.sha256标识完整文件字节，二者分开。RecordRef；补充事实产生新record_version。B 判定固定记录版本，Apps 保存结果后才生成AssessmentRef。读取 last-known 快照不等于确认进程仍活着或资源已释放。execute调用可能等待、接管、重跑，含义不确定AttemptInProgress；控制者状态不明返回RecoveryRequired。执行后的超时/取消/非零退出留在记录里；持久化失败显式报告是否已经启动。plan_generation → W.execute → collect_candidate两阶段 provider。W 先保存 generation manifest，再作为固定输入执行；collect 只读本 attempt 的实际绑定与留存产物。生成/评测是不同 attempt，共用任务预算 scope 和期限。BudgetRequest是输入；W 生成准入/预留回执。预算容量、已观测用量/账单、资源租约与确认释放分别记录。未知实付保留 null，沿用现有保守容量规则。3. 建议本 issue 只收口四项维护者决定
imported、知识存储 state、#177 研究证据成熟度、#350 主题覆盖、许可证与实证资格是不同维度，应分别表达。上游变化，或在有候选集记录的前提下持续不命中，可触发复核，不能自动判失效、晋升或降级。这一轮不需要等待所有 reviewer 对每个 DTO 字段都一致后才切 task。建议维护者先确认 A–D；S1 的小范围联审负责字段、错误、兼容 fixture，模块负责人据此进入后续切片。有异议请指明 A/B/C/D、需要替换的条款、受影响的调用路径或反例；确认应明确记录，不以沉默视为接受。
另修正主帖 §6：把 #303 的方法说明 / 冻结判据 / 执行事实分配到 K/B/W 后，Knowledge 内“扩展既有 method 还是新增 owner”的内容组织选择仍需由 #303 决定，不能说原选择自然消失。
4. 最新相关讨论与映射快照
schema_family=inferrsi.task尚未在 task: support shared YAML task input for the InferRSI CLI and agents #365 接受，不应先当现成标准。f4049814，并出现 LGTM 评论。安装评审中的清单、资源与真实宿主/SSH 兼容要求继续适用于后续迁移；不能用 Ready 或构建结果代替这些行为证据。完整接口草案
下列折叠内容是 v0.3 设计正文，代码基线固定在
1246348f252dbc7e473efb1752c2d81da15e23fd。其中的阶段标记和上面的讨论状态应一起阅读；提议接口不表示源码已经实现。HTML 架构稿、全量映射 XLSX、完整 JSON 已打包准备；本评论尚未包含已上传的附件链接，因此先将完整接口契约内嵌，评审无需依赖外部文件。模块边界与事实拥有者
2. 包边界与事实归属
建议先约束三个业务包核心不导入其他业务包的具体实现，跨包装配放在 apps。运行时数据流、通过注入调用被测对象，与静态导入关系是三件不同的事。Benchmark 测试 Knowledge 检索能力时可以使用由 apps 注入的被测接口；这不意味着 Benchmark 核心导入 KnowledgeReader。
每个包拥有自己的公开 DTO。不同包中的 ArtifactRef、CandidateRef 可以形状相近，但不共用一个不断扩张的 shared/contracts 业务包。apps 负责版本检查、字段转换、路径装配，不重新计算业务结论。需要去重的 JSON 编码、hash、原子文件写入等叶子工具，只在确有共同消费者时抽取，不能借此新增第四个业务模块。
2.1 apps 允许和不允许承接的工作
允许：读取配置、选择公开适配器、将知识快照作为显式输入、将 Benchmark 的操作描述转换成 Workbench 的请求、将 ExecutionRecord 转成 Benchmark 的 EvidenceInput、选择用户明确请求的流程、输出结果。
不允许：循环重试直到通过、累计第二套预算、维护第二套候选状态机、解释 PSNR/MoE rank 聚合、凭 exit code 填入通过的检查、将预算预留伪装成实付、覆盖既有 verdict。运行步骤推进和重试状态属于 Workbench；任务允许什么重试/重复顺序属于冻结的 Benchmark 协议。来源1 §3–7来源2 §3–4
跨模块接口、数据对象与失败语义
4. Knowledge：保留 Bundle，固定读取快照，受控写入
4.1 公开 Protocol
新 collect(request) 可以是类型化入口；原 collect(query, ids=..., revisions=..., ...) 的参数与错误语义由兼容 wrapper 保留。当前 Bundle.metadata / content / dependencies 内部包含可变容器，frozen dataclass 不提供深不可变性；公开快照必须先复制、校验、计算 revision，再交付，不能仅凭 frozen=True 声称已冻结。来源4 · KnowledgeStore
read(revision=None) 可以解析“当前”，但输出必须包含解析后的 revision。后续 resource 或实验消费使用该 pin，不能在每次读资源时重新解析 current。collect 不承诺多个独立 authority 的全局事务快照；精确对照实验由调用者提供 pins 并保留本次 resolved 集合。
4.2 写入和知识状态
沿用现有实现：create 仅建立 store-owned candidate；update 要求 expected revision、理由与证据列表，不能顺手改变内容状态。package / checkout 身份不能由 store shadow；仓库知识改动仍走 PR。来源4 · KnowledgeStore
保留现有多维状态，不发明新的统一生命周期枚举：
上游 revision 变化和检索持续未命中是 review signals，附适用范围、来源和触发证据；不是自动失效、自动删除或自动降级的充分条件。检索未命中还需区分没有进入候选集、排序后未选中、已交付但未使用；不要求 Knowledge 核心获知外部 Agent 是否真的理解了内容。
晋升策略和 reviewer 角色尚待决定，不能通过增加一个 promote() 默认放开。首期保留现有写入语义足够，不建立新的知识工作流引擎。
5. Benchmark.prepare：冻结比较规则，不禁止已有候选
5.1 Protocol 与核心 DTO 草图
以下类型归 Benchmark；Workbench 不导入它们。
可使用注册表选择 TaskAdapter，但首期只需少量静态注册、按任务懒加载。不要默认 import 全部 Torch / NumPy / 云客户端。TaskAdapter 可以实现 prepare 和 assess；按任务可再有 quality evaluator / sample parser，属于 Benchmark 内部接口。只为第二实现或真实外部边界抽 Protocol，不为每个 parser / 数学 helper 增加抽象类。
5.2 字段和冻结规则
prepared_id 识别本次准备信封，protocol_digest 识别实际比较规则；protocol.sha256 只识别完整协议文件字节。已有候选的 expected_candidate 可以改变准备信封，但不能因此把两个不同候选误判为使用不同的统计协议；比较适用性按协议、环境等具体字段判定，不只比较 prepared_id。
对新增候选搜索：先固定题目、规则、输入、生成约束和预算政策，候选可暂未绑定。对已有候选：允许带预期候选同时 prepare。每次 execute 都要核对实际候选字节，不可在运行后为了适配候选而改 protocol。
prepare 不是执行授权。现有 plan 仍是预览；新 execute 必须明确消费所选 PreparedEvaluation，而非重新读取 latest task 重建一份可能不同的规格。prepare 无隐式存储副作用；B 提供 encode/decode/validate，apps 在评测执行前显式保存完整准备信封并取得 PreparedRef；不调用模型、设备或候选程序。来源1 §4来源2 §4–5
recipe 不绑定控制机的 sys.executable 或本地绝对安装路径。Workbench 的目标适配器在受支持的运行环境中解析 runtime role 和入口，核对版本/能力并记录实际解释器、模块及命令身份；不能把本地 Python 路径原样交给远端 executor。
5.3 保留任务专属测量程序
Workbench 接管生命周期并不意味着 Benchmark 只剩一个结果 parser。MoE 的同一进程/通信域内交错采样、rank 同步和聚合属于测量算法，可以封装为一个粗粒度 task worker；Workbench 负责该受支持入口的进程树、期限、日志与产物。
单算子 AB/BA 若已表达为固定顺序步骤，可由 Benchmark 给出步骤和参数，Workbench 推进执行。禁止 Workbench 自己猜测采样顺序，也禁止 apps 外包一轮 AB/BA 到已含交错测量的 MoE 入口上。通用 workflow、重试和资源调度归 Workbench；任务内为测量语义必要的循环归 Benchmark。
任务启动子 rank 不意味着跨主机进程清理天然受支持。适配器必须说明它控制的资源域及确认释放能力；缺少必需能力时启动前拒绝，不能给本地 process group 的测试扩大到所有远端 launcher。
5.4 #364 的落点
建议新增任务特定、独立版本化的 DiffusionVideoQualityPolicy，放在 Benchmark 的 quality evaluator。原 PNG ImageQualityGate 与已冻结历史协议保留。MetricDefinition 明确 gate/diagnostic、单位、范围、aggregation、reference 条件与缺失行为。
#364 的最新评审指出：随机高频噪声可以增加 Laplacian 方差，闪烁也可能增加帧间差分。故锐度、帧差、亮度目前是待验证的指标候选，不能直接替代成通用 PASS 真值。建议分开媒体几何/完整性与质量，在同精度、同布局、匹配输入的 dense 对照上冻结双侧偏差，再用清晰、模糊、噪声、闪烁与正常运动的独立标注样本验证误接受/误拒。阈值与验收范围仍待原 owner 决定。
已有留存帧可以显式用新版本离线重评，保留旧 assessment；缺少匹配参考或原始数据时返回缺证据，不生成新视频补齐。来源：#364 增量评审
6. Workbench.execute：同步尝试、明确绑定、完整保留事实
6.1 Protocol 与核心 DTO 草图
以下类型归 Workbench，Benchmark 不导入。配套 DTO 在后文列出。
上述 command steps 只需支持现有固定顺序，不承诺任意分支图或脚本编排语言。首期入口可限定 python_module / executable 两种，runtime_role 和入口由目标适配器解析成实际 argv，并记录解析后的可执行文件/代码身份；未知 kind 明确拒绝。若首个适配器只支持一个粗粒度命令，公开说明该能力即可。任务需要的多步骤不能由 apps 临时维护自己的状态机来补齐。
首期同步 execute 足够；Cancellation 由 CLI 中断处理或调用方提供，受控执行在轮询点与异常清理路径观察取消。read 只返回已知记录。取消意图、实际退出与确认释放分开记录。跨进程 cancel、reconcile、submit、daemon 和自动 takeover 不属于首期公开 API；未来增加时仍复用同一 attempt/预算账目，不自动重启未知的外部调用。
Workbench 的普通命令模式允许 prepared_ref、protocol_digest、operation、validation_scope、candidate 为空，因此 W 可在完全没有 Benchmark 的情况下执行 CPU 命令。评测模式中，adapter 必须携带固定 prepared/protocol、operation 和 validation_scope，并满足该任务的输入角色约束；不得用空值绕过。assess(record) 根据记录中的固定 prepared_ref 与 scope 解析，不能依赖最近一次 execution_for 的内存状态。
6.2 运行前后的记录
输入捕获后，不继续从原始可变路径执行。目录候选需要明确定义树清单、路径规范与 hash 版本；内容 hash 仅证明所捕获的字节身份，不自动证明整个期间未发生过写入，更不替代某些编辑适配器的操作代次 receipt。现有更严格语义保留，简单内容快照流程不强行引入编辑会话。
任务入口读取自己的冻结协议和已物化的候选路径；Workbench 保留它实际执行的路径/字节绑定。task worker 的回显身份必须与本次 attempt、operation、candidate 相符。apps 只转换已有事实，不能自行生成通过记录。
API的ExecutionRecord采用平铺返回信封；持久payload排除record_ref、observed_at、controller_observation，recorded_at仍参加摘要。评测只消费固定RecordRef对应的payload。
6.3 同步状态机应足够小
建议存储 phase 和结束事实，避免一个 SUCCESS 同时代表所有层：
process_outcome 独立记录 not_started / exited / timed_out / cancelled / execution_error，exit_code 另列。cleanup 独立记录 not_needed / confirmed / failed / unknown；“取消已请求”另有字段。
先登记 attempt 和预算范围再启动。执行前的资源不足、能力不支持、身份不符要保留 not_started 原因。若连 attempt 记录都无法持久化，抛 ExecutionPersistenceError(started=false) 并不启动；启动后提交失败尽力清理并保留局部记录，统一抛 ExecutionPersistenceError(started=true, partial_record, retained_refs)。接口不能承诺磁盘不可写时仍必然得到完整记录。
6.4 预算、用量、资源租约必须三个对象
金额使用带币种的十进制值，token 使用整数；不将不同维度相加为一个 cost。硬上限只对执行器已支持并可验证的能力作承诺。token 停止准入阈值和供应商实际收费硬封顶不是同一能力。
BudgetRequest 是执行前政策输入，不含已准入/已预留回执；BudgetAdmission / Reservation 只由 W 产生。预算政策由发起方与验收主体确定。Workbench 负责支持能力检查、预留、限制和累计记录；Benchmark 只根据预先冻结的某项 claim 是否要求预算证据作解释。超额、缺证据、policy 不支持是不同原因。预算政策缺失不能由 apps 在结果出来后默认为非必需。来源1 §7来源3
包装现有账本必须保留其不同政策：既有 PR 的保守预算容量、daily ledger 的窗口和 claim_once 的一次性执行权不能用同一个“退款/重放”规则覆盖。claim 结果不确定或 claimed 后崩溃，不能仅凭新 request_id / 新进程自动接管执行。读账、准入、执行权和实际消费四种事实分别说明。
6.5 优化循环：Workbench 自有端口
Workbench 的 CampaignCoordinator 拥有尝试推进、累计预算、deadline、候选依赖和取消。apps 创建并注入适配器。首期已有候选路径直接组合 prepare / execute / assess；接真实优化循环时再实现以下 W 自有端口。
完整 DTO 字段与调用例见“可实施契约”。CampaignPlan 搜索前持有各验证阶段的 PreparedRef / protocol digest。execution_for 不改 W 分配的身份、目标、期限和 BudgetRequest，不重选 latest 任务。apps 注入的 adapter 调用 B 公共接口并转换 DTO；知识 adapter 调 K，W 留存实际交付快照。
真实Agent固定为 plan_generation → W.execute → collect_candidate；两端不发外部调用。CandidateProposal 包含candidate、完整InputSpec及generation_record_ref。generation和evaluation各自attempt共享预算scope和总deadline。首期fixture不等于真实Agent资格。
AssessmentSummary 带实际已保存的 AssessmentRef、candidate/attempt/protocol/scope、分范围结论、metric validity和证据。选择策略需要的eligible/ineligible/unknown或better/equivalent/worse/incomparable由B给出，W按冻结策略消费；PASS不自动表示更优或最终接受。assess按固定record revision与PreparedRef恢复，不依赖最近一次调用内存。
7. Benchmark.assess：离线、范围化、不覆盖历史
7.1 EvidenceInput 不是直接传 Workbench 内部对象
apps 的适配器将 ExecutionRecord 转为 Benchmark 自有的只读 EvidenceInput。转换必须保留原记录引用及 digest、protocol / candidate / operation / attempt 关联、退出/清理事实、检查的来源与状态、原始产物、预算和环境中本次协议需要的事实。
映射可以是字段一一复制和格式转换；不能替 Benchmark 判定哪些证据足够，也不能默默省略执行错误。建议对这个适配器用一个固定输入/输出 golden fixture 证明没有丢失关键身份、状态和单位，而非为每个字段写一套镜像单元测试。
assess 先核对对象与版本，再检查每项 claim 的必需证据，再由 task-owned evaluator 解析和计算。离线可以做文件解析、hash 核对、统计重算；不调用候选程序，不访问模型服务/设备，不从可变 upstream 拉新资料，不在缺原始数据时偷偷重测。ArtifactReader 仅提供已留存且可校验的只读材料。
task-owned 解析器代码是安装包的一部分；历史记录不能把任意 Python 模块路径或 pickle 作为 assessor 指令。读取历史材料按支持的 schema 转换，未知版本明确不支持；历史重判不是自动运行归档中的代码。
7.2 失败不能跨范围互相覆盖
按 task 固定规则可给一个 scoped task verdict，但不能生成涵盖执行完成、任务通过、实验验收、发布和知识推广的“总 PASS”。
7.3 重判与版本
同一 prepared + 同一证据 + 同一 assessor 版本应得到确定的语义结果；评估时间等非语义元数据不影响结果身份。重判持久化为新 assessment 或返回已有相同结果，不覆盖原执行记录。
Benchmark 与 grader 可以演进。升级版本不使所有旧比较自动失效；旧结论保留原 protocol / grader / 数据范围。若发现特定旧 grader 缺陷，单独记录哪些结论需复核或撤回，以及为什么；新评分版本和旧评分不能未经可比性确认混排。
重新运行检查是另一次显式 execute / attempt，不是 assess 的降级路径。旧 benchmarks grade 当前会执行检查的兼容入口，不能在迁移中悄悄改成纯离线；需要保留行为并说明与新 assess 的区别，或另行宣布弃用。来源1 §4–5、§8来源2 §1
8. 错误、幂等与版本：不做新的基础设施平台
8.1 错误类别
每包公开自己的错误类或稳定 reason_code，保留旧入口原异常/CLI 语义。可共享文档词汇，不要求全仓共继承一个巨型错误体系。
数据损坏导致整个输入无法识别、或 assessor 自身程序 bug 时可抛异常。候选不正确、样本不完整、缺预算证据等可预期评估结果，应返回可解释的 ClaimResult。
8.2 幂等策略
execute 至少用现有本地锁/事务或原子创建保留 request / attempt 记录；request_id 的去重不等于外部 side effect 的 exactly once。网络断连、provider 状态未知或控制器崩溃时，无法确认是否执行过则标记 recovery_required / side_effect_unknown，不因未看到最终输出就再启动。清理和实际资源核对是后续显式恢复流程的工作。重试新 request 也不得绕过已有 claim_once 或同一预算 scope 的限制。
若以后需要写入请求的幂等保证，Knowledge 可加 write_request_id + request digest 的事务记录，原子保存写入结果；这是新能力，不能绕过现有 expected revision 直接靠目标 hash 猜测某次写入是否已成功。
8.3 版本策略
具体返回表、不可变记录修订、来源匹配、编码投影及新进程用例见“可实施契约”。
可实施契约与完整交接用例
可直接用于实施的契约补充（v0.3，待讨论确认）
以下约定补齐接口的构造者、持久化、调用顺序和返回行为。它们是本稿明确推荐的设计，尚未成为 main 的实现或 #362 的 accepted 决定。开发者应先引用已确认的决策，再实现对应切片。
1. 谁定义类型，谁持有数据，谁负责转换
核心模块只依赖本模块类型、标准库及明确的纯叶子工具。Apps 可以导入三个模块的公开 api；K、W、B 均不得反向导入 Apps，也不互相导入实现。W 通过声明的命令启动 B 的 task worker 是执行关系，不要求 W import B。测试只在真实适配边界验证转换；无需创建第四个业务 contracts 包。
固定引用的字段
下面是结构规范。B 和 W 各自公开所需的值类型；同名字段通过 Apps 显式转换，不让 W 的 PreparedRef 继承 B 的实现类。
所有 snapshot ref 都引用规范编码后的字节。记录自己的 ref 放在返回信封外层，不参与它引用的 payload 摘要；其余业务字段包括 record_version 必须参加摘要。新协议规定 UTF-8 JSON、键排序及字段级数值编码并提供固定 fixture；JSON 内禁止 NaN/Infinity，参与新请求摘要的非整数阈值/限额使用规范十进制字符串。Knowledge 的旧 Bundle 编码与 revision 算法保持原样。实现 S1 必须给出规范编码的精确 fixture，未通过它不能宣称跨语言摘要兼容。
API 的 ExecutionRecord 采用平铺返回信封：持久 payload 字段加 record_ref、observed_at、controller_observation。持久字节仅编码 payload，明确排除上述三个读取/引用字段；recorded_at 是已提交事实时间，仍在 payload 内。to_evidence 使用 RecordRef 对应的固定 payload，读取时新观测到的控制者状态不能无引用混入评测；需要采用时先形成新的记录修订。S1 的 schema/fixture 应固定这个投影，不由各 adapter 自选嵌套形状。
2. 准备与判定都可脱离工作台进程
Benchmark.prepare 是无实验副作用的准备计算：读取显式声明的资产、验证配置、生成 PreparedEvaluation。它不占用执行预算、不启动服务、不调用模型，也不自行写入隐式全局目录。B 提供 encode_prepared / decode_prepared / validate_prepared 纯函数。
执行前必须由 Apps 的 archive_prepared 完成显式保存，取得 PreparedRef。保存至少包括准备信封、协议及离线判定所需的数据资源；已有大对象可保留经过摘要核验且离线可读的固定位置。引用不保证永远可访问，后续缺失必须报 unavailable，不能重新 resolve latest 来补齐。
assess(record) 的 Apps 适配器按 record.prepared_ref 读取固定准备信封，交由 B 解码、验证，再把该 record revision 投影为 EvidenceInput。适配器不依赖上一次 prepare 或 execution_for 的进程内状态。
B.assess 返回结果 DTO；B 的 encode_assessment 负责规范编码及验证。Apps archive_assessment 显式保存后，才能交付带 AssessmentRef 的 AssessmentSummary。独立离线使用者可自己提供本地 ArtifactReader 和存储，不必创建 W 服务。重复计算允许生成相同语义结果；时间等非语义元数据独立，旧结果不覆盖。
3. 现有候选的完整交接
下面的名称是目标 API 草案，不是声称仓库已经存在这些调用。
archive_*是 Apps 的小型装配函数，字节存储通过构造参数注入；W 提供的存储只认识字节和引用，不理解 B 的评分规则。bind_execution 检查 prepared_ref 与 prepared 的身份一致；按任务输入角色绑定 CandidateProposal，逐字段保留 AttemptContext。目标条件不支持、阶段不匹配、缺必要输入时明确拒绝。环境、授权和资源等即时状态仍由 W 执行前检查，预览通过不保证稍后准入。
ExecutionSpec 必须含 target_request、retry_of/retry_reason、generation_record_ref；后两类可明确为空。bind_execution 将 AttemptContext 的重试来源与 CandidateProposal 的生成记录引用保留到 spec/record，并纳入请求及记录摘要。人工候选的 generation_record_ref 为null，不能制造生成执行历史。
CommandStep.outputs 使用 tuple[OutputSpec, ...]，InputSpec.materialized_path、CommandStep.cwd 及 OutputSpec.path 采用相对于 attempt 工作目录的逻辑路径，拒绝逃出允许根的路径；输出按 attempt 隔离。固定 steps 默认 fail-fast：某步启动失败、非零退出、必需输出缺失、超时或取消后，后续步骤记 not_started。测量算法若需要采集并继续，由一个 task-owned worker 实现并报告，其内部规则在协议里冻结，Apps 不增加另一套循环。
4. 同步 execute 的唯一返回规则
阶段统一为 registered → preparing → running → stopping/finalizing → finished 或 recovery_required。registered 仅表示身份登记，不表示预算准入已经通过。finished 允许 process_outcome 为 not_started / exited / timed_out / cancelled / execution_error；cleanup 是独立的 not_needed / confirmed / failed / unknown。存在未确认的外部进程/租约不能转为生命周期 finished。
read(attempt_id, record_version=None) 返回最新已提交快照；传 record_version 返回该固定历史版本。返回信封包括 record_ref、observed_at 和 controller_observation（observed / unavailable，附来源与时间）。旧 running 记录只证明曾进入 running，不能单凭它推断当前存活或已清理；read 不执行恢复或重启。首期跨进程 cancel、daemon、自动 takeover 均不在契约内。
评测引用固定 RecordRef。后续清理补证形成新 record_version，可派生新的 assessment；旧 assessment 继续指向原记录版本。给“当前文件”重新写内容、保持旧 ref 不变，违反本契约。
去重仅在同一配置的 RunStore 执行命名空间内成立。output_root 只是该命名空间下的产物位置，不得借改路径绕开 claim；不同本地目录不是全局去重系统。BudgetRequest 在执行前表达意图，BudgetAdmission/Reservation 只能由 W 的实际准入产生；没有政策的付费请求必须拒绝，不能把 null 当作预算豁免。
普通免费本地CPU可用 policy_ref=null、空请求限额，前提是W确认所选执行能力不含付费行为且该任务不要求预算政策；仍记录scope、期限和实际可观测用量，不创建假政策。后续真实Agent/provider要求有实际预算规则时，该空值请求启动前拒绝。
5. 优化循环中的三类端口
Workbench 拥有循环、候选依赖、执行尝试和推进状态。它声明自己需要的端口；Apps 构造具体适配器。这些类型属于 W，B/K 不 import 它们。
真实 Agent 的执行路径固定为 plan_generation → W.execute → collect_candidate。plan_generation 与 collect_candidate 不做外部执行，generation 与 evaluation 使用各自 attempt 但共享 budget scope / 总期限。首期 fixture 可生成确定候选验证装配，不能据此宣布真实模型、宿主或远端能力已验收。
两步之间由 W Coordinator 的 seal_generation 小型内部函数明确留存计划：先保存 GenerationManifest 取得 ArtifactRef，再把 role=generation_plan、expected_sha256=该摘要的 InputSpec 加入最终 spec，最后计算 request_digest 并执行。manifest 不含自身引用、完整 spec、本次尚未产生的 RecordRef 或候选引用；已有 context_refs 可作为输入，因此不存在循环摘要。该保留角色冲突时拒绝，不覆盖调用方输入。
collect_candidate 从 record 的实际 BoundInput 读取 generation_plan，按其固定 output_contract 解析本 attempt 的产物；不读原可变 source 或内存里的最新配置。缺 manifest、版本不支持、候选角色/格式/attempt 不匹配时明确失败。provider_id/revision 本身是计划声明，必须与实际 worker/命令身份对照才能归因，不能单凭字符串声称某个模型已执行。
execution_for 只能使用既有 prepared_ref、proposal 和 W 分配的 attempt；不得在 adapter 中重选 latest task、修改门槛、生成另一套 ID 或延长总预算。assess 的返回只有在对应结果已经持久化后才带 assessment_ref。W 根据 B 给出的比较资格和冻结推进规则行动，PASS 本身不表示更优或最终验收。
#363 的后续扩展仍按单父 + 单投机后继建议讨论。multiple starting points 尚待独立范围决定；不能因接口能保存多个 ID 就声称已实现多分支调度或失效传播。范围澄清
6. 模块内部的实际依赖与首批实现
先移动责任和稳定出口，保留兼容 wrapper，再迁移物理目录。不要按目录名整块移动混合职责代码。例如 runner 中的 AB/BA 规则归 B，进程与记录归 W；dashboard 的原始记录 helper 应先下沉到 W，避免 W 反向依赖展示层。资源移动同时检查 wheel 和宿主包，而不只验证 checkout。
7. 开发者必须能演示的三个用例
S1 的契约 fixture 必须覆盖同 key 冲突、进行中重入、prepared/record 修订引用、适配器字段保真、目标端能力拒绝和 fail-fast。S2/S3/S4 分别实现真实行为后再做 S5 组合；不把所有新门禁一并施加给无关在途 PR。
8. 新信封的摘要与检查匹配规则
S1 推荐固定
inferrsi-json-v1：新信封键为 ASCII schema 字段或明确的 ASCII ID；键按字典序排序、数组保持定义顺序、UTF-8、无 BOM、无末尾换行、无无意义空格，字符按 JSON 必需规则转义且中文不转义。输入拒绝重复键、孤立 surrogate、浮点/NaN/Infinity。整数使用十进制无前导零；字段需要非整数时使用规范十进制字符串（不含指数、无多余零、负零归零），数值域由字段 schema 校验。原始样本文件可保留任务格式，摘要直接针对其原始字节。用户 YAML 在 Apps 正规化后才进入此编码，Knowledge 旧编码不变。PreparedEvaluation 明确同时保存
protocol_digest和protocol: ArtifactRef：前者是表中规则投影的语义摘要，后者的 sha256 是完整协议文件字节摘要。ExecutionSpec / ExecutionRecord / EvidenceInput 都传递名为 protocol_digest 的语义字段；读取 protocol 文件还必须核对其独立字节摘要，二者不可互换。迁移旧字段时 adapter 根据其原定义转换，不能仅改名字便宣称等价。这里排除的展示文本仅指纯UI注释；任务指令、提示词、判据解释及影响测量/评分/生成的内容必须按角色保留并参加对应身份。输入角色的集合先按 role 排序；执行步骤和样本顺序有语义，不能重排。目录快照采用有版本的 manifest，路径使用相对 POSIX 形式并拒绝逃逸、重复逻辑路径和未支持链接；不能把 OS 遍历顺序当摘要规则。S1 交付至少两个跨入口编码 fixture，其中一份含非 ASCII 值、十进制阈值、空值、重排键及数组顺序反例。
EvidenceRequirement 还须冻结允许的来源种类/控制域及匹配规则；默认匹配 check_id、checker_revision、subject/candidate、attempt、operation/scope、phase、artifact schema。完全相同的证据可去重，矛盾记录形成 conflict；未有更具体任务规则时，受影响 claim 为 INCONCLUSIVE，不能最后一条覆盖。不同范围的失败按各自规则保留，清理状态不覆盖已有正确性错误。worker 自填 producer.kind 不会升级为独立核验，来源强度以实际采集路径和可核对证据为准。
冻结 grader/rule 版本与实际运行的 assessor 版本分别记录。默认 assessor 必须显式支持 prepared 的冻结规则；不支持则 UnsupportedRuleVersion，不按新默认阈值解释。新政策重评创建新的 prepared/policy 引用及派生关系，旧结论保留。
内部 TaskAdapter.assess 与公开接口统一：
assess(prepared, evidence, *, artifacts: ArtifactReader)。TaskCatalog / task asset reader 在 Benchmark 服务构造时注入；单次 evidence reader 从参数传入，不使用全局隐式 store。数据格式、检查、事件与兼容
数据格式的共同规则
这些是协议约定，不要求引入共同业务包。每个 owner 维护自己的类型；apps 的 adapter 验证并保留字段意义。
来源与执行阶段字段
ProducerRef 的字段为 kind、identity、version、source_ref。kind 取 caller_assertion / adapter_report / controller_observation / independent_verifier / unknown；version或source_ref不适用/不可得时明确null，不伪造已验证出处。PreparedEvaluation、ExecutionSpec、ExecutionRecord 和 EvidenceInput 必须保留评测模式的 operation 与 validation_scope，并与冻结 CampaignPlan 的阶段相符；同一候选可有多次attempt，但开发和最终验收证据不能互换。
检查事实与预期要求的逐项对账
PreparedEvaluation.required_evidence 在执行前声明 check_id、对象/阶段、checker版本、artifact schema、适用claim。ExecutionRecord.checks 记录实际 status、producer、subject、attempt、expected/observed 和 evidence refs。Benchmark 逐项检查其是否满足要求。执行后生成的检查列表不能反过来定义“本来就只需要这些”。caller_assertion、adapter_report、controller_observation、independent_verifier 是出处类别，不能被包装成同一 verified。
事件与 Dashboard 的最小契约
RunEvent 包含 schema_version、event_id、run_id/attempt_id、可选candidate_id/branch_generation、producer、sequence、occurred_at、recorded_at、event_type、payload/evidence_refs。相同producer+event_id去重；不假装全分布式总序。未知时间/事件缺口/断连显式保留。ProgressObservation 使用 completed、total可null、unit和stage；total未知时展示不定进度，0/未运行/N/A不同，100%仅代表工作量完成。
KnowledgeDelivery 只表示 query/selection版本、实际知识ID/revision和交付快照；KnowledgeUse 单列采用/未采用/未知及证据，不通过“已检索”推断被使用。相关评测结果保留B assessment引用，不按条目分摊因果收益。具体持久索引范围由 #333 继续决定。
生命周期与结果实例（示意）
一个可信任务报告已证明当前候选正确性错误，随后子进程清理未确认：ExecutionRecord 保留 process_outcome=exited、cleanup=unknown、lifecycle=recovery_required；EvaluationResult.correctness=FAIL，performance=INCONCLUSIVE/invalid。这个例子只说明新schema语义，不改写旧 evaluator 的整体 INCONCLUSIVE 或历史结论。
模块内接口与现有代码迁移
2.1 建议组件与现有落点
api.pyKnowledgeReader.read/collect/resource；KnowledgeStore.create/update/historybundle.pyBundle.manifest/revision/viewknowledge_operations.Bundle、safe_path/_normalizedsources.pyKnowledgeSource.identities/read；解析函数resolveKnowledgeReader._knowledge/_checkout/_skill/owners/resolve、skill_catalogselection.pyselect(query, records)纯函数；assemble_context纯函数_skill_selection、collect中排名和上下文生成store.pycreate、update(expected, reason, evidence)KnowledgeStoreSQLite 事务research.pyresearch_knowledge、model profiles、knowledge recordscatalog.repository_pack()是例外：它返回运行目标描述，消费者为环境检查，应移到 W 的 target descriptors；repo_packs/*/knowledge仍归 K。不要按目录整体移动repo_packs。2.2 最小内部协议
只有来源存在真实替换需求，值得使用 Protocol。下面为接口方向，先不要求所有方法变成新类：
KnowledgeReader组合多个只读来源。KnowledgeStore另外实现 writer，不让 package/checkout 提供会在运行中报“不支持”的假写接口。Store 已经有足够具体的接口，不需要额外泛型 CRUD 层。当前
Bundle是 frozen dataclass，但字段包含 dict；它不等于深层不可变。目标实现应在边界复制/验证输入，revision 必须对应真正交付的字节。这里应保留 manifest 编码、逻辑资源路径和 hash 算法的兼容测试，避免为了加 immutable wrapper 而改变身份。3.1 内部组件和最少端口
execution.pyExecutionService.execute(spec) -> ExecutionRecordharness.runner中生命周期部分；不保留具体 AB/BA 规则inputs.pybind_inputs(request, workspace) -> BoundInputs；check_inputs(bound)infra.targets.repository_identity、任务/候选捕获executors.pyProcessExecutor.run(command, context) -> ProcessOutcomeinfra.executors.local.execute_command、infra.processesresources.pyacquire(request, owner) -> Lease；release(lease) -> ReleaseRecordbudget.pyreserve/claim_once/advance与AtomicStoretools.skill_eval_budget*；不要再建第二本账records.pyRunStore.begin/append/finalize/readinfra.artifacts、runner 文件、campaign/optimization 记录agents.pyAgentInvocationAdapterCodexClient、Anthropic 请求适配、trace usagecampaign.pyCampaignCoordinator经 W 自有 EvaluationPort 消费 B 的评估结果，复用上表执行服务harness.improvement中选择/推进部分；#249、#363 增量首期不用每行都创建新文件或 Protocol。生命周期、executor、record store 必须有真实实现；预算接入有付费消费者才抽取；资源/并发策略随着 #249/#363 被接受的切片接入。模块设计应写出这些责任，不能用空实现占位并宣布能力完成。
4.1 组件与端口
api.pylist_tasks / prepare / assesstasks.pyTaskCatalog.load(ref) -> TaskDefinitionTaskPackage / load_task / load_builtin_task；工程/诊断任务preparation.pyTaskAdapter.prepare(request) -> PreparedEvaluation（无隐式写入）workers/*assessment.pyTaskAdapter.assess(prepared, evidence, *, artifacts) -> EvaluationResultmetrics.pyadapters/*任务 registry 首期静态注册即可。
TaskAdapter是需要变化的端口；不要将 load、parse、score、每个数学函数都再抽一层接口。prepare可以读取和验证已声明任务资产、计算 manifest/digest，但不运行候选、模型或加速器。assess读取留存内容，核验并重新计算判分；不导入 executor，不创建新执行，也不隐式抓取外部资源。较大的 artifacts 通过 B 的只读ArtifactReader.open(ref)端口读取；由 apps 提供基于 W artifact store 的 adapter，必须按 digest 验证读取到的字节。4.4 当前混合代码的具体拆法
harness.runner.run_experimentharness.evaluation.evaluatescenarios.external.execute_trialread_metric / validate_metric的语义、任务报告解析execute_command和日志/产物留存属 W；旧组合函数兼容转发TaskPackagerunspec()直接构造 W RunSpec 的桥接搬 apps；不让 B import Wgrade_artifactassess才是纯离线skill_evaluationharness.improvementImageProtocol/collect_samples5. Dashboard / context capture 的具体归属
目前
campaign_records.py反向导入dashboard_data的文件和路径 helper；如果把 dashboard_data 整个放 apps，会让记录写入模块依赖展示层。建议先将路径/原始记录读取 helper 放入 W records 内，双方复用，再拆业务解释与展示。optimization_trace的 caller assertions、campaign/candidate/run 关联、引用/hash 检查knowledge_capture的 collect 选择语义与 context 文本组装optimization_story的声明与留存证据对账现有 dashboard 的 outcome/noise/quality 是派生展示语义，应明确标为显示标签，并保留正式
evaluation.verdict。对于旧 archive 的兼容显示可保留现有规则，不将 outcome 当成新的正式判定。新提案的扩展位置
6. #363 与 #364 对接口设计的增量要求
#363 投机验证
在 W 增加有界策略和候选依赖记录，复用 #249 的执行/预算/资源端口。不要建立第四模块或第二个 scheduler/ledger。
CandidateRecord：候选身份、parent、generation_dependencies、artifact refs、producer context、comparison baseline、quality reference。ValidationRequest：development_quick / development_full / final_acceptance 的独立协议引用。阶段不是新的 verdict。CampaignState：stable_head、verified_head、speculative_head、state_revision。只有 W controller 的条件更新可推进开发基线，当前 dashboardrecord_decision的调用者声明不能冒充这个控制动作。#364 Diffusion 质量
MetricDefinition应区分 metric role：gate / diagnostic，计量范围和适用 modality。不能把所有存在的指标都自动用于 PASS。QualityPolicy版本化，明确 comparison reference、precision/layout 条件、几何要求、样本集合与聚合。它归 B。#363 的多起点方向仍待范围决定；本稿推荐首期保持单父+单后继，后续多分支另定身份、晋升冲突和失效传播。
必须保留的验收反例
必须保留的反例
测试复用已有有效回归；上述每项新增测试对应具体迁移风险，不为 DTO 的每个字段建立无意义镜像测试。导入边界先扩展现有 AST 直接规则，再明确是否要求传递闭包；它们不能替代执行和结果语义测试。
Agent开发交付卡
共识之后怎样分配给 agent
在 #362 记录每项 D01–D11 的 accepted/revise/deferred、确认者和决策链接。涉及 #303、#355、#363、#364 的新能力仍由各自 issue 记录范围。接口共识与具体 task 的资源/实验范围分别保留。
每个开发 task 至少包含下面的交付卡：
S2、S3、S4 可在 S1 契约固定后并行；S5 在三个模块的首批契约可用后做组合验收。迁移 task 不擅自重开已关闭目标，不把其他在途 PR 统一附加全部新门禁。接口字段的存在、mock的成功、代码合并、宿主实测、任务收益和项目验收分别报告。
最先应写的端到端用例：安装包外知识读取；真实 CPU 命令的取消与清理；保留单算子/MoE证据的纯离线判定。生成流程首期可用受控provider fixture验证装配。真实Agent新增接入在后续#337切片完成；每实际迁移一个已有宿主/SSH路径，分别补真实路径验收，未迁移者沿用原适配器，不用mock代替资格。
#365 按 D11 单独冻结 parser 依赖、覆盖优先级和 DSH v1 迁移范围；当前主仓映射更新为365项，使用15:17:08上海时间的增量快照。
共享YAML任务输入与协议版本反例
#365：CLI 与 Agent 共享任务输入的接口
建议将任务文档入口放在
inferrsi.apps.task_input，随普通 InferRSI 安装交付。它属于应用入口，负责把用户意图转换成三个模块已经定义的请求。任务语义、执行事实与知识内容仍分别由 B、W、K 拥有。#365明确的公开面
推荐语义，供 D11 确认
inferrsi.task，首个主版本为 1；已有 DSH prototype 的无族名三段 v1 不能被静默当作兼容。按明确迁移适配器转换，或纳入本期并验证同一 fixture。本接口产生任务输入，不产生执行授权。文档 hash、NormalizedTask hash、PreparedRef、实际 InputBinding 分别保存；同一文件不等于同一运行环境。用户显式执行后，仍使用现有 acceptance、冻结 gate、预算和证据规则。默认 flag 与依赖评审 · DSH 兼容评审 · triage 回复
#353 提供的协议版本反例
当前 #353 正文的 B1/B2 规则写两次独立服务启动，但最新评论报告同一服务连续 R1/R2，轮间不重启；正文的暂停描述与最新活动报告也不一致。这次设计不重新裁决作者的实验结论。它说明必须保存生效
protocol_ref、接受依据和实际 service instance / attempt / 阶段拓扑，而不能只引用一个可编辑的 issue URL。B 对照固定规则与执行事实，Apps 不静默替换解释；原作者报告保留来源和适用范围。报告一 · 最新报告按开发切片分配的验收矩阵
5. 最小验收矩阵
这些是针对确定迁移风险的用例，优先复用现有测试。没有必要为每个 DTO 字段写镜像测试。
对于真实 Agent、每一种新宿主、SSH、GPU/NPU、跨主机 rank 控制，另列真实路径验收。上述 CPU fixture 的通过不能替代它们。新资源政策、收费对照、投机并发、质量阈值的接受，仍按各自 issue 的具体范围进行。
Dong1017 commentedon Nov 6, 2026
@amy-why-3459 @zengchuang-hw 麻烦 review 一下这版 接口细化与讨论收口稿 v0.3。完整契约已放在该评论的折叠区，可以直接在 issue 内阅读。
希望这轮明确 A–D 四项哪些可以确认、哪些需要修改，据此冻结架构方向并拆实施任务：
status的建议。inferrsi发行物中，这个定位是否合适；CLI/import、插件 ID/清单、打包资源、会话及真实宿主/SSH 兼容的验收范围是否有遗漏。task: support shared YAML task input for the InferRSI CLI and agents #365 的核心 YAML/PyYAML 依赖变更与 DSH 接入按原 issue 单独推进，是否有需要提前约束三模块迁移的地方。请尽量按 “决定编号 → 同意 / 需修改 / 尚缺信息 → 具体原因、替代方案或反例” 回复，并区分 启动 S1 契约切片前必须解决的问题 与 可以交给后续实施切片的细节。也请直接指出是否还存在阻止大结构冻结的分歧。
zengchuang-hw commentedon Nov 6, 2026
回复 v0.3 复检请求。我这轮重点看 A/D，按当前
main1246348f、#365 的待分诊条款和 #361 的f4049814做静态核对。S1 开始前要定下的边界
A（D01/D02/D07）· 同意。
inferrsi.apps可以独立组织，首期继续由一个inferrsi发行物交付。Apps 负责 CLI、宿主入口、配置和公开接口之间的转换。测量协议由 Benchmark 持有，执行生命周期由 Workbench 持有，知识与资源身份由 Knowledge 持有。S1 开始前应把兼容责任写入交付卡，列明旧 CLI/import、参数与返回语义、资源 ID/逻辑路径及版本、插件 ID/清单与会话入口分别由谁保留，并用现有入口做代表性用例。 v0.3 模块边界 · 现有发行与入口D（D08/D09）· 需补一条产物验收规则。 A13 覆盖普通安装中的知识读取，后续移动资源或迁移入口时，应在对应切片核验实际发行物。改动共用 launcher、打包器或 CLI 时，也把使用该路径的宿主纳入验证。当前 wheel 的
package-data与插件构建器的资源筛选各自维护，现有 Codex 完整性测试聚焦inferrsi/data/。例如把任务输入或 schema 移到新子包，源码测试可通过，而某个宿主包会漏掉资源。建议 S1 先约定按消费者核对必需资源清单、摘要和明确的宿主差异，由发生迁移的切片负责验证。公开包只包含获准分发的任务资源。 Wheel 资源声明 · 插件筛选 · 现有完整性测试D（D09）· 明确共享 CLI 新功能的宿主边界。 feat(dsh): add structured iteration form and SSH execution #361 允许远端调用
plan/run，SSH bootstrap 在调用 CLI 前检查 argparse 顶层路径和脚本字段。以后随远端包带入--task时，YAML 内的仓库和命令可能在这层检查之后才解析。建议 S1 约定远端只开放已验证的输入形式。task: support shared YAML task input for the InferRSI CLI and agents #365/[RFC] Agent plugins: a consistent InferRSI workflow in Codex, DSH and openJiuwen #152 接入时，可先在远端明确拒绝--task，或在远端解析后对生效路径、脚本和执行限制做同等检查，再开放并补越界拒绝用例。这个约束适用于将来的组合路径。 SSH 参数和路径检查 · 远端命令范围交给实施切片的验证
inferrsi.arguments.parser和inferrsi.cli.main，并依赖参数字段与Path类型执行仓库边界检查。验证旧命令可用、越界被拒，以及 session owner、取消和清理语义仍成立。宿主实测留在改动该路径的切片，证据关联产物版本和宿主环境。 Release 产物检查 · DSH SSH bootstrapA/D 视角没有阻止大结构冻结的分歧。S1 前应定下兼容承诺和验证归属，具体打包实现、宿主实测和 YAML 依赖由相应切片完成。本轮未执行安装、升级或 SSH 实测。另一个状态更新可随修订带上：#361 当前为 Ready，
f4049814已有两份正式批准。 Amy 批准 · Dong 批准david6666666 commentedon Nov 6, 2026
回复 v0.3（按决定编号）。对照 main
1246348f，与 v0.3 同一基线。我此前整理的观察多数已被 v0.3 吸收：测量协议归 B、生成与检查分成两次 attempt、
required_evidence在执行前冻结、检查按 producer kind 区分出处、持久信封带schema_version、预算三类对象、dashboard helper 先下沉到 W records。以下只列增量。结论：不存在阻止冻结大结构的分歧；A-1、A-2、A-4、B-1 可直接写进 S1 的交付物，不需要在启动 S1 前另行解决。A（D01/D02/D07）：同意，补四项
tools/需要在 S1 的「包边界及字段 owner」里定位（S1）。 它被 MANIFEST.in 排除在 wheel 之外，却承载预算账本和 SkillEval 控制器：skill_eval_compare.py1,138 行、自行写 verdict，skill_eval_pr.py由 CI 以python -m tools.skill_eval_pr调用；现有边界测试只扫src/inferrsi下三个平面。建议 S1 写明它算 Apps（受「不产生另一套循环、预算规则或 grader」约束），还是 repo ops（不进发行物，但纳入同一方向规则），并写清tools.skill_eval_budget*迁入 W 后 wheel 内容如何变化。这与安装评审第 2 点的资源对等核对相关。harness/evaluation.py。skill_eval_engineering.verify（S2/S3）。 它是包内代码（不含data/）中 infra 之外唯一自行起进程的地方（bwrap 沙箱，rlimit，无宿主回退）。建议评分语义归 B，沙箱隔离作为 W 的required_capabilities，不支持时启动前拒绝，与 v0.3 的 not_started 规则一致。另：dashboard helper 下沉到 W records 时把STAGES一起带上，它目前在dashboard_data与optimization_log各定义一份，campaign_trace也从 dashboard 取。作为 Add offline and live optimization workflow dashboard #319 的提交者，我同意 v0.3 §5 对这一簇的落点。tools/），组间允许关系构成 DAG，逐条检查直接边就能保证传递合规。缺的是覆盖面，外加包内唯一一处动态加载runpy.run_path（加载 request_guard），列入白名单即可。runner → evaluation、inspection → catalog、skill_evaluation → knowledge_operations 三条已知越界边先进带 issue 链接、只减不增的白名单。B（D03/D04/D05）：同意，补两项
inferrsi-json-v1只能有一个实现（S1）。 main 上现有三个编码器都不满足 v1：infra.artifacts.digest与anthropic_agent.canonical对同一个含中文的值算出不同摘要（后者转义非 ASCII），knowledge_operations._json接受 NaN，三者都不拒绝浮点。S1 应新增一个叶子实现加 §8 要求的 fixture，不复用其中任何一个。这正是 v0.3「确有共同消费者时抽取」的情形：B 产出protocol_digest与 assessment 编码，W 产出request_digest与记录摘要，Apps 保存时生成 ArtifactRef。test_runtime的 source changed 改写，A08 对应 termination_failed，A11 对应test_trial_checks，A13/A14 对应test_bundle_manifest与test_knowledge_store，反例 4 对应test_skill_eval_budget。C（D06）：同意分维度表达，补两点（K owner / S4）
check_vllm_ascend_source_anchors.py是现成的离线原型。skill_library依赖摘要，任何 skill 编辑都会让它们一起换 revision。由此 CampaignPlan 钉住的知识 revision 在升级后按 package 读取会失败（「Historical revisions require the matching installed snapshot」），除非存入 store；离线复核依赖 W 留存的交付快照，建议在 A13 写明。D（D08/D09）：同意，补一处兼容细节（S5）
旧
run的退出码 2 同时表示 INCONCLUSIVE 和参数/前置检查错误。wrapper 可以保留，但新 Apps 入口不要继承这个映射，否则 §7.2 表格里分开的 not_started 与 INCONCLUSIVE 会在进程边界上重新合并。D10
#357 明确说
anthropic_edit_agent.py作为通用适配器有意保留，留待维护者另行决定；它在包内与tools/中已没有其他调用方，EDIT_KIND拒绝分支和 model README 的 edit 一节也还在。建议在 D10 记录里给出去留，或单开 issue。核查范围：main
1246348f的静态源码、文档与调用关系，编码差异用本地脚本核对；未运行测试、CI 或实验。本评论不授权迁移、实验或合并。由 coding agent 协助整理。Dong1017 commentedon Nov 6, 2026
v0.4 方案收敛：固定三模块职责，将实施细节落到 S1–S5
根据 v0.3 接口稿、zengchuang 的 A/D 评审 与 David 的 A–D 评审，本轮采用下列方案。当前没有收到阻止大结构冻结的具体反例，建议维护者接受 A–D，并据此启动 S1。 Amy 尚未对 v0.3 回复，不记录为默认同意；评审支持与维护者最终接受也分别记录。
以下条款覆盖 v0.3 对应部分，其余接口定义保留。本轮是设计收敛，不表示源码已迁移或验收已完成。
一、收敛为四项决定
PreparedRef / RecordRef / AssessmentRef、W 分配的 attempt、实际输入绑定、不可变记录修订；执行事实与评测结论分开，预算容量/实际用量/资源租约分开；Agent 生成采用 plan → W.execute → collect。Apps 是独立组织的应用入口与装配层，可以有独立目录、Python 包和维护责任；首期四者由同一
inferrsi发行物交付。 三个核心模块互不导入，包括彼此的 DTO；Apps 在边界转换并装配消费方定义的端口。优化循环、知识选择和评分规则各有唯一负责模块。维持 9 组公开接口、19 组内部职责，不因这轮评审再增加抽象层。二、将评审增量落为明确选择
1.
tools/按职责拆分，S1 建完整归属表。 CI、发布和仓库管理入口属于 repo ops，可留在发行物外；可发布的应用入口属于 Apps；预算政策/账本/执行核心属于 W；任务协议/结果解释/判分属于 B。不能将整个目录归 Apps，也不能因为它在 wheel 外就豁免依赖规则。tools.*可保留必要的薄兼容包装。S1 列迁移目标、旧调用方及 wheel/ZIP 影响，S2/S3/S5 再迁移对应实现。2. 同步修改 agent 入口规则，保留两个坐标轴。
change_plane表示候选修改哪个 Harness/Model/Infra 平面；owner_module表示能力属于 K/W/B/Apps，不能机械替换。S1 同步 AGENTS.md、contributing 和 architecture：保留一次迭代围绕一个假设、一个声明平面的意图，并明确 候选不得修改评价本次候选的冻结 Benchmark、worker、grader、参考输入或协议。Benchmark 自身维护可另立有版本的任务。AB/BA 属于具体任务的 B 协议，W 执行该协议；不再强制给 MoE 等任务外套通用 AB/BA。3. 补齐包内执行与记录归属。
skill_eval_engineering.verify的测试向量与评分语义归 B，沙箱、rlimit 与进程控制归 W，并声明required_capabilities。已知隔离能力不足且候选尚未启动时，持久记录not_started，不回退宿主执行；若已有部分执行，保留事实，不能倒改为未启动。preflight 探针及消耗也留存。STAGES统一由 W-RECORD 定义，dashboard/campaign 读取它；保留原有活动阶段语义，不与 attempt 执行状态混并。4. 采用一个新的
inferrsi-json-v1叶子实现。 B/W 拥有各自语义投影，Apps 用相同编码保存字节并计算产物摘要；该实现不导入业务模块。现有三个编码器均不能直接当作 v1。S1 固定 Unicode、拒绝浮点、十进制负零规范化、拒绝重复键和无尾随换行等 golden fixture。不顺带改变 Knowledge、旧 agent 或历史产物的现有摘要规则。5. Knowledge 复核看相关来源与适用条件；历史复现靠真实留存。 不将“pin 不等于上游 HEAD”或共享资源引发的 package revision 变化直接当作失效依据。现有 source-anchor 工具可复用为离线校验原型，后续复核仍需核对相关定义、片段与适用条件。升级后旧 package pin 可能明确不可读；A13 必须验证原安装快照，或 W 留存的实际知识交付内容及所需资源快照能支撑离线复核。若走 store，使用其自己的 authority/pin，不静默把 package 引用改成 store 引用；未留存的资源仍算缺失证据。
6. 导入边界检查完整覆盖，同时约束允许关系图。 根模块、兼容转发、
tools/均需归组，直接依赖边逐条检查；固定动态加载列明调用点、目标及用途。这里修正一个论证：DAG 只保证无环，并不保证核心隔离，例如 W → bridge → B 仍是无环图。因此允许关系图本身还必须不存在经 bridge/legacy/shared 到另一个核心的路径。现有越界边登记精确例外、issue、owner 和退出条件，只减不增；有例外时不宣称目标隔离已经达成。不引入通用全仓传递闭包框架。7. CLI 保留兼容，同时给新入口明确结果语义。 旧
run保留原退出码映射；新 Apps 入口用版本化结果信封分别表达请求/准入结果、执行状态、固定记录引用和评测结论，不继续把参数错误、未启动、INCONCLUSIVE 全压成同一个 2。具体数值表及优先级由 S1 固定，S5 实现。not_started与INCONCLUSIVE可以同时成立；退出码只概括主要操作结果，完整事实以信封为准。三、S1 固定兼容责任；迁移切片验证实际行为
按实际受影响的消费者验收。 直接迁移宿主，或改动它使用的共用 CLI、launcher、打包器，都必须把该宿主纳入验证；不能因宿主目录未改便排除。S1 固定各产物的必需资源、摘要、允许的宿主差异及获准分发范围，迁移切片再核验实际 wheel / 插件 ZIP。安装、选择、升级、只读入口、session/取消/清理证据要关联产物版本与宿主环境。S1 不要求提前做完全部宿主实测。
18 项验收矩阵维持不变并补足上述含义；优先沿用 runtime、trial checks、bundle/store、budget 等已有回归中的行为用例，避免另写一套只重复字段定义的测试。
四、YAML 契约修正，仍由 #365 / #152 独立推进
load_task_document安全解析及原文检查；normalize_task应用允许的覆盖/默认值并按 origin 解析路径；validate_task校验生效任务与操作完整性；preview_task只展示结果与缺项。冻结门槛和执行准入继续强制。--task默认拒绝，验证后开放。 task: support shared YAML task input for the InferRSI CLI and agents #365/[RFC] Agent plugins: a consistent InferRSI workflow in Codex, DSH and openJiuwen #152 接入时，对解析后的生效路径、脚本与执行限制完成同等检查及越界拒绝用例，再开放该组合。这是未来组合路径的约束，不宣称当前已证实漏洞。schema_family暂不列为 core v1 必需字段。 按 #365 当前schema_version提案推进，族名有实际需要再由该 issue 决定。这些任务可沿现有入口独立推进；消费新模块组合时再声明实际依赖，不统一等待 S1 或 S5。沿现有入口推进的任务在原 issue 列自己的消费者、资源和依赖清单，遵守同等验收规则。
五、开发顺序与本轮收口范围
三模块迁移：S1 契约与兼容基线 → S2 Workbench / S3 Benchmark / S4 Knowledge 并行 → S5 Apps 装配。
S1 的实际交付物是：完整模块归属/依赖表、公开 DTO 与错误/编码 fixture、agent 开发规则、兼容责任表、发行物/消费者资源清单、分阶段验收矩阵。上述细节属于 S1 的工作，不要求在启动 S1 前再开一轮把所有字段和实现先做完。
anthropic_edit_agent暂留兼容，不发展成新模块/接口。另列清理任务核实公开消费者后，一并决定适配器、EDIT_KIND分支与 README；不能仅凭仓内无调用就宣布死代码删除。365 项全量映射继续保留 2026-11-06 15:17:08（UTC+8） 的独立清单快照；本轮更新设计与接口说明，不改写历史 issue/PR 状态。本条和更新后的 HTML/JSON/XLSX 是后续拆解的收敛依据，源码迁移、实验和验收由后续实施任务交付。
Dong1017 commentedon Nov 7, 2026
@Dong1017 Which gaps remain to be discussed in this issue for new arch?
cursor commentedon Nov 7, 2026
Two gaps are still open on this issue. The other new-architecture topics are already written into the v0.4 recommendation or assigned to other issues.
Still to close here
Maintainer acceptance of A–D is not recorded. v0.4 recommends accepting them and starting S1. Reviewer support and maintainer acceptance stay separate; v0.3 says silence is not acceptance. The four items waiting on an explicit accept, or an amend with a counterexample:
inferrsidistribution. B owns the measurement protocol and task workers; W owns the optimization loop and controlled execution.PreparedRef/RecordRef/AssessmentRef, attempt binding, immutable record revisions, execution facts separated from verdicts, three budget facts,plan → execute → collect.statusproposal in §7.4.Amy’s review of v0.3/v0.4 is still unanswered (request). v0.4 records that missing reply as non-consent, and still asks for B (handoff and recovery) and C (split knowledge-status dimensions). The same comment says that missing reply does not block the recommendation itself. zengchuang (A/D, 6681543890) and David (A–D, 6682022266) already replied; both said they have no counterexample that blocks freezing the large structure.
Already settled in the v0.4 text (S1 writes it down; v0.4 asks for no further pre-S1 architecture round)
STAGEShas one W-RECORD definition.01c73521, reservation occupies the cap (Ledger.charged/worst_case); unknown actual cost stays null (budget note).tools/and shims, and an allow-graph with no core-to-core path through a bridge. Exceptions shrink only. v0.4 does not add a general transitive-closure framework.--taskstays closed until task: support shared YAML task input for the InferRSI CLI and agents #365/[RFC] Agent plugins: a consistent InferRSI workflow in Codex, DSH and openJiuwen #152 checks the resolved path.Tracked outside this issue
schema_family, and DSH.anthropic_edit_agent,EDIT_KIND, and the model README wait on a separate cleanup task.A later objection needs a clause id (A/B/C/D), the replacement wording, and a call path, missing field, recovery counterexample, or compatibility break. This reply is from the issue body and the thread through 6704299759; tests were not re-run.
Dong1017 commentedon Nov 7, 2026
三核心 + Apps：模块设计与迁移补充
代码基线
main@3a67f2456156f1071d4821e172a5bb55393f3f08；对照 v0.3、v0.4。现稿已有接口和职责表，缺的是模块级可实施差异、契约及测试映射；以下目标尚待接受。图均为 proposed；“调用”为接口调用，“数据”为返回/字节交接，不是 import；迁移边只表职责映射。三核心互不导入或直接调用，DTO 由 Apps 转换，不共享类。Knowledge 负责来源读取语义，不拥有 checkout 文件生命周期；记录由 Workbench 生成保存，Apps 只归档 prepared/assessment 并绑定 RecordRef。
整体目标
flowchart TB subgraph AppsLayer["Apps"] A["Bridge / DTO 转换 / 展示"] AR["prepared 与 assessment 归档"] A -->|"调用归档"| AR end subgraph KnowledgeLayer["Knowledge"] K["Reader / Writer / catalog"] KS["store：sqlite"] K -->|"数据：读取；受控写入"| KS end subgraph WorkbenchLayer["Workbench"] W["执行 / 协调 / 读模型"] RS["RunStore：记录与留存证据"] W -->|"数据：提交 / 读取"| RS end subgraph BenchmarkLayer["Benchmark"] B["prepare / assess / 任务规则"] end A -->|"调用公开接口"| K A -->|"调用公开接口"| W A -->|"调用公开接口"| B B -->|"数据：prepared / worker 配方 / result"| A W -->|"数据：固定 RecordRef 与 record"| A四模块内部图、统一迁移图与完整交接（6 图）
D2 Knowledge 内部
D3 Workbench 内部
D4 Benchmark 内部
D5 Apps 内部
D6 统一迁移：职责映射，非调用
D7 完整交接与后续循环
sequenceDiagram participant A as Apps participant B as Benchmark participant W as Workbench participant R as RunStore participant Arc as Apps ByteArchive participant C as CampaignCoordinator participant P as CandidateProvider A->>B: prepare break prepare 失败 B-->>A: 返回失败；不进入交接 end B-->>A: PreparedEvaluation / worker 配方 A->>Arc: archive_prepared(prepared bytes) break prepared 归档失败 Arc-->>A: 失败；无 PreparedRef end Arc-->>A: PreparedRef A->>W: allocate_attempt break 身份分配失败 W-->>A: 返回失败；不启动 end W-->>A: AttemptContext；不占预算 / 不启动 A->>A: bind_execution 核对 prepared / AttemptContext；构造 spec break 绑定核对失败 A-->>A: 拒绝交接；不写 RunStore end A->>W: execute(ExecutionSpec，含 worker 配方) break 启动前持久化失败 W-->>A: ExecutionPersistenceError(started=false)；无 RecordRef end break 准入拒绝 W->>R: 提交 not_started 修订 break not_started 持久化失败 R-->>W: 失败 W-->>A: 无已提交 RecordRef end R-->>W: 固定修订 W-->>A: not_started record / RecordRef；不是成功测量 end break 控制器结果未知 W-->>A: RecoveryRequired / 最后已知修订；不取消、不自动重跑 end W->>R: 提交完成修订与留存证据 break 提交失败 R-->>W: 失败 W-->>A: 不返回成功完成交接 end R-->>W: 固定 RecordRef / record 字节 W-->>A: 固定 RecordRef / record 字节 A->>A: 核对 prepared / attempt / 候选 / record 固定修订；组 EvidenceInput break 证据核对失败 A-->>A: 拒绝 assess end A->>B: assess(prepared bytes, EvidenceInput, retained bytes) Note over B: 不启动进程；不访问 current/latest break assess 失败 B-->>A: 返回失败 end B-->>A: EvaluationResult A->>Arc: archive_assessment(result bytes, 固定引用) break assessment 归档失败 Arc-->>A: 失败；无 AssessmentRef end Arc-->>A: AssessmentRef opt 完整成功交接之后的独立后续循环；非首期真实 Agent 验收 A->>C: 注入 CandidateProvider / EvaluationPort / ContextProvider 实现 Note over C: W 定义端口；Apps 适配核心，无核心直接调用 C->>P: plan_generation break 生成计划失败 P-->>C: 返回失败 end P-->>C: GenerationPlan C->>W: execute break 执行未完成 / 未启动 / 结果未知 W-->>C: 停止此轮；不 collect end W-->>C: 固定 RecordRef / record C->>P: collect_candidate P-->>C: 候选或失败；不自动重试 end通用 CandidateProvider 有草案，KDA / SOL 专属 adapter、流程与验收仍 TBD。Collection 新分组未冻结；Writer 的 update 使用 expected revision CAS，create 受 candidate 限制，history 只读。allocate 只分身份，bind 不写 RunStore；not_started 可有自身 RecordRef，但不进入成功测量判定。未知结果进入恢复，不当作取消成功。读模型同时核对 trace 主张和留存证据，STAGES 由记录侧提供、经 Apps 展示。
验收优先覆盖重复请求、报告失败、归档失败、固定修订错配和缺证据；首期仍一个发行物。未跑完整 pytest、真实 SSH/GPU 或干净安装。S1 先契约与夹具，再模块并行，最后 Apps 装配，不先搬目录。