跟AI聊得好好的。第一轮交代了背景、要求、格式，AI按这些规矩生成了好几轮。聊到第十轮，它忽然忘了最开始说过什么——语气变了，方向偏了，连那个费了半天劲才调好的格式也丢了。

不是AI变笨了。

是它的记忆空间被填满了。

提示词写得好不好，决定第一轮。上下文管得好不好，决定第十轮还能不能稳住。这是从"会说"到"会管"的跨越。

两个刚性限制

理解上下文工程，先从理解约束开始。

第一，LLM没有真正的长期记忆。 模型每一轮推理，能"看到"的东西只有当前上下文窗口里的内容——系统提示、对话历史、刚发来的消息。窗口之外的一切，对模型来说等于不存在。说"之前说过"，它只能在对话历史里恰好还没被挤出窗口的那部分里找——一旦超出窗口，这段记忆就彻底丢失了。不是它不想记住，是它没有一个"存档"的地方。

第二，上下文窗口不是无限免费的。 128K、200K、1M token——窗口越来越大，但每塞进去一个token都有代价。计算代价：推理变慢变贵。注意力代价：信息越多，模型对每条信息的关注越稀疏，关键指令可能被淹没在大量无关内容里。机会代价：劣质信息占住位置，好信息就塞不进去了。

两个约束叠加在一起，产生了一个核心问题：怎么让有限的空间装进最有价值的信息，并且排列成让模型最容易理解和使用的结构。 这就是上下文工程。

什么是上下文工程

三层定义，从直觉到精确。

直觉层：管理跟AI之间的记忆空间——决定让它记住什么、忘记什么、先看什么、后看什么。

操作层：在有限token窗口内，通过设计输入的结构、顺序和取舍，最大化输出质量的方法。

工程层：一套系统性的方法论，涵盖容量管理、信息密度、位置效应、上下文污染、信息的生命周期管理和跨会话的上下文复用。

核心的意象是这样——把AI想象成一个人，坐在一张固定大小的书桌前。桌面的面积是有限的，摆满了，再放新的就得把旧的撤下去。上下文工程不是教它怎么干活，而是设计这张桌子上的布局：什么放在手边最顺手的位置，什么叠在旁边备用，什么已经没用了、该直接丢进垃圾桶。

和提示工程的边界

写这个系列以来，一个反复思考的问题是：上下文工程和提示工程，到底是什么关系？

不是包含，是交汇。

提示工程打磨的是一条消息的质量——措辞、示例、格式、角色设定。上下文工程设计的是整场对话的信息环境。

它们交汇的地方在这里：提示词本身占用token，是上下文的一部分；上下文的结构反过来影响每条提示词的效果。一个写好提示词但管不好上下文的人，聊着聊着AI就忘了；一个精于上下文布局但写不好单条提示的人，每句话都问不到点子上。

一句话区分：提示工程回答"怎么说"，上下文工程回答"给AI看什么、按什么顺序看"。

管理什么：七种对象

进入上下文窗口的全部信息，都是上下文工程要管的东西。

系统提示（System Prompt）。 上下文里最持久的部分，定义角色、行为边界、输出格式。它是上下文工程的地基——写什么、写多长、怎么组织，直接影响整个会话的质量上限。

用户输入（User Message）。 单条提示词是提示工程的产物。上下文工程不重写它，但判断它放在什么位置、密度是否合适、和前面信息有没有冲突。

对话历史（Conversation History）。 体积最大、增长最快的部分。聊得越久，越早的内容越被挤出。关键问题是：什么东西保留，什么东西可以——甚至应该——被主动遗忘。

外部检索结果（Retrieved Context）。 搜索结果和文档片段注入上下文的位置、数量和格式，决定了模型能不能有效利用。塞太多，淹没核心指令；塞太少，信息不足。

工具调用输出（Tool Output）。 Agent调用工具返回的结果会被追加进上下文。如果工具返回了5000行日志全部塞进去，核心任务就被稀释了。需要截断、摘要、结构化，或者判断根本不值得放进去。

少样本示例（Few-Shot Examples）。 提示工程里最有效也最吃token的东西。三四个精心挑选的示例，可能比几十个平庸的示例效果好得多。选几个、选哪些、放在什么位置——这是提示工程和上下文工程的交汇带。

