多代理、平行工作流與委派協作

打個比方：前面的章節教你怎麼跟一位很能幹的工程師講清楚一件事、怎麼給他留一本工作守則。這一章開始，你會發現這位工程師其實從來不是一個人——他背後隨時候著一組專職班底：一個專門讀程式碼、一個專門跑測試、一個專門排計畫、一個專門審 code。你不需要每次都自己去分派這幾位，主管（也就是你正在對話的那個 Copilot）會自己判斷什麼時候該叫誰。而當任務夠大、能拆成好幾塊互不相干的子工作，你甚至可以喊一句 /fleet，讓主管自己當協調者，把活分給好幾個分身同時做；如果任務乾脆整個大到你想直接丟出去、不佔你自己電腦資源，還能一句話委派給雲端的另一個完全獨立產品線。

「Work performed by a custom agent is carried out using a subagent, which is a temporary agent spun up to complete the task.」
（自訂 agent 的實際工作是透過 subagent 完成的——subagent 是為了完成任務而臨時生出來的代理。）

這句官方逐字，是整章的地基：custom agent 是「定義」，subagent 是「執行實體」，關係像「類別」跟「實例」。搞懂這一句，後面 14.2、14.3 兩節會清楚很多。

14.1 先建立心智地圖：Copilot 的四種「分身」

(料源：community／practice——下面「四種類型」是研究者整理的分類架構，不是 GitHub 官方逐字給出的分類名詞；但每一格描述的行為，都各自有官方文件可以個別佐證，可以放心借用這個架構理解，只是別寫成「官方稱之為」。)

多代理讀起來容易被術語繞暈，先用一張表把「Copilot CLI 到底能開出幾種分身」釘住：

本章重點放在後面兩種：Sub-agent（怎麼觸發、怎麼平行編排）跟 Cloud（怎麼委派、跟本機平行有什麼本質差異）。

14.2 內建四個專職 subagent：Explore／Task／Plan／Code-review

(料源：official，來源：GitHub Copilot CLI: Enhanced agents, context management, and new ways to install)

Copilot CLI 內建四個專職角色，不用你自己定義：

觸發方式有兩種：

1. 自動委派——你問「這段程式在幹嘛」，Copilot 自動叫 Explore；你要求跑測試，自動叫 Task。你完全不用點名。
2. 手動指定——用 /agent 指令手動挑一個角色。

多個 agent 可以平行跑，不需要你一個一個排隊等。

14.3 委派自訂 agent 成 subagent 的四種方式

(料源：official)

第 13 章教過 .agent.md 的完整 frontmatter 欄位（description 必填、tools／model／disable-model-invocation 等選填）。寫好一份自訂 agent 之後，官方給了四種讓它被實際「叫起來執行」的方式：

1. /agent 互動選單挑選——打開選單直接選。
2. 明確指令：
   複製

   Use the security-auditor agent on all files in the /src/app directory

3. 推論觸發——你描述的內容符合 agent profile 裡定義的觸發詞（例如你自訂的 "seccheck" 這類關鍵字），Copilot 自動叫用，不用你明講 agent 名字。這一步能不能發生，取決於 .agent.md 裡 disable-model-invocation 有沒有被設成 true（第 13 章提過這個欄位，預設 false＝允許自動推論）。
4. 程式化：
   複製

   copilot --agent security-auditor --prompt "Check /src/app/validator.go"

   適合寫進腳本，跳過互動介面直接指定要用哪個自訂 agent 執行單一任務。

14.4 /fleet：平行編排的核心指令

(料源：official，來源：Fleet mode、Run multiple agents at once with fleet in Copilot CLI)

第 7 章已經點過 /fleet 這個名字，說它是「Copilot CLI 自己的多代理輕量版本」，這一節把完整玩法攤開。

觸發方式

