[RFC] RSI 投机验证：覆盖推理引擎优化与 Agent/Skill 自我改进 #363

Current state: RFC 提案。提出覆盖推理引擎优化和 Agent/Skill 自我改进的 RSI 投机验证机制；尚未实现，未测量加速或质量收益。
Decision needed: 请 InferRSI 维护者决定是否接受“一个待验证父候选 + 一个投机后继”的首期范围，以及与 #249 共享调度、预算和资源管理的接口边界；具体实现与验收负责人待指定。
Next action: 维护者评审候选依赖、验证边界和交付切片；范围接受后，先完成两条链路的离线控制逻辑，再安排分别冻结计划的真实试点。

Goal and acceptance

当候选优化通过快速开发检查后，在其完整开发验证尚未完成时，允许在隔离分支中提前生成下一轮候选。父候选验证通过，后继进入正常验证；父候选失败，取消依赖它的工作并保留记录。最终采纳仍需独立验收。

目标是在完整验收标准不变的前提下，缩短得到合格候选的时间，并将无效投机的开销约束在冻结预算内。这里的投机单位是候选改动及其依赖，不涉及 token 级投机解码。

同时覆盖两条链路：

首期候选范围沿用对应适配器已有支持，不借此放宽 Skill 可执行内容、运行权限或产物执行边界。

每个 campaign step 仍只改变一个预先声明的 Harness / Model / Infra plane；投机调度不改变这项约束，跨 plane 改动拆成有明确依赖的步骤。

完成标准分为：可复现的软件契约、两条链路各自的真实试点证据，以及维护者对范围的接受。无收益或负结果可以构成完整试点结果；不预设正面收益或仓库统一数值门槛。

Scope and constraints

与现有工作的边界

• task: parallel optimization rounds with orthogonal lanes for multi-agent harnesses #249： 同一已验证基线上的独立候选并行、测量队列、资源租约和逐步组合。本提案增加的是依赖尚未验证父候选的后继探索及其失效传播。公共执行、预算、资源和记录机制应复用或共同扩展，不再建立第二个 runner/账本。task: parallel optimization rounds with orthogonal lanes for multi-agent harnesses #249 的在途实现不默认视为已具备或已通过资格验证。
• Proposal: controlled task-local harness improvement on top of Skill Eval #93： 复用已有 Skill 开发集比较、质量优先选择、组合后重跑和最终 holdout 纪律；多轮投机是新增范围，不将离线单步控制器描述为已有自主 RSI。
• task: connect engineering tasks to existing Agent execution and evaluation #337： 消费其支持的真实 Agent、任务产物和独立评测交接；不接管任务库建设或扩大当前产物执行资格。
• discussion: Knowledge / Workbench / Benchmark 三模块目标架构——现状、原语、交接时序与遗留问题 #362： 对齐其提出的 Knowledge / Workbench / Benchmark 边界。Workbench 管执行事实、调度和资源；Benchmark 管冻结判据与评分；Knowledge 的更新单独受控。该架构仍是提案，当前目录映射仅作为落点建议。
• discussion: what trace evidence should InferRSI persist beyond per-run artifacts? #333 / task: Dashboard 增强：每轮改动说明、动态 workflow 与耗时、测试进度 #345： 复用适用的事件关联与 dashboard 展示；叙事记录不能替代验证收据或控制器状态。

共用流程与状态

flowchart TD
    A["生成候选并通过快速开发检查"] --> B["完整开发验证父候选"]
    A --> C["隔离生成一个投机后继"]
    B -->|通过| D["推进开发基线，允许验证后继"]
    C --> D
    B -->|失败或证据不足| E["停止推进，取消或挂起依赖工作"]
    D --> F["搜索结束，冻结最终候选"]
    F --> G["一次独立最终验收：采纳或保留原版本"]

维护三个不同含义的引用：

首期仅允许一个正在完整验证的候选和一个投机后继。后继的完整验证等待父候选通过；初期只重叠候选生成和可隔离的快速检查。更深依赖链、多分支搜索、自适应投机深度和分布式租约留待后续。

验证阶段与两条链路的差异

• 引擎每步保留相对父候选的比较，最终候选直接对原始基线重测，不累加各轮百分比推导总收益。质量始终绑定冻结参考或绝对质量标准，避免逐轮容差累积。
• Skill 延续现有质量优先规则，不能以更少 token 补偿不允许的质量回归。组合后的候选独立重跑，不从组件通过推导组合通过。
• grader、参考答案、holdout、选择规则和控制器不属于候选可修改范围。若使用未验证 Skill 生成后继，记录其生成依赖；候选源码无依赖不等于提案依据无依赖。
• 开发证据可以反馈搜索。最终候选冻结后，holdout 只决定接受/拒绝；结束本次搜索，不根据其结果选择另一候选或反复测试同一 holdout。跨 campaign 的 holdout 非复用也需管理，不能靠新输出目录证明独立。
• 现有引擎 evaluator 的中位数/范围是描述性统计，不建立统计显著性。首期冻结重复次数，不根据中途好结果提前宣布通过；需要统计推断时另行定义并验证规则。

身份、失败与恢复

候选记录至少绑定：candidate_id、类型、父候选与生成依赖、产物身份、生产者上下文身份、比较基线、质量参考、计划与验证器身份。每次执行另有 attempt_id、代次、资源/用量和证据引用。

