我們如何讓 GitHub Copilot CLI 更審慎地委託任務

在智慧代理系統中，過多的委託並不總是更好。想象一下，你讓 Copilot CLI 做一個簡單的更改，它卻啟動一個輔助代理去搜尋倉庫、等待結果，然後卡住。本來一個步驟就能完成的工作，現在需要三個步驟。雖然某些任務確實需要專業子代理的幫助——比如探索不熟悉的倉庫、檢查程式碼的獨立區域，或者在主代理繼續工作的同時執行一個長命令——但委託並非沒有代價。每次交接都會增加協調開銷、工具呼叫和等待時間。如果代理過於急切地委託，“幫助”反而可能變成摩擦。

我們最近釋出了一項名為“更智慧的子代理委託”的改進，使得 Copilot CLI 更加審慎。它幫助主代理在以下方面做出更好決策：當自己能更快完成任務時保持專注；當專業代理能創造真正價值時進行委託；當任務確實獨立時並行化工作。

更智慧的子代理委託現已推廣到 100% 的 Copilot CLI 生產流量。如果你今天就想開始使用，只需在終端中執行 /update 命令，將 GitHub Copilot CLI 更新到 1.0.42 或更高版本。

在生產 A/B 測試中，這一改進使每次會話的工具故障率降低了 23%，其中搜尋工具故障減少 27%，編輯工具故障減少 18%。它還使 P95 的總使用者等待時間降低了 5%，P75 降低了 3%，且沒有質量退化。這裡，P95 捕獲了接近最慢 5% 會話的等待時間，而 P75 反映了典型會話中較慢端的等待時間。這意味著更少的不必要交接、更少的重複搜尋、更少的易故障工具路徑，以及在長時間編碼任務中更少的等待。

在本文中，我們將介紹我們如何識別 Copilot CLI 中不必要的委託，我們做了什麼改變來使委託更審慎，以及我們如何透過離線評估和生產 A/B 測試來驗證這些改變。我們還將展示這些改變如何導致更少的故障和更少的等待——以及這對日常使用 Copilot CLI 的開發者意味著什麼。

問題：委託強大但並非免費

子代理是代理型 CLI 中最重要的能力之一。它們讓 Copilot 分解複雜工作、並行進行調查，並讓主代理專注於協調最終答案。對於大型程式碼庫和多步驟工程任務，這可能是緩慢線性工作流與高效並行工作流之間的區別。

但委託引入了自身的故障模式：

• 為簡單任務進行不必要的交接，而主代理自己可以更快完成。
• 過度使用探索子代理，而交接時已包含足夠上下文。
• 主代理和子代理之間重複或重疊的搜尋。
• 順序委託，主代理等待子代理，而不是將委託視為並行工作的機會。
• 易出錯的子代理路徑，包括過時的檔案路徑、移動的檔案、不正確的相對路徑和工作空間不匹配。

圖 1 展示了子代理在工具呼叫失敗而主代理空轉的示例。

我們的目標是：幫助開發者在子代理能創造槓桿時使用它們，在它們增加開銷時避免它們，並在任務確實受益於獨立執行時並行化工作。

從問題訊號到交付改進

我們識別問題的方式也成為了解決問題的方式。我們沒有將代理軌跡分析、產品變更、評估和推廣視為獨立活動，而是將它們作為一個反饋迴圈：觀察代理行為，隔離協調瓶頸，進行針對性更改，離線驗證，線上測量，並且只有在端到端工作流改進後才釋出。

圖 2 展示了端到端改進迴圈：分析、更改、驗證和釋出。

1. 分析：讓 LLM 識別委託瓶頸

我們沒有手動審查代理會話，而是使用 LLM 分析完整的軌跡，識別協調何時有幫助、何時增加開銷。該分析揭示了一個一致的模式：子代理有時被呼叫用於已經狹窄、明顯或在交接中完全描述的任務。

在這些情況下，子代理可能花費時間重新搜尋倉庫，儘管主代理已經有足夠的上下文直接行動。這明確了改進目標：將簡單的發現和編輯任務保留在主代理中，並將子代理保留用於更廣泛、跨領域或自然可並行的工作。

2. 改變：最佳化協調策略

在識別瓶頸後，我們使用 LLM 幫助將該診斷轉化為更審慎的協調策略。

Copilot CLI 應直接處理專注的工作：查詢檔案、讀取、進行針對性更改並驗證。當工作需要獨立上下文、廣泛探索或並行執行時，委託更為有用。

在實踐中，這意味著從最狹窄的有效路徑開始，當複雜性或不確定性創造價值時升級，當任務再次變得專注時降級。子代理應被視為並行工具，而不是暫停按鈕。當 Copilot 啟動子代理時，主代理應繼續在獨立工作上取得進展，而不是僅僅等待結果。

