war-room

概述

War Room 汇集多位 AI 专家，从不同视角分析问题，通过对抗性审查挑战既有假设，并在 Supreme Commander 的指导下综合出最优方案。

理念

“诀窍在于没有诀窍。智能的力量源自我们广泛的多样性，而非任何单一的完美原则。”

• Marvin Minsky，《Society of Mind》

基于可逆性的路由

在讨论前，评估可逆性评分（RS），以确定适当的资源分配：

RS = (Reversal Cost + Time Lock-In + Blast Radius + Information Loss + Reputation Impact) / 25

RS 范围	类型	模式	资源
0.04 - 0.40	Type 2	快速	1 位专家，< 2 分钟
0.41 - 0.60	Type 1B	轻量级	3 位专家，5-10 分钟
0.61 - 0.80	Type 1A	全体委员会	7 位专家，15-30 分钟
0.81 - 1.00	Type 1A+	Delphi	7 位专家，30-60 分钟

快速判断：

• 可以进行 A/B 测试？→ Type 2
• 需要迁移数据？→ Type 1
• 需要公开承诺？→ Type 1A+

完整评分指南见 modules/reversibility-assessment.md。

适用场景

• 存在重大权衡的架构决策
• 需要多方利益相关者从不同视角参与的问题
• 后果重大的高风险选择（RS > 0.60）
• 没有明确先例的新问题
• 头脑风暴产生多个有力的竞争方案时

不适用场景

• 答案显而易见的简单问题
• 常规实现任务
• 有明确解决方案且文档完善的模式
• 需要立即采取行动的紧急决策
• Type 2 决策（RS ≤ 0.40）：使用快速模式，或完全跳过 War Room

专家小组

默认（轻量级模式）

角色	模型	职责
Supreme Commander	Claude Opus	最终综合、升级决策
Chief Strategist	Claude Sonnet	生成方案、分析权衡
Red Team	Gemini Flash	对抗性挑战、失效模式

全体委员会（升级后）

角色	模型	职责
Supreme Commander	Claude Opus	最终综合
Chief Strategist	Claude Sonnet	生成方案
Intelligence Officer	Gemini 3 Pro	大上下文分析（1M+）
Field Tactician	GLM-5.3	实现可行性
Scout	Qwen Turbo	快速收集数据
Red Team Commander	Gemini Flash	对抗性挑战
Logistics Officer	Qwen Max	资源估算

讨论协议

默认两轮

Round 1: Generation
  - Phase 1: Intelligence Gathering (Scout, Intel Officer)
  - Phase 2: Situation Assessment (Chief Strategist)
  - Phase 3: COA Development (Multiple experts, parallel)
  - Commander Escalation Check

Round 2: Pressure Testing
  - Phase 4: Red Team Review (all COAs)
  - Phase 5: Voting + Narrowing (top 2-3)
  - Phase 6: Premortem Analysis (selected COA)
  - Phase 7: Supreme Commander Synthesis
  - Phase 8: Discussion Publishing

Delphi 扩展（高风险）

对于高风险决策，可扩展为迭代式 Delphi 收敛流程：

• 多轮讨论，直至专家达成共识
• 收敛阈值：0.85

集成

与 Brainstorm 集成

在 Skill(attune:project-brainstorming) 的 Phase 3（方案生成）之后，War Room 会自动调用。

Brainstorm 技能会将所有上下文传递给 War Room：

• 问题陈述和约束条件
• 生成的方案及其优缺点
• 对比矩阵
• 可逆性评估（自动计算）

绕过条件（必须全部满足）：

• RS ≤ 0.40（Type 2 决策——显然可逆）
• 只有一个显而易见的方案，且没有实质性权衡
• 复杂度低，且有文档完善的模式可循
• 用户在查看 RS 评估后明确拒绝

# Automatic invocation from brainstorm (do not skip)
/attune:war-room --from-brainstorm

# Direct invocation (standalone)
/attune:war-room "Should we use microservices or monolith for this system?"

与 Memory Palace 集成

会话会持久化到 Strategeion（War Palace）：

