多 Agent 项目 · 状态更新 v3（2026-09-19 01:2x）

## 一、本轮做了什么（首跑实录）

任务：hermes-wear「文件」拆成 本地管理 + 服务器取件 两页，并修 P1/P2（下载代际号 / 孤儿 .part 回收 / 提示自动淡出）。
编排：Hermes delegate_task（一个领导 + 2~3 个子代理），**没有 Code 层**（无编排器 / SQLite / 文件锁 / worktree / 预算熔断 / Checkpoint 拦截）。
交付：3 个 commit 推到 main（c653bf6 拆页与修复 / d2588ca 截图用例 + 文案 / b2939b4 状态行收短）+ 第四个待推（CI 发版号）；CI 三次全绿；APK 已发到公网下载页。

## 二、计划 vs 实际（流程文档〇bis 已收录同一张表）

| 文档的计划 | 实际发生 |
|---|---|
| 独立分支、max_workers=1 | 主工作区直接改、直接 push main；并行 2~3 个 agent |
| 每任务独立 worktree（手册 1.3） | 同 worktree 无锁并行；3 次“文件已被其他 agent 修改”告警 |
| 双 Reviewer JSON verdict | 无 reviewer；验收 = 静态核对 + CI（编译/出图）+ 人工看图 |
| Checkpoint ①②③ 拦截 | 无拦截；人类在对话里当场拍板 |
| Phase 1 先找现成 | 未执行 |

## 三、本轮暴露的真问题（按该不该改文档分两类）

A. **文档没错、是拦截者没实现**（不改条款，已在流程文档〇bis 声明“目标态 / 非现状”）
   1. 同 worktree 无锁并行 —— 手册 1.3 明确禁止，但没有执行者。
   2. 无预算熔断：子代理一次跑多久、烧多少，全凭领导自觉（本轮没有失控，属运气好）。
   3. 无 Checkpoint：该在该停的地方停（如“要不要直推 main”），实际是事后才补。

B. **文档该改的（已改 / 待你拍板）**
   - 已改：手册 0.3 本机实测值（内存 660–770MB、mask 掉 fwupd/packagekit/multipathd 后 +175MB、无 swap 复测、无 docker/podman 复测、磁盘 26GB 剩余）。
   - 已改：流程文档六节删除 ⑤data-worker / ⑥deployer（无容器、无数据库、无部署目标），并加〇bis 现状声明。
   - 待拍板：12.1 指纹标定（依赖 10 任务 × 3 类故障语料，实测任务数 = 1）、Checkpoint SLA（单人无组织、无计时器）、ROI 里的“人工时薪 / 起步阈值 3~5”（无时薪口径）。见《多Agent文档_失配清单_v1.txt》。

## 四、机器侧顺带（本轮实测）

- 可用内存 486MB → 768MB：停用并 mask fwupd（133MB）/ packagekit / multipathd（云主机上都没有用途），撤销 = systemctl unmask 那三个单元。
- 为做一次 Kotlin 语法检查尝试临时装 JRE + kotlinc，被内存压力否决并回滚 —— 再证“本机连纯 JVM 检查都不该起”，验证只能走 CI。
- 磁盘：根分区 40GB、剩 26GB。

## 五、下一步

1. 拍板《失配清单》里标“删/改”的三处（12.1 标定 / Checkpoint SLA / ROI 口径）。
2. 若继续用这套流程，起步期最该补的一条不是 Code 层，而是**派活前的文件所有权声明 + 派发前查 git status**（成本零、能立刻消掉本轮踩到的那个坑）。
3. Code 层（编排器/插件）仍未开工；在它存在之前，流程文档一律按〇bis 的口径读：条款 = 目标态。