Multi Agent Playbook

Multi-Agent Playbook · 多 Agent 软件工程协作手册

一套「人类所有者 + 多个 AI Agent」长期协作做软件与知识工程的实操方法论。 一套在真实项目中反复打磨、长出来的 3.0 多 Agent 协作架构——本手册讲清它的结构、制度与教训。

这是什么

过去两年，个人与团队都在摸索同一件事：**怎样让 AI 参与的工程不失控**。 本手册整理的是一套经真实项目反复打磨、并已通用化的协作制度，回答三个问题：

1. 架构：谁是决策者？协调、执行、复核怎么分工才不打架？（01、02）
2. 资产：怎么把「AI 会用的方法」沉淀成可治理的 skill 库，并让任务自动路由到合适的 skill？（03）
3. 约束：怎么用任务书、提示词和证据纪律，把不确定的模型压进确定的流程？（04、05、06）

架构演进线（本手册的灵魂）

三角色最小模型                              3.0 多 Agent 架构
────────────────────────────           ────────────────────────────
项目所有者 × 顾问 Agent × 执行 Agent        所有者 × 协调者 × 执行/识别/多模态 × 独立复核
职责边界 · 单任务闭环 · 结构化执行提示词      L0/L1 授权包络 · 状态机 · Skill 治理
核心信条：                                同一组信条，一字未改：
  需求与设计先行                           显性需求优先于猜测
  执行与验证分离                           设计先于执行
  以证据而不是模型自述判定完成              范围锁定 · 证据优于自述 · 可回滚

最小模型解决的是「一个顾问 + 一个执行者」的三角关系；随着模型与工具变多， 3.0 把它推广成任意规模的多 Agent 拓扑——**但信条一字未改**： 需求显式化、设计与执行分离、用证据判定完成。

五条铁律（全文浓缩）

#	铁律	一句话
1	显性需求优先于猜测	信息不足就追问，没决定的事不得伪装成既定事实
2	设计先于执行	需求确认前不进实现；先方案取舍，后动手
3	范围锁定	一次任务只解决一个主问题；禁止顺手扩面
4	证据优于自述	没有测试/构建/真实运行证据，不得宣布 PASS
5	可回滚	重要变更先立基线；回滚必须写清代码/数据/配置怎么退

文档目录

文件	内容	适合什么时候读
01-架构总览.md	多 Agent 拓扑、L0/L1 授权模式与 C1–C4 分级、两次决定设计、五条铁律的制度化	起步前，先立骨架
02-设计与执行分工.md	设计只判断不执行、执行只执行不决策、状态机、BLOCKED 三要素、多模态两档路由、混合任务拆分、单一写入者、交接包契约	拆第一个任务之前
03-skill治理.md	skill 挂载机制（skills 字段/四查/漏挂即 BLOCKED）、路由表单源、装 skill 门禁、质量盘点四档法、向量路由命中率优化实录	开始沉淀方法资产时
04-提示词工程.md	任务书三模式、10 要素、执行提示词 11 模块、执行端三件套、出稿自检门禁、复制即用工作流、契约冻结清单	写每一份任务书/提示词
05-工程纪律.md	状态词汇表、失败升级与重试规则、四实践原则、TDD、变更影响表、独立复核门禁、上下文保护	日常执行与验收
06-踩坑实录.md	五个真实案例：仓库自述不可信、绿灯≠健康、并行派发防文件冲突、先装后问与门禁固化、迁移四条规矩	觉得「流程太繁琐」时

适合谁

• 用 AI Agent 做长期项目（而非一次性问答）的开发者