作者注：拆解 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 文档中心
