需要多模型/多视角评审技术决策时：用子代理委员会比较证据并给…

当用户要求委员会、第二意见、多个 agent/模型并行评估、红蓝队比较或在竞争技术方案间做判断时使用。

适用场景

解决思路

1. 先按不同模型、再按不同指派视角来组织多个子代理调查同一问题，并将报告综合成一个建议。
2. 用一句话陈述委员会要回答的决策。
3. 确定正在评审的竞争选项或假设。
4. 确定要检查的代码库、分支、PR、issue、设计或工件。
5. 确定各代理是只读还是可以做代码修改。
6. 确定最终决策标准，如正确性、风险、实现成本、可测试性、发布安全或产品行为。
7. 如果用户请求模糊，只问所需的最小澄清；否则选择合理默认并继续。
8. 优先选择模型多样性；不要默认三个同一模型不同角度；只有在启动配置无法提供多个有用模型或用户明确要求单模型时才这样做。
9. 如果无法获得模型多样性，先简短说明，再退回到仅视角多样性。
10. 三人委员会的优先默认阵容：Opus 4.7 或可用的最强 Claude/Opus 推理模型，负责架构、正确性和边界情况分析。
11. 三人委员会的优先默认阵容：GPT 5.5 或可用的最强 GPT/Codex 模型，负责基于实现的评审、可行性和测试策略。
12. 三人委员会的优先默认阵容：开源模型如 Kimi 2.6、GLM 5.1 或可用的最强 OSS/本地模型，负责逆向批评、隐藏假设和替代框架。
13. 如果具体模型在当前 harness 中不可用，使用该系列最接近的可用模型并注明替换。
14. 如果没有任何开源模型，尽量使用第三个不同的前沿模型；否则使用剩余最强模型并配以刻意对抗或专家角度。
15. 为每个成员分配模型和角度。避免角度与模型冗余；例如不要让所有成员做通用架构评审。
16. 有用角度组合：架构师/正确性评审者。
17. 有用角度组合：实现/可测试性评审者。
18. 有用角度组合：红队、安全、性能或产品风险评审者。
19. 有用角度组合：逆向“论证反对显然方案”评审者。
20. 当不同子代理需要不同模型时，用单独的 run_agents 调用启动它们，因为模型选择是 run-wide。
21. 如果请求的模型解析结果与预期不同，以解析后的启动设置为准并继续，除非这使任务不可行。
22. 使用非默认 harness 时，选择该 harness 的有效模型 ID。例如 Claude Code 可能暴露 claude-opus-4-7，Codex 可能暴露 gpt-5.5，开源模型取决于当前配置的本地或远程 provider。
23. 不要发明不支持的模型 ID；如果所需模型不可用，选择最接近的支持替代品并保持预期角度多样性。
24. 对于只读调查，让所有子代理保持在同一 checkout，并明确告诉他们不要编辑文件。
25. 对于实现或原型委员会，给每个本地子代理自己的 git worktree 和 branch，以免冲突。
26. 对于明确的编排请求，简要告诉用户计划启动哪些委员会成员以及每个成员调查什么，然后在调用 run_agents 前等待批准。
27. 共享简报应包含：仓库路径或工件位置。
28. 共享简报应包含：当前分支或基础上下文。
29. 共享简报应包含：要回答的确切问题。
30. 共享简报应包含：相关背景和已知关注点。
31. 共享简报应包含：已知需要检查的文件/符号（如果已知）。
32. 共享简报应包含：约束，尤其是只读/无 commit/无 PR。
33. 共享简报应包含：期望的报告格式。
34. 保持启动提示足够短，使任务标题保持紧凑。
35. 如果长简报导致启动验证问题，先用最小提示启动，随后立即把完整简报送给孩子代理。
36. 要求每个委员会成员返回：检查过的确切文件路径、符号、文档或证据。
37. 要求每个委员会成员返回：当前行为或当前实现。
38. 要求每个委员会成员返回：正在评估的替代方案。
39. 要求每个委员会成员返回：正确性风险和边界情况。
40. 要求每个委员会成员返回：实现和测试成本。
41. 要求每个委员会成员返回：建议保持当前方案、采用替代方案或使用混合方案。
42. 要求每个委员会成员返回：置信水平和未知项。
43. 鼓励独立性。不要把某个孩子的发现分享给其他人，除非你有意进行第二轮批评。
44. 报告到达时读取完成消息。不要只依赖生命周期成功；有用输出在孩子的报告中。
45. 如果报告缺少关键证据或提出无支持的主张，向同一个孩子发送聚焦的后续问题，而不是启动替代代理。复用现有孩子做后续，因为他们保留上下文。
46. 按证据质量比较报告，而不是按投票数。
47. 最终答案中：先给出建议。
48. 最终答案中：指出共识和分歧。
49. 最终答案中：解释为什么推荐选项在决策标准上胜出。
50. 最终答案中：明确回应用户陈述的关注点。
51. 最终答案中：包含相关文件路径/符号，但不要让答案过载。
52. 最终答案中：区分“现在做”和可选的未来加固。
53. 最终答案中：提及置信度和实质性未知项。
54. 优先写简洁的决策备忘录，而不是转录摘要。用户需要提炼后的建议，不是每个中间细节。
55. 除非任务需要不同形式，使用以下最终答案模板： ## Recommendation [一到两句给出决策。] ## Why - [关键原因 1] - [关键原因 2] - [关键原因 3] ## Tradeoffs and risks - [风险或注意事项] - [测试/发布影响] ## Final call [具体下一步：合并当前改动、采用替代方案、混合方案、运行测试等。]
56. 如果委员会是只读的，告诉孩子们不要修改文件、commit、创建 branch 或打开 PR。
57. 如果委员会涉及 PR 或 branch 工作，遵循仓库的正常版本控制规则，并对并行本地编辑使用隔离的 worktree。
58. 如果委员会是关于代码评审反馈，只有在底层问题实际解决后才把评审评论标记为已解决。
59. 不要在面向用户的摘要中暴露内部子代理 ID，除非用户明确要求。

适用边界 · 注意事项

• 当任务只是简单事实查询、机械执行或不需要判断/权衡时，不要启动多模型委员会。
• 当运行环境不支持子代理/多模型编排，且用户不接受仅视角多样性回退或人工多角色评审时，不适合使用。
• 当低风险、低影响且需要快速低延迟回答时，多模型委员会成本过高、延迟过大，不适合使用。