结构化信息（Structured Context）。 项目规则、记忆文件、风格手册——预先写好、长期复用的上下文材料。怎么组织、什么时候更新、在什么时机加载。Skill本质上就是这种思想的产物。

六个核心问题

这才是上下文工程真正的"硬核"部分。

容量管理

上下文窗口的token上限是硬天花板。系统提示占多少？对话历史留多少？工具返回预留多少？

每个部分不是越大越好。系统提示写得像长篇小说，等于侵占模型"看"真正任务的空间。几百行规则塞进去，模型对每条规则的注意力都被稀释了。容量管理的第一课：不是能塞多少塞多少，而是只塞必要的。

信息密度

同样的1000个token，可以是一段散乱的对话记录，也可以是一组结构化的要点。

上下文工程追求高密度——让每token承载的信息量最大化。格式化的标签、分层结构、紧凑的要点，不是写给人类看的排版，是控制单位token的信息产出比。把信息组织好再塞进去，比随手丢进去再期望AI自己理清楚，要可靠得多。

位置效应

模型对上下文不同位置的关注度不一样。

开头的指令最容易"记住"——首因效应。结尾的内容对当前输出影响最大——近因效应。中间的部分则容易被忽略，这就是"迷失在中间"现象。

上下文工程利用这个规律：核心约束放开头，最新状态放结尾，参考信息放中间但要加结构锚点——小标题、编号、标签——把模型的注意力拉回来。

上下文污染

一条错误、矛盾或过时的信息一旦进入窗口，会持续影响后续所有输出。

更隐蔽的是自我污染：模型自己生成的不准确内容被注入后续上下文，形成错误循环——AI说错了一句话，这句话被当成事实写进下一轮的上下文，然后AI基于这个错误继续推理。很多时候，不是信息不够，是信息不对。

上下文工程的一个重要动作，就是识别和阻断这种污染——在错误信息进入窗口之前拦下来，或者在发现之后主动清除。

记忆的粒度与生命周期

不是所有信息都应该在上下文里活一样久。

有些信息全程保持——任务目标、核心约束、输出格式。有些只在一轮有效——一次搜索的结果、一个临时变量的值。有些需要"降级存储"——把五轮详细对话压缩成三行摘要，保留关键结构但不占用多少空间。

上下文工程要设计这种分层机制：热记忆持续在线，温记忆被压缩存档，冷记忆直接丢弃。

上下文复用

一个精心搭建的上下文环境——系统提示+规则文件+参考文档——能不能被复用？

不同任务之间，哪些上下文配置可以模板化？Skill、项目规则文件、记忆系统——本质上，它们都是上下文工程的产物：把一次好的上下文设计固化下来，变成可重复使用的资产。不用每次都从零搭。

三步学会：感知、管理、设计

不是线性的，但有一条可感知的递进线。

感知窗口的存在。 不急着"管理"，先建立体感。理解token不是字数——中文约100 token对应六七十个汉字，一篇千字文大约1500 token。理解128K大约一本书的厚度，但每轮对话都在消耗。体会到AI什么时候会"忘"——关键词丢失、要求前后矛盾、语气突变。入门第一件事：有意识地控制每次塞进去的量。

管理结构与顺序。 学会判断什么放前面、什么放中间、什么是噪音。知道对话历史里哪些可以丢掉。开始用结构化的方式传递信息——同样的token量，格式化内容比散乱聊天有效得多。

设计系统化的上下文。 上下文不再是单次对话的事。Agent跑几十步，每一步都在消耗和改写上下文。此时上下文工程变成三件事：什么写入长期区（系统提示、项目规则），什么留在短期区（当前任务的数据），什么主动丢弃。更进一步——设计压缩-归档机制，把用完的信息压成摘要保存，既保留关键结构又不占用过多空间。

从"收拾桌面"到"设计档案室"。

几张关系地图

上下文工程不像提示工程那么"看得见"。一条提示词好不好，当场能试出来。上下文好不好，要到第五轮、第十轮才知道。

但它和提示工程一样，本质上是同一种东西——意识。意识到AI的记忆有限。意识到每一条塞进窗口的信息都在产生后果。意识到信息环境是比单条消息更底层的问题。

提示工程磨的是一句话，上下文工程管的是一张信息地图。

一句话决定一轮。一张地图，决定能走多远。

如果这篇文章对你有用，欢迎点赞分享，推荐给需要的人。

如果你对上下文工程有自己的理解或实践经验，欢迎留言交流。