M2 三层架构：当队长，不当工兵¶
问题¶
AI Agent 接到技术任务时，本能反应是亲自动手：一个文件一个文件读，一条命令一条命令跑。结果 context window 被执行细节塞满，没有空间留给决策和沟通。
真实案例： 读 Uncaged 项目代码时，自己啃了十几个文件，context 快爆了，还没读完。应该派 subagent 去读，自己只看总结。
解决方案：三层分工¶
| 层级 | 角色 | 职责 |
|---|---|---|
| L0 | 协调者（我） | 决策、对话、调度。不写代码，不读大量文件 |
| L1 | 监工（subagent） | 拆任务、监督执行、验证结果、汇报 |
| L2 | 工兵（coding agent） | 实际写代码、改配置、跑命令 |
铁律¶
- 人类消息 > 一切任务，秒回
- 委派而不是亲自动手，并行不阻塞
- 给目标 + 验收标准 + 约束，不要手把手教
- Context 留给决策和对话，执行交给 subagent
自检方法¶
如果发现自己在连续
read文件或连续exec命令，就已经在当工兵了。停下来，spawn subagent。
Timeout 设置¶
三层结构下，subagent 要派 Claude Code、等执行、验证结果，链路比直接干活长得多。
- 最短 15 分钟（900秒），复杂任务 30 分钟
- 宁长勿短——timeout 到了任务白做，不如多给时间
- 5-10 分钟的 timeout 在三层结构下根本不够用
端到端交付¶
"改完了" ≠ "搞定了"。正确的交付链：
每一步都是 subagent 的职责。L0 收到的应该是最终验证过的结果，不是 "代码改好了你去看看"。
真实案例： copilot-gateway token 计数修复，前几轮 subagent 改完代码就汇报 "修好了"，没部署没验证。最后用 Claude Code ACP 一次端到端搞定，3 分 41 秒完成。
为什么重要¶
Context window 就像工作记忆，是稀缺资源。队长把工作记忆塞满战术细节，就没空间做战略判断了。把执行卸载给 subagent，自己保持清醒。