multi-agent-division-playbooklisted

# 多 Agent 分工协作协议 多个 AI 一起干活，出问题的地方通常不是模型能力，而是**边界**：同一件事两个 Agent 都做了、状态被写了两遍、任务交出去没人接、或者一个 Agent 悄悄把手伸到了别人的地盘。 本 Skill 把协作拆成五件必须先说清的事：**谁负责什么 → 任务怎么找到对的 Agent → 跨边界怎么交接 → 状态以谁为准 → 交付前谁把关**。 ## 何时使用 - 你在两个以上 AI 工具之间分配工作，且它们共享同一批文件和状态 - 出现了重复劳动、状态冲突，或「这个活该谁做」的犹豫 - 要把一套已经在跑的分工规则固化下来，交给别人复用 ## 何时不用 - 只用单个 Agent：没有分工问题，只有提示词问题 - 具体业务怎么做：本 Skill 只管协作协议，不管业务方法论 - 团队里是人在分工：那需要的是组织流程，不是 Agent 协议 ## 一、先填分工矩阵 **一个域只能有一个主控。** 这是整套协议的基石——两个主控等于没有主控。 | 域 | 主控槽位 | 产物命名空间 | 其他槽位的参与 | | --- | --- | --- | --- | | （例）长篇写作 | 写作端 | `drafts/` | 其他端只读，可出诊断 | | （例）代码与工程 | 工程端 | `src/`、`build/` | 其他端只读 | | （例）检索与情报 | 检索端 | `research/` | 其他端只读 | 填写规则： 1. **产物命名空间唯一**。两个 Agent 写同一个目录，冲突只是时间问题。 2. **只读参与要显式写明**。「其他端可以参与」这种含糊说法等于没有边界。 3. **槽位不绑定产品名**。写「写作端」而不是某个具体工具名——工具会换，职责不会。 4. **冻结项单列**。某个能力被明确停用时，写清停用范围和它是否仍然影响其他端。 ## 二、意图路由：七条优先级 用户只说目标，不背命令。路由按这个顺序判断： 1. **停用清单优先**——被明确停用的能力，任何情况下不触发，直接给出归属说明。 2. **否定语优先**——先识别「不要、不是、先别、暂停」。不得用被否定的关键词触发动作。这是最常见的路由事故。 3. **域判定优先**——先判断这件事属于哪个域，再看谁主控。不属于本端的域，出归属说明，只做只读辅助。 4. **继续 / 验收先查状态**——读状态续跑，不重跑已完成的阶段。 5. **高风险动作在动作时刻确认**——发布、外发、付费、删除、权限变更。无论命中哪条路由都不豁免。 6. **歧义只问一个问题**——只有歧义会实质改变结果时才问，且给选择题、推荐项放首位；不影响结果的歧义做有界假设，直接推进。 7. **路由不扩大授权**——分析类请求保持只读；「帮我看看」不等于「帮我改」。 ## 三、范围声明：最容易出事的地方 **用户说出口的措辞，就是任务边界。** 协作事故很少来自恶意，多数来自一种默认：自己理解了新情况，就以为对方也理解，于是没说就跨了界。 ### 三个必须声明的时刻 1. **任务性质变化时**——同一个请求，做着做着从「调一个参数」变成了「重构整个模块」，这是两件事。切换的那一刻要说明：接下来动哪一侧、动什么。 2. **必须越界才能完成时**——先说「这件事需要读 X，可以吗」，得到同意再动。 3. **要把结果写回别人的地盘时**——单独问一次，不夹带在别的动作里。 「做完才交底」不算声明。 ### 伪只读命令 有些命