AI Token 為什麼這麼貴？從「自迴歸」運作原理拆解 Coding Agent 燒錢的真相
如果你最近開始用 AI Coding Agent 寫程式，應該多少感覺到一件事：同樣是「跟 AI 對話」，用網頁版聊天機器人問問題很便宜，但把 AI 接進開發流程做自動修 bug、讀檔案、跑測試，帳單卻會不成比例地飆高。這不是你的用法特別浪費，而是語言模型計算 Token 成本的方式，天生就是這樣設計的。這篇文章會把「Token 為什麼貴」拆到最底層的運作原理，讓你在評估要不要導入 AI Coding Agent、要抓多少預算時，有一個真正貼近技術現實的判斷基礎。
先複習：Token 是什麼（如果你已經懂，可以跳過這段）
Token 就是一個字，或是一個字的一部分——這件事本身不複雜。模型不會照人類直覺用空格切字，而是連空格、標點、程式碼裡的大括號都會各自算成 Token；中文字則可能拆成一到兩個 Token。如果你還沒看過完整的定義說明，可以先讀〈AI Token 是什麼？新手一次看懂 AI 為什麼一直提到 Token〉打底，這篇會直接跳到大家真正想知道的問題：Token 為什麼貴。
關鍵原因：語言模型是「自迴歸」運作，每一步都要重讀全部內容
這是整篇文章最核心的觀念。人類回答問題時，不會每次都把整段對話從頭重讀一遍才開口；但語言模型的運作方式（稱為 autoregressive，自迴歸）不是這樣——它每預測一個新 Token，就要把「目前為止的全部內容」重新看過一次，再吐出下一個 Token，然後把這個新 Token 加進去，繼續看一次全部內容，再吐下一個（後面會提到有 KV Caching 這個優化手段，但先看沒有它時的樸素運作方式）。
舉個最簡單的例子：模型要接龍「the cat sat on the ___」，它不會只看最後一個詞就猜答案，而是要把「the cat sat on the」這整串都放進運算裡，才能預測出「mat」。這個過程會不斷重複，而且每多一個字，要重新處理的內容就多一分——這也是為什麼跑這些模型會這麼耗電，因為每一步都不是「接著講」，而是「從頭再看一次、再多講一個字」。
聊天機器人 vs. Coding Agent：為什麼後者的成本會失控
同樣是問 AI 問題，網頁版聊天機器人通常成本可控：你問一個 500 Token 的問題，模型輸出一段思考過程和答案，成本就停在這裡，因為對話通常不會無限往下疊加太多輪。
但 Coding Agent 完全是另一回事，原因是它有「工具呼叫」（tool call）的能力——它可以主動要求讀取檔案、執行指令、修改程式碼，而不是像聊天機器人一樣只回答文字。問題在於，每一次工具呼叫回傳的內容（例如整份程式碼檔案），都會被加進「上下文」（context）裡，而根據前一段的自迴歸原理，之後每一步都要重新處理這個越滾越大的上下文。你問的可能只是「幫我修這個登入功能的 bug」，但模型讀了兩個檔案、想了幾輪，這個過程本身就會讓輸入 Token 量呈倍數成長。
具體試算：一個「簡單」的 bug 修復，Token 是怎麼滾到 5、6 萬的
以下是根據影片描述的運作邏輯，重建的示意性試算（非影片原始逐項數字），用來還原 Token 放大的過程：假設系統提示詞（system prompt，告訴模型「你是誰、該怎麼做事」的背景指令）是 4,000 Token，加上你的問題 200 Token，第一次輸入就是 4,200 Token。
模型先思考一下（產出約 2,000 output Token），接著決定要讀第一個檔案，這個工具呼叫本身很短（約 100 Token），但系統回傳的檔案內容可能有 5,000 Token，全部加回輸入後，下一輪輸入就變成約 11,300 Token。模型再想一輪（再 2,000 Token），決定讀第二個檔案（又是約 4,000 Token 的檔案內容），輸入這時候已經逼近 17,400 Token。模型再思考一輪、最後產出程式碼修改（diff），整趟流程跑下來，光是「讀兩個檔案、修一個 bug」這麼「簡單」的任務，加總下來的輸入 Token 量就落在 5.5 萬到 6 萬之間，還沒算進思考過程本身消耗的輸出 Token。
這還只是一次成功的修復。如果模型改錯了、你要求它重新來過，這個累積的上下文會被整段帶進下一輪，成本只會繼續往上疊加，不會歸零重算。
真實案例：一個小遊戲的 6 個提示，燒掉 200 萬個輸入 Token
Computerphile 主持人在影片中示範了一個更真實的例子：他用 GitHub Copilot 寫了一個復刻 Windows 3.11 風格的 Starfield 螢幕保護程式，過程中只下了大約 5、6 個提示（例如「幫星星加點顏色」「讓速度不要那麼一致」），中途還讓 AI 修過自己造成的一個 bug。最後檢查該次工作階段的用量，累計輸入 Token 高達 200 萬、輸出約 4.7 萬 Token——這遠遠超過一般人「在網頁上跟 AI 聊天」的用量級距，但對 Coding Agent 的實際工作模式來說，這其實是很典型的規模。
KV Caching：能省一點，但解決不了根本問題
如果你覺得「每次都要重算全部內容」聽起來太沒效率，業界確實有對應的優化手段，叫做 KV Caching（鍵值快取）：模型會把處理過的中間運算結果暫存起來，下一輪如果內容有重疊的部分（例如同一段對話往下接），就不用完全重算，只算新增的部分。
但這個優化有兩個限制：第一，快取不會永久保留，如果你晾著不動一段時間，系統可能會把快取清掉、之後要重新「預填」（prefilling）回去；第二，快取能省的是「重複計算」的運算成本，並不會改變「上下文越滾越大，之後每一步都要處理更多內容」這個根本結構。也就是說，KV Caching 讓自迴歸運作沒有想像中那麼浪費，但沒有從根本上解決 Coding Agent 場景下 Token 用量會隨對話輪次快速膨脹的問題。
這對評估 AI Token 預算的人意味著什麼
理解了這套機制，就更容易看懂近期的一個實際案例：以 Computerphile 影片中提到的 GitHub Copilot 為例，它近期已從「固定月費、用量隨便用」調整為更貼近實際運算成本的計費方式——這是目前觀察到的個案，不代表所有平台都會走同一條路，實際計費模式仍要以各平台官方公告為準。但背後的邏輯值得留意：如果平台方長期用固定月費補貼遠高於月費本身的實際運算成本，這種補貼模式終究難以長期維持。
對正在評估導入 AI Coding Agent 或估算 Token 預算的團隊來說，這裡有幾個實務上的判斷點：
不要只用「聊天機器人」的用量經驗去估算 Coding Agent 的成本，兩者的上下文成長模式完全不同，Coding Agent 的成本會隨工具呼叫次數與檔案大小非線性放大。
任務拆得越細、範圍越明確，成本越可控——一次只處理一個小改動，會比丟一個模糊、需要讀大量檔案才能理解的任務便宜很多。
注意模型「想太久」的風險：思考過程（thought）本身也會計費，有些任務模型可能陷入迴圈、想很久卻沒有實質進展，這部分同樣會反映在帳單上。
如果團隊已經開始大量使用 Coding Agent，建議提早建立 Token 用量追蹤機制，而不是月底才看到帳單才發現用量遠超預期。
FAQ
Q1：Token 是不是就等於一個字？
不完全是。Token 可能是一個完整單字，也可能只是單字的一部分，空格、標點符號、程式碼符號都會各自被算成獨立 Token，中文字則常拆成一到兩個 Token，實際切法由模型使用的 tokenizer 決定。
Q2：為什麼 Coding Agent 的 Token 消耗會比一般聊天機器人高這麼多？
因為 Coding Agent 具備工具呼叫能力，能主動讀取檔案、執行操作，這些回傳內容會持續疊加進上下文；而語言模型是自迴歸運作，每一步都要重新處理目前為止的全部上下文，上下文越大，後續每一步的成本就越高。
Q3：KV Caching 可以完全解決 Token 成本過高的問題嗎？
不能。KV Caching 能減少「重複計算」的部分成本，但無法改變上下文本身會隨對話輪次或工具呼叫持續變大的結構性問題，而且快取本身有存活時間限制，閒置一段時間後可能需要重新預填。
Q4：是不是所有平台都會把固定月費方案改成按 Token 計費？
不一定。以 GitHub Copilot 為例，它是目前觀察到的一個個案：固定月費若長期低於使用者實際消耗的運算成本，等於平台在持續補貼，這種補貼模式難以長期維持。但這不代表所有平台都會走同一條路，實際計費模式仍要以各平台官方公告為準。
Q5：一般開發團隊要怎麼避免 Token 帳單暴衝？
建議把任務拆小、範圍寫清楚以減少不必要的檔案讀取與思考輪次，並提早建立 Token 用量監控，而不是等到帳單出來才發現問題；評估預算時也不要直接套用聊天機器人的用量經驗。
資料來源聲明
本文內容參考整理自 YouTube 頻道 Computerphile 於 2026 年 7 月 2 日發布的影片《Why AI Tokens are so Expensive》，文中案例與試算數字均為該影片內容之整理與重新論述，非逐字翻譯。
延伸閱讀
立即行動
如果你的團隊正在評估導入 AI Coding Agent，或想搞清楚自己現在的 Token 用量到底花在哪裡，免費試用 AI Token King，讓我們幫你把用量追蹤與預算規劃一次建立起來，不用等到帳單出來才傻眼。
留言