GitHub Copilot 自動模型分級：Efficiency、Balance、Intelligence 怎麼選

快速解答

GitHub 在 2026 年 9 月 18 日的 Copilot 每週更新中，為自動模型選擇加入三個分級：Efficiency、Balance 與 Intelligence。三個分級並不是解鎖不同的模型池，而是改變 Copilot 針對每項任務選模型時的偏好，讓開發者可以偏向成本、成本／品質／延遲的平衡，或更高的回答品質。目前正陸續推向 VS Code、Copilot CLI 與 GitHub Copilot app。

TowCue 的判斷是：模型選擇正從「固定挑一個最喜歡的模型」，轉變成一種執行策略。簡單工作不一定需要最強模型，而模糊的架構問題或疑難除錯，可能值得使用成本更高的推理能力。真正有用的指標不是哪個模型處理最多 Prompt，而是產生一個可接受、可審核成果所需要的成本與總時間。

延伸閱讀 TowCue 的 Codex 工具頁、AI Agent 最佳實務，以及 AI Agent 任務簡報檢查表。

GitHub 改了什麼

GitHub Copilot 原本就有自動模型選擇。這次新增的是一層由使用者決定「路由器應優先最佳化什麼」的偏好。

GitHub 文件列出三個分級：

Efficiency 優先考量成本，適合快速、直接的任務。
Balance 同時考量成本、品質與延遲，適合日常工作。
Intelligence 優先考量品質，適合較複雜的任務。

三個分級都從使用者原本可用的同一組模型中選擇。差別是路由偏好，而不是另一套高階模型目錄。

GitHub 也強調，路由器仍會判斷任務本身。選 Intelligence 不代表所有簡單問題都會送到最大模型；選 Efficiency 也不代表無論任務難度如何都只會使用最便宜的模型。

因此，這個設定更像是「模型路由系統上的策略」，而不是固定模型選擇器。

為什麼這比多一個模型選單更重要

開發者常把 Coding Model 拿來比較，好像一定要有一個模型在所有任務上勝出。

但真實軟體工作非常多樣。重新命名 symbol、摘要 diff、調查不穩定的 integration test，以及規劃跨多個服務的 migration，需要的推理能力完全不同。

固定模型等於把同一組成本／品質取捨套在所有工作上。路由器則可以逐項任務做決定。

工作流會變成：

任務 → 評估複雜度 → 套用成本／品質偏好 → 選模型 → 執行 → 審核成果

這已經更接近 workload scheduling，而不是一般聊天機器人的模型切換。

相同模型池，不代表相同的工作流經濟性

GitHub 表示三個分級使用相同的可用模型，但每個分級會改變路由器對模型的偏好。

Efficiency 會偏向最具成本效率、同時足以完成任務的模型；Balance 會綜合成本、品質與延遲；Intelligence 則會評估哪個模型最可能提供最高品質的回答。

GitHub 也表示，付費 Copilot 方案在支援的 Copilot 體驗中使用 auto model selection，可享有模型成本 10% 折扣。實際用量仍依 Auto 最終選中的模型計費。

因此真正的問題不是「哪個 tier 最便宜」。一次便宜但需要大量返工的嘗試，可能比一次較強的模型執行更昂貴。反過來，例行修改若一律使用最高推理能力，也可能只是增加成本而沒有改善成果。

TowCue 判斷：最佳化每個已驗收成果的成本

團隊不應只用 token 單價評估模型路由是否成功。

更好的單位是每個已接受、已審核成果的成本。

對程式任務來說，可以一起計算：

模型使用成本；
到達可 review 狀態的實際時間；
人工 review 時間；
測試失敗次數；
後續修正 Prompt；
review 後返工；
merge 後的 defect 或 rollback 工作。

假設 Efficiency 每次呼叫較便宜，卻需要三輪修正；如果 Intelligence 一次就產生正確 patch 與足夠測試證據，那麼看似昂貴的 tier 在整體工作流上反而可能更便宜。

對重複、規格清楚的工作，情況也可能完全相反。

開發者可以怎麼設定實用的路由策略

TowCue 會先把 Balance 當成預設，而不是每一個任務都手動挑模型。

Efficiency 可以優先用於邊界明確的工作，例如：

機械式修改；
直接的文件更新；
簡單的 repository 問題；
有完整測試保護的重複格式整理或 refactor。

