dispatching-parallel-agents

概觀

這個技能在做什麼

dispatching-parallel-agents 示範如何將多個彼此獨立的任務分派給不同、專門化的 agents，並讓它們平行運作。每個 agent 都會有自己的精簡情境、指示與目標，不會繼承你主工作階段中的歷史紀錄或狀態。

核心概念很簡單：當你面對多個互不相關的問題時，不要把所有事情都塞給一個超載的 agent。你應該：

• 辨識彼此獨立的問題領域
• 每個領域建立一個 agent
• 只給每個 agent 它需要的情境
• 讓它們同時工作，而你負責協調

這種編排模式可以在更短的實際時間內完成更多工作，特別適合處理彼此無關的測試失敗、不同子系統的除錯，或同時探索多種解法選項時使用。

適合哪些人使用

如果你符合以下情境，這個技能會很適合你：

• 建置或維運 multi-agent systems 或 agent 型工作流程
• 在大型程式碼庫上執行 AI 協助的 除錯、測試或分析
• 需要同時 分流與處理多個錯誤或事故
• 在意 情境隔離，不希望無關的歷史紀錄在任務之間互相「外洩」

特別適合已經在用 agents 處理複雜工作、但希望對「一次處理多個獨立任務」有更系統化、可重複模式的開發者、SRE、QA 工程師與工作流程設計者。

它解決哪些問題

當你有 2 個以上彼此不共享狀態、且不依賴彼此結果 的任務時，就可以使用 dispatching-parallel-agents。例如：

• 多個失敗的測試檔，各自觸及不同子系統
• 來自不同使用者回報的多個不相關 bug
• 平行程式碼庫分析（例如這邊做 security scan，那邊做 performance review）

相較於：

• 依序 調查每一個問題，或
• 要求單一 agent 一次處理所有失敗案例

你會改成：

• 針對每個問題建立不同的 agents
• 給每個 agent 自己整理好的情境
• 平行執行，最後再整併它們的輸出

這樣可以讓每個 agent 更專注、減少情境雜訊，也讓整體調查流程更快結束。

什麼時候不適合用這個技能

在以下情況，dispatching-parallel-agents 不 是理想做法：

• 任務 共享關鍵狀態，且必須在所有步驟中保持一致
• 工作必須照 嚴格順序 進行（步驟 B 依賴步驟 A）
• 所有 agents 都必須即時看到同一份、持續演進的情境

在這些情況下，比較適合使用單一 agent 並小心維護情境，或採用 串行工作流程，而不是平行派發。

使用方式

1. 安裝技能

要從 obra/superpowers repository 新增 dispatching-parallel-agents 技能，請使用：

npx skills add https://github.com/obra/superpowers --skill dispatching-parallel-agents

這會拉取技能定義與相關素材，來源為：

• Repository：https://github.com/obra/superpowers
• 技能路徑：skills/dispatching-parallel-agents

安裝完成後，在你的 skills 目錄下找到相對應的技能檔案（確切位置視你的 skills runner 或工具而定）。

2. 理解核心模式

dispatching-parallel-agents 的核心，是一個決策模式，幫助你判斷何時應該平行派發 agents。上游技能用一個簡單流程來說明：

• Multiple failures?
  • 如果沒有，你大概只需要一個 agent。
• Are they independent?
  • 如果 no – related，就用 single agent，讓它掌握完整全貌。
  • 如果 yes，往下判斷。
• Can they work in parallel?（沒有共享 state，也沒有必須序列化的共享資源）
  • 如果 yes，就使用 parallel dispatch。
  • 如果 no – shared state，則改用 sequential agents。

每次你在思考究竟要建立多個 agents，還是只用一個時，都會用到這套邏輯。

3. 先從 SKILL 檔開始

安裝完成後，先打開：

• SKILL.md

這個檔案包含 dispatching-parallel-agents 模式的標準說明，包括：

• 什麼情況下應該使用這個技能
• 概念性總覽
• 如何依問題領域來拆分與結構化 agents 的指引

建議先從頭到尾看過一遍；這是理解此技能預期用法的主要參考。

4. 找出彼此獨立的問題領域

在你派發 agents 之前，先把任務清楚拆分：

1. 列出目前所有問題或目標（例如失敗的測試、bug 回報、分析任務）。
2. 把它們分組成 不共用 state、也不共用邏輯 的 domains。例如：
   • Domain A：ui/ components 的 frontend 測試失敗
   • Domain B：api/ services 的 backend 錯誤
   • Domain C：jobs/ scheduler 的間歇性失敗
3. 檢查是否真獨立：
   • 是否走不同的 code paths 或子系統
   • 是否沒有共用可變 state 或高度耦合的邏輯

只有在你確定它們是獨立之後，再讓它們平行執行。

5. 為每個 domain 建立一個具隔離情境的 agent

對於每一個獨立的 domain：

1. 建立一個新的 agent（依你使用的 framework 來表達，例如新的 agent config 或新的 conversation/session）。
2. 不要重用你的主工作階段情境。改為明確提供：
   • 該領域相關的檔案、logs 或設定片段
   • 針對該領域的精簡問題說明
   • 該領域專屬的限制條件或目標
