AI 專案的費用，不能用代理數、任務數或人數來估，要用輪數乘以每輪的平均上下文來估。低估多半出在三處：重試與驗證多出來的輪數、思考用掉的 token，以及快取其實沒有生效。2026 年 8 月到 10 月，開發團隊用 AI 代理做開發與資料處理，量過三組用量。只依代理數估算，兩組的實際花費是估算的約 10 倍與 5 到 8 倍，另一組的代理數則從約 6 個放大成 136 個。
估法：輪數乘以平均上下文
AI 代理每做一輪，就要把到目前為止的上下文重新讀一次。一個代理的費用，因此大致是輪數、每輪平均上下文長度與快取讀取單價三者相乘。代理數只說明有幾位在做事，沒有說明每位做幾輪，也沒有說明每輪要重讀多少內容，所以用代理數或任務數估，落差常是五到十倍。開發團隊承接 AI 導入與開發時，估價前先用這個算法抓量級。預估超過事先訂的門檻，就先報客戶；作業途中也會量用量。
三組用量如下。費用是依官方牌價換算，這些工作跑在開發團隊自己的方案上，不是實際帳單，所以下表只列倍數與用量。
| 工作 | 只依代理數估算的 | 實際用量 | 結果 |
|---|---|---|---|
| 全站瘦身 | 4 個 Sonnet 代理 | 每個代理跑 220 到 370 輪，每輪平均重讀 45 萬到 63 萬 token，快取讀取合計約 6.5 億 token | 實際費用約為估算的 10 倍 |
| 企劃流程 | 8 個代理 | 約 580 次工具呼叫，快取讀取合計約 1.46 億 token | 實際費用約為估算的 5 到 8 倍 |
| 稽核流程 | 約 6 個代理 | 136 個代理，合計約 830 萬 token | 批次驗證後約 7 個代理，成本約為原本的 5% |
第三組是一次程式稽核。稽核流程找出約 120 則發現，若每一則各派一個驗證代理，找出多少就派出多少個。改成一個代理驗 15 到 20 則之後，代理數降到約 7 個，成本降到原本的約 5%。
- 每則發現各派一個驗證代理136 個代理代理數隨發現數放大
- 合併後少掉的代理成本約為原本的 5%一個代理驗 15 到 20 則
- 批次驗證約 7 個代理派工前先算出發現數乘以驗證者數的上限
稽核流程。成本為依牌價換算，不是帳單。
開發團隊的做法是四條規則：
- 動態派工（fan-out）之前，先算出發現數乘以驗證者數的上限；講不出數字，就不要那樣寫。
- 把大任務拆小，並替每個任務設定輪數上限。
- 作業途中就量用量，不等到結束才看帳。
- 預估超過事先訂的門檻，先報客戶。
思考會先用掉大量 token
讓模型先思考再寫，輸出比較守規則，但思考的內容同樣算在輸出的 token 裡。在一個 AI 報告生成功能的測試站上，同一份報告一次寫完，模型啟用思考（強度設為低也一樣）時，輸出共 12,000 到 17,000 token，其中真正寫出來的文字約 3,000，其餘是思考。寫一份報告要 15 到 75 秒，13 題測試裡有 2 題超過寫作期限而失敗。
- 15 到 75 秒啟用思考，一次寫完保留11/11
- 6 到 17 秒關閉思考，一次寫完不採用2/13
測試站、真模型，13 題。被驗證程式刪掉的句子，關閉思考時是啟用思考的 3 倍。
開發團隊沒有採用關閉思考，而是把同一份資料包分給幾位「作者」同時寫：每個子問題一位，直接回答與標題一位，提醒一位，規劃一位，其餘一位。每位只拿到自己欄位的提示，總時間約等於最慢的一位。某一段失敗，只是那一塊留空，由程式用資料事實補底；全部失敗才算整份失敗。測試結果是 13 題全數完成，最慢 46 秒。
拆段是用更多次呼叫換等待時間，所以費用要照輪數乘以上下文的算法重新估，不能沿用一次寫完的估價。這類取捨也不能只看單一指標：語言模型評估的研究主張，應同時看多個指標，不能只看準確率，才看得出各種取捨（Liang 等，2023）。
快取的門檻會靜默失效
提示詞快取能讓重複送出的內容變便宜，但有最低長度的門檻。官方文件寫明，提示快取有依模型而定的最低可快取 token 數，低於門檻的提示，即使標記了 cache_control 也不會被快取（Anthropic，Prompt caching）。
乖獸（Cooking Monsters）的正式站為了成本，把模型從 gpt-4o 換成 Claude Haiku 4.5，並在系統提示詞加上快取。該站實測結果如下：同樣的工作量，換模型後成本約為原本的一半，快取命中時又比沒有快取低約 27%。
風險在提示詞的長度。這份系統提示詞約 4,900 token，而該模型的最低可快取門檻是 4,096 token，只高出約 800。這個數字以當時的官方文件為準，之後可能變動。日後若有人把提示詞精簡到門檻以下，快取就會失效，而且不報錯，只是快取讀取量變成 0，帳單卻變貴，沒有任何訊息提醒。
對策是讓失效看得見。日誌表記下輸入、輸出、快取寫入、快取讀取四種 token，費率放在後台可調整的設定，再做成用量與費用儀表板，成本變貴時就看得到是哪一欄變了。估價時也該一併問清楚：提示詞多長、用哪個模型、門檻是多少、誰在看快取讀取量。上線後怎麼持續盯用量與品質，另見AI 上線後的品質與維運。
大批量工作，審查比產出貴
一批上千份文件的段落重排與標籤，是典型的大批量工作。試跑兩輪、共 62 篇時，花費幾乎都在審查：兩輪審查的費用約為標註的 20 倍。花費集中在確認結果是否正確，不在產出本身。
全量因此不再讓最貴的模型逐篇讀。程式先整理出精簡的審查對照檔，審查者不必翻資料庫與原檔。標註交給 Haiku，一篇一個子任務；長篇先切段再合併；驗證器的結束碼是 0 才收，不靠人眼判斷。Sonnet 依風險抽審 10 到 15%，長篇、掃描檔、版面有疑慮的與新來源優先。升級條件寫成規則：只有被標出的難例，以及驗證器過不了的，才交給 Opus。
- 全部語料標註約 1,500 篇一篇一個子任務，由 Haiku 標註
- 未抽審的篇數只過程式驗證器結束碼 0 才收
- 依風險抽審約 160 篇約一成，由 Sonnet 審查
- 升級給 Opus9 個子任務只處理標出的難例與驗證器過不了的
子任務數：Haiku 約 1,600 個、Sonnet 約 50 個、Opus 9 個。篇數與子任務數均為約略值。
整批處理的成本落在數百美元等級，每篇不到一美元。這是依牌價換算的量級，不是帳單。
審查端也需要抽樣核對與程式驗證，不能只靠模型自己給分。用模型當評審，已知評審會偏好特定的答案位置、較長的回答，或自己產生的答案（Zheng 等，2023）。品質規則怎麼訂，另見批次內容的品質關卡。
額度要依用途分帳
使用者功能用的額度，不能被內部的批次處理或測試吃掉。常見的錯誤，是把只供最終使用者查詢解析的金鑰拿去跑批次標註：批次裡只要提示詞寫錯，整批丟棄的呼叫就是純浪費，前台的正當查詢卻可能因額度耗盡而全部失敗。批次試跑若用了後端金鑰，測試站的使用者功能也可能因額度不足全部失敗。
規則是劃線。批次、清理、測試一律不動使用者功能的金鑰；要用到該金鑰的批次試跑，先報預估花費，同意才跑；整批資料處理改走獨立的金鑰或本機，定期審核也不佔用使用者額度。另一個專案裡，金鑰只花在後台提交的需求上，金鑰壞掉時整輪中止，不重複打十幾次。
分帳也讓用量圖看得懂。額度混用時，失控的 fan-out 讓用量暴增，第一個反應往往是懷疑金鑰外洩，因為從用量圖上，分不出正常工作與金鑰被盜。用途分開之後，出現異常，就是異常。
先小量試跑，再放大
全量之前，先用小量樣本跑一輪，量出分數與每份的花費，再放大。前面那批文件，試跑 62 篇、兩輪之後才決定全量的做法，規則也固定下來，下一批新資料照同一套走。上線前的評估怎麼做，另見AI 上線前的評估。
- 取一小批具代表性的樣本，要包含長篇、掃描檔這類難處理的情況。
- 同時量品質分數與每份的花費，兩者都要有數字。
- 用輪數乘以平均上下文，把試跑的用量放大到全量，並替重試與審查留餘裕。
- 訂一個費用門檻，預估超過就先報客戶，全量途中再定期量用量。
試跑也讓「不做」成為可以在花大錢之前做出的決定：試跑兩輪後若評估成本偏高，可以在全量之前停掉。
哪些數字不該交給模型決定，見婚宴外燴的線上提案：價格一律依規格。
不適合的情況
- 只有單次呼叫、提示詞固定的功能：輪數與上下文都固定，用呼叫次數乘以每次的 token 數就夠，不需要這套估法。
- 還沒有可試跑的樣本，也沒有可檢查的品質規則：這時估不出輪數，先收樣本、訂規則，再談預算。
- 預算必須在試跑前定成單一數字，而且試跑後不能調整：這套估法給的是區間，要靠試跑的實測值收斂。
下一步：要準備什麼
洽談前先備齊四項：要交給 AI 的任務清單與預計的量；一小批具代表性的樣本資料；品質怎麼算過關的可檢查規則；使用者功能與內部批次各自使用的額度。備齊之後，聯絡開發團隊，從小量試跑開始量。
