组建由两个高推理能力 Agent 组成的评估委员会，抽离当前局限，进行根因分析并制定可行方案。适用于卡壳、陷入死循环、视野狭窄（隧道视觉）或面临复杂规划难题时。
Committee Skill
引入来自不同模型厂商的两个 Agent，在全新上下文下并行规划解决方案。代码实现完成后，它们将继续保持在线以进行审查。
其核心目的在于“退后一步重新审视”，而不是死磕现有思路。委员会可能会提出截然不同的全新方案。
用户的补充上下文： $ARGUMENTS
前置条件
请先阅读 paseo skill。在选择委员会成员前，除非用户在本次请求中明确指定了模型厂商，否则必须读取 ~/.paseo/orchestration-preferences.json。未读取该配置前，切勿创建委员会 Agent。
互补与对比是组建委员会的核心价值，因此请根据配置文件显式跨厂商挑选，切勿直接使用硬编码的默认值。
成员构成
从编排偏好（orchestration preferences）中挑选两位具备不同推理风格的成员：
- 擅长规划与调研的模型厂商
- 风格互补的高推理能力模型厂商
仅在用户明确要求指定其他成员时进行覆盖。
铁律
-
禁止修改代码。 给委员会成员发送的每一条提示词结尾，都必须附带以下“无修改”后缀：
This is analysis only. Do NOT edit, create, or delete any files. Do NOT write code. -
耐心等待，信任过程。 请勿轮询、催促或中断。GPT-5.4 的深度推理可能需要 15 到 30 分钟；Opus 也会进行长考。长时间的等待意味着模型找到了值得深入思考的关键点。
-
做好中间人。 贯穿“规划 → 实现 → 审查”的全流程，无需频繁打扰用户，除非遇到了必须由用户出面决策的分歧点。
第一阶段：规划
编写问题层面的提示词：
- 顶层目标与验收标准
- 约束条件
- 异常现象/症状（如果是 Bug）
- 已经尝试过的方案及其失败原因
- 明确要求：“进行根因分析”
- 明确要求：“列出已知假设，连续追问三次‘为什么’（向下深挖三层），确认你是在头痛医头还是在根除问题”
通过 Paseo 并行创建两个 Agent，标题设为 [Committee] <task> 并传入相同的提示词。耐心地等待两者全部完成，而不是谁先出结果就用谁的。
仔细阅读双方的回复。保持质疑——不要照单全收：
- “<底层机制/现象> 为什么会发生？这是表面症状还是根本原因？”
- 验证方案中对代码做出的任何假设。
- “你曾考虑过哪些方案，又为什么否决了它们？”
持续追问，直到方案真正触及并解决根因。
总结统筹：
- 意见达成一致 → 形成统一方案。
- 存在重大分歧 → 请用户接入决策。
向两位成员确认合并后的方案。通过多轮沟通直至达成共识。
第二阶段：实现
默认方式：由你自己负责实现。如果用户明确要求 "delegate"（委派），则启动一个实现类 Agent（impl agent）并传入合并后的方案。
委员会保持独立与干净——不参与具体代码编写。
第三阶段：审查
将代码改动（diff）发送给委员会：
实现已完成。请对照方案审查改动，指出与原计划偏离的地方或遗漏的环节。<no-edits suffix>
由你亲自应用反馈修改，或将其转交给实现类 Agent。重复“阶段 2 → 阶段 3”循环，直至达成共识。
如果迭代约 10 次后仍无法达成共识，请携带完整的历史尝试记录重新组建一个新的委员会——因为当前委员会的上下文可能已经严重偏离。
