執行 5 行評測 50,000 次後，我們學到了什麼

2026 年 6 月 19 日由 VS Code 評測團隊發布，@code

在過去六個月裡，我們已經執行了這個極小的評測超過 50,000 次。它只給 VS Code 代理程式一個指令：將字串寫入檔案。沒有大型程式碼基底要理解、沒有測試套件要除錯、也沒有架構決策要做。這是我們的煙霧測試（smoke test），是一種快速確認端對端模型互動是否依然正常的有效方法。

如此簡單的任務讓我們能立即掌握系統的健康狀況：代理程式完成工作的可靠性有多高，以及實務上會出現哪些類型的失敗。我們原本沒打算讓它承載更多功能。但在這個規模下，它意外地成為一個豐富的洞察來源，讓我們了解模型如何處理即使是最簡單的請求。

在我們上一篇文章中，我們介紹了 VSC-Bench，這是我們用來衡量 VS Code 中代理程式行為的離線評測套件。在這篇部落格文章中，我們將探討模型如何解決一個簡單的任務，以及它對效率、模型選擇以及小型穩定評測價值的啟示。

五行評測

簡單的任務之所以有價值，正是因為它消除了變數。當工作明確且正確答案固定時，每次執行之間所產生的任何變化都來自模型或其周邊系統，而不是任務本身。這使得小型評測成為一個靈敏的工具：它能對測試環境的退步、基礎設施事故以及模型行為的差異做出反應，而沒有複雜問題所帶來的干擾雜訊。

我們為此使用的 say_hello 任務就是環繞這個理念建構的。每次執行都從同一個空白工作區開始，使用相同的工具和相同的固定提示詞（prompt），並透過我們的 VS Code 代理程式測試環境。該任務要求代理程式「將 HELLO 新增至 HELLO.txt」，並檢查兩個斷言（assertions）：檔案是否存在，以及是否包含預期的內容。

promptSteps:
  - text: Add HELLO to HELLO.txt.
    assertions:
        - check: file_exists("HELLO.txt")
        - check: file_contains("HELLO.txt", "HELLO")

由於 say_hello 在每個基準測試套件執行前都會作為煙霧測試運行，它在六個月內默默累積了跨越 30 個模型的 50,974 次執行。這個龐大的數據量將一個基本的健全性檢查（sanity check），轉化為一份有用的資料集，展示了不同模型在處理最簡單工作時的差異。

執行此任務的開發人員會辨識出工作區是空的，建立 HELLO.txt，並加入要求的內容。在最直接的 VS Code 代理程式路徑中，這會轉化為單一的 create_file 工具呼叫，並以 HELLO 作為檔案內容。

tool : create_file
args : {
  "filePath": "/path/to/workspace/HELLO.txt",
  "content": "HELLO"
}

模型如何解決 say_hello

如預期般，say_hello 任務非常簡單，以至於所有模型在大多數時候都能通過。有趣的部分不在於它們是否能完成工作，而在於它們是如何完成的。模型是否能辨識出這是一個只需要簡單解決方案的基本請求？還是它仍然將其視為需要規劃、探索和搜尋的複雜問題？

為了建立基準，我們篩選出使用這個單一工具呼叫路徑且成功的執行紀錄，並查看該群組中最低的輸出 Token 數。這些執行的平均輸出 Token 大約為 50 個（包含工具呼叫結構）。接著，我們測量了每個模型採用該路徑的頻率。

有一個模型每次都選擇直接路徑。更廣泛的趨勢則引人注目：少數模型經常走直接路徑，大多數模型僅偶爾為之，而有五個模型從不走直接路徑。

在頂端，Model-A 獨樹一格。它在 100% 通過的執行中都直接進行檔案建立，每次都只使用單一工具呼叫。針對這個簡單的請求，Model-A 總是直接建立檔案，不需要先進行規劃或探索。Model-B 和 Model-C 分別以 73% 和 71% 緊隨其後。

龐大的中間群集（Model-D 到 Model-P）在 19% 到 52% 的時間內會採用直接路徑。這些模型能夠辨識出簡單的任務，但並非始終如一。通常在建立檔案之前，它們會先加入一個小步驟，例如讀取內部狀態或進行簡單的工作區探索。

在它們之下，Model-Q 到 Model-X 很少採用直接路徑，在通過的執行中僅佔 0.2% 到 6%，其中有五個模型的比例低於 1%。對這些模型而言，額外的工作是預設行為。在產生存放五個字元的同一個檔案之前，它們幾乎總是會先進行規劃、探索或搜尋。

在最底層，有五個模型（Model-Y 到 Model-AC）在數千次通過的執行中從不採用直接路徑。它們總是先做其他事：規劃、使用修補工具（patch tool）而不是簡單的檔案建立、搜尋與規劃，或者在建立檔案前進行長篇大論的闡述。對它們而言，即使是最簡單的請求也會觸發處理複雜請求的完整機制。

所有模型都建立了包含正確內容的檔案，但它們透過截然不同的工作量達到了相同的結果。即使在幾乎沒有歧義的任務上，某些模型仍然會進行規劃、搜尋或選擇更複雜的編輯工具。它們全都通過了評測，但通過所花費的心力卻不盡相同。

模型如何花費其額外開銷

由於我們的離線評測測試環境捕捉了完整的工具呼叫序列，我們可以將這些追蹤記錄轉化為模型行為模式。在各種執行中，模型往往會透過以下幾種常見方式花費其額外的精力：

這些並不是正確性方面的失敗。它們顯示出模型無法始終如一地辨識何時最短路徑就已足夠。在較長的任務中，規劃和探索可能很有價值。但在單步驟任務中，它們只會增加延遲與成本，卻無法改善結果。

過度思考的成本

