多 Agent 体系 · 待处置清单 v1.1
来源：《多 Agent 体系可行性验证报告（整合版）》（元宝沙盒，2026-09-18 晚）
基线：手册 v0.2.1 ／ 流程文档 v2.4.4（当前锁定候选）
变更（v1 → v1.1）：
  ① 原 A7 提升为置顶项 T1（唯一"静默放行"故障，独立于 A 类编号等权处理）
  ② A8 复核完成：v2.4.4 未修改起步期配置，A8 维持原判、不瘦身（见附注）
  ③ A4 按新版基线调整：头部"配套 v2.4.4"不再算错，仅剩机制改动
  ④ 事实核查补记：Sol 复核分节条数为 24/21/20/18/4 = 87（与流程文档引用一致）

==================================================
零、置顶项 T1（原 A7）：高危域清单不一致
【全清单唯一"系统自认为在防护、实际没防住"的项】
==================================================
位置：手册 3.1.2 列 10 项 / 6.2 rules.json high_risk_domains 只列 5 项
漏掉：密钥管理、审计日志、回滚脚本、隐私数据处理、安全中间件
危害：插件按 rules.json 判高危域 → 这 5 类不被识别 → 可默认落妥协模式 → 直接违反 3.1.2/3.1.3
关键：6.4 的 fail-closed 挡不住它——规则文件存在、解析成功、只是清单不全，
      插件会正常 approve，**静默放行，不触发任何告警**。
      对比：A1 跑不动会报错、A2 写不进会被拒、A8 超限会被拦——都能在运行时被发现。
      只有本项不会。
建议：以 3.1.2 的 10 项为权威源对齐 rules.json；6.8.2 回归断言新增
      "3.1.2 全量 10 项命中时均判高危"。启动前必修。

==================================================
一、A 类：阻断项（除 T1 外，按原编号）
==================================================

A8 max_workers 权威值不统一【部分已修；复核确认不瘦身】
  位置：手册 0.3 写"硬上限 ≤2"；流程文档仍按 3 设计
  复核结论（2026-09-18 23:0x）：v2.4.4 **未修改**起步期配置，三处仍在——
        · v2.4.4 L214：worker 上限 max_workers=3（起步期）
        · v2.4.4 L622：开放问题 4「max_workers=3 下的领导综合质量是否达标？」
        · v2.4.4 L740：附录 B 批 2「M2 → M3a ∥ M3b ∥ M3c（受 max_workers=3 约束）」
  本机已修：手册 6.2 rules.json 示例 "max_workers": 3 → 2
  待处置：① 流程文档全文按 2 重排（或反过来确认 3 可用并改 0.3）
          ② 明确 max_workers 上限的"唯一权威位置"
  后果：附录 B 批 2 三路并行在目标环境不成立；开放问题 4 要标定的配置不可用

A1 重活去向需分档
  位置：手册 0.3 / 流程文档附录 B / 12.1
  现状：2.1.4 已把"串行队列"与 CI 并列为合规路径（非死锁），但
        附录 B 主示例（80+ 文件迁移、Phase 6 全量 199 测试）在 600MB 下大概率 OOM
        → 12.1 标定要用的正是这类任务 = 标定样例本身不可执行
  建议：低资源档定义测试分档（只跑变更影响子集）；附录 B 增补"轻量档演算变体"

A2 状态机枚举缺项
  缺：running、needs_recovery、paused
  另有：escape_bypass 零入边零出边；escape_compromise / escape_advisor 只有入边
  后果：1.0 强制要求 6（子代理丢失置 paused/needs_recovery/blocked）写不进状态机
  建议：补齐枚举与出入边，迁移表同步

A3 Checkpoint 键名与状态落点未对齐
  键名：6.1 写 checkpoint_timeout_actions，6.2 实际是 timeout_high_risk_action
  落点：枚举里没有 checkpoint_timeout / hold 状态，超时后写不进状态机

A4 版本绑定【值已修完，仅剩机制】
  已修：手册 1.5.1 engineering_manual_version → v0.2.1；头部声明与当前锁定版一致
  撤回：报告原判"手册头部配套 v2.4.4 是错的"——按 v2.4.4 新基线，该声明正确，撤回
  待处置：按建议改为"运行时从 rule_versions 表读取"，文档只写字段名与取值来源

