上一篇我把整个 Agent 系列串成了一个生产级项目，结尾也预告了接下来的方向：上下文工程。本来想歇两天，结果项目跑起来之后，我去翻账单、盯显存监控，越看越睡不着：API 账单的大头几乎全在输入 token 上；显存监控里 KV Cache 吃掉的显存比模型权重还多；更扎心的是，我把文档一股脑塞进长上下文，模型反而找不到关键信息。三件事指向同一个结论——上下文正在成为 AI 应用里最贵的资源。这不是比喻，是三笔可以算清楚的账。这篇是”上下文工程”系列的开篇，我把这三笔账摊开算一遍。

一、从 Prompt 工程到上下文工程

先说背景。前两年大家聊得最多的是 prompt 工程，怎么把提示词写得更巧；今年风向已经变了。Anthropic 官方在 2025 年 9 月发了一篇文章《Effective context engineering for AI agents》，开篇就点题：上下文对 AI Agent 来说是”关键但有限”的资源。所谓上下文工程，就是围绕”给模型什么上下文”做设计——选哪些信息、按什么顺序组织、怎么压缩、怎么缓存。为什么这件事突然变得重要？因为上下文窗口这些年从几千 token 一路涨到 128K（比如 Llama 3.1）、200K（Claude），甚至 1M（DeepSeek V4 官方文档里上下文长度就标着 1M）。窗口变大，塞进去的东西变多，成本也跟着起飞。以前 4K 窗口时代，几千 token 的输入成本几乎可以忽略；现在动辄几十万 token，量变引起质变，”上下文”从免费午餐变成了账单上的常客。

二、第一笔账：token 计价，重复输入最烧钱

第一笔账是 token 计价。聊天的时候，每一轮都要把全部输入重新发给模型算一遍：系统提示、历史消息、检索回来的文档，一个都跑不掉。输入 token 单价看着便宜，架不住量大——一次问答塞进 5 万 token 的文档，等于每问一句都要为这 5 万 token 各付一次钱。我按 DeepSeek 官方定价顺手算过一笔：deepseek-v4-flash 非高峰时段，输入缓存命中是 0.007/百万 token，缓存未命中是0.22/百万 token，差了 31 倍。假设一个 Agent 每次请求带 10 万 token 上下文、一天跑 1000 次：不命中缓存，光输入就是 10 万 × 1000 × 0.22/100 万 =22/天；命中缓存只要 $0.7/天。同一份长上下文反复用，命中不命中缓存，成本差出一个数量级。所以各家 API 现在都推”提示缓存”（prompt caching），省钱的钥匙就藏在”重复的输入别重复算”这句话里。

三、第二笔账：KV Cache 吃显存，抵得上整个模型

第二笔账是显存。推理时模型要把每个 token 的 K、V 向量缓存下来供注意力计算用，这就是 KV Cache。它的体积有公式：2（K 和 V 两份）× 层数 × KV 头数 × 头维度 × 精度字节数 × token 数。我拿 Llama 3.1 8B 算过一笔：32 层、8 个 KV 头、每个头 128 维、FP16 精度，一个 token 就是 128KB；塞满 128K 上下文，KV Cache 要 16GB。而模型权重本身——80 亿参数、FP16——也正好是 16GB。也就是说，跑满上下文的时候，光 KV Cache 就抵得上再装一个模型。显存从”装模型”变成了”装上下文”，这是我在写部署那篇（821）时体会最深的一件事。而且长度每翻一倍，KV Cache 就线性翻一倍，注意力计算的耗时更是随长度平方上涨——这些坑我下篇专门拆。

四、第三笔账：上下文越长，模型越”迷路”

第三笔账最扎心：上下文越长，模型越容易”迷路”。UC Berkeley 2023 年的论文《Lost in the Middle: How Language Models Use Long Contexts》（arXiv:2307.03172）做过一个经典实验：把关键信息放在长上下文的不同位置，结果模型在信息位于开头或结尾时表现最好，放在中间时明显变差——而且即使是专门为长上下文优化过的模型也一样。所以”上下文贵”不光是钱和显存的事，还有效果的事：无脑堆上下文，可能既贵又差。这正好解释了为什么 RAG 那套”先检索、再拼进窗口”的做法依然有效——不是模型读不完，是它读不过来。

五、所以上下文工程要解决什么

三笔账合起来，上下文工程要解决的就三件事：让 KV Cache 少占显存（GQA、KV 量化、PagedAttention 这些手段）、让重复输入少花钱（提示缓存、提示压缩）、在有限的窗口里装下真正有用的信息（检索、路由、长文档处理）。这也是我这个新系列接下来要逐个展开的方向。

总结

一句话总结：上下文正在成为最贵的资源，贵在三个层面——账单上的钱、显存里的空间、还有模型”记不住中间内容”的效果损耗。我的排查顺序是先打开 API 账单看输入 token 占了多少，再统计哪些输入是重复的，最后看单次请求到底塞了多少 token——这三步做完，省钱的空间基本就浮现了。

下期预告：KV Cache 到底怎么把显存吃光的？GQA、KV 量化、PagedAttention 各自解决什么问题？我会用 Llama 3.1 的实测数字拆一遍，顺便聊聊怎么给推理服务调显存。想一起折腾的，下篇见。

参考文献

• Anthropic：Effective context engineering for AI agents（2025-09-29）：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• DeepSeek API 官方文档：Models & Pricing（deepseek-v4-flash 定价、1M 上下文）：https://api-docs.deepseek.com/quick_start/pricing
• Liu et al.：Lost in the Middle: How Language Models Use Long Contexts（arXiv:2307.03172）：https://arxiv.org/abs/2307.03172
• Grattafiori et al.：The Llama 3 Herd of Models（arXiv:2407.21783）：https://arxiv.org/abs/2407.21783
• kipply：Transformer Inference Arithmetic：https://kipp.ly/transformer-inference-arithmetic/
• Anthropic：Claude 模型与上下文窗口：https://docs.anthropic.com/en/docs/about-claude/models
• 上一篇：生产级 Agent 应用从零到上线：我把整个系列串成了一个完整项目：https://www.fedte.cc/p/833.html

转载请注明：Falost的小窝 » 上下文工程开篇：为什么“上下文”正在成为最贵的资源？