上下文工程：下一代 AI 应用的基石

为什么你的 AI 应用总是"忘记"重要的事

很多开发者在将 AI 集成到产品中时，都会遇到一个令人困惑的问题：模型在短对话中表现出色，但一旦对话变长、上下文积累增多，AI 就会开始"遗忘"关键信息、混淆时间线，甚至给出前后矛盾的回答。这不是模型本身的问题，而是上下文工程（Context Engineering） 没有做好。

上下文工程是 Prompt Engineering 的下一阶段。Prompt Engineering 解决的是"怎么问"的问题，而上下文工程解决的是"给 AI 什么信息、以什么结构、在什么时机给"的问题。随着 GPT-4o、Claude 3.5、Gemini 等大上下文窗口模型的出现，上下文工程已经从"锦上添花"变成了 AI 应用的决定性因素。

本文将系统性地介绍上下文工程的核心概念、关键技术、以及当前工业界的最佳实践。

---

什么是上下文窗口？

大语言模型的一次推理过程，本质上是对一串 Token 的数学运算。这个"一串 Token"就是上下文窗口（Context Window）——模型在单次生成回答时能够"看到"的所有输入信息。

当前主流模型的上下文窗口：

模型	上下文窗口
GPT-4o	128K Tokens
Claude 3.5 Sonnet	200K Tokens
Gemini 1.5 Pro	2M Tokens
Claude 3 Opus	200K Tokens

128K Tokens 大约相当于 10 万个汉字，或一本《战争与和平》的长度。猛一看这个数字很大，但实际应用中很快就会遇到瓶颈：一个 50 人的 Slack 风格聊天历史可能就有 30K Tokens，一次代码库的检索可能吃掉 80K Tokens，剩余空间留给真正需要模型处理的任务时，已经所剩无几。

更重要的是，上下文窗口的增大并不等于模型对上下文中每个信息的关注度均等。心理学中有一个概念叫**"峰终效应"**，LLM 也存在类似的偏差——更靠近对话末尾的信息通常获得更高的注意力权重，而中间的信息则容易被"稀释"。这就是为什么在超长上下文中，模型有时会"忽略"开头部分的关键指令。

---

上下文工程的三大挑战

1. 容量挑战：信息太多，放不下

当可用上下文空间被占满时，必须做出取舍。粗暴的截断（Truncation）会丢失关键信息，等比例压缩又会稀释核心内容。好的做法是智能压缩（Smart Compression），保留语义上最重要的部分。

一个常见的策略是**"Recap + 增量"模式**：模型只保留对话的摘要（Recap），再加上最新的增量内容。摘要由模型自己生成，定期更新。例如：

[对话摘要 v3 - 最后更新: 6月15日]
用户正在开发一个电商推荐系统，技术栈是 Python + FastAPI。
目前遇到的问题是推荐延迟过高（>500ms），怀疑是向量数据库查询效率问题。
用户偏好深入的技术分析和具体的代码示例。
[增量内容 - 6月18日]
...

2. 相关性挑战：找到真正重要的信息