Agentic 工作流的真實成本結構:token、工具、維運與人審的隱藏帳單

上個月我們幫一家保險客戶算一筆帳。他們的理賠審核 agent,PoC 階段每次執行的 LLM 帳單是 0.11 美元,團隊據此樂觀地把「每案成本」寫進了給高層的簡報。我把生產環境三個月的實際數字攤開來看,單次真實成本是 0.94 美元。差了將近九倍。

錢沒有憑空消失。它藏在 token 以外的地方,而多數 PoC 從來沒把那些地方算進去。

agentic workflow 成本從來不是一條 token 帳單

先給一個可以直接引用的定義:一次 agent 執行的完整成本,等於「模型推論 + 工具呼叫 + 迭代重試 + 維運基礎設施 + 人工審核」五項的加總,而不是單看 API 回傳的 token 用量。PoC 之所以會嚴重低估 agentic workflow 成本,是因為它只量測了第一項——偏偏那一項在成熟系統裡往往是最小的一塊。

problem 出在 agent 跟單次 prompt 不一樣。一次 chat completion 就是一進一出。一個 agent 要規劃、呼叫工具、看結果、再決定下一步,一個任務跑五到十五輪 LLM 呼叫是常態。每一輪都把前面累積的 context 重新餵一次,token 是隨步數平方成長的,不是線性。這是第一個被漏掉的乘數。

把單次執行的帳單拆開

下面是我們替客戶落地時,實際用來估算與對帳的成本模型。比例來自我們手上幾個生產案的加權平均,產業不同會漂,但結構高度一致:token 幾乎從來不是大頭。

成本項目	佔單次執行成本	PoC 是否計入	為什麼被漏掉
模型推論 token	12–20%	通常有	只算了單輪,沒算多步累積的 context 膨脹
工具與外部 API 呼叫	15–25%	少數有	搜尋、向量檢索、程式沙箱、第三方查詢各自計費
迭代與失敗重試	10–18%	幾乎沒有	agent 卡住會重跑,失敗任務照樣燒完整成本
維運基礎設施	15–20%	幾乎沒有	向量庫、追蹤、日誌、版本控管、監控的攤提
人工審核與例外處理	25–40%	從不	高風險輸出需要人看過才能放行

看最後一列就懂了。真正壓垮商業案例的不是模型太貴,是人審與維運這兩塊,而它們恰好是 Demo 那天完全看不到的。

人審是隱形帳單裡最大的一張

一個能自動處理八成案件的 agent 聽起來很美。但另外兩成,只要輸出會影響錢、合規或客戶權益,就得有人簽字。那家保險客戶的 agent,自動通過率確實有 78%,問題是被退回人審的每一案,平均要資深理賠員花六分鐘讀完 agent 的推理鏈、核對來源、再決定推翻或放行。

把那六分鐘的人力成本除回每一次執行,就是那條讓 0.11 變成 0.94 的曲線。更麻煩的是,人審成本不會隨規模下降——量放大十倍,你要嘛請十倍的人,要嘛審核品質崩掉。這跟軟體「寫一次跑到飽」的直覺是反的,也是最多商業案例翻車的地方。

維運與重試:那些沒有 Demo 的成本

維運這塊更陰險,因為它平常沒有畫面。向量資料庫要錢,而且知識庫每更新一次就要重新索引;可觀測性工具按事件計費,一個多步 agent 一次執行就打出幾十個 trace;prompt 和工具定義要版本控管,不然出事沒人知道昨天改了什麼。這些都不會出現在 PoC 的試算表,卻是上線後每個月準時扣款的固定支出。

重試則是被低估的浮動成本。agent 會卡在迴圈裡、會呼叫工具失敗後重來、會產出格式錯誤觸發重跑。關鍵在於:一個最終失敗、沒交付任何價值的任務,照樣把 token、工具、算力全部燒完。我們看過失敗率 12% 的 agent,等於每產出一個有效結果,就有一次執行的成本純粹蒸發。估 ROI 時如果用「成功案例」當分母,數字會漂亮得危險。

怎麼算才不會自欺

一個能被董事會採信的 agentic workflow 成本模型,分母必須是「所有發起的執行」,包含失敗與被退審的;分子要把上面五項全部含進去,而且人審與維運要用月攤提、不是單次邊際。我們給客戶的簡單檢查法是:拿生產環境跑滿一個月的總帳單,除以那個月真正被系統交付、且沒被人推翻的任務數。這個數字通常是 PoC 估值的五到十倍——早知道,總比上線第二季被財務追問好。

這也是為什麼我們進場做 FDE 時,不會停在「Demo 能跑」。工程師會在客戶現場把這五項成本接上真實計費、盯滿一個完整週期,再回頭決定哪些步驟該收斂 context、哪些例外值得投人審、哪些乾脆不該交給 agent。Demo 很美不算數,帳算得清、上線後有人願意一直用,才算數。