Council 是一套面向复杂决策的多智能体审议系统。它把一个问题交给多个固定专家角色并行分析，再经过交叉讨论和综合，形成带有置信度和异议记录的建议。
用途
Council 用于那些能从多元视角中获益的复杂决策，包括：
- 架构决策：具有长期影响的系统设计选择
- 功能设计：需要兼顾用户体验（UX）和工程的用户功能
- 技术权衡：性能与可维护性、速度与正确性等取舍
- 风险评估：从多个角度评估潜在失效模式
- 战略方向：重大转向或技术选择
官方明确不适合用于简单缺陷修复、例行实现任务、需求与方案已经清晰明确的情况，以及时间紧迫的决策，因为审议会带来额外开销。
主要能力
9 个固定成员
每个成员有明确角色、关注点、风格和关键提问方式：
| 成员 | 姓名 | 视角 | 代表性提问 |
|---|---|---|---|
| 架构师 | Serena | 系统设计、可扩展性、模式 | 这如何融入更大系统？是否符合架构原则？如何扩展？ |
| 设计师 | Aditi | 用户体验、可访问性、流程 | 用户会如何体验？是否对所有用户可访问？认知负荷如何？ |
| 工程师 | Marcus | 实现、测试、维护 | 如何干净地实现？测试要求是什么？维护负担如何？ |
| 研究员 | Ava | 数据、先例、替代方案 | 类似情况别人怎么做？数据说明什么？有哪些替代方案？ |
| 质量工程师 | Wei | IATF 16949 合规、FMEA、缺陷预防、审计准备 | 潜在失效模式是什么？对控制计划和 FMEA 有何影响？是否可审计合规？遏制计划是什么？ |
| 运营经理 | Kenji | 产能规划、排程、吞吐量、OEE、交付 | 能否按时交付？产能影响如何？瓶颈在哪？ |
| 供应链负责人 | Priya | 供应商能力、交期、成本、库存、风险 | 供应商能否满足规格？总落地成本是多少？自制还是外购？ |
| 财务控制 | David | ROI、现金流、利润率、资本开支、回收期 | ROI 和回收期是多少？对利润率有何影响？不做的成本是什么？ |
| 运营总监 | Steve | 多工厂运营、可制造性设计、GD&T、流程纪律、简化 | 流程是什么？这是设计问题还是制造问题？生产能否稳定保证该公差？最简单可行的方案是什么？ |
三轮审议流程
- 第一轮：独立视角（并行）。各成员在不看其他人输入的情况下独立分析，输出格式包含评估摘要、关键考虑点、具体建议和顾虑或风险。
- 第二轮：交叉回应（顺序）。成员针对彼此观点作出回应，整理出共识点、张力（例如架构师与工程师之间的张力）以及讨论中提出的新问题。
- 第三轮：综合。合并为统一建议，包含决策、理由、实施说明、用户影响、证据基础、风险与合规、运营影响、供应链与成本、财务分析、异议观点和置信度（高/中/低）。
快速议会（2 名成员版本）
针对更快节奏的审议，可以只选择最相关的两个视角。官方给出了一张搭配表，例如：
- API 设计：架构师 + 工程师
- UI 功能：设计师 + 工程师
- 性能：工程师 + 研究员
- 安全：架构师 + 研究员
- 制造流程：质量 + 工程师
- 合规与审计：质量 + 研究员
- 产品设计：质量 + 架构师
- 新项目启动：运营 + 质量
- 自制或外购：供应链 + 财务
- 资本开支投资：财务 + 运营
- 供应商问题：供应链 + 质量
- 产能规划：运营 + 财务
- 设计公差评审：运营总监 + 质量
- 流程简化：运营总监 + 运营
- 工程变更评审：运营总监 + 工程师
- 多工厂问题：运营总监 + 质量
使用方式
官方给出三种调用途径：
- 通过工作流：
/council "Should we use GraphQL or REST for the new API?"
- 通过技能触发：在遇到复杂决策时描述情境并召集议会审议，例如说明面临一个能从多视角获益的架构决策，并给出决策描述。
- 编程调用（从 hooks）：
import { conveneCouncil } from './lib/council-utils';
const result = await conveneCouncil({
topic: 'GraphQL vs REST for new API',
context: 'Building a new public API for third-party integrations',
constraints: ['Must support real-time updates', 'Team has REST experience'],
urgency: 'medium'
});
快速议会的调用示例：
/quick-council architect+engineer "Should we cache at the API or database layer?"
审议结果存储
审议记录存放在 ~/.claude/MEMORY/Decisions/，按日期和主题命名，例如 2026-01-17_graphql-vs-rest.md。文件结构包含主题、日期、召集方、紧急程度、背景与约束、第一轮各成员分析、第二轮交叉分析、第三轮带置信度的建议，以及后续填写的实际结果。
适用场景
从示例看，Council 适用于技术选型（如 PostgreSQL 与 MongoDB 的取舍）、功能范围取舍（如是否先发布不含离线支持的 MVP）等需要在用户需求、交付时间、架构可扩展性和团队经验之间权衡的决策。其成员构成同时覆盖软件工程与制造运营（IATF 16949、FMEA、OEE、DFM 等），因此也面向制造运营相关的流程、质量、产能、供应链与资本开支议题。
最佳实践
- 召集时：提供清晰背景；提前说明约束（时间、预算、团队技能等）；定义成功标准；设定紧急程度以影响审议深度。
- 审议中：让每个成员充分表达；明确记录分歧张力；追求综合而非全体一致，因为完全一致值得警惕；保留少数意见。
- 决策后：记录实际结果；定期回看判断是否正确；从错误中更新成员启发式。
与其他技能的集成
Council 可与 7 阶段流程配合：OBSERVE 阶段收集背景；THINK 阶段进行议会审议；PLAN 阶段落实建议；BUILD 阶段据此定义 ISC；EXECUTE 阶段按计划构建；VERIFY 阶段按议会标准测试；LEARN 阶段评估决策质量。相关技能包括 Algorithm、A3CriticalThinking 和 Agent Personas。
限制
官方明确 Council 会带来审议开销，不适合时间紧迫或方案已经清晰的简单任务。所有成员角色、提问框架和输出结构均来自资料原文；具体模型配置、运行环境要求、收费与价格信息暂未提供。