從每個 Token 中獲取更多價值：Copilot 如何改進上下文處理與模型路由

隨着 Copilot 承擔更多智能體工作，從規劃、編輯到調試、審查以及在更長的會話中調用工具，效率的提升不僅僅意味着使用更少的 Token，更要考慮如何更智能地使用它們。

提升效率的第一步是減少 Copilot 在每次交互中需要重複的內容，包括上下文、工具定義和緩存狀態。接着是選擇適合當前任務的模型。快速解釋、精準編輯和複雜的多文件更改不應採用同一種處理方式。

我們正在從兩方面入手：改進 Copilot 的底層架構，使更多會話資源用於實際任務；擴展 Auto 功能，讓 Copilot 能自動選擇最合適的模型，無需開發者每次都手動選擇。本文將聚焦於 VS Code 中 GitHub Copilot 的架構改進，以及 Auto 在各 Copilot 界面上的擴展工作。

增強的提示緩存與按需工具加載

在 VS Code 的較長 GitHub Copilot 會話中，底層架構會為模型準備大量重複信息：指令、倉庫上下文、對話歷史、可用工具和當前任務狀態。其中部分上下文是必要的，但有些可以被緩存、延遲加載，或僅在需要時加載。

GitHub Copilot for VS Code 的兩項改進在這方面發揮了主要作用。提示緩存幫助 Copilot 重用重複提示前綴的模型狀態，而不是在每次請求時重新計算相同的前綴。工具搜索則允許模型按需加載工具定義，而不是在每次交互時將所有完整工具模式發送到上下文中。

隨着智能體使用更多工具，這一點變得愈發重要。一個會話可能需要訪問 MCP 工具、終端命令、文件操作、工作區搜索和特定產品操作。每次交互時預先加載所有完整工具定義會帶來固定成本，即使只有少數工具與當前任務相關。通過工具搜索，Copilot 可以保持廣泛的可用工具集，同時減少不必要的工具模式傳遞給模型。

關於實現的更多技術細節，包括提示緩存、緩存控制斷點、特定提供商的工具搜索以及這些變化如何在長時間運行的智能體會話中工作，請閲讀 VS Code 技術深度文章。

GitHub Copilot 自動模型選擇的作用

Auto 解決了一個實際問題：當前任務最適合哪個模型？

在您的第一個提示之後，Copilot 使用任務意圖和當前模型健康狀態來選擇最適合任務的模型。不同類型的工作，如快速解釋、精準編輯或多文件更改，並不都受益於相同級別的推理能力，因此 Auto 會做出決定，而無需您調整模型設置。

在我們的評估中，沒有單一模型在所有任務上持續表現最佳。在許多情況下，更高效的模型可以達到相同的結果，而更強的模型在任務需要更深推理時才至關重要。Auto 學習了何時更強的推理能改善結果。當任務需要時，它會路由到更強的模型；當不需要時，它保持高效。目標不是在質量和成本之間取捨，而是使用最適合工作的模型。

Auto 如何選擇正確的模型

Auto 結合了兩個信號：當前哪個模型健康且可用，以及 Copilot 被要求做什麼工作。

實時模型健康：一個動態引擎跟蹤模型可用性、利用率、速度、錯誤率和成本。一個模型可能能夠處理某項任務，但這並不意味着它是當時的最佳選擇。Auto 考慮當前系統條件，以便 Copilot 路由到既勝任又準備好響應的模型。

任務感知路由（HyDRA）：一個路由模型，考慮推理深度、代碼複雜性、調試難度和工具編排需求等因素。HyDRA 識別能夠滿足任務質量標準的模型，然後在其中選擇最佳匹配。

圖 1：三個 HyDRA 操作點展示了可調性：（峯值）超過 Sonnet，節省 12.9%；（激進）平衡質量，節省 72.5%。

圖 2：HyDRA（保守）在解決率（70.8%）上與 OpenRouter Auto 持平，但節省 3.3 倍。HyDRA（激進）優於 Azure Foundry 的兩種操作模式。

綜合來看，這些信號使 Auto 避免了千篇一律的方法。關鍵不是將每個任務發送給最大的模型，也不是每個任務發送給最便宜的模型，而是選擇適合工作的模型。

讓 Auto 在實際中發揮作用

