先划边界。本篇不比较任何模型"谁更聪明""谁的上下文窗口更长"。站内已有的推理图像模型横评、开放与闭源图像成本账，走的都是"只算账、不比能力"的路子，本篇是把同一套方法论迁移到 Agent 场景。
具体口径如下。
算的账：一个 Agent 任务从发起到结束，累计支付给推理服务的 token 费用，以及为压低这笔费用而投入的工程成本。我们关心的是"总成本 = 直接推理费 + 工程改造摊销 + 失败重试的额外支出"。
不算的账：模型准确率、工具调用成功率、端到端延迟——除非它直接改变成本结构。这些变量我们一律设为"外生给定"，只在一个维度上较真：上下文是怎么被计费、被重复计费的。
数据来源与估算假设：本文所有单价一律不编造。凡涉及具体定价，统一用符号表示，例如输入单价记为 P_in、输出单价记为 P_out、缓存命中价记为 P_cache；或明确标注"以官方定价页为准"。所有量级判断（例如"缓存命中可把常驻前缀成本压到原来的零头"）均标注为"工程估算 / 示意口径"，不是某次实测。
为什么必须这么写？因为 Agent 的上下文账单极其容易被低估。一个看似 8K 上下文的聊天请求，到了 Agent 手里，可能膨胀成几十 K 的回填轨迹。低估它，预算就崩。
一、问题定义：Agent 与聊天的上下文成本结构根本不同
聊天的上下文是线性增长。用户说一句，模型回一句，历史线性追加，每轮只看增量，计费近似：
C_chat(t) ≈ P_in · (H_base + t·Δ_in) + P_out · (t·Δ_out)
其中 H_base 是系统提示，Δ 是单轮增量。简单、可预测。
Agent 的上下文是复合堆积。它至少叠加了四层：
- 系统提示常驻：每轮请求都要重新携带，且每轮都按全价计费（除非命中缓存）。
- 工具调用结果回填：每次调用工具——查数据库、读文件、跑命令、搜网页——的返回，都要塞回上下文，长度随任务发散。
- 多轮轨迹累积：对话历史加上工具输入输出再加上中间推理，逐轮只增不减。
- 失败重试重放：一次工具报错，往往要连同前面 N 轮轨迹一起重发给模型。
把它写成可复算的单轮成本公式：
C_agent(turn_i) ≈ P_in · (S_sys + Σ_{k≤i} T_k + O_i) · (1 − h·c) + P_out · R_i
其中 S_sys 是常驻系统前缀，T_k 是第 k 轮的工具输出，O_i 是本轮用户输入，R_i 是本轮模型输出，h 是缓存命中率，c 是缓存命中后的折扣系数（0<c<1）。
这个公式暴露了 Agent 成本的两大痛点：S_sys 每轮都要重付（乘以轮数），ΣT_k 随轮数线性膨胀且无上限。聊天的"线性"是温和的；Agent 的"复合"是带乘数的。
这就是本篇横评的切入点：五个杠杆，都是从公式里抠出来的省钱点。
二、成本账的五个杠杆
1. 前缀缓存 / Prompt Caching
这是性价比最高的"软杠杆"。核心思想：系统提示、Few-shot 示例、甚至前几轮轨迹，如果内容不变，就缓存其 KV，后续请求只付"缓存读取"的低价，不必重付全价输入。
价差结构（示意口径，以官方定价页为准）：未命中时输入按 P_in 计费；命中缓存时按 P_cache 计费，通常 P_cache 远小于 P_in。但写入缓存本身可能有一笔一次性的"缓存写入费"或"缓存存储费"，且缓存有失效条件——系统提示哪怕改动一个字符、或两次请求间隔超过 TTL，命中即失效，退回全价。
工程估算：对于系统提示常驻、轨迹重复的 Agent（如固定流程的客服机器人），命中率可以很高，前缀缓存能把 S_sys 的重复付费几乎归零。但对于轨迹高度发散、每轮都不同的 Agent（如开放式编程助手），命中率可能很低，收益有限。
适用场景判定：你的 S_sys 越大、重复请求越多，这个杠杆越值。反之，先把 S_sys 压短，比上缓存更划算。
2. KV Cache 压缩与稀疏注意力
这条是技术路线的硬杠杆，也是本批热点的主角。DeepSeek V4.1 Flash 官方定性的方向就是"显著压缩 KV Cache，降低 Agent 场景成本"。我们引用的口径只有这些事实：552B 参数 MoE、非对称 Causal-Encoder-Decoder 架构、输入激活 8B / 输出激活 16B、原生多模态、KV Cache 被显著压缩、API 模型名改为 deepseek-flash、腾讯 WorkBuddy/CodeBuddy 与 OpenCode 已接入（来源：DeepSeek 官方公众号，经 ai-bot.cn 9/10 转述）。
"压缩 KV Cache"是官方定性表述，我们不会写成"压缩了百分之多少"这种编造数字。它的原理是：KV Cache 占显存、也间接影响长上下文的边际成本；把它压下来，等于在同样硬件上能塞下更长的轨迹，或同样长度下单位成本更低。
稀疏注意力的算子底座，可以关联到本批同发的 DSA TopK kernel（详见站内开源资源帖 /zh/posts/deepseek-deepselect-resource，DSA TopK 是稀疏注意力的算子底座）。但注意：稀疏不等于免费。被稀疏掉的位置可能丢掉信号，对需要"回头看"长轨迹的 Agent 任务有信息损失风险。
适用场景：长轨迹、高并发、对延迟敏感但能容忍少量信息损失的 Agent。对短任务，压缩带来的收益可能还抵不过实现与调试成本。关于这一模型在 Agent 场景的接入与成本表现，可参考本批热点帖 /zh/posts/deepseek-v4-1-flash-open-source-hotspot 与集成 SOP /zh/posts/deepseek-v4-1-flash-integration-sop。
3. 上下文压缩 / 摘要折叠
这是"有损"杠杆。当轨迹超过某个阈值，用模型把前面若干轮摘要成一段，替换掉原始长文本。收益是显式的：ΣT_k 被截断，输入 token 数下降。
代价也是显式的：
- 信息丢失：摘要会吞掉细节，troubleshoot 时回头发现"当初那句关键报错被折没了"。
- 调试困难：一旦结果出错，你很难分清是模型不行，还是摘要把上下文压坏了。
- 额外成本：摘要本身也要调一次模型、花一次推理费，属于"用一次小花费换后续多次大节省"的博弈。
工程估算：折叠阈值设太高，省不到钱；设太低，损失太大。经验上以"可复现的回归测试"作为折叠是否安全的判据，比拍脑袋强。
4. 工具输出裁剪与结构化返回
这是性价比最高、却最常被忽略的工程杠杆。思路朴素：工具返回什么，模型就必须读什么。如果你的工具动辄返回 5KB 的 JSON，而模型只需要其中两个字段，那多出来的部分就是纯浪费。
做法：
- 让工具只返回模型真正需要的字段（结构化、最小化）。
- 对超长返回做截断、分页或摘要，下游再按需二次拉取。
- 用 schema 约束返回格式，避免模型自己解析冗长文本。
它几乎不损失信息（因为删掉的是冗余），实现成本只是改几个工具接口，却能把 O_i 与 T_k 的体量直接砍掉一大截。对很多团队来说，这一步的投资回报率高于上任何花哨的缓存或压缩。
5. 轨迹重放 vs 增量提交
这是"失败重试成本倍率"杠杆。很多 Agent 框架在工具报错时，是把整个历史轨迹（含前面的工具输出）重新发给模型再试。如果轨迹已经 30 轮，一次重试就是 30 轮的体量再付一遍。
增量提交思路：把已确认无误的中间结果"固化"为外部状态（写文件、存数据库），重试时只带着"当前这一步 + 必要上下文"重新请求，不必重放全轨迹。代价是需要框架支持状态外置与断点续跑，工程改造稍重。
工程估算：重试率越高的场景（网络抖动、工具不稳定），这个杠杆的倍率收益越大。一个重试率 20%、平均轨迹 20 轮的 Agent，若每次重试都全量重放，重试成本可占总成本相当比例；改成增量提交后能省掉这部分重复。
三、对照表：五杠杆与三类场景
表 1：五条杠杆的"收益量级 / 实现成本 / 风险 / 适用场景"对照（单价以官方定价页为准，以下为工程估算 / 示意口径）
| 杠杆 | 收益量级(示意) | 实现成本 | 主要风险 | 适用场景 |
|---|---|---|---|---|
| 前缀缓存 | 高（常驻前缀成本可降至零头） | 低（开开关/配 TTL） | 命中率依赖稳定性，改一字即失效 | 系统提示大、请求重复度高 |
| KV Cache 压缩 / 稀疏注意力 | 高（长轨迹边际成本下降） | 高（依赖模型/框架支持） | 稀疏可能丢信号 | 长轨迹、高并发、可容忍少量损失 |
| 上下文压缩 / 摘要折叠 | 中高（超阈值后显著） | 中（需摘要策略 + 回归测试） | 信息丢失、调试困难 | 超长轨迹且可容错的任务 |
| 工具输出裁剪 | 高（直接砍冗余，近乎无损） | 低（改接口 / schema） | 需梳理真实所需字段 | 几乎所有 Agent，尤其返回冗长 |
| 轨迹重放改增量提交 | 中高（重试倍率收益） | 中高（需状态外置 / 断点） | 框架改造重，易引入 bug | 重试率高、轨迹长的不稳定任务 |
表 2：三类典型 Agent 场景在不同策略下的成本结构示意（符号口径：P_in 输入单价、P_out 输出单价、P_cache 缓存命中价，具体以官方定价页为准）
| 场景 | 无优化(示意) | 仅前缀缓存 | 缓存 + 裁剪 + 折叠 | 全杠杆(含增量提交) |
|---|---|---|---|---|
| 10 轮工具调用单任务 | 高（每轮重付 S_sys + 全轨迹） | 中（省掉 S_sys 重复） | 较低（再砍工具冗余） | 低（重试不再全量重放） |
| 长轨迹编程 Agent | 很高（轨迹无上限膨胀） | 中高 | 中（折叠控住膨胀） | 中低（压缩 + 增量双管） |
| 批量离线任务(日万次) | 极高（量 × 单价放大） | 低（命中率高摊薄） | 低（裁剪折叠规模效应） | 最低（全杠杆叠加） |
注：上表"高 / 中 / 低"为工程估算的示意相对量级，非实测金额；真正数字请按你自己的 P_in / P_out / P_cache 与命中率代入前文公式复算。
四、可操作结论：按量级选杠杆
不同体量，该先动哪根杠杆，优先级不同。
个人开发者（日跑个位数到几十次）：
- 先动工具输出裁剪——零成本、近乎无损、立刻见效。
- 再上前缀缓存——改个配置，系统提示大的话回本极快。
- 上下文压缩放最后——个人调试期，丢信息很烦，能不折就不折。
小团队（日跑百次量级）：
- 前缀缓存加工具输出裁剪，双管齐下，ROI 最高。
- 上上下文压缩，但配回归测试兜住质量。
- 若发现重试是成本大头，再考虑增量提交。
批量离线（日跑万次量级）：
- 全杠杆叠加，因为量变引起价变——每省 1% 在万次下都是真金白银。
- 重点盯缓存命中率与工具输出长度这两个决定性变量。
- 优先考虑 KV Cache 压缩类模型（如已接入的 deepseek-flash，详见站内热点帖与 SOP 帖），在长轨迹高并发下边际成本优势被放大。
一句话：量小先裁剪、量中重缓存、量大上全栈。
五、冷思考：厂商的"降本 X%"到底怎么读
厂商发布"成本下降 X%"时，请默认它是特定 workload 下的最优值，不是你的 workload 的保证值。
真正决定你账单的，是三个你自己的变量：
- 缓存命中率：你的请求有多"重复"？系统提示改不改？间隔超不超 TTL？
- 上下文分布：你的轨迹是多长？是平稳的小任务，还是动辄上百轮的长轨迹？
- 工具输出长度：你的工具返回是精简 schema，还是动辄几 KB 的整页 JSON？
这三个变量，厂商不会替你测。建议自建度量：在 Agent 框架里埋点，记录每轮的输入 / 输出 token、命中标记、重试次数、工具输出体量，按任务聚合出"单任务上下文成本分布"。拿到这个分布，你才知道该优先抠哪根杠杆，而不是盲信发布会数字。
也别神话任何单一技术。"压缩 KV Cache"是方向，但稀疏会丢信号；"前缀缓存"很香，但命中率脆弱；"上下文压缩"省钱，但坑在调试。工程上永远是组合拳，按你的量级挑组合，才是最实在的降本。
关于长上下文模型的能力边界与更早的成本讨论，可延伸阅读站内既有文章 /zh/posts/deepseek-v4-flash-hotspot 与 /zh/posts/deepseek-v4-flash-codex-benchmark-review；图像场景的"只算账"写法可参照同批的 /zh/posts/open-vs-closed-image-model-review。
常见问题
Q1：前缀缓存命中失败最常见的原因是什么？
A1：最常见是系统提示或常驻前缀在两次请求之间发生了变化（哪怕多一个空格或版本号），以及两次请求间隔超过了缓存 TTL。排查时先确认前缀字节级一致，再看 TTL 配置。
Q2：KV Cache 压缩会不会让 Agent 变笨？
A2：官方只定性"显著压缩 KV Cache 降低 Agent 场景成本"，没有给出具体压缩比例。稀疏或压缩可能丢信号，对需要"回头看"长轨迹的任务有信息损失风险，但通常在可容忍范围内。是否影响你的任务，要用你自己的回归测试判断，不能一概而论。
Q3：上下文压缩（摘要折叠）阈值设多少合适？
A3：没有通用值。工程上建议以"可复现的回归测试通过"为安全判据：先设一个保守阈值跑测试，逐步收紧直到出现质量回退，再回退一档。切忌拍脑袋定一个数字。
Q4：工具输出裁剪听起来很土，真的值得做吗？
A4：值得，而且往往是 ROI 最高的一步。它近乎无损（删掉的是冗余字段），实现成本只是改接口或加 schema 约束，却能把每一轮的输入体量直接砍掉一大截。很多团队上了缓存和压缩，却忘了这一步，等于把水从漏的桶里往外舀。
Q5：小团队到底要不要上增量提交这种重改造？
A5：看重试率。如果工具稳定、重试率低，全量重放的成本占比很小，不值得为它做状态外置的工程改造；如果重试率高、轨迹又长，重试的重复计费会非常刺眼，这时增量提交的倍率收益才划算。先埋点看数据，再决定。