pcommittee (雙智能體根源分析委員會)

pcommittee（雙智能體根源分析委員會）

概述

兩個來自不同模型家族的代理，面對同一個問題，各自擁有全新的上下文背景。它們會平行分析問題；你讓他們針對分歧點進行辯論；你彙整最終保留下來的見解。然後由你來實作——委員會絕不觸碰任何檔案。

何時值得付出這個成本： 你已經在同一個問題上繞了兩次圈子、錯誤沒有明顯的根本原因，或是一個計劃的成本高到值得在執行前先聽取第二和第三意見。兩個 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 建立的檔案是此執行階段專用的，且只有你可讀取。

以回答語言開頭，即使用者對話所使用的語言（Answer in <語言>.）——成員會以提示中使用的語言回答；一個使用某種語言的對話，卻收到兩份另一種語言的報告，會在彙整時造成不必要的摩擦。

[使用者對話的語言，作為一個指令：「以 <該語言> 回答。」]

## 問題
[什麼地方出錯了或尚未決定。是症狀，而不是你的推測——你的推測是你想被驗證的東西。]

## 已知資訊
[事實、測量數據、錯誤訊息、逐字引述。不是結論。]

## 已嘗試過的方法
- [方法] — [發生了什麼事，為何放棄]

## 應查看的位置
- `/絕對/路徑/檔案.ts` — [它是什麼以及為什麼重要]

## 我希望得到的結果
根本原因分析和一份行動計劃。說明你的信心程度，並指出什麼情況可以推翻你的診斷。如果問題本身的框架就是錯誤的，請先說明這點。

此為純分析。請勿編輯、建立或刪除任何檔案。請勿撰寫任何程式碼。

將你自己的假設排除在提示之外，否則你只會得到以不同措辭重複兩次的相同答案。如果你必須提及它，請將其標記為一個需要被挑戰的假設。

2. 將兩者都衍生為此工作階段的子程序。 首先確認供應商可用性，與 pspawn 的步驟 1 完全相同（<此技能的基礎目錄>/../pspawn/SKILL.md）。然後，在同一個回應中（以便它們平行思考），執行：

paseo run --no-wait --json --provider '<claude/最新-opus>' --thinking xhigh \
  --mode bypassPermissions --title "[委員會 A] <主題>" "$(cat <提示檔>)"
paseo run --no-wait --json --provider '<codex/最新>' --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 呼叫中使用 run_in_background: true 執行 paseo wait <id-a> --json; paseo wait <id-b> --json，並從 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，則可以回退使用中斷（interruption）。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 的退出碼	它在 idle、permission 和 error 狀態下都會返回 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——一個代理、一個意見，成本僅為一小部分