• 互動輸入 /fleet。
• 或者先走 Plan 模式，計畫產出後選「Accept plan and build on autopilot + /fleet」——這個選項等於把 14.6 的 Autopilot、本節的 Fleet 三合一啟動。

/fleet 把這個大重構拆成幾個獨立子任務平行跑

運作原理

主 agent 收到 prompt 後先判斷能不能拆成獨立小任務。能拆，它就自己當協調者（orchestrator）——官方逐字：「managing the workflow and dependencies between the subtasks」（管理子任務之間的工作流程與依賴關係）——把可平行的部分分給多個 subagent，「run the subagents in parallel, allowing the whole task to be completed more quickly」（讓 subagent 平行跑，整個任務因此完成得更快）。

模型選擇：subagent 預設用低成本模型跑，但你可以指定特定模型、或指名一個自訂 agent（例如 @test-writer）去執行特定子任務。

各 subagent 有獨立 context window——彼此看不到對方在做什麼，除非協調者主動彙整結果回報給你。

官方誠實給的限制（很重要，別無腦每次都上 /fleet）

「If your request is inherently sequential, using the /fleet slash command mode may not provide any benefit.」
（如果你的請求本質上是循序的，用 /fleet 模式未必有好處。）

再加一句更值得記住的成本警語：拆得太細，可能導致更多次 LLM 互動，成本反而比讓主 agent 直接做還高。這不是猜測，是官方明講的取捨——平行化本身不是免費的，拆分、協調、彙整都要吃 token。

14.5 併發控制與遞迴保險絲：depth 與 concurrency

多代理最怕的事，是「代理委派代理、代理又再委派代理」失控增生，Copilot CLI 用兩個維度管住這件事：

• Depth（巢狀深度）：agent 裡面再生 agent 的層數，達上限後最內層的 agent 不能再生 subagent。
• Concurrency（併發數）：整個 session tree 裡同時在跑的 subagent 數，達上限後新請求會被拒絕，直到有一個先跑完騰出位置。

v1.0.66+：usage-based billing 使用者可以直接在 /settings 裡調整這兩個值。

subagents.maxDepth：預設從 6 降到 4（v1.0.71 起）。官方 changelog 給的理由逐字精神是「curb runaway recursive sub-agent delegation」（遏止失控的遞迴子代理委派）。usage-based billing 使用者可以調到最高 128，數值會被 clamp 在 1~256 之間。

COPILOT_SUBAGENT_MAX_CONCURRENT：環境變數，啟動 CLI 前設定，用來覆寫併發上限。

COPILOT_SUBAGENT_MAX_CONCURRENT=3 copilot

跨單元對照：跟 Codex CLI 比，誰比較保守

兩邊都用「遞迴深度保險絲」防同一個問題（多代理指數爆炸），但保守程度的拿捏不同——Codex CLI 直接鎖死到「不准孫代理」，Copilot CLI 給了更寬的深度但仍是從 6 主動砍下來的收斂結果。這組對照的完整版本，見章末「對照另一套教學」卡片。

14.6 Autopilot 進階：接進自動化管線的程式化旗標

(料源：official)

第 7 章已經教過 Autopilot 的四種停止條件、--max-autopilot-continues N、「Enable all permissions」的官方原句警告（「這等於授權 CLI 可以做任何它認為完成任務所必要的改動，包含修改與刪除檔案」），這裡不重複，只補程式化、接進自動化管線這一層。

把互動時按 Shift+Tab 循環進 Autopilot 的動作，換成一行可以寫進腳本的指令：

copilot --autopilot --yolo --max-autopilot-continues 10 -p "PROMPT"

跟單純 --allow-all 的差異：--allow-all 仍是標準互動流程（逐步跑，但不用逐次核可）；Autopilot 是多步自主——Copilot 不等你輸入，自己連續跑完多個步驟，性質不同，別把兩者當同義詞混用。