當一次弱回答的代價較高時，可以偏向 Intelligence，例如：

模糊的 production bug；
架構決策；
涉及安全性的推理；
不熟悉的多服務修改；
含有隱藏依賴的 migration。

重點不是這份分類本身，而是讓路由規則足夠清楚，之後可以用數據驗證。

Reliability 也是模型選擇的一部分

GitHub 表示，自動模型選擇也會考慮即時系統健康狀態與可用性。相較於在某個模型降級時仍強制使用它，Auto 可以降低 rate limiting、延遲與錯誤。

這讓模型路由的經濟性又多了一個維度。

理論上能力更好的模型，如果任務真正要執行時不可用，就不一定是更好的工作流選擇。對 production agent 系統而言，可用性與 latency 可能與 benchmark 品質同樣重要。

GitHub 也表示，路由會沿著自然的 cache 邊界進行，因為 session 中途切換模型可能增加成本，卻未必帶來足夠的品質提升。這提醒我們，模型 orchestration 本身也有成本。

管理員政策仍然限制路由器

Auto 不會繞過組織政策。

GitHub 文件指出，自動選擇會排除使用者方案中不可用的模型，以及被管理員政策禁止的模型。Data residency、FedRAMP compliance 或 evaluation model 相關政策也可能縮小可用模型池。

因此企業模型路由正在形成兩層結構：

管理員核准的模型池 → 任務層級路由策略

這比讓每個 Agent 不受限制地自行挑任何供應商或模型更容易治理。

這次 Copilot 更新也顯示工作流正在擴張

GitHub 9 月 18 日的每週更新不只有模型分級。

Copilot code review 現在可以在後續 review 中自動解決已處理的 comment，同時保留尚未處理的回饋。Review 可以使用 shell tools 驗證修改，Lite review 也會整合多個 agents 的 findings。

Copilot app 還加入 Sentry canvas，可以從 production crash report 開始，查看 error、stack trace 與相關 context，再讓 Copilot 協助調查原因、驗證修復並準備 pull request。

VS Code 的 Agent session 也正逐步支援 local Dev Containers，而 Agent Host session 可以直接在 Agents window 建立 pull request。

把這些更新放在一起看，Coding Assistant 正在變成跨越路由、執行、驗證、review 與 PR 準備的完整工作流。

誰最值得關注這三個分級

這項功能最適合已經會使用多個 Coding Model，或 AI credits 用量已經高到需要關注模型經濟性的開發者。

對正在從偶爾聊天走向長時間 Agent 工作的團隊也很重要。任務越自主，人類就越不可能替每一個中間步驟手動選模型。

如果每天只發幾個簡單 Copilot Prompt，差異可能有限。在用量還沒大到值得最佳化之前，不需要先建立複雜路由政策。

如何低風險測試三種 tier

不要用幾個漂亮 Demo 下結論，先挑一組可重複的真實任務。

連續兩週記錄：

任務類型；
使用的 tier；
到達可接受輸出的時間；
修正 Prompt 次數；
測試與 review 結果；
使用的模型成本或 credits；
是否最後仍由人工重做。

再依任務類型比較成果經濟性。

不要因為 Intelligence 在困難任務上勝出就說它「最好」，也不要因為 Efficiency 單位成本低就說它「最好」。目標是找出每一類工作最便宜、同時可靠的路由方式。

TowCue 判斷：模型選擇正在變成基礎設施

當 AI 產品支援越來越多模型，要求每個使用者理解每一個模型會越來越不實際。

更持久的抽象層可能是 policy：告訴系統你在乎什麼，讓系統路由任務，再提供足夠資訊讓你稽核實際發生了什麼。

GitHub 已允許使用者查看每個 Copilot response 最終用了哪個模型。這種透明度很重要，因為沒有 observability 的自動路由很難被評估。

實用的操作循環會是：

任務 → 路由策略 → 選定模型 → 執行證據 → 已審核成果 → 成本／品質回饋

問題正在從：

「我應該用哪個 Coding Model？」

轉變成：

「對這一類工作，什麼路由策略能用合理的成本與時間產生最好的已驗收成果？」

這是一個更成熟的問題，而且隨著 Coding Agent 接手更長的工作流，它只會越來越重要。

GitHub Copilot 新增自動模型分級：為什麼 AI 程式開發正在變成路由問題