上下文工程

跟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基于这个错误继续推理。很多时候，不是信息不够，是信息不对。 上下文工程的一个重要动作，就是识别和阻断这种污染——在错误信息进入窗口之前拦下来，或者在发现之后主动清除。 记忆的粒度与生命周期 不是所有信息都应该在上下文里活一样久。 有些信息全程保持——任务目标、核心约束、输出格式。有些只在一轮有效——一次搜索的结果、一个临时变量的值。有些需要"降级存储"——把五轮详细对话压缩成三行摘要，保留关键结构但不占用多少空间。 上下文工程要设计这种分层机制：热记忆持续在线，温记忆被压缩存档，冷记忆直接丢弃。 上下文复用 一个精心搭建的上下文环境——系统提示+规则文件+参考文档——能不能被复用？ ...