pcommittee（双智能体根因分析委员会） 是做什么的？
概述
两个智能体，两个模型家族，同一个问题，双方拥有全新的上下文。它们并行分析；你让它们在分歧之处争论；你对幸存的观点进行综合。然后你去实施——委员会永远不会触碰文件。
何时值得这么做： 你已经在同一个循环里打转两次，bug没有明显的根因，或者一个计划成本高到值得在做之前听听第二和第三种意见。两个xhigh智能体并不便宜。要单一意见请使用padvisor；要把工作交出去请使用pspawn或phandoff。
生成的智能体可以做什么。 两者都以团队默认设置运行，无需权限提示（Claude上的bypassPermissions，Codex上的full-access），但它们是通过指令设置成只读的，而不是通过模式：提示中的“不编辑”后缀阻止它们更改文件。如果团队希望更多权限，可以在仓库的AGENTS.md中要求（这也是一条指令），或者通过Claude Code的permissions.deny规则阻止，这些规则在bypassPermissions下仍然适用。
调用
/pcommittee <问题> — 默认配对如下；用户指定的成员将替代它。
组成
对比是机制，而不是锦上添花。来自同一家族的两个智能体会产生两次相同的盲点，并把手机为确认。
默认委员会配对 claude 和 codex；两者都必须在paseo provider ls中显示为available和Enabled：
- 成员A：
paseo provider models claude列出的最新Opus（例如claude/claude-opus-5-5）· 推理模式xhigh· 模式bypassPermissions - 成员B： Codex的最新模型，
paseo provider models codex列表中的第一个ID · 推理模式xhigh· 模式full-access
从这些列表中读取ID，永远不要凭记忆。Claude成员使用普通ID，即1M模型（pspawn解释了为什么没有[1m]）。两个成员都无需权限提示运行，就像每次生成一样（团队默认）；是“不编辑”后缀，而不是模式，阻止它们更改文件。
如果用户指定了成员，则使用那些成员。如果只有一个家族可用，则说明情况并运行padvisor，而不是假装一个成员委员会是委员会。
步骤
1. 编写一个统一的问题提示。 两个成员都获得完全相同的文本——不同的提示会使分歧成为你措辞的人为产物，而不是真正的分歧。
将其写入一个单独的文件，并将"$(cat <提示文件>)"传递给两个生成操作。 两次输入相同的heredoc会使文本无声地发生漂移；使用文件使一致性成为结构性的，而不是需要小心维护的。使用mktemp创建文件，并使用它打印的路径作为<提示文件>：/tmp中的固定名称会与另一个会话的委员会冲突，并且所有用户都可读，而mktemp文件是本次运行新创建的，只有你可读。
以用户对话所使用的语言开头（用<语言>回答。）——成员会以提示所用的语言回答，而用一种语言对话、两份另一种语言的报告，在综合时会带来不必要的摩擦。
[用户对话的语言，作为指令："用<该语言>回答。"]
## 问题
[哪里出了错或待决定。症状，而不是你的理论——你的理论是你想被检验的东西。]
## 已知信息
[事实、测量结果、错误消息、原文。不是结论。]
## 已经尝试过的方法
- [方法] — [发生了什么，为什么放弃了]
## 需要查看的位置
- `/绝对/路径/文件.ts` — [它是什么以及为什么重要]
## 我希望获得的结果
一份根因分析和一份计划。说明你的信心水平，并指出什么会证伪你的诊断。如果问题的框架本身就是错误的，请首先说明。
这只是分析。不要编辑、创建或删除任何文件。不要编写代码。
将你自己的假设排除在提示之外，否则你会收到两份措辞不同的相同回答。如果你必须提及它，请将其标记为需要被攻击的假设。
2. 将两者生成为当前会话的子进程。 首先检查提供者可用性，完全按照pspawn的步骤1（<本技能基本目录>/../pspawn/SKILL.md）。然后，在同一个响应中（以便它们并行思考）：
paseo run --no-wait --json --provider '<claude/newest-opus>' --thinking xhigh \
--mode bypassPermissions --title "[委员会A] <主题>" "$(cat <提示文件>)"
paseo run --no-wait --json --provider '<codex/newest>' --thinking xhigh \
--mode full-access --title "[委员会B] <主题>" "$(cat <提示文件>)"
在paseo下，两者会自动进入当前会话的工作区，作为当前会话的子进程——并且保持这样：不要分离它们。委员会属于这个问题；归档此会话也会归档它们，这正是应该发生的。在paseo外部，添加--workspace <id>，像pspawn的步骤2那样查找一次。
3. 等待两者完成——每个成员一次paseo-notify，然后结束你的回合。
paseo-notify <id-a>; paseo-notify <id-b>
每个成员的消息都会独立到达。如果一个已就绪而另一个尚未完成，就再次结束你的回合；第二条消息会唤醒你。finished its turn → 它已回答。is waiting for a permission → 有一个权限请求在等待你。stopped with an error → 说明情况并读取其日志；不要静默地重新生成。使用量限制不会唤醒你：paseo-limit-watch会恢复成员并重新激活监听（如果其cron行已安装，请参阅README）；如果没有安装，请在重置后自行检查成员。成员通常运行15-30分钟。永不轮询，永不sleep，永不发送催促消息。
在paseo外部（无$PASEO_AGENT_ID）：在一次bash调用中使用paseo wait <id-a> --json; paseo wait <id-b> --json，并设置run_in_background: true，然后从JSON中读取每个status，绝不依赖退出码。
关于permission（在bypass和full-access中较少见，但rm -rf仍然会提示）该成员会停滞，无人监视。读取它（paseo permit ls），确定它是否在你给出的授权范围内，然后使用paseo permit allow <agent-id> <request-id>或deny（两个ID均来自paseo permit ls），并重新激活paseo-notify。超出授权范围或不确定时→询问用户，不要替他们批准。
4. 读取两者。
paseo logs <id> --filter text --tail 3
pagent.py <id> -t -n 3 --full（<本技能基本目录>/../pagent/）功能更丰富，带有时间戳，并且可以同样读取Claude和Codex成员。
5. 让它们争论。 这一步是让委员会值得两个智能体的关键——跳过这一步只会留下两份报告而没有解决方案。
找出它们真正分歧的地方——不同的根因、不同的修复方案、不同的风险评估。忽略措辞和重点的差异；那些不是分歧。
对于每个真正的分歧，将对方的论点发送给每个成员：
paseo send --behavior steer --no-wait <id-a> "成员B得出结论<X>，理由如下：<原文推理>。直接回应：B哪里错了，或者你是否错了？如果B是对的，就改变你的立场——如果你改变了，请直接说出来。"
paseo send --behavior steer --no-wait <id-b> "成员A得出结论<Y>，理由如下：<原文推理>。直接回应：A哪里错了，或者你是否错了？如果A是对的，就改变你的立场——如果你改变了，请直接说出来。"
较长的原文推理更容易通过文件传递：写入消息并使用paseo send --behavior steer --no-wait --prompt-file <文件> <id>。如果提供者不接受steering，可以回退到中断。paseo send会恢复已归档的智能体——先检查paseo inspect <id> --json中的ArchivedAt；不要恢复已归档的成员。
--no-wait在这里是强制性的。 普通的paseo send会阻塞直到智能体完成——两次阻塞式发送会使成员顺序执行而不是并行执行，而且第一个就会突破10分钟的前台Bash上限。同时启动两者非阻塞式，然后再次激活两个监听（步骤3）并再次读取（步骤4）。两轮通常就足够了。如果两轮后它们仍然存在分歧，请停止并将分歧作为结果报告——两个强大模型之间真正的未解决分歧本身就是关于问题的一个真实发现，而通过发送第三轮来人为制造共识会破坏这一点。
6. 为用户进行综合：
- 双方同意什么——这是支撑点
- 它们在哪里分歧，以及如何解决（或未解决）
- 你自己的解读，标记为你的
- 你现在会遵循的计划
7. 归档两者 —— 对每个使用paseo archive <id>——除非用户希望继续询问它们。
常见错误
| 错误 | 修复方法 |
|---|---|
| 两个成员来自同一个提供者家族 | 对比是机制——claude + codex |
| 每个成员提示不同 | 一个文件，"$(cat …)"传入两个生成操作——两个heredoc会漂移 |
| 未指定回答语言 | 成员会以提示所用的语言回答；以用户的语言开头 |
| 在提示中将你自己的假设作为事实陈述 | 省略它，或将其标记为需要攻击的假设 |
| 跳过争论轮次 | 两份报告不是委员会——第5步是价值所在 |
| 在第三轮强制共识 | 两个强模型之间未解决的分歧就是发现 |
信任paseo wait的退出码 | 对于空闲、权限和错误，退出码都是0——从--json读取status |
| 前台等待 | run_in_background: true；10分钟的Bash上限会杀死等待，而不是智能体 |
Codex成员保持默认模式，或claude保持auto | codex → full-access，claude → bypassPermissions（团队默认）；保持默认模式的成员会在无人回答的提示处停滞 |
| 轮询/催促消息 | 每个成员使用paseo-notify并结束你的回合；成员需要15-30分钟推理 |
第二轮使用普通paseo send | 它会阻塞直到完成——两个都使用--no-wait，然后步骤3 |
| 省略“不编辑”后缀 | 两个成员会开始实现你让它们分析的东西 |
分离成员，或env -u PASEO_AGENT_ID | 它们本来就是当前会话的子进程：会话归档时它们随之结束 |
| 对一个小问题运行委员会 | padvisor——一个智能体，一个意见，成本的一小部分 |