建議流程：先用 Plan 模式把計畫討論出來、確認方向 → 選「Accept plan and build on autopilot + /fleet」，等於 Plan ＋ Autopilot ＋ Fleet 三合一：先把風險最高的「決定方向」這一步做完看過，剩下機械式的平行執行才放手交出去。

適合場景：目標明確的大型任務（寫測試、重構、修 CI 失敗）、批次／CI 場景——跟 14.11 談的「循序任務別硬拆」剛好是一組互補判斷：任務夠明確、夠大、能自動判定完成與否，才適合 Autopilot；任務含糊、需要你邊看邊引導，兩者都不適合。

14.7 -p 非互動模式的自動化補完：--no-ask-user、--secret-env-vars

(料源：official，來源：GitHub Copilot CLI for beginners: interactive v. non-interactive mode)

第 10 章已經整章教過 -p／-s 的權限旗標家族、排程、--model 跨供應商切換。這裡只補兩個跟「多代理／CI 自動化」場景特別相關、第 10 章沒細講的旗標：

copilot -p "只跑全部測試並回報結果；不要部署、不要讀取或修改憑證" --no-ask-user

headless 環境的認證順序：依序檢查 COPILOT_GITHUB_TOKEN → GH_TOKEN → GITHUB_TOKEN，找到第一個有值的就用。

14.8 Hooks：把生命週期掛鉤補完整

(料源：official，來源：Hooks reference)

第 12 章已經介紹過 Hooks 的基本概念跟七八個常見事件。這一節把完整的 14 個生命週期事件、三種 hook 類型、載入路徑優先序、輸入輸出契約、跟一個容易忽略的「fail-open／fail-closed」細節，一次補完。

14 個事件

三種 hook 類型

• command：本機指令，設定裡分開含 bash／powershell／command 跨平台欄位——同一支 hook 要在不同作業系統上跑，得各自準備對應腳本（第 12 章已經點過這個「一個 hook 兩份腳本」的硬性規定）。
• http：遠端 webhook，僅允許 HTTPS，除非目標是 localhost。
• prompt：CLI only，送一句 prompt 或 slash 指令觸發新的一輪互動。

{
  "preToolUse": [
    {
      "type": "command",
      "bash": "./hooks/pre-tool-check.sh",
      "powershell": "./hooks/pre-tool-check.ps1"
    }
  ]
}

載入位置（依優先序）

