作者注：拆解 Agent 長任務的 Token 賬單結構，說明輸入 Token 爲什麼會佔到絕大部分，以及如何調整上下文結構，提升前綴緩存的複用率。
很多團隊把多步 Agent 接進產品後，月底看賬單才發現問題：用戶只提了一個需求，消耗的 Token 卻是普通對話的幾十倍。大家的第一反應通常是“模型輸出太囉嗦”，於是去壓輸出長度。實際的大頭在輸入側，而且主要來自 每一輪都要重新帶入的歷史上下文。
這不是憑經驗的猜測。近期公開的工程分享給出了比較具體的數據：國內線上場景中，一次用戶請求平均觸發約 7.2 次模型調用；在一條 50 步的調用鏈裏，輸入 Token 約佔 99.4%，輸出只佔約 0.6%。推理引擎團隊對 Agent 負載也有類似描述：長前綴、短輸出、多輪循環。
核心價值：讀完本文，你能看懂 Agent 長任務 Token 賬單的結構，理解前綴緩存爲什麼能降本，並拿到 5 個在應用側就能落地的上下文組織方法。
Agent 長任務 Token 賬單核心要點
先用一張表概括本文的結論，後面各節再逐條展開。
| 要點 | 說明 | 對你的價值 |
|---|---|---|
| 調用次數被放大 | 一次用戶請求平均約 7.2 次模型調用，複雜任務超過 50 步並不少見 | 估算成本要按“任務”算，不能按“請求”算 |
| 輸入佔絕對大頭 | 50 步調用鏈中輸入約佔 99.4%，輸出約佔 0.6% | 降本應優先處理輸入，壓輸出收效有限 |
| 重複上下文是主因 | 每一步都重新帶入歷史上下文，同樣的內容被反覆計費 | 找準真正的成本來源 |
| 前綴緩存可以複用 | 前綴相同的部分若命中緩存，可以省去重複的 prefill 計算 | 結構穩定的上下文更便宜 |
| 結構決定命中率 | 固定提示詞和工具結構、變化信息放在末尾、適時壓縮歷史 | 不換模型也能降低成本 |
Agent 長任務 Token 成本重點詳解
Agent 和普通聊天的最大區別在於“循環”。以製作一份 PPT 爲例，系統要依次完成材料讀取、內容規劃、逐頁生成、工具製作和結果檢查。用戶眼裏這是一項任務，系統裏卻是多輪推理加多次工具調用，而且每一步都可能重新讀取上下文，結果不合格時還要回頭修改。
每一輪調用，模型拿到的都是“系統提示詞 + 工具定義 + 截至目前的全部歷史 + 本輪新信息”。歷史越積越長，單輪新增的內容卻很少，幾十輪下來，同一段前綴被重複計費幾十次。99.4% 的輸入佔比就是這樣累積出來的。
爲什麼 Agent 長任務的輸入 Token 遠多於輸出
從推理引擎一側看，這個結構更清楚。TokenSpeed 的分享以 coding agent 爲例：模型持續思考、調用工具、獲取結果、再繼續思考，整個過程由多輪短請求循環組成。第一次請求可能就帶着幾十 K 的前綴上下文，後續每次循環的輸出往往只有幾百個 token。
下表把聊天負載和 Agent 負載放在一起對比，便於你判斷自己的應用屬於哪一類。
| 維度 | 傳統 Chat 負載 | Agent 長任務負載 |
|---|---|---|
| 請求形態 | 一問一答，一次生成完整回覆 | 多輪短請求循環，夾雜工具調用 |
| 前綴長度 | 通常較短 | 起步即可達幾十 K，並逐輪增長 |
| 單輪輸出 | 相對較長 | 往往只有幾百個 token |
| 上下文複用 | 一次加載後即釋放 | 同一前綴在任務內被反覆攜帶 |
| 成本主導項 | 輸入、輸出都有分量 | 輸入（尤其是重複前綴）佔絕大部分 |
前綴緩存在 Agent 長任務中如何工作
推理引擎處理請求分兩個階段：prefill 階段把輸入全部計算一遍，生成 KV Cache；decode 階段再逐個生成輸出 token。Agent 場景下，幾十 K 的前綴每輪都要 prefill，這部分計算正是成本所在。如果同一段前綴已經算過、結果還留在緩存中，就可以直接複用，省掉這部分 prefill。
推理引擎團隊把 KV Cache 複用率視爲決定推理成本的關鍵變量。分享中提到，據稱 DeepSeek 的緩存複用率在 99% 以上，業界多數系統目前在 70% 到 80% 之間；Agent 負載在 prefill 場景下的前綴命中率通常在 90% 以上，命中後只需追加計算幾百個 token。
還有一個容易忽略的細節：前綴緩存是從頭開始逐段匹配的。TokenSpeed 早期借鑑 SGLang，用 Radix Tree 管理前綴緩存，樹上每個節點對應一段 token 序列，請求沿着這棵樹從根部開始匹配。後來雖然改成了 Flat KV 設計，複用仍以固定大小的邏輯塊（128 個 token）爲單位。對應用開發者來說，結論很直接：前面只要有一個 token 不同，後面的內容就無法複用。
如何組織上下文提升 Agent 長任務前綴緩存命中率
理解了緩存的匹配方式，優化方向就明確了：讓每一輪請求的開頭儘量長、儘量保持不變。WorkBuddy 團隊採用的做法是固定提示詞和工具結構、把變化信息放到上下文末尾，上下文變長之後再壓縮歷史內容。下面把它展開成可以執行的 5 條做法。
| 做法 | 具體動作 | 常見反例 |
|---|---|---|
| 1. 固定系統提示詞 | 系統提示詞逐字穩定，版本變更集中發佈 | 在開頭插入當前時間、用戶名、隨機示例 |
| 2. 固定工具結構 | 工具列表順序、參數描述保持不變 | 每輪按需增刪工具，或者序列化順序不穩定 |
| 3. 變化信息放末尾 | 時間戳、本輪觀察結果、動態狀態追加在最後 | 把“當前進度”寫進系統提示詞頂部 |
| 4. 歷史只追加不改寫 | 已發送的歷史保持原樣，新內容只往後接 | 每輪重新格式化或重排之前的消息 |
| 5. 階段性壓縮歷史 | 上下文過長時在檢查點壓縮一次，之後繼續追加 | 每輪都重新生成摘要，導致前綴天天變化 |
固定提示詞與工具結構的 Agent 長任務實踐
第 1、2 條最容易被忽視。很多框架會在系統提示詞裏拼接當前日期，或者根據步驟動態挑選工具，這兩種寫法都會讓開頭每輪不同，前綴緩存從第一個 token 起就失效。比較穩妥的做法是：系統提示詞只放規則和角色，日期等信息作爲一條普通消息放到末尾；工具全集一次性列出，用提示詞約束“本階段只用哪些”，而不是改動工具列表本身。
序列化方式也要留意。同一份工具定義，如果 JSON 字段順序在不同進程裏不一致，從字節層面看就是兩個不同的前綴。建議對工具定義做固定排序後再發送，並在日誌中記錄前綴的哈希值，方便排查“明明沒改卻沒命中”的情況。
壓縮歷史與緩存複用的 Agent 長任務權衡
第 5 條存在一個需要權衡的地方。壓縮歷史能減少輸入長度，但壓縮之後前綴發生變化，本輪的緩存必然失效。如果每輪都壓縮，等於每輪都放棄複用。因此更合理的節奏是設定閾值，比如上下文達到某個長度、或者一個子任務結束時壓縮一次，壓縮後的版本再作爲新的穩定前綴，繼續只追加不改寫。
上圖的兩種佈局，只看單輪請求幾乎沒有區別，放到幾十輪的長任務裏，賬單差距會很明顯。想確認自己的應用屬於哪一種，最直接的辦法是看調用日誌裏每一輪的輸入 Token 變化。API易 apiyi.com 提供統一計費、用量統計和調用日誌，多模型的數據可以放在同一處對比，適合用來做這類賬單結構的診斷。
Agent 長任務 Token 賬單優化快速上手
本節不涉及代碼，只給出一套可執行的排查步驟，按順序做即可。
第一步：把 Token 賬單按任務拆開
- 爲每個用戶任務生成一個任務 ID，任務內的每次模型調用都帶上這個 ID 記錄日誌。
- 從每次響應的
usage信息中記錄輸入、輸出 Token 數；部分供應商還會單獨返回緩存命中的 Token 數，具體字段名以官方文檔爲準。 - 按任務彙總三項指標：調用次數、輸入/輸出比例、緩存命中佔比。
如果你同時調用多家模型，日誌口徑往往不統一。通過 API易 統一接入後，可以在同一個控制檯裏查看各模型的用量明細和調用記錄，再結合自己記錄的任務 ID，就能拼出“每個任務花了多少、錢花在哪一步”的完整視圖。
第二步：定位前綴被破壞的位置
- 抽取同一任務中相鄰兩輪請求，逐段比較系統提示詞、工具定義和歷史消息是否逐字一致。
- 重點檢查時間戳、隨機數、用戶狀態這類動態字段出現在什麼位置。
- 檢查工具定義和消息的序列化順序在多次請求之間是否穩定。
第三步：按 5 條做法調整並複測
- 把動態內容移到末尾，凍結系統提示詞和工具列表。
- 設定歷史壓縮閾值，改爲在檢查點壓縮，而不是每輪壓縮。
- 用同一批測試任務跑一遍改造前後的版本，對比單任務的輸入 Token 和緩存命中佔比。
🚀 上手建議：改造前後的對比一定要用同一批任務、同一個模型完成，否則數據沒有參考意義。藉助 API易 的統一接口，換模型複測時不必逐個適配接口，用量統計也集中在一處，便於把“結構優化”和“模型差異”這兩個變量分開觀察。
關於成本測算的邊界
WorkBuddy 給出過一組測算：按其任務規模和 TokenHub 旗艦檔刊例價計算，緩存命中率達到 90% 時，單任務估算成本可以從約 21.06 元降到約 3.36 元。需要注意，這組數字對應特定的上下文長度和價格條件，完整條件並未公開，無法復算，也不能直接套用到你的應用上。
| 影響因素 | 爲什麼會改變結果 | 你需要覈實什麼 |
|---|---|---|
| 上下文長度 | 前綴越長，緩存複用帶來的節省越多 | 自己任務的平均前綴長度 |
| 緩存計費方式 | 不同供應商對命中部分的折扣不同 | 目標模型官方文檔中的緩存價格 |
| 緩存觸發條件 | 最小長度、有效期等規則各不相同 | 官方文檔中的觸發與過期規則 |
| 調用間隔 | 兩輪間隔過長，緩存可能已經過期 | 工具執行耗時與緩存有效期是否匹配 |
| 任務步數 | 步數越多，重複前綴的累積越明顯 | 真實任務的步數分佈 |
Agent 長任務 Token 降本的配套做法
上下文結構之外，同一份分享還提到兩項應用側策略，可以和前綴緩存一起使用。
- 按步驟選模型：WorkBuddy 團隊分享稱，約八成簡單步驟可以交給輕量模型，單任務成本降低約 57%。資料整理、格式轉換這類步驟不一定需要旗艦模型。
- 按原因處理故障：遇到超時、請求被拒或供應商故障時，按原因限次重試、調整上下文或切換模型。無限重試會讓同一段長前綴被反覆計費。
需要提醒的是，切換模型意味着換了一套緩存，前綴複用要從頭開始。所以在路由設計上，最好讓同一子任務的連續步驟儘量留在同一個模型上，把模型切換安排在子任務的邊界。
常見問題 FAQ
Q1: 什麼是 Agent 長任務裏的前綴緩存？
前綴緩存指推理服務把已經計算過的輸入前綴（KV Cache）保存下來，後續請求開頭相同時直接複用，省去這部分的 prefill 計算。Agent 每輪都帶着大段相同的歷史，因此特別適合複用。
Q2: 前綴緩存和壓縮歷史上下文有什麼區別？
前綴緩存不減少輸入內容，只讓重複部分的計算更便宜；壓縮歷史則直接縮短輸入，但會改變前綴，導致本輪緩存失效。兩者需要配合使用：平時只追加以保證命中，到檢查點再壓縮一次。
Q3: 99.4% 的輸入佔比適用於所有 Agent 嗎？
不一定。這個數字來自一條 50 步調用鏈的分享。步數更少、單輪輸出更長的任務，輸入佔比會低一些。但只要是“長前綴、短輸出、多輪循環”的結構，輸入佔大頭的規律通常都成立，建議用自己的日誌實測。
Q4: 哪些 Agent 場景最值得優化前綴緩存？
– **編碼 Agent**：倉庫上下文長，讀文件、改代碼、跑測試循環頻繁
– **文檔或 PPT 生成**：材料讀取後逐頁生成，前綴高度重複
– **數據分析 Agent**：表結構和指標說明固定，每輪只追加查詢結果
Q5: 怎麼快速看清自己應用的輸入/輸出 Token 構成？
最簡單的辦法是按任務 ID 彙總每輪的 usage 數據。如果應用接入了多個模型，可以通過 API易 apiyi.com 統一調用，平臺提供用量統計和調用日誌，便於按模型、按時間段查看輸入輸出構成。至於平臺對各模型提示緩存的支持情況和計費方式，請以平臺文檔的實際說明爲準。
Q6: 前綴緩存有哪些已知限制？
– 各供應商的觸發條件不同，例如最小長度和有效期，需要逐一查官方文檔
– 工具執行耗時過長時，緩存可能在下一輪到來前就已過期
– 切換模型或修改系統提示詞會讓緩存整體失效
– 命中部分的折扣力度因模型而異，節省幅度需要實測確認
Agent 長任務 Token 賬單核心要點 Key Takeaways
- 成本按任務計算：一次請求約 7.2 次調用，長任務可超過 50 步
- 輸入是主要矛盾：50 步鏈路中輸入約佔 99.4%，壓輸出收效有限
- 緩存從頭匹配：開頭只要一個 token 不同，後面的內容都無法複用
- 結構比模型更關鍵：固定提示詞與工具結構，變化信息放在末尾
- 壓縮要有節奏：在檢查點壓縮一次，避免每輪改寫前綴
- 測算不能外推：公開的成本數字依賴特定長度和價格，需要自己複測
- 先觀測再優化：藉助 API易 的用量統計和調用日誌拆解賬單結構
總結
Agent 長任務 Token 賬單的核心結論：
- 賬單結構：成本主要來自每輪重複帶入的歷史上下文，輸入 Token 佔絕大部分。
- 降本原理：前綴緩存讓重複前綴省去 prefill 計算，命中率由上下文結構決定。
- 落地方法：固定提示詞和工具、變化信息放末尾、歷史只追加、階段性壓縮，再配合按步驟選模型。
建議先用一週時間把日誌按任務拆開，確認自己的輸入佔比和緩存命中情況，再按本文的 5 條做法逐項改造。多模型場景下，可以通過 API易 apiyi.com 統一接入，集中查看用量和調用記錄，用同一套數據評估每一步優化的實際效果。
📚 參考資料
- 構建面向 Agentic 推理的下一代 LLM 推理引擎：TokenSpeed 在 AICon 2026 深圳站的分享整理
- 鏈接：
infoq.cn/article/YwAayF1ylWb7oN4P0lyC -
說明： 介紹 Agent 負載“長前綴、短輸出”的特徵、KV Cache 複用率與前綴緩存的結構設計
-
從模型調用到任務交付：MaaS 如何走進 Agent 生產：騰訊雲 MaaS 專場內容整理
- 鏈接：
infoq.cn/article/zZutPTX8bsr6NWQYNC3A - 說明： 包含 WorkBuddy 關於調用次數、輸入佔比、前綴緩存和模型路由的分享數據
作者: APIYI 技術團隊
技術交流: 關於多模型調用與用量分析的問題，歡迎通過 API易 apiyi.com 聯繫我們，更多資料可訪問 docs.apiyi.com 文檔中心
