在Copilot CLI中使用/fleet同時執行多個代理

如果 GitHub Copilot CLI 能同時處理五個檔案，而不是一個接一個，會怎樣？這就是 /fleet 的作用。

/fleet 是 Copilot CLI 中的一個斜槓命令，它使 Copilot 能夠同時與多個子代理並行工作。與順序處理任務不同，Copilot 現在擁有一個幕後協調器，該協調器會規劃並將你的目標分解為獨立的工作項，然後排程多個代理同時執行它們。在不同檔案上，在程式碼庫的不同部分，同時進行。

想了解 /fleet 的工作原理，以及更重要的是如何高效使用它嗎？讓我們深入探討。

工作原理

當你使用提示執行 /fleet 時，幕後協調器會：

• 將任務分解為具有依賴關係的離散工作項。
• 識別哪些項可以並行執行，哪些必須等待。
• 同時將獨立項作為後臺子代理排程。
• 輪詢完成狀態，然後排程下一波。
• 驗證輸出併合成最終工件。

每個子代理都有自己的上下文視窗，但共享相同的檔案系統。它們不能直接相互通訊；只有協調器進行協調。

可以將其視為專案負責人，將工作分配給團隊，檢查進度並組裝最終交付物。

入門

透過傳送 /fleet 啟動艦隊模式。例如：

/fleet 重構 auth 模組，更新測試，並修復 docs/auth/ 資料夾中的相關文件。

就這樣。協調器接收你的目標，找出可以並行化的部分，並開始排程。

你也可以在終端中以非互動方式執行：

copilot -p "/fleet " --no-ask-user

--no-ask-user 標誌是非互動模式所必需的，因為無法響應提示。現在讓我們看看什麼構成一個好的提示。

編寫可良好並行化的提示

/fleet 提示的質量決定了工作分配的有效性。關鍵在於給協調器足夠的結構來清晰地分解任務。

一種好方法是具體說明交付物。將每個工作項對映到具體的工件，如檔案、測試套件或文件部分。模糊的提示會導致順序執行，因為協調器無法識別獨立的部分。

例如，與其使用：/fleet 構建文件，不如嘗試：

/fleet 為 API 模組建立文件：

• docs/authentication.md 涵蓋令牌流程和示例
• docs/endpoints.md 包含所有 REST 端點的請求/響應模式
• docs/errors.md 包含錯誤程式碼和故障排除步驟
• docs/index.md 連結到所有三個頁面（依賴於其他頁面完成）

第二個提示給了協調器四個不同的交付物，其中三個可以並行執行，一個依賴於它們。

設定明確邊界

當子代理確切知道其範圍的起點和終點時，它們的工作效果最佳。編寫提示時，包括：

• 檔案或模組邊界：每個軌道負責的目錄或檔案
• 約束：不要觸碰的內容（例如，不修改測試，不升級依賴）
• 驗證標準：必須透過的 lint、型別檢查、測試

以下是一個展示這些邊界的提示：

/fleet 在三個軌道中實現功能標誌：

1. API 層：在 src/api/middleware/ 中新增標誌評估，幷包含檢查標誌評估成功和測試 API 端點的單元測試
2. UI：在 src/components/flags/ 中連線切換元件，不引入新依賴
3. 配置：在 config/features.yaml 中新增標誌定義，並根據模式驗證

獨立軌道並行執行。不修改指定目錄之外的內容。

存在依賴時宣告它們

如果一項工作依賴於另一項，請說明。協調器會序列化這些項，並並行化其餘項。例如：

/fleet 遷移資料庫層：

1. 在 migrations/005_users.sql 中編寫新模式
2. 更新 src/models/user.ts 中的 ORM 模型（依賴於 1）
3. 更新 src/api/users.ts 中的 API 處理程序（依賴於 2）
4. 在 tests/users.test.ts 中編寫整合測試（依賴於 2）

專案 3 和 4 可以在專案 2 完成後並行執行。

為不同作業使用自定義代理

你可以在 .github/agents/ 中定義專門的代理，並在 /fleet 提示中引用它們。每個代理可以指定自己的模型、工具和指令。請注意，如果不指定使用哪個模型，代理將使用當前的預設模型。

.github/agents/technical-writer.md

--- name: technical-writer description: 文件專家 model: claude-sonnet-4 tools: ["bash", "create", "edit", "view"] --- 你編寫清晰簡潔的技術文件。遵循 /docs/styleguide.md 中的專案風格指南。

然後在提示中引用自定義代理：

/fleet 對所有文件任務使用 @technical-writer.md 作為代理，對程式碼更改使用預設代理。

當不同軌道需要不同優勢時，這很有用，例如為複雜邏輯使用更重的模型，為樣板文件使用更輕的模型。

如何驗證子代理正在部署

觀察協調器如何部署子代理，這是學習如何編寫良好並行化提示的最快方式。

使用此快速檢查清單：

• 分解出現：在開始工作之前，檢視 Copilot 與你共享的計劃，看它是否將工作分解為多個軌道，而不是一個長的線性計劃。
• 後臺任務 UI 確認活動：一旦開始工作，執行 /tasks 開啟任務對話方塊並檢查正在執行的後臺任務。
• 並行進度出現：更新引用同時移動的獨立軌道。

如果艦隊似乎沒有並行化，嘗試停止 Copilot 的工作並要求顯式分解：

首先將此項分解為獨立軌道，然後並行執行軌道。分別報告每個軌道的狀態和阻礙。

避免常見陷阱

Fleet 很強大，但一些陷阱值得事先了解。

分割槽檔案 子代理共享沒有檔案鎖定的檔案系統。如果兩個代理寫入同一檔案，最後完成的代理獲勝——靜默地。沒有錯誤，沒有合併，只是覆蓋。

解決方法是提示中為每個代理分配不同的檔案。如果多個代理需要貢獻同一個檔案，考慮讓每個代理寫入臨時路徑，讓協調器在最後合併它們。或者為代理設定顯式順序。

保持提示自包含 子代理看不到協調器的對話歷史。當協調器排程子代理時，它會傳遞一個提示，但該提示需要包含子代理所需的一切。如果你已經在會話早期收集了有用的上下文，確保你的 /fleet 提示包含它（或引用子代理可以讀取的檔案）。

引導進行中的艦隊 排程後，你可以傳送後續提示來指導協調器：

• 首先優先處理失敗的測試，然後完成剩餘任務。
• 列出活動子代理以及每個子代理當前正在做什麼。
• 僅在 lint、型別檢查以及所有測試透過時標記完成。

何時使用 /fleet（以及何時不使用）

/fleet 在你的任務具有自然並行性時表現出色——多個檔案、獨立模組或可分離的關注點。它特別適用於：

• 同時跨多個檔案重構。
• 一次為多個元件生成文件。
• 實現跨越 API、UI 和測試的功能。
• 執行不共享狀態的獨立程式碼修改。

對於嚴格的線性、單檔案工作，常規的 Copilot CLI 提示更簡單且同樣快速。Fleet 增加了協調開銷，因此當有真正的工作要分配時才值得使用。

/fleet 在你將其視為團隊而非魔術技巧時最有用。從小處著手。選擇具有清晰輸出、乾淨檔案邊界和明顯並行性的任務。觀察協調器如何分解工作，哪裡有幫助，哪裡會礙事。隨著你越來越熟練，將其推向更大的重構、多軌道功能或並行文件和測試。瞭解 /fleet 何時值得的最快方法是將其用於實際工作，並根據所見調整提示。

開始使用 GitHub Copilot CLI >