3. 讓 prompt 保持聚焦。例如：

“You are an agent focused only on debugging front-end tests under ui/. Ignore other systems. Here are the failures and relevant files…”

技能中的指引強調，agents 不應繼承你工作階段的情境或歷史。這能讓它們保持專注，也避免不同調查之間的情境互相污染。

6. 平行執行 agents 並協調結果

當各個 domain 專屬的 agents 都設定好之後：

1. 使用你的 orchestrator 或 scripts，平行派發它們。
2. 讓每個 agent 獨立運作，直到產出明確的階段性結果（例如推測的 root cause、一個修補方案或一串後續問題）。
3. 作為協調者（可以是人、也可以是 supervising agent）：
   • 收集所有 agents 的輸出
   • 比較、驗證或整併它們的發現
   • 決定要採納哪些建議

負責「實際讓 agents 並行執行」的是 orchestration layer（不包含在這個技能裡）；這個技能聚焦在 何時與如何 設計那種平行化，而不是特定的執行環境。

7. 當任務後來被證明是相關時，調整策略

有時你會在調查途中發現，原本以為獨立的兩個問題其實有關聯：

• 共用同一個 root cause
• 同一個設定錯誤
• 系統之間存在隱藏耦合

這時你應該：

• 不再把它們當成分離的 domains
• 把情境整併到一個 single agent 或新的共享工作階段
• 讓那個 agent 在統一的問題空間中推理

dispatching-parallel-agents 模式刻意保持彈性：在安全時鼓勵平行處理，一旦發現依賴關係，就回到單一情境。

8. 將此模式套用到你的技術堆疊

Repository 著重在概念模式，但你可以在許多環境裡加以實作：

• Agent frameworks： 使用其提供的 primitives 建立多個 agents，各自擁有獨立的 memory 或 context stores。
• Custom scripts： 直接呼叫你的 LLM provider，針對每個 domain 使用不同 prompts 與輸入組合。
• CI/CD 或自動化 pipelines： 啟動由各 domain 專屬 agent 駕馭的獨立 jobs 或 stages，並行執行。

關鍵不在於工具，而在於紀律：

• 明確的 domain 邊界
• 每個 agent 擁有隔離的情境
• 有計畫地整併結果

常見問題（FAQ）

實務上來說，什麼是 dispatching-parallel-agents？

dispatching-parallel-agents 是一個技能，教你如何設計 multi-agent 工作流程，讓每個獨立任務都有自己的 agent、情境與指示。與其讓一個萬用型 agent 處理所有事情，你會在任務不相關、且不共享 state 的情況下，啟動多個專注的 agents，並讓它們平行運作。

什麼時候應該使用 dispatching-parallel-agents？

當你有 2 個以上獨立任務，且：

• 不依賴彼此的輸出
• 不需要共享、可變的 state
• 可以安全地同時執行

就很適合使用這個技能。

典型案例包括多個彼此無關的測試失敗、不同來源的 bug 回報，或在不同子系統上各自進行獨立分析。

什麼時候應該避免使用這個模式？

在以下情況，請避免使用 dispatching-parallel-agents：

• 任務共享關鍵 state，且必須保持同步
• 工作流程本質上是串行的（後續步驟需要依賴前一步的結果）
• 你需要橫跨整個任務的一條連續敘事或完整歷史

這些情境下，比較適合使用單一 agent，或嚴格排序的多步驟工作流程，而不是平行派發。

要如何安裝 dispatching-parallel-agents？

從 obra/superpowers repository 安裝技能，使用：

npx skills add https://github.com/obra/superpowers --skill dispatching-parallel-agents

安裝後，打開 dispatching-parallel-agents 目錄中的 SKILL.md，閱讀完整的概念導引。

這個技能有提供可直接執行的程式碼嗎？還是只有指引？

上游技能主要是一份定義在 SKILL.md 中的 概念與教學指南。它說明了如何決策與設計平行派發 agents 的模式，你需要自行在自己的 agent framework、scripts 或 orchestration 工具中套用這個模式。

這怎麼幫助處理多個測試失敗或多個 bug？

與其把一長串互不相關的失敗案例丟給單一 agent，dispatching-parallel-agents 建議你：

• 依子系統或 domain 將失敗案例分組
• 為每一組建立專用 agent，提供相關的測試輸出與程式碼
• 讓這些 agents 平行執行

這樣可以減少每個 agent 的雜訊，並加快整體診斷時間。

可以把這個技能跟其他工作流程或編排技能一起用嗎？

可以。dispatching-parallel-agents 很適合搭配其他 agent-orchestration 與 workflow-automation 模式一起使用。你可以例如使用另一個技能來管理某個 domain 內部的串行步驟，再在更高層級用 dispatching-parallel-agents 把不同 domains 分派給多個平行運作的 agents。

安裝後，我應該先看哪些檔案？

請從這裡開始：

• SKILL.md —— dispatching-parallel-agents 模式的主要說明文件

把它當作判斷何時應該平行派發 agents，以及如何設計它們情境結構的主要參考。接著再把這些概念套用到你自己的程式碼庫、CI pipeline 或 agent framework 中。