launch-sub-agent

launch-sub-agent skill 總覽

launch-sub-agent skill 能幫你針對特定任務派發一個聚焦的子代理，而不是把同一條對話線程塞得過滿。它最適合正在建置或操作 launch-sub-agent for Multi-Agent Systems 模式多步驟工作流程的使用者：像是程式開發、研究、審查、設計或驗證這類，適合使用隔離上下文與刻意挑選模型的任務。

launch-sub-agent skill 擅長什麼

launch-sub-agent skill 的核心價值在於編排：它會分析任務、選擇合適的模型層級、視需要匹配專門的 agent，然後在內建驗證的情況下啟動工作。當你想減少上下文汙染、又希望輸出更有紀律時，它會比一般提示詞更有用。

誰應該安裝它

如果你經常把工作切成子任務、需要監督其他 agents，或想要一套可重複的方式依複雜度來分派任務，就應該安裝 launch-sub-agent。它特別適合已經在使用 agentic 工作流程的團隊；真正的問題通常不是「模型能不能回答」，而是「要怎麼乾淨地路由任務，並且驗證結果？」

什麼情況下很適合

當輸入可以被框成一個界線明確的指派時，launch-sub-agent skill 就很適合：實作功能、調查問題、比較方案、撰寫文件，或審查程式碼。若是模糊腦力激盪、需要高度互動式協作，或必須保留完整對話歷史才能完成的工作，它就沒有那麼實用。

如何使用 launch-sub-agent skill

安裝並檢視這個 skill

先透過你的 skill manager 使用已發布的 skill 安裝路徑安裝，接著先打開 SKILL.md。就這個 repository 來說，沒有額外的支援資料夾可以瀏覽，所以主要的權威來源就是 skill 檔本身。實際的 launch-sub-agent 安裝流程可以這樣做：安裝、閱讀 SKILL.md，再依你的環境調整命令與參數模式。

把模糊目標轉成可執行任務

這個 skill 最適合處理足夠明確、可以委派的任務。好的輸入會描述目標、預期輸出、限制，以及任何相關的 repo 或環境細節。舉例來說，不要只寫「修 auth」，而是改成：Implement password reset for the existing Express app, preserve current API shape, and output a patch summary to docs/reset-plan.md。

提示詞中要提供什麼

launch-sub-agent 的使用模式預期會有任務描述，以及可選的路由提示，例如 --model、--agent 和 --output。只有在它們能增加清晰度時才使用。如果你已經知道工作很複雜，就選更強的模型；如果你知道子代理應該是專門化的，就明確指定；如果你需要把交付內容存到某個位置，就先把輸出路徑寫進去。

先讀這些檔案

先從 SKILL.md 開始，因為它定義了編排順序、任務分析與驗證要求。接著再查看任何說明周邊 agent 系統的 repo 層級文件，尤其當你要把 launch-sub-agent 接到既有的 multi-agent 設定時。如果你正在改寫這個 skill，也要注意你的工具鏈是在哪裡處理模型選擇與 agent 命名。

launch-sub-agent skill 常見問題

launch-sub-agent 只適合 multi-agent systems 嗎？

它在 multi-agent systems 中最有價值，但即使是較簡單的架構，你也可以把它當作一個有紀律的子任務啟動器。核心好處是一樣的：launch-sub-agent skill 透過把單一任務隔離在單一、聚焦的執行路徑中，來減少上下文雜訊。

這和一般提示詞有什麼不同？

一般提示詞是在要一個答案。launch-sub-agent skill 比較像一層路由：它會評估任務、選擇執行策略，並加入自我檢查步驟，讓結果在回傳前更有可能先被檢視。當品質不只取決於生成內容、也取決於流程時，它就特別有用。

這對新手友善嗎？

可以，只要你能清楚描述任務就行。你不需要懂得所有 agentic 概念也能使用 launch-sub-agent，但你必須說明工作內容、邊界與期望輸出。任務界定得越好，委派效果通常越好。

什麼情況下不該使用它？

如果任務很小、純聊天性質很高，或非常依賴與同一段上下文持續來回互動，就不要用 launch-sub-agent。在這些情況下，直接提示詞通常比啟動子代理更快，也比較不脆弱。

如何改進 launch-sub-agent skill

寫出更好的任務簡報

launch-sub-agent 最強的結果，通常來自包含範圍、限制與成功標準的簡報。例如：Review this checkout flow for accessibility issues, focus on keyboard navigation and error states, and return prioritized fixes with code pointers 會比 review this flow 更可執行。

讓模型與工作難度相符

如果你知道任務需要深度推理、跨檔案分析，或對架構很敏感，就應該偏向更強的模型，而不是把選擇留成隱含狀態。如果任務只是例行、範圍狹窄，就把要求寫得簡單一點，讓 skill 能有效率地路由。好的 launch-sub-agent 使用方式，不是永遠把 agent 拉到最大，而是把規模配對到剛剛好。

要求可驗證的輸出

因為這個 skill 內建必要的自我檢查驗證，所以應該要求能被檢核的輸出：差異摘要、假設、風險、邊界情況，或測試想法。如果你希望子代理第一次就有用，就要它明確指出它不確定的地方，以及接下來需要驗證什麼。

第一次執行後持續調整

把第一次結果拿來收斂下一次的提示詞。如果子代理太發散，就縮小任務並加上明確邊界。如果它漏掉上下文，就補上相關檔案或片段。如果它錯配了 agent，就覆寫路由提示。讓 launch-sub-agent skill 變好的最快方式，是把每次執行都當成校準，而不是一次性的答案。