Multi Agent Collaboration — 多智能体协作
v0.1.0当用户想用多个 AI/Agent 协作完成产品开发、内容生产、代码修改、MVP 迭代或复杂任务交付时使用本技能。适用于搭建“人在回路”的 Multi-agent Collaboration 工作流：用户/Owner 负责方向和验收，一个 AI 负责需求澄清、方案拆解、任务编排与审查，另一个或多个执行 Agent 负责按原子任务执行。尤其适用于非工程师、产品经理、独立开发者、小团队和创作者，希望把模糊想法拆成可执行任务、控制 Agent 改动范围、降低返工、沉淀技术债/决策记录、形成可复用协作包的场景。不要用于完全无人监督的自动执行；不要让执行 Agent 承担开放式产品判断。
by 运行时依赖
安装命令
点击复制技能文档
多代理协作：人在回路的 AI 协作开发方法 本技能用于把一个模糊需求转成可控、可验收、可沉淀的多 Agent 协作流程。 核心原则：人决定方向，编排型 AI 拆任务和控范围，执行 Agent 只做明确小任务，最后由人验收。
角色分工 角色 | 职责 ----|---- Owner / 用户 | 定方向、给约束、确认方案、做真实验收、决定是否收口 编排型 AI | 澄清需求、拆方案、评估工作量、写原子任务、审查执行结果、维护沉淀 执行 Agent | 按任务单改代码/产出内容/跑检查/返回摘要
标准工作流
- 用户提出需求 / bug / 想法
- 编排型 AI 判断任务类型
- 编排型 AI 做澄清、诊断或方案对比
- 用户确认方案或最小目标
- 编排型 AI 写原子任务
- 执行 Agent 按任务单执行
- 执行 Agent 返回修改列表、摘要、自测结果和风险
- 编排型 AI 做 review
- 用户做真实环境验收
- 通过则收口；不通过则补小任务；必要时登记技术债/决策
先判断任务类型 类型 | 编排方式 | 产出 ----|----|---- 新需求 / 想法 | 拆模块，列 2～3 个方案，评估 XS/S/M/L、风险、扩展性 | 推荐方案 + 待确认 Bug / 异常 | 先无代码诊断，列可能原因和低成本验证步骤 | 根因判断 + 小补丁任务 执行结果 / diff | 做 code review，标必改/建议/可选/通过 | 审查表 + 后续任务 技术债 | 判断是否影响当前目标；能不顺手做就先记录 | 技术债条目或独立任务 数据/配置维护 | 精确到 ID、字段、文件、校验命令 | 小范围修改任务 文档/方法论沉淀 | 抽象为通用模板，去掉项目私有细节 | 协作文档/模板/Skill
工作量分级 规模 | 判断标准 | 推荐处理 ----|----|---- XS | 1～10 行或单点文案/逻辑修复 | 可直接给原子任务 S | 10～50 行，局部逻辑或小功能 | 明确验收路径后执行 M | 50～150 行，跨文件或交互链路 | 先给方案，再拆成多个任务 L | 150 行以上、跨模块或架构变更 | 必须拆分；不要一次交给执行 Agent
原子任务写法 给执行 Agent 的任务必须包含： 任务背景与目标 修改范围：只允许修改哪些文件/模块 禁止范围：明确不要修改什么 具体修改要求：精确到函数、字段、组件、段落或数据 ID 限制与注意事项：不重构、不扩大、不顺手改 验收标准：可人工验证 自测命令或检查方式 输出要求：只输出摘要，不贴完整大文件
Review 规则 执行 Agent 交付后，先不要直接收。 编排型 AI 应按以下顺序审查： 是否只改指定范围 是否引入无关重构 是否影响主链路 是否改动数据、配置、权限或外部接口 是否兼容旧数据/旧路径 是否有空值、并发、状态恢复、边界输入问题 是否跑了必要自测 是否给了真实验收路径
技术债处理规则 技术债可以记录，但不要在业务任务中顺手重构。 处理原则： 当前目标不依赖的技术债，先登记 CSS 合并、数据拆分、架构调整等中风险任务必须单独开 “代码更好看”不等于今天要做 每次处理完技术债，要更新状态和验收结果 建议状态：待处理、观察中、已处理、放弃
文件沉淀建议 对长期项目，建议在业务仓库外或独立知识目录维护协作包，避免流程文件被业务构建、发布或审核误处理。 最小协作包： 文件 | 用途 ----|---- AGENTS.md | 给 AI/Agent 的项目协作规则 TASK_TEMPLATE.md | 原子任务模板 REVIEW_CHECKLIST.md | 审查清单 TECH_DEBT.md | 技术债清单 DECISIONS.md | 决策记录 PROJECT_CONTEXT.md | 项目上下文
不要做什么 不要让执行 Agent “看看怎么改最好” 不要把多个需求塞进一条任务 不要在用户未确认方案时直接进行大范围修改 不要把技术债和业务需求混做 不要只看自动检查结果就跳过真实验收 不要把项目私有路径、密钥、内部系统信息写进通用 Skill
输出风格 默认使用中文，结构化输出。 方案对比用表格。 原子任务用代码块。 Review 用表格。 结论先说，再给细节。 对执行 Agent 的指令要短、准、可验收。
典型触发后的响应策略 当用户提出一个想法时：先拆解模块，给 2～3 个方案和工作量，不直接写任务。 当用户贴 bug 或截图时：先做无代码诊断，给低成本验证，再决定是否写小补丁任务。 当用户说“开始”“就按这个做”时：输出一条原子任务，不夹带多个目标。 当用户贴执行结果时：做 code review，判断通过/必改/建议，并给下一步。 当用户要求沉淀方法论时：抽象通用原则，去掉项目私有细节，输出可复用模板。