~/.claude/memory-palace/strategeion/
  - war-table/      # Active sessions
  - campaign-archive/  # Historical decisions
  - doctrine/       # Learned patterns
  - armory/         # Expert configurations

使用 Conjure

专家通过 conjure 委派调用：

• conjure:gemini-delegation 用于 Gemini 模型
• conjure:qwen-delegation 用于 Qwen 模型
• GLM-5.3 使用直接 CLI（通过 ccgd 或 claude-glm，调用 get_glm_command()）

默认开启委派不会改变这里的行为，因为战情室本来就是通过委派构建的：面板要么由外部模型组成，要么就不是面板。

改变的是回退行为。conjure:delegation-core 现在会在没有提供方响应或操作员拒绝委派时返回 fallback_reason，而不是抛出异常；让 Claude 回答所有席位并不是使用这一结果的正确方式。

无法连接外部模型的面板就不是面板。 委派关闭或委派链耗尽时：

1. 在开始审议前说明情况，指出原因和尝试过的提供方。
2. 不要让 Claude 填补空缺席位，再把输出当作多模型面板结果呈现。由一个模型扮演七个角色，会产生看似共识、实则并非共识的一致意见。
3. 提供选择：进行明确标注为单模型审查的审查，或者暂停，直到有提供方可用。

这是本仓库中唯一一个静默回退到本地会歪曲结果，而不仅仅是拖慢进度的地方。

用法

基本调用

/attune:war-room "What architecture should we use for the new payment system?"

附带上下文

/attune:war-room "Best approach for API versioning" --files src/api/**/*.py

仅评估可逆性

快速评估，不进行完整审议：

/attune:war-room "Database migration to MongoDB" --assess-only

输出：

Reversibility Assessment
========================
Decision: Database migration to MongoDB

Dimensions:
  Reversal Cost:      5/5 (months of rework)
  Time Lock-In:       4/5 (migration path hardens)
  Blast Radius:       5/5 (all services affected)
  Information Loss:   4/5 (query patterns, ACID)
  Reputation Impact:  2/5 (internal unless downtime)

Reversibility Score: 0.80
Decision Type: Type 1A (One-Way Door)
Recommended Mode: Full Council

Proceed with full deliberation? [Y/n]

强制使用快速模式（类型 2）

对于明确可逆的选择，直接进入快速决策：

/attune:war-room "Which logging library to use" --express

强制召集完整议事会

对于关键决策，忽略 RS 评估：

/attune:war-room "Migration strategy" --full-council

Delphi 模式

用于风险最高、不可逆的决策：

/attune:war-room "Long-term platform decision" --delphi

恢复会话

/attune:war-room --resume war-room-20260120-153022

输出

决策文档

战情室会生成一份最高指挥官决策文档：

## SUPREME COMMANDER DECISION: {session_id}

### Reversibility Assessment
| Dimension | Score | Rationale |
|-----------|-------|-----------|
| Reversal Cost | X/5 | ... |
| Time Lock-In | X/5 | ... |
| Blast Radius | X/5 | ... |
| Information Loss | X/5 | ... |
| Reputation Impact | X/5 | ... |

**RS: 0.XX | Type: [1A+/1A/1B/2] | Mode: [delphi/full_council/lightweight/express]**

### Decision
**Selected Approach**: [Name]

### Rationale
[Why this approach was selected]

### Implementation Orders
1. [ ] Immediate actions
2. [ ] Short-term actions

### Watch Points
[From Premortem - what to monitor]

