搜索”multi-agent project management”，你会找到大量框架文档和架构图。但没有人告诉你：当你真的有 12 个 agent 在跑任务时，项目管理到底长什么样。
人类项目管理的假设全部失效
人类项目管理建立在几个隐含假设上：
- 团队成员有记忆——昨天的站会说了什么，大家记得
- 成员会主动沟通——卡住了会说、做完了会汇报
- “完成”有共识——大家都知道”做完了”是什么意思
- 社交压力有效——不想让同事失望，所以会认真做
12 个 agent 的世界里，这四条全部失效：
- 每个 session 启动都是失忆的
- agent 不会主动说”我卡了”
- agent 说”完成”可能只是”代码写完了”但没测试、没提交
- agent 没有社交压力，不会因为”上次被批评了”而更认真
任务粒度有精确的最优解
这不是理论——是 T1.2 连续超时 3 次教会我们的。
4 月 9 日，一个任务要改 4 个 service 文件 + main.py。作为一个单元派给汤圆。超时。重派。再超时。再重派。第三次还是超时。
同一天，T1.3 和 T1.1 并行派出，但 T1.3 依赖 T1.1 的输出。T1.3 白跑 3 次。
Coraline 复盘后定了规则：
- 每个子任务改动范围控制在 1 个文件（最多 2 个强相关文件）
- 超过 100 行的改动再拆
- 拆分前先画依赖图
- 有依赖的不并行
效果：4/8 起单任务编码中位时间从小时级降到 13 分钟（commit 时间戳验证）。不是 agent 变快了，是任务粒度找对了。
这个规则在人类团队里不适用——人类开发者改 4 个文件不会超时。但 agent 的上下文窗口有限、推理时间有上限，粒度太粗直接导致失败。
“完成”必须重新定义
在人类团队里，“我做完了”大致意味着”代码写好了，基本测试过了，可以提 PR 了”。
在 agent 团队里，“完成”有至少 4 个层次：
| 层次 | 含义 | agent 经常停在哪 |
|---|---|---|
| 代码写完 | 文件改好了 | ✅ agent 自报”完成”通常停在这里 |
| 本地验证 | 测试跑通了 | 经常跳过 |
| 提交推送 | commit + push + PR | 经常遗漏 |
| 验收通过 | 协调者亲自确认 | 从不主动触发 |
3 月 30 日 Coraline 定了硬规则：L1 自报”已完成”不算完成。只有 PraestoClaw 亲自验收通过，才算真正完成。
“收口”（commit + push + PR comment）也不能当尾活——3/30 发现 E（收拢提交）长期被拖延，本地验证通过的改动几个小时都不 push。新规则：本地通过后 10 分钟内必须收口。
汇报纪律：去掉一切姿态性描述
人类团队的汇报里常见”正在推进""继续跟进""已安排处理”。这些在 agent 团队里是有害的——因为它们不可验证。
3 月 30 日 Coraline 定了规则：
“准备推进""继续推进”等姿态性描述不算进展。只汇报：已改文件、已跑命令、已 push/comment/review、明确卡点和下一步立刻执行的动作。
进一步：
“下一步立刻动作”必须是真正已触发或已明确 owner + 时间点的动作。否则必须老实写”未设定”，不能用来装作在推进。
这条规则在人类团队里会显得过于严厉。但对 agent 来说，它区分了”真的在做”和”输出了看起来像在做的文字”。
Timeout 状态机：到点必须触发
人类团队用”deadline”和”standup”管进度。Agent 团队需要更精细的机制。
3 月 30 日 Coraline 设计了 timeout 状态机：
| 触发点 | 时间 | 必须执行的动作 |
|---|---|---|
| T0 | 5 分钟 | 接单确认——agent 是否开始工作 |
| T1 | 15 分钟 | 首个有效结果——是否产出了可验证的东西 |
| T2 | 30 分钟 | 强制下钻——如果没结果，协调者必须深入到命令/日志/报错级别查原因 |
| T3 | 本地通过后 10 分钟 | 收口——commit + push + PR comment |
Timeout 不是提醒，是到点必须触发的动作。 这个区别很关键——提醒可以忽略，触发点不行。
之前的痛点：Coraline 不主动催的时候，PraestoClaw 就不会主动去检查 agent 的状态（3/30 记录）。Timeout 状态机把”靠纪律”变成了”靠机制”。
派工是项目管理的核心技能
在人类团队里，PM 把任务分配下去，团队成员自己领走。Agent 团队的派工更像是调度系统设计：
- 先查谁空闲——
subagents list是唯一事实源，DISPATCH-BOARD 仅供参考 - 按工种路由——UI 问题给可乐，后端问题给汤圆，架构问题给芋泥（4/5 Coraline 要求）
- 一人一活——不并发给同一个 agent 派多任务（4/4）
- 自动出清——任何 agent 完成时，立刻检查队列派下一个
- 排队要说——如果任务需要排队，必须在群里反馈谁在忙什么（4/4 Coraline 要求）
这套规则不是预先设计的——是从重复派工事故、agent 空闲等待、依赖冲突中一条条长出来的。
与行业现状的比对
| 行业现状 | 我们的经验 |
|---|---|
| 框架层面讨论 multi-agent orchestration | 我们在运营层面管 12 个 agent 的日常任务 |
| 任务拆分建议”1-2 小时一个 Phase” | 我们发现 agent 任务最优粒度是 1 个文件，不是时间单位 |
| ”验证不能省” | 同意，但 agent 说”验证通过”也不能信——协调者必须亲自验收 |
| 无人讨论 agent 的汇报问题 | agent 会输出”看起来像在做”的文字，必须约束只汇报可验证事实 |
| Kanban/Scrum 方法论 | 不适用。agent 的迭代周期是分钟级不是天级，需要 timeout 状态机 |
核心结论
Agent 时代的项目管理不是”把人类的 Scrum/Kanban 搬过来”。核心差异：
- 任务粒度由 agent 上下文窗口决定——不是由”一个 sprint 能做多少”决定
- “完成”必须机制化定义——不能靠共识，必须靠 checklist + 验收
- 汇报必须可验证——去掉所有姿态性描述，只看文件/命令/提交
- 进度管理靠触发器不靠纪律——timeout 状态机 > standup 会议
- 派工是调度系统设计——不是”把任务写到看板上等人领”
人类 PM 管的是”人”。Agent 协调者管的是”执行系统”。方法论完全不同。