《AI Agent 开发》系列 30 篇讲的是"怎么把 Agent 搭起来"：工具调用、RAG、记忆、规划，零件一一到位。但真把 Agent 放进生产环境跑长任务，问题就来了——跑着跑着开始"失忆"，重复犯过的错，忽略早期定下的约束，成本还一路飙升。2026 年行业对这类问题的诊断高度一致：Agent 质量的瓶颈不在模型，而在上下文——不是模型不够聪明，而是它在每一步决策时拿到的信息不对。
本篇是《上下文工程》系列的第 1 篇（全景篇）。先讲清楚范式为什么从 Prompt Engineering 挪到了 Context Engineering，再解剖上下文窗口的构成与量级，然后给出这个领域的根本矛盾、核心实证现象与三大主流技术，最后交代全系列 18 篇的路线图。
1、从 Prompt 到 Context 的范式转移
Prompt Engineering 的隐含前提是"一次交互、一条消息"：你精心措辞一个 prompt，塞几个 few-shot 示例，模型一次性给出答案。在这个前提下，优化对象就是那一段文字本身——怎么问，决定答案好不好。
Agent 把这个前提掀了。Agent 在循环里跑几十上百轮，每一轮发给模型的内容由你的代码组装：系统提示、工具定义、历史对话、上一轮的工具返回、检索到的文档、记忆里回填的画像。用户的那句"问句"，只是窗口里很小的一块。此时再谈"怎么问"，就像只优化一封信的措辞，却不管整条流水线上传的是什么货。
2025 年 6 月，Shopify CEO Tobi Lütke 先用起了 context engineering 这个词，几天后 Andrej Karpathy 在推文里把它推成了行业共识，原话大意如下：
它（context engineering）比 prompt engineering 更准确地描述了核心技能——为模型提供恰当的信息与工具，使其完成任务的技艺。
真正的奠基是 Anthropic 2025 年 9 月的文章 Effective context engineering for AI agents。它把上下文定义为"采样时输入模型的全部 token"，把上下文工程定义为确定模型在每一步需要什么上下文的技艺，并给出三大技术：compaction（压缩）、结构化笔记、子代理架构。
所以这不是换个时髦名词。优化对象从"一段话"变成"一条信息流水线"，优化时机从"写一次"变成"每一步动态决定"，思路也从 just-in-case（预防性多塞点）转向 just-in-time（要用时再取）。此后一年，主流 Agent 框架的文档、各家模型厂商的官方指南几乎全部换用了这套话语——术语更替的背后，是工程对象实实在在地变了。
2、上下文窗口的构成解剖
先建立一张构成图。以 200K token 的窗口为例，六个部分与各自量级如下：
上下文窗口（以 200K token 为例）
├─ 系统提示 角色设定、行为规则、输出格式 1K ~ 4K
├─ 工具定义 schema 描述，随工具数线性叠加 1K ~ 20K+
├─ 对话历史 每轮一问一答，线性累积 0 ~ 100K+
├─ 工具结果 搜索、读文件、命令输出 0.5K ~ 10K+
├─ 检索注入 RAG 召回片段，每次检索叠加 1K ~ 8K
└─ 记忆回填 长期画像、笔记、偏好 1K ~ 4K
这张图的关键信息是各部分的增长方式不同：系统提示基本固定；工具定义这一格在接了 MCP（Model Context Protocol）服务器后最容易失控——每个工具的 schema 数百 token，十几个工具叠加就是上万；对话历史随轮数线性涨；而工具结果是爆炸最猛的一格——一次文件读取上万 token，一次命令输出几千 token，且全部滞留在后续每一轮里。
把量级整理成表格：
| 组成部分 | 典型量级 | 增长方式 |
|---|---|---|
| 系统提示 | 1K～4K token | 固定 |
| 工具定义 | 1K～20K token | 随工具数线性 |
| 对话历史 | 每轮 0.5K～2K token | 线性累积 |
| 工具结果 | 单次 0.5K～10K token | 累积，最易爆炸 |
| 检索注入 | 单次 1K～8K token | 每次检索叠加 |
| 记忆回填 | 1K～4K token | 按策略载入 |
落到代码上，这六个部分最终拼成一次 API 请求。截取一个简化骨架：
{
"system": "你是部署在服务器上的运维 Agent……（1~4K token）",
"tools": [
{ "name": "web_search", "description": "搜索公开网页……（数百 token）" },
{ "name": "read_file", "description": "读取仓库内文件……（数百 token）" }
],
"messages": [
{ "role": "user", "content": "查一下线上 502 的原因" },
{ "role": "assistant", "tool_calls": [
{ "id": "c1", "name": "read_file",
"arguments": { "path": "/var/log/nginx/error.log" } }
] },
{ "role": "tool", "tool_call_id": "c1",
"content": "……日志全文，约 12000 token……" },
{ "role": "assistant", "content": "根据日志，是 upstream 超时……" }
]
}
注意最后那个 tool 消息：一次日志读取 12000 token，它支撑的结论却只有一句话。这些"陪跑"内容会在后续每一轮继续计费、继续参与注意力竞争。对话里最占地方的从来不是用户说的话。
3、窗口有限与需求无限的矛盾
上下文工程的根本问题一句话可以说完：窗口有限且越大越贵，而任务的信息需求没有上限。
拆开看。有限：即便 2026 年主流模型的窗口到了 200K～1M token，一个中型代码库、七年的访问日志、上百轮的会话历史，依然装不下。贵：输入按 token 计费，第 N 轮请求要把前 N-1 轮全部重发一遍——单轮成本线性涨，累计成本随轮数平方涨。举个数（示意）：平均每轮新增 5K token 的会话跑满 40 轮，累计输入约 4.1M token；若把每轮窗口压在 10K 以内，累计降到 400K 上下，差出一个数量级。Prompt Caching 把命中缓存的输入降到原价约 10%，官方文档写得很清楚，但缓存救的是钱，救不了信息质量。
另一头，每一步真正用到的信息其实很少。看一份真实感很强的账单拆解：
某 Agent 第 12 轮的窗口快照（累计，示意）
system prompt 2,100
工具定义（14 个） 9,800
对话历史（11 轮） 14,300
工具结果（8 次） 47,600 ← 最大头
检索注入（2 次） 6,200
合计约 80K token，本轮真正新增且被用到的信息不足 3K
80K 的窗口里，本轮真正需要的不足 4%，其余 96% 是历史包袱。这与操作系统的内存管理是同构问题：磁盘远大于内存，所以有分页、有换入换出、有工作集的概念。上下文工程就是 LLM（Large Language Model，大语言模型）的内存管理——不是把所有信息塞进窗口，而是为每一步挑选当下最有用的子集。
4、上下文腐烂实证
"窗口装得下"不等于"模型用得上"。2025 年 7 月，向量数据库 Chroma 发布了 Context Rot 报告，对 18 个前沿模型做系统测试，结论是：随着输入 token 增多，模型准确率系统性下降——无论是喂一份超长文档，还是喂一堆短文档凑长度，都逃不开。这就是上下文腐烂（context rot）。
更早的佐证是 2023 年的 Lost in the Middle 论文：把关键信息放在长上下文的不同位置测试召回，模型对开头和结尾的信息利用得好，对中段信息的利用率明显下滑，呈 U 形曲线。腐烂的机制至今没有定论，注意力稀释是主流解释——注意力权重要分给窗口里的所有 token，无关内容越多，关键信息分到的权重越薄。
对工程师的含义很直接：
- 标称窗口只代表"能装多少"，不代表"能用多少"
- 塞满窗口是双重失败：token 照付全价，信息还在腐烂
- 位置也是资源：关键约束放开头，放中段等于半埋
所以长上下文模型的进步并没有取消上下文工程，反而抬高了它的优先级——窗口越大，往里乱塞的代价越隐蔽。
5、三大核心技术预览
针对上述问题，Anthropic 那篇奠基文章归纳了三大技术，也是本系列的主线。
5.1、压缩
compaction 的思路：历史累计到阈值时，让模型把此前的对话总结成一段摘要，用"任务背景 + 已完成事项 + 待办 + 关键事实"替换原始历史，窗口瞬间回落。Claude Code 的 /compact 命令就是这个机制。代价有两个：摘要必然有信息损失；重写历史会击穿缓存前缀，原本 10% 价格的缓存读取变回全价。何时触发、摘要里保留什么、怎么验证没丢关键约束，都是实打实的工程问题。压缩与保留的权衡是 2026 年的讨论热点，系列第 5、6 篇展开。
5.2、结构化笔记
把记忆外置：Agent 边执行边把关键事实写进外部文件——进度、决策、用户偏好、踩过的坑，下次会话只载入笔记，不载入全量历史。Claude Code 的 CLAUDE.md 与 TODO 列表就是该模式的工业化实例。笔记是结构化的、可增删的、跨会话的，比把一切寄托在对话历史里可靠得多。系列第 7、11 篇展开。
5.3、子代理隔离
主代理不亲自干"脏活"：派一个子代理带着干净的新窗口去读文件、跑搜索、翻日志，工具结果的污染留在子代理的窗口里，主代理只接收一段结论。用多花一份 token 的钱，换主代理上下文的干净，这是应对上下文腐烂最釜底抽薪的一招。系列第 9 篇展开。
6、从零件到信息流
如果你读过《AI Agent 开发》30 篇，会发现 RAG（Retrieval-Augmented Generation，检索增强生成）、记忆、工具设计都是老朋友。区别在视角：30 篇是零件视角——RAG 教你怎么检索得准，记忆篇教你存什么取什么，工具篇教你怎么写 schema；本系列是信息流视角——这些零件最终都往同一个窗口里灌信息，何时灌、灌多少、何时清，需要统筹。
举一个具体例子。30 篇的 RAG 回答"怎么找到相关内容"；本系列第 10 篇回答"找到之后注入多少、怎么裁剪、多久失效"。零件都对、流水线不通，Agent 照样不可靠——这正是很多团队"功能全上了、质量没上去"的原因。
7、系列路线图
本系列共 18 篇，按主题分六组：
- 基础认知（第 1～3 篇）：全景、窗口解剖与腐烂、系统提示的信息架构
- 预算与压缩（第 4～6 篇）：token 预算、compaction 实战、压缩与缓存的权衡
- 记忆与治理（第 7～9 篇）：结构化笔记、工具结果治理、子代理隔离
- 检索与长上下文（第 10～13 篇）：RAG 注入、记忆分层、多文件代码上下文、百万窗口取舍
- 经济学与质量（第 14～16 篇）：缓存命中率经济学、上下文质量评测、注入攻击面
- 实战收束（第 17～18 篇）：给 RAG Agent 做端到端优化、决策框架
每篇独立成文，但建议按序读：前 3 篇建立心智模型，中间 10 篇是技术主体，最后 5 篇回到钱和质量。
8、总结
回顾全文。范式上，上下文工程取代提示工程，因为 Agent 的优化对象从一段话变成了每一步动态组装的信息流水线；构成上，窗口由系统提示、工具定义、对话历史、工具结果、检索注入、记忆六部分拼成，工具结果是最易爆炸的一项；矛盾上，窗口有限且越大越贵，而每一步真正需要的信息只占很小比例；实证上，context rot 证明塞满窗口只会让信息腐烂。三大技术——压缩、结构化笔记、子代理隔离——分别对应历史瘦身、记忆外置、污染隔离。
对于已经在生产环境跑 Agent 的团队，建议先做一次上下文审计：抓几条真实会话，统计六个组成部分各占多少 token，最大的那一格就是第一优化点。对于准备系统学习的读者，建议按路线图读完前 3 篇再动手——先建立"窗口是稀缺资源"的直觉，后面每个技术决策都会自然很多。
