多 Agent 文档 · 与实际不符清单 v1（2026-09-19 01:2x，基于首跑实测） 口径：拿 2026-09-19 的首个真实任务（hermes-wear 拆页，Hermes delegate_task 编排）当样本，逐条对两份文档。 判定标准：**这份文档描述的前提，我们这里是否真的存在**。 ──────────────────────────────────────── 一、已处置（今天已改，均有 .bak_pre_realign_20260919 备份） 1. 【改】手册 0.3 本机实测值 - 可用内存：常态 490MB → 660–770MB（mask 掉 fwupd/packagekit/multipathd 后 +175MB） - 无 swap：标为“2026-09-19 复测确认；加 swap 须人工批准” - 无 Docker：标为“2026-09-19 复测：docker / podman 均不存在” - 磁盘：补“根分区 40GB，剩约 26GB” 2. 【加】流程文档新增〇bis 节「起步期实际口径」 把 20+ 处“由 Code 层执行/判定”统一声明为**目标态**：没有编排器、SQLite、文件锁、worktree 隔离、预算熔断、reviewer JSON 比对、Checkpoint 拦截；并附首跑计划 vs 实际对照表。 3. 【删】流程文档第六节：⑤data-worker / ⑥deployer 两类 + 附录 A 两个返回 schema 理由：本机无容器运行时、无数据库、无部署目标 —— 这两类的前提一个都不成立，留着会诱导“照六类跑”。第六节改为“定义 4 类，起步启用 3 类”。 ──────────────────────────────────────── 二、待你拍板（我没动，因为删它们会丢掉路线图；但按“符合实际”的标准都该改） 4. 【建议改，别删】12.1 指纹标定（10 任务 × 3 类故障 → 30 样本 ≥90% 准确率） 前提：一份 10 个典型任务的回归语料 + 可注入 3 类故障的 harness。 实际：真实任务数 = 1，harness 不存在。 建议处置：整节加【起步期不执行】标记，起步期只统计「L1/L2/L3 出现次数 + 人工介入次数」三栏；语料攒够再启用标定。 为何不直接删：这是唯一定义“指纹粒度该多细”的依据，删了就只剩拍脑袋。 5. 【建议改，别删】九节 Checkpoint 表的 SLA / 责任人 / 授权有效期 前提：一个组织（有 owner、有 4 小时 / 1 个工作日的响应，有计时器落实超时动作）。 实际：单人项目，唯一的“人工”就是你自己，且没有计时器 —— “超时默认拒绝并挂起”不会自动发生。 建议处置：该三行改为“单人项目不适用：checkpoint 只作待办提醒，人工当场处理，不阻塞、不自动放行”。 6. 【建议改】Phase -1 的 ROI 公式（人工工时 × 人工时薪）与起步阈值 3~5 前提：人工有可折算的时薪。 实际：无时薪口径；真实成本是 API 额度（你自己的跟踪工具已能给准确数字）。 建议处置：改成“token/额度消耗 + 人工介入次数 + 等待天数”三栏记录，阈值留空待实测；不删公式，标为“有外部客户时启用”。 ──────────────────────────────────────── 三、明确建议**保留**（不依赖 Code 层也能用，是文档里最保值的一层） - 三节 Brief 方法论（两个独立 / 派发前五问 / 反作弊条款）—— 本轮虽然没按它写 brief，但它描述的是“好 brief 长什么样”，成本为零、随时可用。 - 五节失败阶梯与逃生舱（L0–L3、妥协/顾问/旁路三选一）—— 没有 Code 层时就是人工判级，照样能用；本轮没触发只是没遇到连续失败。 - 十节高腐化区结构 + 回流读取 —— 前提只是“记账”，一个人也能记。 - 八节避坑清单 —— 逐条都经得起我们这里的实际检验（如第 6 条“多 agent 消耗 15–50 倍”）。 ──────────────────────────────────────── 四、一条不在文档里、但本轮证明最该补的（零成本） 派活前先声明**文件所有权**，并在派发前查一次 `git status`： - 本轮踩到的唯一真坑是“同 worktree 无锁并行”，过程中出现 3 次“该文件已被其他 agent 修改”的告警； - 手册 1.3 已有“禁止多任务共享同一 worktree”的条款，但起步期没有执行者； - 在 Code 层做出来之前，用“一句话声明 + 查一次 status”把这条兜住，比任何文档修订都值钱。