模型提供原始智慧,而 harness 則決定這些智慧如何有效運用。GitHub Copilot 代理式 harness 是 GitHub Copilot SDK 的單一共享元件,驅動 GitHub Copilot CLI、GitHub Copilot app 以及 Copilot code review,並支援 GitHub 與 Microsoft 各式體驗。改善 harness,所有介面都能受益。

工具、上下文與工作流程由 harness 負責協調。一個 harness 應具備快速、省 token 且可預測的特性。這正是我們設計 GitHub Copilot 代理式 harness 的目標。
在本篇文章中,我們將呈現 GitHub Copilot 代理式 harness 在廣泛代理式軟體工程任務中的效率與效能數據。
我們如何透過基準測試進行迭代
我們持續透過公開與內部開發的基準測試,評估 GitHub Copilot 代理式 harness 的能力與效率。公開基準測試包含業界標準,而多項內部基準測試則來自 GitHub 與 Microsoft 的大型程式碼庫。我們也結合真實世界指標與線上實驗,以確保了解 harness 在受控環境中的表現,以及其對代理式問題解決與任務完成的實際影響。
為了評估 GitHub Copilot harness 與模型供應商 harness 的效能,我們盡可能控制變數:使用相同模型、相同基準任務,並在上下文視窗、推理努力程度、工具選擇與 MCP 伺服器上進行正規化。
以下我們報告針對四個領先模型:Claude Sonnet 4.6、Claude Opus 4.7、GPT‑5.4 與 GPT‑5.5 的最新基準測試子集結果:
| Benchmark | Domain | Purpose |
|---|---|---|
| SWE-bench Verified | 來自開源 Python 儲存庫的 500 個人類驗證錯誤修復任務 | 編碼代理的業界標準基準測試 |
| SWE-bench Pro | 更困難、多步驟的工程任務,需要更深入的推理與更廣泛的程式碼變更 | 更能反映複雜的真實世界軟體工程工作 |
| SkillsBench | 代理使用技能解決任務的效能 | 評估擴充性以及技能使用與觸發能力 |
| TerminalBench | 代理在終端機任務上的表現 | 衡量開發者在命令列工作流程中的效能 |
| Win-Hill | Windows 容器內部任務的內部基準測試 | 驗證效能是否能跨作業系統與環境通用 |
我們將 GitHub Copilot CLI 與這些模型原生提供的供應商 harness 進行比較:Sonnet 4.6 與 Opus 4.7 使用 Claude Code,GPT‑5.4 與 GPT‑5.5 使用 Codex CLI。
Token 效率
在模型與任務固定的情況下,多項基準測試結果顯示,GitHub Copilot harness 的任務完成率與其他模型供應商 harness 相當,但在多數配置中 token 消耗較低。

任務完成率
只有當工作確實完成時,token 效率才有意義。
GitHub Copilot 代理式 harness 在這些基準測試中的任務完成率,與使用相同模型與基準任務的模型供應商 harness 相當。這確保了基礎模型的完整潛力得以發揮,同時兼具多模型彈性、token 效率,以及記憶體與上下文能力。

這些結果反映出實質上的相等性,因為任一方向的差異都在模型隨機性造成的變異範圍內,使得跨 harness 的表現相當。
TerminalBench:Token 效率、任務完成率與變異性
為了持續改善 GitHub Copilot 代理式 harness 在任務完成率與 token 效率上的表現,我們定期在基準測試中進行深入分析。以下是 TerminalBench 2.0 的變異性分析範例,不僅突顯 GitHub Copilot 在任務完成率與 token 效率上的優勢,也顯示此類基準測試中固有的執行間變異。

圖中每個標記代表 TerminalBench 2.0 上的一種代理與模型配置,縱軸為完成率,橫軸為每項任務的美元成本。每個點周圍的陰影橢圓表示 ±1σ 的執行間變異,顯示該配置在不同執行間的變動程度。
有三點值得注意:
- GitHub Copilot 代理式 harness 在任務完成率與每項任務成本上,與其他代理不相上下或更勝一籌。紫色(Copilot)標記及其相同模型的競爭者在兩個軸上的橢圓幾乎都重疊,差異都在執行間變異範圍內。Copilot 在完成率上從未低於競爭者,在成本上也從未高於競爭者。
- 執行間變異性。我們對每個代理-模型組合至少執行五次。橢圓標示這些執行的 1σ 範圍;較緊的橢圓表示結果更具可重現性,較寬的橢圓則表示成本與任務完成率在不同執行間波動較大。
- GitHub Copilot 模型選擇的優勢:圖表顯示真實的權衡:GPT 模型(左側)提供最佳價值——以最低成本達成強勁完成率。Claude Opus(右上)則以較高成本達到最高完成率。GitHub Copilot 同時提供這兩種選擇,讓您可依據任務需求選擇效率或峰值品質。
單一 harness,多種模型
GitHub Copilot 代理式 harness 支援 GPT、Claude、Gemini 與 MAI 系列的 20 多種前沿模型,並可透過自帶金鑰使用開源與本地模型。您可以針對每項任務選擇合適的能力與成本配置,或讓 Auto model selection 根據任務意圖與模型健康度自動選擇,以最佳化 token 效率。
多模型架構也解鎖了模型供應商 harness 無法提供的 harness 層級能力。例如 Rubber Duck 使用跨模型家族的評論機制,讓一個模型審查另一個模型的輸出,以獲得超越單一模型的結果。
結論
基準測試只是眾多指標之一。我們持續致力於改善基準測試、真實世界使用指標與線上實驗的品質,同時追求以最高效率善用每一個 token。
GitHub Copilot 提供與領先模型供應商 harness 相當的任務完成率,同時在多種配置中使用較少的 token,且透過多模型架構讓您不被鎖定在單一模型上。對開發者而言,這意味著您可以在維持相當任務完成率的同時降低 token 成本,並仍可選擇最適合任務的模型。
親自試用
選擇您偏好的模型試用 GitHub Copilot,在日常任務上比較不同方法,並觀察不同模型與代理策略在您的環境中的表現。
了解更多:
這些體驗皆由相同的代理式 harness 驅動。我們將持續改善其品質、效率與彈性。
方法論
為了盡可能讓比較具控制性與可重現性,我們在模型、任務與環境中使用等效設定執行每個代理。
所有執行皆設定兩小時逾時。所有代理皆以非互動單回合方式執行,停用網頁工具,並允許所有工具。
TerminalBench2 分析:代理啟用預設設定,推理努力程度設為中(例如 Claude Code 啟用工具搜尋,Copilot CLI 使用 github-mcp-server)。Codex 與 Claude Code 使用 Anthropic 與 OpenAI 的直接端點。為了確保完整且可靠的結果,任何遺漏資料或基礎設施相關失敗都會重新執行,直到所有 89 項 TerminalBench2 任務皆產生結果。模型產生的錯誤會保留且不排除於分析之外。每個模型皆進行五次獨立執行,而 Copilot 則分兩批評估以便與 Claude Code 及 Codex 比較。
所有基準測試:所有代理-模型配對皆正規化為相同上下文視窗大小、相同提示 token 限制、推理努力程度(中)與設定——無工具搜尋、無 MCP 伺服器。保留 harness 的預設內建工具。基礎設施相關異常與網路存取影響會排除於所有代理的基準測試之外,以確保公平比較。為了降低較小基準測試(<100 個實例)的執行間變異影響,我們進行五次獨立執行,並報告最佳得分的執行。所有指標皆以 pass@1 呈現。這些正規化表示結果與公開基準提交不同,後者通常使用較高的推理努力程度與其他調整過的設定。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.