让生产按规则连续执行，
让 Agent 处理需要判断的变化。
存在流程臃肿，主要集中在重复协调、重复核对和工程任务缺少生产接续；不是现有四阶段生产链整体需要推倒重来。调整方向是收拢职责、明确运行范围、复用证据，并将修复与稳定生产隔离。
最新状态已变化：用户于 03:49 授权正式大规模生产，负责人正在准备 e2-glm53-scale24-20261104，报告 22 个镜像可用、2 个标签不存在。此前“旧窗口结束、没有新窗口”的诊断不能继续作为当前全部状态；准备启动也不等于新产率已验收。
哪些需要精简，哪些必须保留
| 问题 | 具体表现与责任 | 调整 |
|---|---|---|
| 协调回合过多 | 我对已核实的解释也追加独立核对；多轮读取相同上下文、再产报告，增加了控制工作的模型调用。这不是新的生产产出。 | 确定性任务直接跑现有脚本；同基线结论复用。复杂审查只分独立问题，不固定套“规划→执行→审查→再审查”角色链。 |
| 工程任务缺少回到生产的条件 | 我给 Flake8 的任务只包含 CPU 回归；36 项测试耗时 0.822 秒，真实环境资格却另待安排。代码通过与业务可用之间留下了空档。 | 派发时一起定义代码、必要的真实验证、已有授权范围、交付后如何启用。预算缺项一次列齐，而不是每过一层再等待下一层。 |
| 监督容易成为第二个调度者 | “每轮挑一个工程问题”可能把监督变成不断生成修复任务；30 分钟操作超时也不等于目标执行停止。 | 先读一次权威汇总；只有新异常或指标越界才通知唯一负责人。相同缺陷与操作不重派；周期检查不成为生产接续屏障。 |
| 停派与排空没有自动接续 | run_bounded 到期退出循环，在 finally 暂停协调器并 halt campaign；只记录尚在途的作业。已运行求解可能继续，但后续判分/准入需要额外收尾接续。 | 在原控制器内明确“运行 → 停新派发并有界排空 → 关闭”。排空不启动新来源或新 solve；原调用预算继续生效，未知执行仍对账。 |
| 多个入口同时解释运行状态 | 生产账本、阶段表、作业租约、会话、HANDOFF 和 HTML 的含义不同。旧页面曾以历史库存或 halted 快照充当“当前状态”。 | 一个运行状态有明确权威来源，其他视图只派生展示。保留不同层的数据库，但不让文档或会话消息回写业务终态。 |
| 清理越过资源所有者 | 我曾按低 CPU 和无连接停止共享服务，随后又恢复服务及挂载路径。没有证明清理提高产率。 | worker 或服务所有者负责退出和回收；监督发现疑似残留后交所有者对账。以任务归属、启动身份、终态及依赖证明决定清理。 |
| 证据和文档反复扩张 | 报告曾膨胀到约 113 KB，旧批次、旧方案与当前结论混在一起；后来已清理。报告发布还消耗额外工程时间。 | 原始收据保留，汇总用同一入口生成；页面保留当前结论和证据指针。文档同步是交付动作，不放进逐来源生产关键路径。 |
应保留：来源与家族隔离、去重、独立官方判分、公开 probe、token 对齐、loss mask、P0 身份绑定、预算、租约、未知执行对账及撤销链。来源级质量门、协调器预留和启动前复核位于真实边界，并非“检查多就都该删”。
外层工程协调与求解器内部模型调用是两类开销。减少不必要的 Agent 协调，不是删除教师求解、必要的 probe 撰写或独立数据判分。
目标结构：沿用现有运行器，收拢控制职责
发布后独立抽检；监督读取事件/汇总，必要时通知负责人。二者均不增加正常来源的串行 Agent 审批。
生产控制器
现有入口：storage/e2_pipeline.py
按冻结来源和预算推进四阶段。小批汇报作为运行中的检查点；只在已授权范围内接续，不能在旧窗口终态后暗中重置额度。
点选节点查看职责。图是目标职责划分，不表示新增一个框架。准备驱动仍可作为现有控制器的子组件；不需要为了统一职责先合并文件、数据库或引入消息总线。
每种状态只有一个权威解释
| 状态或决定 | 保留的权威入口 | 其他组件的边界 |
|---|---|---|
| 来源、一次尝试、预算与结果 | e2_queue / campaign 账本 | 流水线引用来源身份与结果；会话和报告不能自行重置尝试、追加来源或改判分。 |
| 下一阶段与阶段依赖 | e2_pipeline / pipeline 状态 | 准备驱动只提交准备子步骤和产物，避免另维护一套业务完成定义。 |
| 作业、资源预留、租约 | orchestration.Coordinator | worker 接受租约后启动，临启动再检查真实资源。短时资源变化不是删掉第二道检查的理由。 |
| 进程/容器实际生灭 | 启动它的 worker 或服务所有者 | 使用已有收据记录 job/run、PID+创建时间或容器 ID、共享依赖。常驻服务与逐题环境分开管理。 |
| 准入、撤销和库存 | 原自动准入/发布入口；e2_admission.scan 派生汇总 | 独立判分与原始收据保持。READY、HTTP 200、transport succeeded 和 admitted 不混用。 |
| 面向用户的进度 | 上述数据的只读汇总，附 run/版本/观测时间 | HTML、HANDOFF、监督报告都不是第二本生产账；过期快照明确标时间。 |
因此，一个负责人不等于所有模块合成一个大程序；一个权威入口也不等于把三个数据库硬合成一个。要消除的是重复决定同一件事、跨层直接改状态和重复全量扫描，不是删除持久化与恢复语义。
按收益排序的最小调整
- 优先一：先改任务闭环，不等代码重构。
每项修复同时约定“实现 → 针对性回归 → 必要的一次真实验证 → 原入口接续”。当前已经授权的新批次继续按冻结范围推进；单来源缺陷单独修复，不要求所有历史问题清零。工程版本与正在运行的冻结版本隔离。
- 优先二：在原控制器内补全截止与排空。
针对
e2_pipeline.py:796的run_bounded，把停新来源/新 solve 与推进已开始求解的判分准入分开；显式限制排空时间并计入完整墙钟。截止、取消、共享故障和来源耗尽各自保留终态原因，不能一律当作“pause 后等 Agent 接手”。原四来源 01:40 的结束是全部终态，不是被截止中断；这里指出的是“截止时仍有在途工作”的结构性缺口，未量测其造成的总耗时。
- 优先三：收拢重复状态解释与失败分类。
复用自动汇总，一次读取 run、来源、stage/job、预算和待对账原因。将
e2_pipeline.py:298周边的暂停决定按作用范围收拢：有停止、清理及用量证据的源局部失败可局部终结；未知执行、共享身份变化和用量不明仍停派并保留预留。已有零调用失败隔离复用，不另建第二套分流。 - 优先四：统一资源门内的调度与生命周期。
已存在的 finish 优先和 ready 派发不重写。先测后处理等待究竟来自排队、内存还是暂停，再决定是否加有限优先级。所有者在 finally/终态回收自己的临时资源；共享服务以引用与冻结依赖判断保留。
- 后续再做：按实测收敛轮询和重复读取。
已完成收据只在恢复或变化时读取；候选/ready 的展示结果可缓存，真正派发仍复验身份。先记录每 tick 扫描量与耗时，再改热点。保持现有短轮询也可以，只在状态变化时通知 Agent；无需先把所有循环重写为事件系统。
本轮不会热改正在准备的 scale24 批次、修改其预算或替换运行中的 producer。先在独立工作树完成调整和验证，再选择明确的版本切换边界。
把任务写成可完成的交付
工程修复任务
监督任务
30 分钟监督可作为兜底，但不负责接续每个来源。能由既有 worker/控制器完成的状态检查与汇总不调用模型；工程 Agent 仅在确实需要判断时介入。
有界运行把来源集合、请求/token、时间与资源上限一次确定；运行中的小批可只作检查点。在这个已授权范围内按 ready 接续，不把每次汇报变成新的启动许可。达到上限后如实结束，后续范围需要另立合同，不能拿未用完的请求数补新来源。
用这些变化验收架构调整
| 维度 | 建议的验收方法 | 不能替代它的数字 |
|---|---|---|
| 协调开销 | 分别记录外层工程会话/模型调用、排队与执行时间；固定合同下正常命令阶段不依赖外层 Agent 回合。与同口径基线比较。 | 总进程数、角色名或“少用了几个 Agent”。 |
| 接续能力 | 受授权窗口内，有合法 ready、空槽且资源门满足时可继续派发；Agent 汇报尚未结束也能推进下一来源。 | 只启动了控制器，或只修改了任务提示。 |
| 修复交付 | 受影响路径一次针对性回归；涉及真实环境时在预先确定的范围内验证资格，再沿原入口启用。已通过的相同 hash 证据复用。 | CPU mock 通过就宣称容器恢复，或反复重跑不变的全量测试。 |
| 状态与回收 | 源局部失败不扩大为无关任务停派；未知执行不重复启动；结束时临时资源有对应停止收据，共享服务仍健康。 | 会话 completed、无连接或 CPU 为零。 |
| 实际产能 | 用当前冻结协议的完整墙钟与有效监督 token 判断吞吐和稳定性，同时报告准备通过率、官方通过率、准入和撤销。旧 60k/h 目标需与当前合同核对。 | 缩短统计窗口、恢复窗口高分、token 输出变长或跳过独立质量门。 |
依据与实施边界
版本、证据与尚未测量的部分
- 生产源码审查基线
f15e4dc7ee7a552dac99335bc6baf57d2612b10c；旧架构页来自文档基线7f898de，其中逐来源审查与初始资源参数已过时，本页不再当当前执行说明。 - 近期证据：
storage/audits/e2-throughput-diagnosis-20261104/current-status.json、生产分支的e2-no-agent-wait-20261104/acceptance.json、e2-flake8-isolation-engineering-20261104/acceptance.json及清理更正。这些是本地收据路径，不作为公开下载链接。 - 03:42 的停派快照与 03:49 后的新授权属于不同时间点。当前新批次的产出与性能仍须看它自己的执行收据。
- 精确代码入口：
e2_pipeline.py:796–905（截止、pause/halt 与结束收据）、e2_pipeline.py:298（停止策略）、e2_pipeline.py:753–757（报告路径反复验证 ready）、orchestration.py:191（资源与租约）、e2_prepare_driver.py:106（准备提交）。以上均按本页生产 SHA 定位。 - 本轮确认职责与静态重复点，未测得各层开销占比或重构后的加速倍数。新架构是建议，不将本文发布等同实现完成或生产准入。
- 独立判分读取 hidden judge/gold；任何工程审查、Agent 提示和公开报告都不读取或复制该内容。