A5 指纹标定冷启动不可达 + 数字冲突
  冲突：手册 2.7.1（历史真实失败 50%）/2.7.2（每故障类别 ≥20）vs 流程 12.1（30 样本、每类 10）
  问题：冷启动时"历史真实失败"= 0；样本不足会系统性偏向 L2 逃生舱 → 提前堆技术债
  建议：把阶梯已有的冷启动模式（首次计入仅登记不判级）复用到 12.1

A6 全量类型检查与 Stress test 未纳入重活
  问题：0.3 重活清单只有"编译"、无"类型检查"；且措辞是"不得本地并行"，未禁止本地执行
        12.3 Stress test 是故意的资源炸弹，可能打挂编排器自身
  建议：把全量 tsc/lint 列入重活、轻量档改增量；Stress test 放进带内存上限的独立 cgroup

==================================================
二、B 类：定义缺口（不阻断启动，但会导致不可测试或运行时冲突）
==================================================

B1  SQLite 并发配置缺失：默认 journal_mode=DELETE + busy_timeout=0 → 并发写立即 SQLITE_BUSY
    建议写死：WAL、busy_timeout≥5000ms、短事务
B2  reviewer 是否占 max_workers 配额未定义（上限 2 而 builder+双 reviewer = 3，直接超限）
B3  浏览器实例与双 Reviewer 冲突（只允许单实例 headless，双 Reviewer 要独立取证 → UI 验收互斥）
B4  environment_image 在无容器档无意义（轻量档应可空，降级为独立目录+端口+env 文件）
B5  deployer 类型在目标环境无实现路径（0.3 禁容器构建 → 派发即失败，应在类型注册表标注禁用）
B6  test-runner 例外计费无上限口径（无公式，未说明记 Phase 池还是全局池）
B7  幂等键中 attempt 无定义（未定义递增主体与重置条件 → 重放保护失效）
B8  "长期 100% 一致必须抽检"无阈值（多少轮算长期、抽检比例都没写）
B9  锁等待 300s 降级串行在当前环境无效果（上限 2 本来就是串行）
B10 灰轨"旧实现 100% 绿"前提不可达（依赖完整测试套件；旧实现带 flaky 则永不满足）
B11 code-reviewer / debugger 返回 schema 未定义（附录 A 六类 schema 未说明复用 reviewer）
B12 开放问题未标注环境适用性（开放问题 4/5/7 与目标环境冲突，未注明需重设）

小不一致（建议顺手修）：
  · 4.5.2 记账事件用 timestamp，附录 C 表用 created_at
  · 4.6.1 manifest 只有 2 个版本字段，1.5.1 要求绑定 6 个
  · 附录 D approve 分支缺 rule_id（另两个分支都有）

==================================================
三、已修记录（手册 v0.2 → v0.2.1）
==================================================
1. 1.0 的 OOMPolicy 归因修正：不是"249 不支持"，而是 OOMPolicy 属 service unit 属性、
   写在 scope 上才报错（本机 systemd 249 实测双向验证）；补回 OOM 自保
   （OOMPolicy=stop / OOMScoreAdjust=-500）
2. 6.2 rules.json 示例 "max_workers": 3 → 2（与 0.3 硬上限一致）
3. 1.5.1 版本字段对齐（engineering_manual_version v0.1 → v0.2.1），头部版本声明同步

==================================================
四、事实核查（外部技术判断）
==================================================
· OOMPolicy：报告结论正确（service 支持 / scope 不支持），本机 systemd 249 实测已确认
· SQLite：WAL 只做到读写不互阻，任何时刻仍只有一个写者；
  busy_timeout=0 意味着拿锁失败立即返回 SQLITE_BUSY；生产建议 5–10s + 短事务
· Sol 复核条数核对：本机 review_by_sol.md 分节为 逻辑漏洞 24 / 不可执行 21 /
  缺失项 20 / 冲突 18 / 框架级 4 = 87，与流程文档引用数字逐项吻合

==================================================
五、不在本清单内的内容
==================================================
· 《Sol 复核处置分诊表》（B 组 28 项 + C 组框架级 4 项在其中）——尚未获取，无法交叉核对