多 Agent 协作体系 · 上下文交接摘要 v1（2026-09-18 23:07）

==================================================
一、我们在做什么
==================================================
把《多 Agent 协作流程设计文档》+《多 Agent 工程实施手册》落成一套能在本机实际运行的多 Agent
任务系统，并验证其可行性（当前阶段：纸面评审收口 + 环境适配 + 准备首跑）。

==================================================
二、文档现状
==================================================
1) 流程文档（业务规则，唯一事实源）
   - 当前版本：v2.4.4（定稿锁版候选）
   - 已并入：A 组一致性硬伤 34 项（v2.4.3）＋ B 组 22 项补定义（v2.4.4）
   - 未并入：C 组 28 项工程子系统（已剥离到手册）
   - 待拍板：D 组框架级 4 项（不阻塞锁版）
2) 工程实施手册（C 组工程化）
   - 当前版本：v0.2.1 = v0.1 + 环境适配三节 + 三处事实修正
   - 新增三节：0.3 资源预算与单机运行限制／1.0 宿主与编排器层／2.1.4 无容器隔离降级路径
   - 三处修正：① 1.0 的 OOMPolicy 归因改为"属 service unit 属性、scope 上不支持"，
     并补回 OOM 自保（OOMPolicy=stop / OOMScoreAdjust=-500）；
     ② 6.2 rules.json 示例 max_workers 3 → 2；③ 1.5.1 版本字段对齐（v0.1 → v0.2.1）

==================================================
三、评审链（谁评的、结论在哪）
==================================================
1) 外部评审（gpt-5.6-sol）：87 条 = 逻辑漏洞 24 / 不可执行 21 / 缺失项 20 / 冲突 18 / 框架级 4
2) 该 87 条被分诊为 A/B/C/D 组，落在《Sol 复核处置分诊表》——该文件我们尚未获取
3) 元宝沙盒《可行性验证报告》：结论"有条件可行"，给出
   A 类 8 条阻断 + B 类 12 条定义缺口 + 3 处小不一致 + 2 处外部技术判断修正

==================================================
四、待处置清单 v1.1（最新）
==================================================
【置顶 T1（原 A7）：高危域清单不一致】
  手册 3.1.2 列 10 项，6.2 rules.json 只列 5 项，漏掉：密钥管理、审计日志、回滚脚本、
  隐私数据处理、安全中间件。全清单唯一的"静默放行"项：规则文件存在、解析成功、只是清单
  不全 → 插件正常 approve，不触发任何告警。启动前必修。

【A 类：阻断项】
  A1 重活去向需分档（附录 B 主示例在 600MB 下大概率 OOM；12.1 标定样例不可执行）
  A2 状态机枚举缺 running / needs_recovery / paused（escape_bypass 零出入边；escape_* 缺出边）
  A3 Checkpoint 键名不一致（checkpoint_timeout_actions vs timeout_high_risk_action）+ 超时无状态落点
  A4 版本绑定：值已修完，仅剩"改为运行时从 rule_versions 表读取"的机制改动
  A5 指纹标定冷启动不可达（2.7.1 要求 50% 历史真实失败；2.7.2 每类 ≥20 vs 12.1 每类 10）
  A6 全量类型检查与 Stress test 未纳入重活清单
  A8 max_workers 权威值不统一：手册 0.3 写"硬上限 ≤2"，流程文档三处仍按 3
     （已复核 v2.4.4 L214 起步期、L622 开放问题 4、L740 附录 B 批 2 均未改）

【B 类：定义缺口（不阻断启动）】
  B1 SQLite 未写 WAL / busy_timeout（默认配置并发写立即 SQLITE_BUSY）
  B2 reviewer 是否占 max_workers 配额未定义    B3 单实例 headless 与双 Reviewer 取证冲突
  B4 environment_image 在无容器档无意义        B5 deployer 类型在目标环境无实现路径
  B6 test-runner 例外计费无上限口径            B7 幂等键 attempt 无定义
  B8 "长期 100% 一致必须抽检"无阈值            B9 锁等待降级串行在当前环境无效果
  B10 灰轨"旧实现 100% 绿"前提不可达           B11 code-reviewer/debugger 返回 schema 未定义
  B12 开放问题未标注环境适用性

【小不一致】4.5.2 timestamp vs 附录 C created_at；4.6.1 manifest 只 2 个版本字段（1.5.1 要 6 个）；
  附录 D approve 分支缺 rule_id

==================================================
五、本机环境基线（实测，非推测）
==================================================
- 2 vCPU ／ 总内存 1.6GB（常态可用约 600MB）／ 无 swap ／ 无 Docker
- systemd 249（Ubuntu 22.04），已有 4 个 systemd --user 服务在跑
- node v26.8.1、npm 11.19.0、Python 3.12、git 2.34.1、flock；无 sqlite3 CLI（用 Python 模块）
- 编排器形态必须是：常驻进程（systemd service）+ SQLite 状态 + git worktree 隔离
- 关键限制：Hermes 子代理是内存态（/new、/stop、进程退出即丢），不能当任务状态存储
- 已端到端验证：插件 pre_tool_call 的 block 与 modify 两条硬拦截路径实测生效；
  注意插件异常默认 fail-open，要硬拦必须自己包 try/except 后显式 block
- OOMPolicy 实测：`systemd-run --user --scope --property OOMPolicy=kill` 失败；
  `systemd-run --user --property OOMPolicy=kill` 成功（service 支持、scope 不支持）

==================================================
六、尚未获取的资料
==================================================
《Sol 复核处置分诊表》（B 组 28 项 + C 组框架级 4 项在其中）——拿到后才能交叉核对
C 组 4 项与本清单 A/B 类是否存在重合。

==================================================
七、建议下一步
==================================================
1) 让对方复核手册 v0.2.1 的三处修正是否到位
2) 先修 T1（对齐 10 项清单 + 补一条回归断言）
3) 再修 A8（流程文档三处改 2，或反向确认 3 可用并同步 0.3）
4) 首跑一个小的真实任务（独立分支、max_workers=1），只记录"卡在第几步"