推进开发基线前，核对当前父依赖仍有效、验证绑定的实际候选/环境/计划匹配、完整证据通过，并原子更新引用。保留原始字节身份和适配器已有的操作/修改代次规则；内容 hash 不替代既有的 receipt 失效协议。

invalidated_dependency 是调度状态，不是新的验收 verdict。父候选失败不能伪造后继已被证明错误的 FAIL。现有 PASS / FAIL / INCONCLUSIVE 保留，并显式标注开发验证或最终验收范围。

资源与总预算

• 正式测量优先并独占其声明的资源域；必要时包括 CPU、内存带宽、I/O，而不仅是 GPU/NPU。
• 投机工作只能使用不干扰测量的资源。代码分析、远端提案和轻量检查也需按实际资源条件判断；不能默认“CPU 工作不影响 GPU 测量”。
• 独立 worktree 不足以证明运行隔离。校验实际加载的包、扩展、服务与依赖身份，复用并验证适配器已有执行隔离；构建/import/smoke 也属于相应执行边界。
• 所有尝试共享 campaign 截止时间和总预算，并为最终验收预留额度。引擎 runner 的每次实验 deadline 需要受 campaign deadline 约束。
• 并发任务在启动前原子预留适用额度；失败、取消和失效分支的实际消耗照常记账。外部支出/已消耗 token 与可释放的并发槽位、设备占用分别处理。
• 未知用量保持未知，不填零；按冻结策略停止新任务或限制主张。停止新任务的 token 阈值不宣称是供应商硬消费上限。
• 取消请求与实际退出、进程树清理和资源释放分别记录；未确认释放的资源不能重新分配给正式测量。

Inputs and deliverables

核查来源为 main 1246348f。这是设计依据的源码版本，不是实验 baseline/candidate pin。

新增能力是一个有界投机策略及两条验证适配链路。是否新增 harness/speculation.py 或并入 #249 的共享控制层，在接口评审时决定；不预设一套重复执行框架。最小语义包括冻结候选、快速检查、完整开发验证、最终验收和取消，具体接口遵守既有身份及执行契约。

交付切片建议：

1. 离线控制器： 两条链路的确定性 fixtures，固定一个投机后继，完成依赖、身份、预算、取消与恢复规则；不调用模型或加速器。
2. 真实适配试点： 引擎接真实 AB/BA 与质量检查；Skill 接明确支持的真实客户端和独立任务验证。分别冻结任务、模型、环境、重复次数、质量门槛及预算。
3. 后续策略： 只有在数据支持时，再提多分支、自适应深度和学习式排序；不作为首期完成条件。

可检查的完成清单

• 与 task: parallel optimization rounds with orthogonal lanes for multi-agent harnesses #249 明确共享控制层及增量范围，并形成两条链路的接口与支持矩阵。
• 两条离线链路覆盖父失败、依赖失效、迟到结果、身份变化、组合候选重跑及最终验收隔离。
• 验证并发预算预留、campaign deadline、重启不重复执行/不重置用量、取消与实际清理的差异；缺少平台资格时明确不支持或保留未验证。
• 快速检查不能冒充完整验证；开发通过不能冒充 campaign 通过；缺失证据不能产生通过结论。
• 引擎与 Skill 各完成一个受支持的真实试点，保留全部失败/取消/未完成尝试；不以脚本化固定输出代替真实 Agent 效果证据。
• 提供可复现入口、适用范围、已执行证据和限制，并由指定验收方记录接受或修订。

如何验证投机的实际价值

每条链路采用三个对照：①串行生成+完整验证；②快速筛选+串行完整验证；③快速筛选+投机后继。先用相同的预生成候选及固定依赖序列隔离调度收益，再做真实生成实验；后者会改变探索路径，报告为整体工作流效果，不能解释为纯并发加速。

记录到合格结果的总时间（未达到的运行也保留）、固定预算下最终质量/性能、模型调用与 token、设备时间、队列等待、投机失效率及浪费开销。预先抽定一部分快速淘汰候选进行完整检查，评估误杀风险并将审计开销记入预算。两种资源配置的对照保持一致；新增设备不能被隐藏成调度收益。

指标、重复次数、数值门槛和最终验收数据在具体 acceptance issue/冻结计划中确定。本 RFC 不声明任何已测得收益，不增加默认 CI 付费或设备实验。

Ownership and authorization

• Proposed by / actual requester: 本 Issue 提交者；按请求由 Codex 整理并提交，范围明确覆盖引擎优化与 Agent/Skill 改进。
• Status: Proposed。
• Accountable parent / slice implementers: TBD，由维护者在接受范围时指定。
• Goal-acceptance owner: InferRSI 维护者指定，具体负责人 TBD。
• Accepted decision or scoped delegation: 当前授权为提交设计提案；实现范围、真实试点预算、付费调用、知识晋升和合并沿用各自授权流程。本 Issue 不改变关联 Issue 的所有权或验收状态。

Completion and closure

• 由指定验收方核对交付清单与两条链路的证据后决定完成和关闭；软件测试通过、PR 合并和 campaign 验收分别记录。
• 待决定：与 task: parallel optimization rounds with orthogonal lanes for multi-agent harnesses #249 的最小公共接口、首期候选支持范围、取消/恢复资格、两条真实试点的任务与资源配置。
• 不包含自动知识晋升、自改 grader、holdout 反馈搜索、无限递归、目录迁移、自动代码合并或普遍服务收益承诺。