為什麼你需要在乎模型為了寫一個五字元檔案而採取了多少額外步驟？因為這些額外步驟並不是免費的，它們會直接轉化為輸出 Token 的使用量，而這會產生實際的成本。

對於這個簡單的任務，大約 50 個輸出 Token 是實際的最小值。下圖顯示了不同模型所使用的輸出 Token 範圍。針對同一個五字元結果，所選模型的消耗量從這個最小值一直延伸到數千個 Token 不等！

該圖表可明顯分為四個區段。極端群組包含 Model-AB、Model-M 和 Model-U，它們的平均輸出 Token 分別為 3,676、2,120 和 1,441 個。這比相同五字元結果的實際最小值高出 29 到 74 倍。高開銷群組（400 到 1,000 個 Token）包含 Model-AA、Model-B、Model-N、Model-H、Model-V、Model-E、Model-S 和 Model-K。這些模型的消耗量雖然沒有達到數千個，但仍花費了大約 8 到 12 倍於實際最小值的 Token。

中等群組（150 到 400 個 Token）包含 Model-P、Model-D、Model-X、Model-T、Model-G、Model-Z、Model-I、Model-AC、Model-F、Model-J 和 Model-Q。它們會產生額外開銷，但比任務的自然大小更接近。高效群組則低於 150 個 Token：Model-R、Model-A、Model-Y、Model-W、Model-O、Model-C 和 Model-L。Model-L 以 55 個 Token 最接近我們的實際最小值，這表明即使模型不總是走直接工具路徑，也能在極少額外闡述的情況下完成任務。

選擇一個較少過度思考的模型既能省時又能省錢，但要了解哪一個模型對特定任務最有效率，通常意味著必須執行你自己的基準測試。為了幫你省去這個負擔，VS Code 與 GitHub Copilot 團隊持續投入於最佳化與模型路由。例如，自動模型選擇功能讓 VS Code 可以為你的任務挑選最佳模型。

模型大小無法預測開銷

我們最初的假設是較大的模型會過度思考更多，但我們的數據與此相反：

• Model-F（較大的模型）平均使用 160 個輸出 Token 以及 2.1 次工具呼叫。它是其家族中最具紀律的模型。

• Model-H（來自同一家族的較小模型）平均使用 485 個輸出 Token 以及 3.7 次工具呼叫。其開銷大於其體型較大的同門模型。

• Model-AB（「迷你」模型）是開銷最高的單一模型，平均輸出 Token 高達 3,676 個。此樣本中最小的模型做了最多額外的工作。

我們的解讀是，無論參數數量為何，每個模型家族中的新世代往往都更有紀律。這指向了訓練的成熟度：模型如何根據眼前的任務調整其心力。這種校準並非學術上的好奇心，而是直接反映在帳單上。

我們接下來要往哪裡去？

我們希望能分享團隊從這些執行中所獲得的一些關鍵洞察，以及你或許能應用到自己的日常工作流程中的一些心得。

為你的任務搭配合適的模型

透過以量計費（usage-based billing），輸出 Token 同時代表著金錢與時間。在執行此任務時，最精簡與最笨重的模型之間，在產生相同輸出的情況下差距大約達 70 倍。最顯而易見的教訓可能是「不要挑選最大的模型來寫 HELLO」。但這個教訓過於粗糙，而了解背後的原因才是 say_hello 教給我們最有用的事。

這些結果有一個重要的注意事項。say_hello 是一個具備一個步驟和一個正確答案的短視野（short-horizon）任務。在長視野（long-horizon）的工作中，規劃、探索和推理可以防止代價高昂的錯誤，並提高完成的機率。我們的目標並不是消除規劃，而是要了解模型是否能分辨單步驟任務與 30 步驟任務之間的差異。

這就是為什麼我們認為模型選擇不應該成為開發人員負擔的原因之一。諸如心力校準、Token 效率和工具紀律等訊號，可以協助自動模型路由為當前任務挑選正確的模型，而不需要求開發人員去權衡每一個取捨。我們將持續投入並研究VS Code 中的自動模型選擇，讓產品隨著時間為你做出更多這樣的選擇。

從小處著手，妥善衡量

大多數團隊一開始都沒有每天都能執行的私有離線基準測試套件。即使是一個簡單的任務，只要能持續執行並做好日誌記錄，也能揭示模型或系統行為中的有益變化。

從具有明確正確答案的最小任務開始。然後持續執行它：將其用作夜間評測、模型導入和基礎設施變更之前的預檢（preflight check）。這個任務不需要很聰明；它只需要夠穩定，使得通過率、延遲、工具使用或失敗模式的變化具有意義。

重要的一點是要捕捉足夠的結構來解釋是什麼發生了變化。記錄工具呼叫序列，而不僅僅是次數。知道有 4 次工具呼叫很有用，但並不完整。知道模型先進行了規劃、探索、搜尋，然後才建立檔案，可以告訴你開銷是從哪裡來的，以及為什麼這次執行成本更高。

// What most harnesses log:
{ "tool_calls": 4, "pass": true }

// What you actually need:
{
  "tool_sequence": ["plan", "list_directory", "search_files", "create_file"],
  "output_tokens": 617,
  "pass": true
}

從煙霧測試到有效訊號

say_hello 令人驚訝的地方不在於模型能夠寫入 HELLO.txt。而是五字元的編輯讓「心力」變得清晰可見：哪些模型降低了規模、哪些模型持續規劃或搜尋，以及哪些系統失敗只有在數千次執行後才會顯現。

在 VS Code 中使用你偏好的模型嘗試相同的請求，在聊天偵錯檢視中檢查其工具呼叫，並思考你自己的最小有用任務可能是什麼。在 VS Code 儲存庫中分享你的發現。

祝開發愉快！ 💙