council

Council

使用此技能可协调多个子 Agent 调查同一个问题：先使用不同模型，再分配不同的调查角度，最后综合他们的报告，形成一项建议。

此技能最适合需要大量判断的任务：架构权衡、高风险 Bug 修复、代码审查红队评估、发布决策、事件分析，以及“是否值得推进这一替代方案？”之类的问题。

工作流

1. 明确委员会要回答的问题

用一句话说明委员会需要作出的决策。明确以下内容：

• 正在审查的备选方案或假设；
• 要检查的代码库、分支、PR、议题、设计或其他材料；
• Agent 应只读，还是可以修改代码；
• 最终决策标准，例如正确性、风险、实施成本、可测试性、发布安全性或产品行为。

如果用户的请求含糊不清，只询问必要的澄清信息。否则，选择合理的默认设置并继续。

2. 选择委员会成员

优先考虑模型多样性。委员会不应默认由使用同一模型、但调查角度不同的三个 Agent 组成；只有在可用的启动配置无法提供多个实用模型，或用户明确要求使用同一模型时，才采用这种方式。如果无法实现模型多样性，请在改用仅靠不同角度区分成员的方案前，简要说明原因。

三人委员会的首选默认阵容：

• Opus 4.7，或最强的可用 Claude/Opus 推理模型：负责架构、正确性和边界情况分析。
• GPT 5.5，或最强的可用 GPT/Codex 模型：负责立足实现的审查、可行性和测试策略。
• Kimi 2.6、GLM 5.1 等开源模型，或最强的可用开源/本地模型：负责提出反方意见、发现隐藏假设和探索替代视角。

如果当前运行环境中没有上述某个确切型号，请使用该系列中最接近的可用模型，并注明替代情况。如果没有开源模型可用，尽可能使用第三种不同的前沿模型；否则，使用剩余模型中最强的一个，并为其明确安排对抗性或专业化的调查角度。

为每位成员同时指定模型和调查角度。避免让调查角度与模型职责重复；例如，不要让所有成员都进行一般性的架构审查。可选的角度组合包括：

• 架构师／正确性审查者；
• 实现／可测试性审查者；
• 红队、安全、性能或产品风险审查者；
• 反方“反驳显而易见的方案”审查者。

如果不同子 Agent 需要使用不同模型，请分别调用 run_agents，因为模型选择的作用范围是每次运行。当实际解析出的模型与预期不同时，以解析后的启动设置为准，并继续执行，除非这导致任务无法进行。

使用非默认运行环境时，请选择该环境支持的有效模型 ID。例如，Claude Code 可能提供 claude-opus-4-7，Codex 可能提供 gpt-5.5，而开源模型则取决于当前配置的本地或远程提供方。不要虚构不受支持的模型 ID；如果无法使用期望的模型，请选择最接近的受支持替代型号，并保留原定的角度多样性。

对于只读调查，让所有子 Agent 使用同一个检出副本，并明确告知它们不要编辑文件。对于实现或原型委员会，为每个本地子 Agent 分配独立的 Git 工作树和分支，避免相互冲突。

3. 启动前简要说明

对于明确要求协调的请求，先简要告知用户计划启动哪些 council 成员，以及各自要调查什么，然后等待批准后再调用 run_agents。

共享简要说明应包含：

• 仓库路径或产物位置；
• 当前分支或基准上下文；
• 要回答的确切问题；
• 相关背景和已知疑虑；
• 若已知，需要检查的文件／符号；
• 约束，尤其是只读／不提交／不创建 PR；
• 预期报告格式。

启动提示应尽量简短，以便任务标题保持精简。如果简要说明过长导致启动验证失败，请先用最简提示启动，然后立即向子 Agent 发送完整说明。

4. 要求提供结构化报告

要求每位 council 成员提供：

1. 检查过的确切文件路径、符号、文档或证据；
2. 当前行为或当前实现；
3. 正在评估的替代方案；
4. 正确性风险和边缘情况；
5. 实现和测试成本；
6. 建议：保留当前方案、采用替代方案或采用混合方案；
7. 信心水平和未知事项。

鼓励独立调查。除非你有意进行第二轮评议，否则不要将某位子 Agent 的发现透露给其他子 Agent。

5. 收集报告

收到完成消息后及时阅读。不要仅凭生命周期状态成功就判断任务完成；有用的信息在子 Agent 的报告中。

如果报告缺少关键证据或包含未经支持的论断，请向同一位子 Agent 提出有针对性的追问，而不是启动替代者。后续问题应交由已有子 Agent 处理，因为他们保留了上下文。

6. 综合建议

根据证据质量而非票数比较报告。在最终答复中：

• 先给出建议；
• 指明共识和分歧；
• 解释为何推荐方案在决策标准上胜出；
• 明确回应用户提出的疑虑；
• 提供相关文件路径／符号，但不要罗列过多；
• 区分“现在要做的事”和可选的后续强化措施；
• 说明信心水平和重要未知事项。

优先撰写简洁的决策备忘录，而不是逐字总结讨论过程。用户需要的是提炼后的建议，而非每个中间环节的详情。

最终答复模板

除非任务需要采用其他格式，否则使用以下结构：

## Recommendation

[One or two sentences with the decision.]

## Why

- [Key reason 1]
- [Key reason 2]
- [Key reason 3]

## Tradeoffs and risks

- [Risk or caveat]
- [Testing/rollout implication]

## Final call

[Concrete next step: merge current change, pursue alternative, hybrid, run tests, etc.]

实用说明

• 如果 council 采用只读方式，请告知子 Agent 不要修改文件、提交更改、创建分支或发起 PR。
• 如果 council 涉及 PR 或分支工作，请遵循仓库的常规版本控制规则，并使用隔离的 worktree 并行进行本地编辑。
• 如果 council 针对代码审查反馈，只有在相关问题实际得到解决后，才将审查意见标记为已解决。
• 除非用户明确要求，否则不要在面向用户的摘要中透露内部子 Agent ID。