### Reversal Plan (for Type 1 decisions)
[If this decision proves wrong, here's the exit strategy]

### Dissenting Views
[For the record]

会话产物

保存到 Strategeion：

• 情报报告
• 形势评估
• 所有 COA（解封后附完整归属信息）
• 红队质询
• 事前验尸分析
• 最终决策

记录权衡（决策日志）

最高指挥官决策本质上是一份权衡记录：选定的方法、与之权衡的 COA，以及不同意见。将其同步到 docs/tradeoffs.md，让推理过程随代码保存，而不只留在 Strategeion 中（先起草并确认）：

• 如果已安装 leyline，则调用 Skill(leyline:decision-journal) 并追加一条权衡记录。直接映射：Selected Approach 对应 decision，RS 和理由对应一条 Y 陈述，被否决的 COA 对应 options，Dissenting Views 对应 consequences_negative。将 phase 设为该决策的发起阶段（例如 plan）。在记录链接中注明 RS。确认后再追加。
• 回退方案（未安装 leyline）：使用文件内的 ENTRY TEMPLATE 追加到 docs/tradeoffs.md；分配下一个 TR-NNN ID。

如果该决策在架构层面足够重要，值得在 docs/adr/ 中编写编号 ADR，则编写 ADR，并在权衡记录中引用其编号，而不是重复记录内容。

匿名化

审议期间，专家贡献会通过 Merkle-DAG 匿名化：

• 审查期间，响应标记为“Response A, B, C...”等
• 只有在决策作出后才会公布归属信息
• 哈希校验确保完整性

详情请参阅 modules/merkle-dag.md。

升级

自动（基于可逆性）

系统会根据可逆性评分自动选择审议模式：

RS 评分	自动模式
≤ 0.40	快速（跳过完整战情室流程）
0.41 - 0.60	轻量级面板
0.61 - 0.80	完整议事会
> 0.80	完整议事会和 Delphi

手动覆盖

当出现以下情况时，最高指挥官可以覆盖自动分类：

• 检测到高复杂度（存在多个架构权衡）
• 初始专家之间存在重大分歧
• 涉及需要专项分析的新问题领域
• 会成为先例的决策（未来决策将遵循这一模式）
• 超出技术范围的政治或组织敏感性

升级必须附上书面理由和 RS 评估。

降级

同样重要的是，要识别被过度审议的决策：

• 如果 RS ≤ 0.40，建议使用 Express 模式或立即执行
• 质疑“虚假的不可逆性”（没有证据却称“我们之后无法更改”）
• 将降级率作为团队健康度指标进行跟踪

配置

用户设置

{
  "war_room": {
    "default_mode": "lightweight",
    "auto_escalate": true,
    "delphi_threshold": 0.85,
    "max_delphi_rounds": 5
  }
}

Hook 自动触发

满足以下条件时，War Room 可以通过 hook 自动建议：

• 检测到关键词（“战略决策”“权衡”等）
• 复杂度评分超过阈值（0.7）
• 用户已在设置中选择启用

Agent Teams 执行模式

概述

指定 --agent-teams 时（或在 Full Council / Delphi 模式下自动选择时），War Room 会使用 Claude Code Agent Teams，而不是按顺序进行 conjure 委派。每位专家都将作为持久队友运行，并通过双向消息传递进行交流，从而实现实时审议，而非批量请求/响应周期。

要求：Claude Code 2.1.32+、CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1，并已安装 tmux。

Agent Teams 的优势

模式	不使用 Agent Teams	使用 Agent Teams	优势
Express	Sonnet 直接调用	N/A（杀鸡用牛刀）	无：跳过
Lightweight	3 次顺序委派	N/A（开销超过收益）	无：跳过
Full Council	7 次顺序/并行委派	7 位队友通过实时收件箱消息进行交流	专家可以实时回应彼此的 COA
Delphi	多轮委派	持久团队迭代，直至达成一致	每轮无需重新调用；状态在各轮之间保留

经验法则：仅在 Full Council 和 Delphi 模式下使用 Agent Teams。Lightweight 和 Express 模式产生的专家间通信不足以抵消协调开销。

团队配置

# War Room agent team structure
Team: war-room-{session-id}
  Lead: supreme-commander (Opus) — orchestrates phases, final synthesis
  Teammates:
    chief-strategist (Sonnet) — approach generation
    intel-officer (Sonnet) — deep context analysis
    field-tactician (Sonnet) — implementation feasibility
    scout (Haiku) — rapid reconnaissance
    red-team (Sonnet) — adversarial challenge
    logistics (Haiku) — resource estimation

注意：在 Agent Teams 模式下，所有队友均以 Claude Code 实例（Opus/Sonnet/Haiku）的形式运行。由于 Agent Teams 需要 Claude CLI，因此不会使用外部大模型专家（Gemini、Qwen、GLM）。代价是失去模型多样性，优势则是获得实时的专家间消息传递。

使用 Agent Teams 的审议流程

1. 负责人创建团队 → 在 tmux 窗格中启动队友
2. 阶段 1（情报）：负责人通过收件箱向侦察员和情报官分配情报任务
3. 阶段 3（COA）：负责人广播形势评估；队友独立制定 COA；通过消息传递，可在制定过程中提出澄清问题
4. 阶段 4（红队）：红队队友收到所有 COA 后提出质疑；其他队友可以实时回应质疑
5. 阶段 5（投票）：负责人广播选票；队友通过收件箱消息进行排序
6. 阶段 6（预演失败）：所有队友收到选定的 COA；可以在彼此的失败场景基础上进一步分析
7. 阶段 7（综合）：负责人收集所有产出，形成决策
8. 阶段 8（发布讨论）：最高指挥官决策文档定稿后， 你必须执行 modules/discussion-publishing.md 将决策发布到 GitHub Discussions。 默认会发布。用户可以回复“n”拒绝。 完整的分步工作流请参阅下方的“讨论发布（必需）” 一节。

回退到 Conjure 委派

如果 Agent Teams 失败（tmux 不可用、团队创建错误），War Room 会自动回退到标准 conjure 委派。审议协议保持不变：仅执行后端有所不同。

成本考量

Agent 团队的 Token 消耗远高于 conjure delegation（每位队友都维护自己的上下文窗口）。只有当协作带来的价值足以抵消成本时才使用，通常适用于 Delphi 模式，因为多轮修订让持续协作的队友更有价值。

讨论发布（必需）

第 7 阶段综合完成后（无论采用哪种执行模式），你都必须执行讨论发布工作流。除非用户明确拒绝，否则此步骤不可跳过。

按以下顺序执行这些步骤：

1. 阅读 modules/discussion-publishing.md，了解完整的 GraphQL 工作流
2. 询问用户：“正在将此决策发布到 GitHub Discussions。[Y/n]”
3. 如果用户回答“n”，则跳至“相关技能”部分。否则，继续执行步骤 4-6。
4. 运行该模块中的 gh api graphql 命令，在“Decisions”类别中创建讨论
5. 将各阶段摘要作为串接评论发布到该讨论中
6. 使用讨论 URL 更新本地 strategeion 文件

如果无法使用 GitHub Discussions（非 GitHub 平台、已禁用 Discussions、gh 未通过身份验证），请提醒用户并跳过。发布失败不会阻碍作战室工作流。

退出标准

• 计算并记录可逆性评分和决策类型。
• 生成一份最高指挥官决策文档，其中包含选定方案、理由和异议观点。
• 将决策同步到 docs/tradeoffs.md（如果属于架构决策，也同步到 docs/adr/ 中带编号的 ADR）。
• 记录预演的关注点，以及 Type 1 决策的逆转计划。

相关技能

• Skill(attune:project-brainstorming) - 战略室讨论前的构思
• Skill(imbue:scope-guard) - 范围管理
• Skill(imbue:rigorous-reasoning) - 推理方法
• Skill(conjure:delegation-core) - 专家调度
• Skill(conjure:agent-teams) - Agent 团队协调（完整议会 / Delphi）

相关命令

• /attune:war-room - 调用此技能
• /attune:brainstorm - 战略室讨论前的构思

参考资料

战略基础

• 孙子 - 《孙子兵法》（情报收集）
• 克劳塞维茨 - 《战争论》（摩擦与迷雾）
• Robert Greene - 《战争的 33 条战略》（统一指挥）
• MDMP - 美国陆军（结构化决策流程）
• Gary Klein - 预演（失效模式分析）
• Karpathy - LLM Council（匿名同行评审）

可逆性框架

• Jeff Bezos - Type 1 与 Type 2 决策（亚马逊股东信）
• Farnam Street - 可逆与不可逆决策（STOP-LOP-KNOW 框架）
• Tapan Desai - 单向门与双向门决策（实际应用）