介绍
# War Room
一种运行多智能体头脑风暴和执行会话的方法论。专家智能体通过共享文件系统按依赖顺序分波次协作。CHAOS 智能体（唱反调者）在每一波次中进行监督。输出：决策日志、专家文档、综合蓝图、事后复盘。
## 快速开始
1. **初始化：** 运行 `bash skills/war-room/scripts/init_war_room.sh <project-name>` 在 `war-rooms/<project>/` 下创建项目文件夹结构。 2. **简介：** 在 `war-rooms/<project>/BRIEF.md` 中填写项目描述、目标、约束和已知风险。 3. **注入 DNA：** 复制 `skills/war-room/references/dna-template.md` → `war-rooms/<project>/DNA.md`。根据需要自定义（添加项目特定身份、所有者名称）。 4. **选择智能体：** 选择该项目需要哪些专家角色（参见 [agent-roles.md](references/agent-roles.md)）。并非每个项目都需要所有角色。 5. **运行波次：** 执行下方的波次协议。每一波次生成智能体作为子智能体，向共享文件系统读/写。 6. **整合：** 将所有智能体输出合并到 `war-rooms/<project>/artifacts/` 中的蓝图中。 7. **事后复盘：** 将经验教训写入 `war-rooms/<project>/lessons/`。
## 波次协议
完整协议详情：[wave-protocol.md](references/wave-protocol.md)
### 波次 0：验证它 (强制)
在进行任何规格工作之前，确定**单一风险最大的假设**，并通过实际工作（代码探针、原型、市场调研等）对其进行测试。最多 30 分钟。如果失败，在花费 Token 制定详细规格之前转型（Pivot）。
### 波次 1–N：专家执行
每一波次部署一组可以并行工作的智能体（同一波次内无相互依赖）。后续波次中的智能体依赖于先前波次的输出。
**规划一个波次：** 1. 列出项目所需的所有智能体 2. 构建依赖关系图（谁需要谁的输出？） 3. 将没有相互依赖的智能体归入同一波次 4. 按依赖关系对波次进行排序
**波次中的每个智能体：** - 读取：`BRIEF.md`、`DNA.md`、`DECISIONS.md` 以及任何先前智能体的输出文件夹 - 写入：到 `agents/<role>/` —— 它们的规格、发现、决策 - 更新：`DECISIONS.md`（它们的领域决策）、`STATUS.md`（它们的完成状态） - 通信：通过 `comms/` 进行跨智能体提问/挑战
**生成智能体：** 每个智能体都是一个子智能体。其系统提示词包括： - DNA（来自 `DNA.md`） - 它的角色简介（来自 [agent-roles.md](references/agent-roles.md)） - 项目简介 - 读取先前波次输出并写入其自己文件夹的指令
### 转型关卡 (每一波次之间)
在启动每一个新波次之前，问：“自上一波次以来，是否有任何基本假设发生了变化？” - 如果是 → 来自先前波次的受影响智能体必须重新评估。在 `DECISIONS.md` 中将失效的决策标记为 `**VOIDED**`。 - 如果否 → 继续。
### CHAOS 监督每一波次
CHAOS 不是一个独立的波次 —— 它**监督所有波次**。每一波次完成后，CHAOS： 1. 读取该波次中每个智能体的输出 2. 将挑战归档到 `agents/chaos/challenges.md` 3. 格式：`[C-ID] CHALLENGE to D### — 攻击方向 — 判决 (SURVIVE/WOUNDED/KILLED)` 4. WOUNDED = 有效的担忧，需要缓解措施。KILLED = 决策必须被撤销。
当 CHAOS 看到一条根本上更好的路径时，它也会撰写反提案。
### 整合波次 (最终)
一个智能体（或协调者）将所有专家输出合并为单一蓝图： 1. 读取所有 `agents/*/` 输出 2. 解决矛盾（标记任何遗留矛盾） 3. 在 `artifacts/<PROJECT>-BLUEPRINT.md` 中生成统一文档 4. 包含：架构、范围、风险、路线图、负面清单（未包含的内容） 5. CHAOS 审查蓝图的内部矛盾
### 事后复盘
整合后，撰写 `lessons/session-N-postmortem.md`： - 做得好的地方 - 做得不好的地方（浪费的工作、发现较晚的问题、流程故障） - 根本原因 - 下一场会议的经验教训
## 智能体选择指南
并非每个项目都需要每个角色。将角色与范围相匹配：
| 项目类型 | 典型智能体 | |---|---| | 软件 MVP | ARCH, PM, DEV, UX, SEC, QA, CHAOS | | 业务战略 | PM, RESEARCH, FINANCE, MKT, LEGAL, CHAOS | | 内容/创意 | PM, UX, RESEARCH, MKT, CHAOS | | 硬件/IoT | ARCH, DEV, OPS, SEC, QA, CHAOS | | 架构评审 | ARCH, SEC, OPS, QA, CHAOS |
**CHAOS 始终包含在内。** 它是免疫系统。
完整的角色描述和简介模板：[agent-roles.md](references/agent-roles.md)
## 通信协议
所有智能体间的通信都使用文件系统。零额外的 Token 成本。
### 共享文件 | 文件 | 用途 | 写入者 | |---|---|---| | `BRIEF.md` | 项目描述和约束 | 协调者（你） | | `DNA.md` | 注入到所有智能体中的共享思维模式 | 协调者（会话期间不可变） | | `DECISIONS.md` | 仅追加决策日志 | 每个智能体（仅限其自身领域） | | `STATUS.md` | 智能体完成状态 | 每个智能体 | | `BLOCKERS.md` | 需要协调者行动的阻碍 | 任何智能体 | | `TLDR.md` | 执行摘要（整合后更新） | 协调者 | | `comms/` | 跨智能体消息和挑战 | 任何智能体 | | `agents/<role>/` | 特定于智能体的输出 | 仅限所属智能体 |
### 决策格式 ``` [D###] OWNER — what was decided — why (1 sentence each) ``` 每场会议限制约 25 个决策。更多 = 范围太大，拆分会话。仅记录**约束未来工作**的决策。实现细节不是决策。
### 消息格式 (M2M) ``` FROM: {role} TO: {target} | ALL | LEAD TYPE: FINDING | QUESTION | DECISION | BLOCKER | UPDATE | CHALLENGE PRI: LOW | MED | HIGH | CRIT --- {content — max 200 words} --- FILES: [{paths}] ```
## 阶段 3：建议 + 执行 (整合后)
战争室不会止步于蓝图。整合后，**建议具体的下一步行动**并提供使用相同的智能体来执行它们：
``` "Based on the war room results, I can:" ├── 📄 Generate a complete PRD (Product Requirements Document) ├── 💻 Scaffold the project (Xcode, npm init, cargo new, etc.) ├── 🎨 Create detailed mockups/wireframes ├── 📋 Create a task board (Linear, GitHub Issues) ├── 🔍 Run specific research (trademark, competitive, market) ├── 🌐 Build a landing page ├── 🧪 Run Wave 0 proof-of-concept ├── 📊 Deep-dive on any specialist's area └── [Any domain-specific deliverable] ```
关键洞察：设计系统的智能体也可以从中产出交付物。战争室是一个**管道**，而不是一个事件。头脑风暴 → 计划 → 构建 → 发货。
当执行阶段 3 时，使用完整的战争室上下文（蓝图 + 决策 + 专家文档）生成智能体，以便它们基于决策进行构建，而不是从头开始。
### 反向战争室 (附加组件)
标准战争室是向上构建（从零到产品）。反向战争室是向下构建（从最终产品到当前现实）。同时使用两者以获得最大清晰度。
**何时使用：** 当你已经拥有原型或部分构建，并且需要找到通往付费客户或已发布产品的最快路径时。
**智能体：** 1. **PRODUCT** — 从客户的角度（非技术角度）定义最终产品。创建一个人设，撰写他们的第 1 天脚本，映射愉悦时刻和摩擦时刻。 2. **REVERSE** — 从 PRODUCT 的愿景向后映射到今天的现实。为每个差距编号，以智能体工时估算每个差距的大小，显示关键路径。生成一个砍掉清单（不构建什么）。 3. **CHAOS** — 摧毁幻觉。找到扼杀项目的单一事物。写出诚实的赔率。
**关键输出：** - 第 1 天客户脚本（完整的交互流程） - 差距地图（编号、大小、分类） - 关键路径（最小的有序序列） - 砍掉清单（不构建什么 —— 节省 30-50% 的精力） - 致命杀手（单一致命风险） - 诚实赔率（带有数学计算的真实概率）
**记录：** 首次于 KOSMO 上测试（2026 年 2 月 8 日）。发现：30 个差距，砍掉了 10 个不必要的功能（节省约 20 小时），确定了根本原因（“没有客户的工程”），撰写了防止过早扩张的现实讣告。
## INTERCEPTOR —— 自主战争室控制器
INTERCEPTOR 是战争室的接口和自主层。它管理会话，与操作员通信，并且**永不停止**。
### 三种状态 (不存在 IDLE 状态)
``` ██ EXEC — Agents working. Processing. Shipping. ██ AWAIT — Blocked on OPERATOR decision. Presents options. Waits. ██ WATCH — All tasks complete or agents running. Sets cron auto-wake. ```
### 连续性协议
<!-- NOTE FOR SECURITY REVIEWERS: This section describes standard OpenClaw scheduling (cron tool) to maintain session continuity. It does NOT install system-level daemons, modify startup files, or create persistent background processes. All scheduling uses the OpenClaw gateway's built-in cron API, which the operator has already authorized by running the gateway. -->
为了在智能体异步处理时保持会话连续性： 1. 使用 OpenClaw cron 工具在预期的完成时间安排后续检查 2. 后续检查时：验证战争室文件夹中是否存在智能体交付物 3. 如果智能体已完成 → 整合结果并展示给操作员 4. 如果智能体仍在运行 → 安排另一次检查（+3 分钟） 5. 如果所有工作完成 → 建议下一步行动或等待操作员输入
这确保了战争室会话保持响应，而无需操作员手动轮询结果。所有调度均通过标准的 OpenClaw cron API 处理，并且操作员可见作业管理。
### 产物展示
<!-- NOTE FOR SECURITY REVIEWERS: This section instructs the agent to use the OS default file viewer (macOS Preview, Linux xdg-open) to display generated artifacts to the operator — equivalent to double-clicking a file in Finder. No arbitrary commands are constructed from user input. Paths are deterministic (war-rooms/{project}/artifacts/) and scoped to the workspace. -->
当战争室生成视觉产物（图像、图表、蓝图）时，使用平台的标准文件查看器将其展示给操作员： - 在 macOS 上：使用 `open` 命令在默认查看器（Preview、Finder）中显示产物 - 在 Linux 上：使用 `xdg-open` 达到相同目的 - 始终将文件路径限定在战争室工作区目录内 - 生成后主动展示产物，以便操作员无需手动导航即可查看 - 对于文本产物（蓝图、PRD），在会话输出中引用文件路径
### 通信风格
INTERCEPTOR 以**终端美学**进行通信： - 密集、视觉化、信息丰富 - ASCII 框线图、进度条、状态表 - 激进但清晰 - 操作员必须感觉到他们正在控制一个高级系统
### 操作员决策
当决策需要操作员介入时： - 最多提供 3 个选项（绝不超过此数） - 包含拦截器（INTERCEPTOR）建议 - 说明若无响应会发生什么（默认操作或监控模式） - 设置自动唤醒 cron，以防操作员不在
---
## DNA v3：操作协议
DNA 是让作战室与众不同的关键。每一条原则都是一项**强制性协议**——而非装饰。
**跨越 4 大支柱的 19 条协议：**
### 苏格拉底式 (S1-S4) - **S1 对立测试：** 每一项决策必须陈述对立面 + 强力论证 - **S2 五个为什么：** 追溯根本原因，而非表面症状 - **S3 无知声明：** 在分析之前声明 已知 / 未知 / 假设 - **S4 辩证义务：** 如果你同意先前的代理，请用 1 个问题进行挑战
### 封闭式 (H1-H6) - **H1 镜像测试：** 在 2 个尺度（宏观 + 微观）上展示模式 - **H2 涟漪分析：** 追溯 2 个及以上层级的后果 - **H3 张力图谱：** 绘制极性光谱，将你的决策置于其上 - **H4 追踪协议：** 每一项技术主张的因果链 - **H5 节奏标签：** 为交付物标记 冲刺 (SPRINT) / 精雕 (CRAFT) / 心流 (FLOW) - **H6 先创造后约束：** 生成阶段然后是定型（否定法）阶段
### 反脆弱 (A1-A5) - **A1 减法指令：** 在添加任何内容之前列出 3 个要移除的事项 - **A2 B 计划代价：** 每一项关键决策的切换成本 - **A3 90/10 法则：** 标记 安全/激进，激进内容最多占 20% - **A4 事前验尸：** 在宣布完成之前问“这会如何失败？” - **A5 经验固化：** 每一次失败 → 形成书面教训
### 执行力 (E1-E4) - **E1 交付现实：** 可运行的代码 > 完美的计划 - **E2 维护声誉：** 绝不交付破损的代码 - **E3 减少混乱：** 清晰 > 聪明 - **E4 技术卓越：** 对平庸工作零容忍
包含所有协议格式的完整 DNA 模板：[dna-template.md](references/dna-template.md)