800 行程式碼燒掉 1.56 億 Token：SonarSource 為 Coding Agent 的「上下文稅」標出真實價格

每個跑過 coding agent 的開發者都有同感：帳單隨著 codebase 的規模成長，而不是隨著改動的規模。2026 年 9 月 1 日，SonarSource 終於為這個現象提出了具體數據，並以「上下文稅」（context tax）為名，公布了自家工程流程的詳細遙測。頭條數字相當驚人：一個普通的、約 800 行的 pull request——一個人類五分鐘就能讀完的改動——消耗了大約 1.56 億個 context token，花了約 41 美元的模型費用。

SonarSource 量測了什麼

這份量測的可信度來源相當特殊：SonarSource 是在打造 SemSitter（其新版 AI coding agent 產品 Sonar Vortex 背後的語意程式碼導航引擎）的過程中，對自己的工程流程做儀器化。因為團隊保留了每個 agent session 的完整 trace，公司得以精確量測這筆「稅」，而不是憑感覺估計。

那個 PR 的任務是教 SemSitter 的 Python 分析器做 call-site resolution，完整解剖如下：

指標（單一 PR 實測）	數值
session 中的模型往返次數	512
context window 峰值	458,700 tokens
全新輸入 token	106k
Cache-read token（被重複計費的對話紀錄）	1.528 億
Cache-write token	310 萬
輸出 token	289k
總計費 context token	約 1.56 億
session 大約成本	約 $41

關鍵在 cache-read 那一列：1.528 億 token。而輸出只有 289,000 token——這個 agent 為它實際寫出的內容，支付了超過 500 倍的費用。

帳單為何爆炸：上下文是每一輪都要繳的稅

背後的機制是結構性的，一點都不神祕。Coding agent 不會只讀一個檔案一次。在每一個新步驟，模型都會把目前為止的整段對話重新送進去當輸入。Prompt caching 讓這些重複的 token 單價變便宜——約為輸入價的 10%——但你仍然在每一輪都為它們付費。

所以一個 token 的真實成本不是它的大小，而是它的大小乘上它在對話中存活的輪數。在一個 512 輪 session 的第 40 輪讀了一個 600 行的檔案，你付的不是 600 行的錢，而是 600 行 × 再 470 輪的錢。

SonarSource 逐輪追蹤了一次「過度讀取」。PR 早期，agent 需要理解一個約 67 行的輔助函式。為了找它，agent 讀了整個 618 行的檔案——6,472 個 token，而實際用到的只有約 700 個。這次讀取在第 42 輪左右進入對話，然後在剩下的 470 輪裡全程留守：5,770 個浪費 token × 470 輪 ≈ 270 萬個純浪費 token，以目前 cache-read 定價約 0.54 美元——只因為一次不必要的整檔讀取。

五毛四聽起來微不足道。但那個 PR 把同樣的模式重複了約十次，外加數十次盲目的全樹 grep——其中好幾次什麼都沒搜到，只好再來一次範圍更大的 grep。在同一個 repo 的 18 個可比較單一任務 PR 中，平均數字更糟：每個 PR 約 2.34 億 context token、約 65 美元（中位數約 52 美元）、約 700 次模型往返，context window 常態性地在 45 萬到 97.5 萬 token 之間見頂——逼近 1M 上限，而一旦觸頂，agent 就被迫壓縮（compact）並完全失去先前的上下文。

第二個更安靜的失敗：grep 會漏

在 token 成本之下，還藏著一個正確性成本。在一個塞不進 context window 的 repo 裡，grep 不只是花 token——它會漏。正規表達式找到的是你「想到要搜」的字串，而不是那個透過介面、別名或另一種程式語言輾轉呼叫到你函式的那個呼叫點。

SonarSource 的文章記錄了一個完美範例。名為 resolve_return_type 的方法存在於多個後端——Python、TypeScript、Java、Rust、C# 和一個共用核心。當 agent 去 grep 它時，正規式無法判斷這個呼叫實際綁定到哪個定義，只能打開檔案、讀一大段切片來猜。更麻煩的是，C# 後端裡的對應函式叫做 resolve_type_node——一個搜 resolve_return_type 永遠不會浮出的名字。跨語言重構——今天你所能交辦給 agent 最昂貴的事情之一——從多語法 grep 侵略戰，變成單純的「沿著邊走」。

漏掉的呼叫點變成建置失敗、多一趟 CI 往返、更多重工——每一次都再繳一次全新的上下文稅。

提出的解法：導航圖，而不是檔案系統

SonarSource 的答案是 SemSitter——一個為 codebase 建立 Unified Dependency Graph（UDG）的導航引擎：每個函式、方法、類別、欄位與參數都是節點，彼此的關係是帶類型的邊——calls、references、returns、has-param、is-type、contains、extends。agent 不再問「哪些檔案提到這個字串」，而是問圖：「給我這個呼叫綁定的定義、擁有它的型別、它的回傳型別，以及誰呼叫它」——然後拿回正好就是這些：一個方法主體加上回答問題的邊，沒有整個檔案、沒有需要擴大範圍的讀取。

這張圖的連結也不止於程式碼對程式碼。程式碼節點連到治理它的特定文件（documented_by 邊），而文件、ticket 與設計筆記之間按語意互相連結——agent 可以循著「這條規則被那篇 ADR 修訂」走下去，而不必讓全文搜尋吐回五十個近似錯誤的結果。

Sonar 早前（2026 年 6 月 30 日發布）的基準測試報告稱，語意程式碼圖在對照實驗中最多可降低 36% 的 agent 成本。必須講明白：這些是廠商的數字，量測的對象正是廠商自己賣的產品，請自行斟酌。但本週公布的量測方法——完整 trace、逐輪 token 會計、明確標價——比多數同類報告透明得多。

分析：利潤移到了導航這一層

拿掉產品推銷，這個發現本身依然成立。在真實的大型 codebase 中，AI coding agent 的瓶頸不是推理——是導航。以 grep 導航帶著兩個你不量測就看不見的複利成本：

1. Token 成本。每一次盲目讀取都會在之後每一輪被重複計費。在一個普通 PR 上，那是 1.56 億 context token、約 41 美元；在一批 PR 上平均約每個 65 美元。
2. 正確性成本。grep 找到的是字串，不是語意。漏掉的東西變成重工和額外的 CI 往返，每次都再繳一次稅。

SonarSource 自己的紀錄裡有個值得玩味的諷刺：那個燒掉 1.56 億 token 的 agent，當時正在實作的正是 call-site resolution——它自己所缺少的那個導航能力。因為沒有索引可用，它退回 grep 和整檔讀取，換來 500 倍的輸入輸出比。

這個結論可以推遠遠超出程式碼。任何「為了回答一個問題而掃整個共用硬碟」的自動化，或任何「每一步都把不斷膨脹的對話重新送進模型」的流程，都在用另一張發票繳同一種稅。解法枯燥但有效：收窄檢索、白名單讀取、有意識地壓縮，而最重要的——去量測。因為一個 token 的成本，取決於它在迴圈裡存活多久，而不是它有多大。

如果你的 agent 工作的 codebase 比它的 context window 大，SonarSource 的訊息很直白：這筆稅已經在你的帳單上了。唯一的問題是，你看過那一行細項了嗎？