在評估中做好路由只是問題的一部分。為了使 Auto 在實際工作流程中有用，我們還必須考慮開發者實際使用 Copilot 的方式：對話變長、上下文積累、任務變化以及開發者使用多種語言。

緩存感知路由。每次交互都切換模型聽起來很靈活，但這可能會損害效率。當對話停留在同一模型上時，提示前綴可以在交互之間緩存和重用。在對話中途切換模型會破壞該緩存，這可能導致比路由改變節省更多的成本。Auto 通過在自然緩存邊界處路由來避免這種情況：首輪（沒有緩存可丟失）和壓縮後（Copilot 總結較舊的回合並重置提示前綴）。在這些點之間，選定的模型保持不變，以便緩存繼續構建。

跨語言路由。Copilot 服務全球開發者，因此路由必須適用於英語以外的語言。我們使用跨 16 個語系（包括 CJK、歐洲等）的對話訓練了路由模型。在評估中，路由準確性在不同語言組中保持在英語基線的四個百分點以內，沒有統計上顯著的質量差距。

圖 3：智能路由保持在英語基線的 4 個百分點以內。基於來自生產 VS Code 聊天遙測的 19 種語言保留評估集的模型評估，涵蓋英語、歐洲、CJK 和其他文字家族。

學習何時升級更重要。我們沒有簡單地將任務標記為“簡單”或“困難”，而是訓練路由器學習模型實際出現差異的地方。對於每個訓練查詢，評估來自能力較弱模型和較強模型的響應在多個質量維度上的得分。路由器學習何時更強的模型能增加價值，以及何時更高效的模型也能產生同樣好的結果。對於較長智能體會話中依賴上下文的消息，路由器在完整的多輪對話上進行訓練，包括原始用户意圖、最近的助手響應和對話元數據。

帶有任務意圖的 Auto 正在擴展

帶有任務意圖的 Auto 已在 Visual Studio Code、github.com 和移動端上線。它給 Copilot 提供了更多關於您正在做什麼工作（編碼、調試、規劃或使用工具）的信號，以便為任務做出更好的模型選擇。

我們正在繼續擴展這種體驗。接下來，我們將把帶有任務意圖的 Auto 帶到更多界面，並添加更多方式讓團隊將 Auto 設為默認。

• 帶有任務意圖的 Auto 即將應用於 Copilot CLI、GitHub App 和更多 IDE。
• Copilot Free 和 Student 計劃將簡化為僅使用 Auto 作為模型選擇選項。
• 管理控件將允許組織將 Auto 設為默認或強制僅使用 Auto。

從您的 AI 積分中獲取更多價值

Copilot 在默認情況下變得更高效，但一些習慣可以幫助您的積分走得更遠。

• 從 Auto 開始。對於許多任務，Auto 是強大的默認選擇，因為它根據您嘗試做的事情選擇模型，而無需您每次都手動選擇。
• 保持上下文聚焦。切換任務時開始新會話，在必要時壓縮長時間會話，並在已經知道相關代碼位置時提及您希望 Copilot 使用的文件。較少的無關上下文意味着更多會話資源用於實際工作。
• 避免在會話中途更改模型或設置。切換模型、推理級別、上下文大小或工具配置可能破壞緩存複用，並使 Copilot 重建上下文。按您希望的方式設置會話，然後保持相關工作在一起。
• 在並行化之前先規劃。對於較大任務，先讓 Copilot 做規劃。並行智能體在任務真正可以拆分時有用，但它們也並行消耗積分，因此要謹慎使用。
• 只使用您需要的工具。工具和 MCP 服務器很強大，但廣泛的工具集可能增加額外上下文。啓用與任務相關的工具，關閉不需要的。查看 GitHub Copilot 中的 agent finder 以幫助簡化工具使用。
• 檢查您的使用情況。您的 AI 使用頁面顯示積分在功能和模型之間的去向。在 Copilot CLI 中，會話級使用情況也可以幫助您在工作時發現高消耗模式。

完整指南請參見“如何從您的 AI 積分中獲取更多”。

開始使用

自動模型選擇現已適用於支持的 Copilot 體驗。要了解更多，請參閲自動模型選擇文檔。您也可以在 Copilot 討論中分享反饋。

我們正在繼續使 Copilot 在整個系統中更高效，以便更多積分用於有用工作，而無需您自己調整每個模型選擇。