當使用子代理時，交接也應具體：使用者的要求、已知資訊、子代理負責的內容以及主代理需要返回的結果型別。

3. 驗證：離線測試，線上確認，然後釋出

在廣泛推廣之前，我們使用自動生成的迴歸案例和現有基準驗證了更改。這有助於確認新的委託指導減少了可避免的開銷，而沒有破壞子代理真正有價值的案例。

最後，我們進行了員工和公開 A/B 測試，然後分析了可靠性、響應性、子代理工作負載和質量方面的生產指標。收益並非主要來自加快單個 LLM 呼叫，而是透過避免不必要的子代理路徑和降低每個使用者的子代理工作負載來減少協調開銷。

這一端到端過程使我們能夠從問題訊號到交付改進，同時保持使用者體驗穩定：更少的可避免交接、更少的易故障工具路徑，以及無質量退化。

成果

在將更智慧的子代理委託推廣到生產流量後，我們在可靠性和響應性方面看到了可衡量的百分比改進（表 1）。

| 維度 | 指標 | 變化 | | --- | --- | --- | | 可靠性 | 每次會話工具故障 | 減少 23% | | 可靠性 | 搜尋工具故障 | 減少 27% | | 可靠性 | 編輯工具故障 | 減少 18% | | 響應性 | P95 總使用者等待時間 | 降低 5% | | 響應性 | P75 總使用者等待時間 | 降低 3% | | 質量 | 質量指標 | 無退化 |

表 1：生產 A/B 測試結果

| 指標 | 與對照組的差異 | 解釋 | | --- | --- | --- | | 失敗的原始子代理搜尋呼叫 | 減少 15% | 可靠性：更少的易故障子代理搜尋路徑 | | 每個使用者的平均子代理 LLM 持續時間 | 降低 12% | 響應性：減少每個使用者的協調開銷 | | 每個使用者的 P95 子代理 LLM 持續時間 | 降低 18% | 響應性：更好的最壞情況子代理開銷 |

表 2：A/B 測試結果背後的方向性代理軌跡分析

這些結果表明，即使可見功能表面沒有變化，更好的協調也能改善開發者體驗。透過教導 Copilot CLI 何時委託、何時不委託以及如何並行化正確的工作，我們減少了代理迴圈本身的摩擦。

這就是 GitHub Copilot 作為一個系統的力量：體驗變得更好，不是因為有更多開關讓開發者管理，而是因為 Copilot 在後端更好地分配模型、工具和子代理。

這對開發者今天的好處

對於使用 Copilot CLI 的開發者來說，這將感覺更順暢。直截了當的任務更可能直接處理，複雜任務在需要時仍獲得專業幫助，長時間執行的會話保持進展，更少不必要的等待。實踐中，Copilot CLI 變得更高效、更安靜，而無需開發者改變工作方式。

這一改變是幕後進行的。你的工作流程保持不變，但 Copilot CLI 能更好地協調工作：更少不必要的交接、更少的重複搜尋工作、更少的失敗工具路徑，以及更快的進展。

下一步

這項工作是我們更大目標的一步：改進 Copilot CLI 如何在你的工作流中選擇正確的模型、代理和工具。雖然更多代理和模型擴充套件了 Copilot 的能力，但價值取決於 Copilot 如何應用它們於你已經做的工作，比如讀取檔案、執行命令，以及從 issue 到 pull request 的推進。

隨著任務變得複雜，協調的質量變得更加重要。最好的系統不是委託最多的系統，而是知道何時直接行動、何時委託、以及如何在不增加摩擦的情況下保持工作推進的系統。

下一步是讓 Copilot CLI 在模型、代理、技能和工具方面更具適應性，這樣開發者就不必決定任務是否需要更大的模型、專業的子代理或程式化技能。Copilot 應根據任務、倉庫上下文、策略和預期結果做出決定。

我們將繼續改進 Copilot CLI 的計劃工作、協調子代理和測量端到端結果的方式。這包括更好地可見主代理和子代理行為、更深入地分析故障原因，以及更強大的協調質量代理指標。目標很簡單：更少的等待、更少的可避免故障，以及每個代理會話中更有用的進展。

立即開始並分享反饋

在終端中執行 /update 命令更新 GitHub Copilot CLI 到 1.0.42 或更高版本。

已經嘗試過？我們期待聽到你的想法。透過 CLI 會話中的 /feedback 命令分享反饋，或在我們的公共倉庫中提交 issue。

致謝

更智慧的子代理委託的實現得益於 Code|AI、Copilot CLI、實驗、人工評估和產品團隊的協作。感謝所有幫助識別問題、設計流程、驗證結果並將改進交付生產的人。