第 18 节 · 上下文工程：为什么要管、什么时候爆

一句话回答

上下文管理 = Agent 工程的核心。 Day2 你看到的"每轮全量传 messages"在真实任务里很快会变成窗口、成本、质量三重问题，今天我们就来解决它。

一个多轮对话能膨胀到什么程度

跑一下 demo_18_context_explosion.py，让 Agent 反复回答"总结之前的讨论 + 再补充 3 条建议"。结果非常具体：

[第  1 轮] prompt=  256 tokens · total=  680 tokens
[第  5 轮] prompt= 2280 tokens · total= 2700 tokens
[第 10 轮] prompt= 5800 tokens · total= 6300 tokens
[第 15 轮] prompt=12400 tokens · total=13000 tokens
[第 20 轮] prompt=22500 tokens · total=23200 tokens

在这个演示配置下，20 轮 prompt 涨了 88 倍。更关键的是：如果每轮都重发全部历史，单轮 prompt 会持续变长，累计输入成本会接近平方级增长。三件事会同时变糟：

1. 撞窗口 / 撞有效窗口：标称 128K、200K、1M 很大，但 Coding Agent 一个 read_file 工具调用就能塞进去几千 token；复杂任务真正可用的"有效上下文"常小于规格表
2. 烧钱 / 变慢：每轮重新发整段历史 = 同样内容反复进入输入计费和推理路径；即使命中 prompt caching，也只是更便宜，不是免费
3. 变笨 / 被污染：Day1 第 3 节讲过 Lost in the Middle。2026 年的新模型有所改善，但长上下文里的噪声、冲突信息和中间位置事实仍会干扰答案

三类信息的"代价"完全不同

信息类型	来源	单条规模	累计速度	备注
system	你写的角色提示	几百 token	不增长	一次性的
user / assistant	对话历史	每条 100-500 token	线性增长	多轮就累积
tool	工具返回结果	几百 ~ 几万 token	可能爆炸	Coding Agent 杀手

工业上最贵的是 tool 消息：

• read_file("README.md") → 整个 README 内容塞回 messages
• bash("npm test") → 几千行 stdout 回到 messages
• grep("function", "src/") → 几百个匹配行回到 messages

没有上下文管理的 Coding Agent 也许还能跑，但会很快变贵、变慢、变不稳定。

上下文管理要解决的三件事

痛点	工程对策
撞窗口	触发阈值 → 主动压缩
烧钱	稳定可缓存前缀 + 压缩重复历史 + 控制工具输出
变笨	把"重要事实"前置 + 把无关历史挪后

具体怎么压、怎么缓存、怎么前置——下一节给你 4 种典型策略。

2026 Prompt Caching：缓存的是稳定前缀，不是混乱上下文

OpenAI、Anthropic、Google 等平台都支持 Prompt Caching / Context Caching。核心条件很朴素：前缀要稳定、顺序要稳定、内容要尽量一致。

• 把不变的部分放在 messages 开头：system prompt、工具定义、长期规则、少量稳定示例
• 把变化的部分放在末尾：最新 user 消息、最新 tool 结果、临时检索片段
• 避免频繁改前缀：动态工具列表、随机排序的上下文块、不断重写的摘要都会降低缓存命中

Prompt caching 可以显著降低重复前缀的成本和延迟，但它不会提升答案质量，也不会替你删除噪声。缓存 + 压缩 + 检索要一起用。

"上下文工程"为什么是 Agent 工程的核心

Andrej Karpathy 在 2025 年提出过一个流行说法：Context engineering is the new prompt engineering。

一句话总结这个观点：在 Agent 时代，写 prompt 已经不是难点，难点在于怎么把对的信息在对的时机塞进 messages：

• ContextManager → 管"本次对话的 messages 怎么压缩"
• Memory → 管"跨会话的事实怎么持久化 + 检索"
• 工具的输出格式 → 管"tool 消息怎么写得短而有用"
• Skills（Day7） → 管"领域规范怎么按需加载"

今天我们重点搞前两个：ContextManager + Memory。

一些 2026 数字感

价格和模型名变化很快，不要背具体报价，记住这些量级就够了：

现象	量级	对 Agent 的启示
主流长上下文模型	128K / 200K / 1M token 都已常见	窗口变大了，但不能把它当垃圾桶
单次工具结果	几千到几万 token 很常见	tool 消息才是 Coding Agent 的大头
Prompt caching	命中稳定前缀时成本和延迟会明显下降	静态内容放前面，动态内容放后面
有效上下文	随任务类型、噪声和位置变化	能塞进去不代表模型真的用得好

"窗口大"≠"可以不管"：更大的窗口只是给你更多预算，不会自动解决 Lost in the Middle、context pollution 和错误召回。

动手试试

cd labs/04-context-and-memory
python demo_18_context_explosion.py

源码：demo_18_context_explosion.py

看着 prompt_tokens 一路飙升，记住这个数字，Day4 后面要把它压回去。

小结

概念	一句话理解
上下文工程	决定"什么信息在什么时机塞进 messages"的工程
三大痛点	撞窗口 / 烧钱 / Lost in the Middle
最贵的角色	tool 消息（一次返回几万 token 不奇怪）
不管的代价	几十轮内就会明显变贵、变慢、变笨

---

下一节：四种典型上下文管理策略——截断 / 摘要 / 分层 / GSSC —— 各自适合什么场景。