运行一个模型多样化的子代理委员会，从多个角度调查同一问题，比较发现，并生成最终建议。当用户要求委员会、第二意见、多个代理/模型评估一个问题、并行调查、红队/蓝队比较，或帮助在竞争的技术方案之间做决策时，使用此技能。
委员会
使用此技能协调多个子代理调查同一问题，首先使用不同模型，然后分配不同视角，最后综合他们的报告形成一条建议。
此技能最适合判断密集型任务：架构权衡、有风险的错误修复、代码审查红队演练、发布决策、事件分析，以及“这个替代方案值得考虑吗？”之类的问题。
工作流程
1. 明确委员会问题
用一句话说明委员会需要回答的决策。确定：
- 正在审查的竞争选项或假设；
- 需要检查的代码库、分支、PR、问题、设计或工件；
- 代理是只读还是可以进行代码更改；
- 最终决策标准，如正确性、风险、实现成本、可测试性、发布安全性或产品行为。
如果用户的请求不明确，仅询问所需的最少澄清信息。否则选择合理的默认值并继续。
2. 选择委员会成员
优先考虑模型多样性。委员会不应默认使用同一模型的三个代理但不同角度；仅在当前启动配置无法提供多个有用模型，或用户明确要求使用一个模型时，才使用这种方式。如果模型多样性不可用，请简要说明，然后回退到仅视角多样性。
三人委员会的首选默认名单：
- Opus 4.7 或最强的可用 Claude/Opus 推理模型：架构、正确性和边界情况分析。
- GPT 5.5 或最强的可用 GPT/Codex 模型：基于实现的审查、可行性和测试策略。
- 开源模型，如 Kimi 2.6、GLM 5.1 或最强的可用 OSS/本地模型：逆向批判、隐藏假设和替代框架。
如果这些确切模型在当前运行环境中不可用，请使用该系列中最接近的可用模型，并注明替换。如果没有可用的开源模型，则尽可能使用第三个不同的前沿模型；否则使用最强的剩余模型，并赋予其故意对抗性或专业性的角度。
为每个成员分配一个模型和一个角度。避免角度与模型冗余；例如，不要要求所有成员进行通用架构审查。有用的角度组合包括：
- 架构师/正确性审查者；
- 实现/可测试性审查者；
- 红队、安全、性能或产品风险审查者；
- 逆向批判“反对明显解决方案”的审查者。
当不同子代理需要不同模型时，在单独的 run_agents 调用中启动它们，因为模型选择是运行范围的。如果请求的模型解析结果与预期不同，则将解析后的启动设置视为权威，除非它们使任务不可行。
使用非默认运行环境时，请为该环境选择有效的模型 ID。例如，Claude Code 可能暴露 claude-opus-4-7，Codex 可能暴露 gpt-5.5，而开源模型取决于当前配置的本地或远程提供商。不要发明不支持的模型 ID；如果所需模型不可用，请选择最接近的支持替代品，并保持预期的角度多样性。
对于只读调查，将所有子代理保持在同一个检出目录中，并明确告知它们不要编辑文件。对于实现或原型委员会，为每个本地子代理提供自己的 git 工作树和分支，以避免冲突。
3. 启动前简要说明
对于显式编排请求，简要告知用户你计划启动哪些委员会成员以及每个成员将调查什么，然后在调用 run_agents 之前等待批准。
共享的简要说明应包括：
- 仓库路径或工件位置；
- 当前分支或基础上下文；
- 需要回答的确切问题；
- 相关背景和已知问题；
- 需要检查的文件/符号（如果已知）；
- 约束条件，特别是只读/不提交/不创建 PR；
- 预期的报告格式。
保持启动提示足够简短，以便任务标题保持紧凑。如果长简要说明导致启动验证问题，请使用最小提示启动，然后立即将完整简要说明发送给子代理。
4. 要求结构化报告
要求每个委员会成员返回：
- 检查的确切文件路径、符号、文档或证据；
- 当前行为或当前实现；
- 正在评估的替代方案；
- 正确性风险和边界情况；
- 实现和测试成本；
- 建议：保持当前方法、采用替代方案或使用混合方案；
- 置信水平和未知因素。
鼓励独立性。除非你有意进行第二轮批判，否则不要将一个子代理的发现分享给其他子代理。
5. 收集报告
在报告到达时阅读完成消息。不要仅依赖生命周期成功；有用的输出在子代理的报告中。
如果报告缺少关键证据或包含未经支持的声明，请向同一子代理发送有针对性的后续问题，而不是启动替代代理。重用现有子代理进行后续问题，因为它们保留上下文。
6. 综合建议
根据证据质量比较报告，而不是按投票计数。在最终答案中：
- 以建议开头；
- 指出共识和分歧；
- 解释为什么推荐的选项在决策标准上胜出；
- 明确解决用户提出的问题；
- 包含相关文件路径/符号，但不要使答案过载；
- 区分“立即执行”和可选的未来加固；
- 提及置信水平和重大未知因素。
优先使用简洁的决策备忘录，而不是转录摘要。用户需要提炼后的建议，而不是每个中间细节。
最终答案模板
除非任务要求不同格式，否则使用以下结构：
## 建议
[一两句话说明决策。]
## 原因
- [关键原因1]
- [关键原因2]
- [关键原因3]
## 权衡与风险
- [风险或注意事项]
- [测试/发布影响]
## 最终决定
[具体下一步：合并当前更改、采用替代方案、混合方案、运行测试等。]
实用说明
- 如果委员会是只读的，告知子代理不要修改文件、提交、创建分支或打开 PR。
- 如果委员会涉及 PR 或分支工作，请遵循仓库的正常版本控制规则，并对并行本地编辑使用隔离的工作树。
- 如果委员会涉及代码审查反馈，仅在底层问题实际解决后才将审查评论标记为已解决。
- 除非用户明确要求，否则不要在面向用户的摘要中暴露内部子代理 ID。
