AI 專案帳單突然變大時，先別急著全面限制 Token。Google Cloud 8 月 22 日提出的 AI Tokenomics，核心是把模型消耗連回業務結果：同樣花一筆錢，成功完成可採用的客服分流，和產生一堆被人工退回的答案，價值完全不同。
Google 文中提到一個客戶的 AI 支出單月增加超過五成，問題在於團隊無法回答是哪個部門、專案或 Agent 造成。這是 Google Consulting 的客戶案例，不代表普遍平均；但它指出一個常見盲點：Token 帳單告訴你花了多少，沒有告訴你為什麼值得。
Agent 成本為何特別難估
傳統軟體常以席次或固定資源規劃。Agent 的成本會跟著上下文長度、推理模型、重試、子 Agent、搜尋與工具呼叫變動。同一個使用者問題，可能一次完成，也可能反覆規劃、查詢與自我修正。
因此，每百萬 Token 價格只能比較一層原料。完整成本還包含向量搜尋、資料庫、外部 API、執行環境、監控、評測與人工覆核。這也是企業 AI ROI 成本衝擊常被低估的原因。
FinOps Foundation 的說法更精準：Token 經濟是 AI 單位經濟的一部分，不能把 Token 成本直接等同所有 AI 成本。自建模型的固定投入、資料授權與團隊維運仍要算進去。
先追四組欄位
第一組是歸屬：部門、產品、環境、用例與責任人。第二組是執行：模型、輸入與輸出 Token、快取、工具呼叫、重試與延遲。第三組是品質：通過評測、人工退回、錯誤與完成率。第四組是結果：節省時間、完成交易、解決案件或產生可採用內容。
Google 的模型 API 支援把自訂標籤送進帳務系統，這類標籤適合做成本歸因。跨供應商時也可沿用相同欄位，搭配模型路由成本策略比較，而非每家各用一套報表。
最值得看的指標是「每次成功結果成本」：總執行成本除以通過品質門檻的結果數。旁邊再放重試率、人工覆核分鐘與錯誤成本，才能辨認便宜模型是否只是把工作轉嫁給人。
台灣中小企業的最低可行做法
先選一個已在付費的用例，連續記錄一段正常營運週期。不要一開始就做全公司儀表板。把每次執行標上用例與版本，區分正式、測試與個人實驗；超過基準時先看上下文變長、迴圈增加、流量成長或模型切換，再決定限額。
我不建議只設每日 Token 上限。硬上限能止血，卻可能在最有價值的流程中途切斷。比較好的護欄是每個用例有預算、單次執行上限、異常提醒與降級模型，並保留Shadow AI的未授權支出盤點。
當某個 Agent 成本上升但成功率與收入同步改善，可以擴大；成本下降、人工退回卻增加，通常只是把帳藏到另一個部門。這才是 Tokenomics 真正要解的問題。
常見問題
AI Tokenomics 和加密貨幣 Tokenomics 一樣嗎？
不同。這裡的 Token 是模型讀寫與推理的計量單位，Tokenomics 指如何把 AI 用量、成本與業務價值連起來，不是在分析代幣供需。
只看每百萬 Token 價格夠嗎？
不夠。你還要計入上下文、重試、工具、基礎設施、監控與人工覆核；最終用每次成功結果成本比較才有意義。
沒有 FinOps 團隊也能開始嗎？
可以。先為一個用例記錄模型、Token、工具呼叫、成功與人工退回，建立正常基準。資料穩定後再擴大到部門與跨供應商報表。
參考來源
- Google Cloud Blog：Tokenomics: Why smart teams spend more on AI, on purpose（2026-08-22）
- Google Cloud Docs：AI and ML perspective: Cost optimization（2026-08-24 查核）
- Google Cloud Docs：Custom metadata labels（2026-08-19）
- FinOps Foundation：Token Economics: The Atomic Unit of AI Value（2026-05-10）
- Google Cloud Docs：Guide to Cloud Billing Resource Organization and Access Management（2026-08-24 查核）