在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 >