收集入口
看板把团队意见、用户反馈、邮件、GitHub Issues 和临时想法放到一个池子里，避免任务散落在聊天记录里。
Operating System
多 Agent 并发需要一套操作系统
会议把多 Agent 协作讲得很具体：看板收集需求，Issue 定义任务，Worktree 隔离并行，PR 承接 Review，指标监控健康度，资源列表防止项目互相踩踏。
Board
看板是并发控制台
当开发者从副驾变成管理者，看板就从辅助工具变成工作台。
并发分派
每张卡片对应明确目标、范围和验收条件。Agent 不直接接收模糊愿望，而是接收可以执行的工作单元。
收口与复盘
完成不等于结束。卡片要记录 Review 结果、遗漏测试、复用经验和是否需要沉淀为 Skill。
Worktree
Worktree 的正确位置
Worktree 是隔离并发的手段，但会议没有把它神化。
适合使用
多个相对独立 feature 并行推进，文件冲突概率高，需要每个 Agent 拥有独立分支和工作目录。
谨慎使用
任务强耦合、仓库很小、上下文需要频繁共享，或合并成本高于并发收益时，Worktree 反而会增加管理负担。
判断原则
先问是否能降低冲突和等待，再问是否能承受合并、端口、依赖安装和 Token 上下文成本。
Metrics
Token 与增删比是健康信号
会议提到的指标不是为了炫耀消耗，而是为了判断系统是否进入不健康重构。
| 指标 | 健康解释 | 需要警惕的信号 |
|---|---|---|
| Token 消耗 | 并发扩大后自然升高，关键看是否换来可验收产出。 | 消耗暴涨但 PR 无法合并，说明任务边界或上下文设计有问题。 |
| Deletions / Additions | 约 12%-15% 被视为较健康的收敛区间，5%-6% 可能说明质量更稳。 | 超过 30% 可能发生局部或全局重构，需要检查 Agent 是否误改架构。 |
| Review 发现数 | 早期多很正常，后续应随着 Skills 和检查点沉淀逐步下降。 | 同类问题重复出现，说明经验没有进入自动验证或项目规范。 |
Loop
一条可执行的多 Agent 循环
把会议讨论收束成一个操作闭环。
1. 从看板挑任务
任务必须有目标、非目标、文件/模块边界、验收方式和回滚判断。
2. 分配执行环境
根据复杂度决定是否开 Worktree，并在资源表中登记端口、服务、GPU/CPU 占用。
3. Agent 实现与自测
要求 Agent 先理解现有结构，再提交最小可 Review 的改动，不顺手做无关重构。
4. 人类 Review
Review 重点看行为回归、过度设计、复用缺失、测试空洞和资源冲突。
5. 沉淀为约束
把重复问题转成 Skill、模板、Lint、测试或检查清单，降低下一次管理成本。
6. 合并与复盘
PR 合并后记录指标和经验。并发不是越高越好，而是每一轮都能稳定收菜。