1. 策略級：/etc/github-copilot/policy.d/*.json（Linux／macOS）、C:\ProgramData\GitHub\Copilot\policy.d\*.json（Windows）——企業可強制下發，使用者關不掉，跟 Codex CLI 的「Managed hooks」概念一致。
2. 使用者級：~/.copilot/hooks/
3. 專案級：.github/hooks/*.json
4. 設定檔內嵌：.github/copilot/settings.json、~/.copilot/settings.json、.claude/settings.json（跨工具相容）
5. 外掛提供：各外掛自己的 hooks.json

停用所有 hooks：設定檔頂層 "disableAllHooks": true。

輸入輸出契約：exit code 決定生死，但有一個例外要記牢

preToolUse 的輸出可以回 permissionDecision: "allow"|"deny"|"ask"，決定這次工具呼叫是否放行。

exit code 的完整規則（這裡是最容易被誤解的地方，官方分得比表面看起來細）：

跨工具相容彩蛋：官方明講相容 Claude 的 matcher 語意

官方文件明講支援 PascalCase 事件名相容格式（例如把 preToolUse 寫成 PreToolUse），並且「apply Claude's matcher semantics」——*、**、空字串 matcher 對每個工具都會觸發。這代表你如果已經幫 Claude Code 寫過 hooks，理論上有機會直接沿用（規則語意層面相容），不用整套重寫。

雲代理（Copilot coding agent）的執行環境差異

委派給 14.9 要講的雲端 coding agent 時，Hooks 的行為會縮水：

• sandbox 非互動、網路受限、job 結束即銷毀。
• 只有 bash 欄位被採用（powershell 被忽略——雲端執行環境本來就是 Linux）。
• permissionRequest／notification／prompt 三種類型不觸發，因為雲端是非互動環境，工具都已經預先核可過，沒有「等你回應」這回事。

14.9 委派給雲端 Copilot coding agent：& 前綴與 /delegate

(料源：official，來源：Delegate tasks to Copilot coding agent)

任何 prompt 前面加一個 &，就等同背景委派給雲端 coding agent——終端機立即釋放，不用等。這等同 /delegate 指令的簡寫。

&幫我把 README 裡過時的安裝說明更新一下

運作方式：Copilot 在 GitHub 雲端建立分支、開 draft PR，完全在背景跑，回你一個 PR 連結 + agent session 連結。

在往下講「跟 /fleet 差在哪」之前，先把最根本的問題講清楚——這件事到底解決了你的什麼痛點，這是本章最值得放慢腳步理解的一段。

傳統的開發工作方式，本質上是單執行緒人力：你手上同時間只能真正推進一件事，一個任務沒做完，下一件事就只能排在後面等；就算你想「同時」處理兩件事，實際上做的也只是不斷手動切換 context——先把手上這一件卡在哪一步、下一步要幹嘛，硬記在自己腦子裡，切過去做另一件，等一下又要切回來，重新把前一輪的狀態喚回腦子裡。這個「切換」本身不是免費的：你切得越頻繁，花在「回想自己剛才做到哪」的時間佔比就越高，真正往前推進的產出反而更少。

雲端委派把這個限制直接拆掉。你不再被綁在「一次只能顧一件事」的單執行緒裡：改一段過時的 README、修一個小 bug、幫你去探勘另一個你還沒空看的子系統——這幾件事可以各自加一個 & 同時派出去，每一個都在 GitHub 雲端獨立跑，佔用的是 GitHub 的運算資源，不是你的注意力，也不需要你守在終端機前等它做完。你的角色從「一個人把每件事從頭做到尾」，變成「派工，然後回頭驗收」——終端機立刻釋放，你可以繼續手上正在做的事，或是接著派下一個任務；等雲端那幾個做完了，你拿到的是可以直接看、直接核可或打回去要求修改的 PR 連結，不是一堆你得自己從頭拼湊上下文才看得懂的半成品。

這正是本章一開頭「工頭帶一整組班底」那個比方裡最實在的一塊：光是班底自己會做事還不夠，真正的改變是你因此不再被「一次只能顧一件」卡住——手上這件事還在做，另外幾件已經在雲端動起來了。

14.10 三選一：/fleet vs & 雲端委派 vs 手動指定單一 agent

把前面幾節收斂成一張決策表：

14.11 現實檢查：拆太細，比不拆更貴

14.4 已經引過官方那句誠實警告：「循序任務用 /fleet 未必有好處」，這裡把這個判斷整理成可操作的心法。

多代理平行編排的成本，不是只有你分派出去的那幾個子任務各自的 token——協調者本身判斷怎麼拆、拆完怎麼彙整，也是要吃 LLM 呼叫次數的。任務拆得越細，協調開銷佔比越高；如果每塊子任務本來就很小、彼此又有先後依賴（後面的子任務得等前面的結果才能開始），拆分本身的協調成本很可能超過「平行帶來的時間節省」，結果變成又貴又沒真的比較快。

14.12 安全警語：多代理與自動化不是無風險

(料源：community／security-research——本節引用的具體漏洞案例來自 2026 上半年多篇第三方安全研究，不是 GitHub 官方逐字立場，但對「大師篇」讀者有實質警示價值，值得誠實收在這裡。)

多代理、Autopilot、雲端委派把「Copilot 自己判斷、自己動手」的範圍越開越大，安全風險自然也跟著放大。下面幾個是第三方安全研究揭露的案例，動手前務必知道：

• PromptArmor（2026）「GitHub Copilot CLI Downloads and Executes Malware」：indirect prompt injection（間接提示注入）經由被污染的 README 觸發惡意指令。研究指出，env 指令在唯讀白名單裡會被自動核可，攻擊者利用 env curl ... | sh 這類寫法繞過「外部 URL 存取」的驗證邏輯——因為驗證器沒把 curl／sh 識別成 env 的子指令。
• RoguePilot（Orca Security）：另一組獨立揭露的漏洞鏈。
• Git hook／執行檔搜尋順序劫持：Windows 上部分 AI agentic 工具，在資料夾信任提示跳出之前就先執行了 workspace 裡的 git.exe；Windows 預設搜尋順序會先查工作目錄再查系統路徑，攻擊者只要在該路徑放一個惡意同名執行檔就能劫持——這是重演 2020 年 Git Credential Manager Core 曾出過的同一種攻擊手法。
• MCP server 自動執行：多款 agentic CLI（含 Copilot CLI）在使用者按下「信任這個資料夾」的瞬間，就會執行該專案定義的 MCP server——一鍵接受資料夾信任，等於一鍵讓惡意 repo 定義的 MCP server 在無沙箱環境跑起來。
• 官方側的對照：github/copilot-cli issue #1076「Secure or Untrusted mode」，社群訴求「唯讀／不受信任模式」的討論串截至研究當下仍開放中——代表這塊防護還在補強，不是已解決的問題。

本章小結

這一章你把 Copilot CLI 從「一對一帶」升級成「帶一整組班底」：內建的 Explore／Task／Plan／Code-review 四個專職 subagent 可以自動委派也可以用 /agent 手動指定；自訂 agent（.agent.md）透過四種方式被委派成真正執行的 subagent；/fleet 讓主 agent 當協調者，把可平行的任務拆給多個 subagent 同時跑，但官方誠實警告「循序任務用了未必划算、拆太細反而更貴」；subagents.maxDepth 從 6 砍到 4 這道遞迴保險絲，跟 Codex CLI max_depth=1 是同一種防指數爆炸的設計思路，只是保守程度不同；Autopilot 跟 -p 都補上了程式化旗標，讓多代理接進真正的自動化管線；Hooks 的完整 14 個生命週期事件、三種類型、preToolUse 的 fail-closed 例外規則、以及跟 Claude 相容的 PascalCase matcher 語意，都摸過一輪；& 前綴／/delegate 委派給雲端 coding agent，跟本機 /fleet 是完全不同的執行環境，不要混為一談。最後你也老實看了一次多代理與自動化系統的真實安全風險——授權範圍越大，一旦被注入，代價也越大。

動手試試

1. 在你已經在用 Copilot CLI 的專案裡輸入 /fleet，挑一個真的能拆成兩三個獨立子任務的工作（例如「同時探勘 A、B 兩個不相干的子系統」），觀察它怎麼分派、怎麼彙整結果。
2. 跑 /agent，看看你的個人層或專案層有沒有已經定義的自訂 agent；如果有，用「Use the XXX agent on YYY」這種明確指令句觸發一次，感受跟自動推論觸發的差別。
3. （進階） 在 /settings 或你版本對應的設定檔裡查一下目前的 subagents.maxDepth 是多少，跟本章提到「6 砍到 4」的官方調整對照一下，你這版是不是已經是新預設。
4. （進階） 照 14.8 的表格，寫一支簡單的 preToolUse command hook，故意讓腳本本身壞掉（例如打錯字讓它直接 exit 1），實測看看是不是真的 fail-closed（擋下來），跟一支非 preToolUse 事件的壞掉 hook 做對照。
5. （安全意識練習） 挑一個你 clone 過、來源不太熟的 repo，看看它的 AGENTS.md／.github/copilot-instructions.md／README 裡，有沒有你以前沒特別注意過、讀起來比較像「指令」而不是「說明」的可疑段落。