1. 从一个真实困境说起：为什么模型“变笨”了
很多人应该都遇到过这种场景：同一个模型，同一套接口，昨天跑得好好的任务，今天换了个问法就答非所问；或者在一个多轮对话里，聊到第五六轮之后，模型开始忘记前面说过的关键约束，甚至自相矛盾。第一反应往往是“模型是不是降智了”“是不是服务端出问题了”，但排查一圈下来，接口正常、网络正常、参数没动，问题其实出在一个很容易被忽略的地方——上下文工程。
所谓上下文工程，简单说就是：你喂给模型的全部信息，以及这些信息被组织、裁剪、排序、压缩的方式。它不只是“写个好提示词”那么简单，提示词只是其中一层。真正决定模型输出质量的，是模型在生成每一个 token 时，眼前能看到的那一整个上下文窗口里到底装了什么、按什么顺序装、哪些被丢掉了、哪些被强调了。这个窗口是有限的、有成本的、有注意力偏好的，所以“装什么”和“怎么装”本身就是一门工程。
这篇文章想聊的就是标题里那个问题：为什么上下文工程重要。我会从实际项目出发，把上下文窗口的物理限制、信息组织策略、多轮对话的上下文管理、检索增强场景下的拼接技巧、以及常见的踩坑经验都拆开讲一遍。适合正在做 AI 应用开发、Agent 编排、RAG 系统，或者只是想让日常对话质量更稳的人参考。不管你是刚接触这块的新手，还是已经写过不少 prompt 的老手，相信都能从中找到一些能直接抄作业的东西。
2. 上下文窗口到底是个什么东西
2.1 用生活类比理解 token 预算
把上下文窗口想象成一张固定大小的会议桌。模型就是坐在桌前的顾问，你每次提问，他能看到的只有桌上摆着的材料。桌子就这么大，你摆得越多，每份材料能分到的“注意力”就越少；你摆得越乱，他越容易抓错重点；你把关键材料压在最后一叠纸下面，他可能翻都懒得翻。
技术上，这张桌子的容量用 token 衡量。一个 token 大约对应中文的 1 到 2 个字，英文的 0.75 个单词左右。不同模型的窗口大小差异很大，从早期的 4K、8K，到后来的 32K、128K，再到宣称百万级的。但这里有个关键认知：窗口大不等于能用好。这就像给你一张能坐 50 人的大桌子，但你只有 10 分钟会议时间，人越多反而越难达成共识。模型也一样，上下文越长，中间部分的信息越容易被“稀释”，这就是业内常说的“lost in the middle”现象。
所以上下文工程的第一性原则是：不是塞得越多越好，而是让每一份进入窗口的信息都有明确目的。我见过太多项目，为了“保险”把整篇文档、整个历史记录全量塞进去，结果模型反而抓不住重点，还白白烧了 token 成本。
2.2 窗口里的信息分几类
在实际项目里，一个典型的上下文通常由这几部分拼成：
- 系统指令：定义角色、边界、输出格式，通常放最前面，权重最高。
- 任务描述：当前这一轮到底要干什么。
- 背景知识：从知识库检索出来的片段、文档、数据。
- 对话历史：之前几轮的问答记录。
- 示例：few-shot 的输入输出样例。
- 当前输入：用户这一轮的原话。
这六类信息在窗口里是竞争关系。系统指令太长，背景知识就没地方放；对话历史不裁剪，当前输入就可能被挤到窗口边缘。上下文工程的核心工作，就是在这几类信息之间做动态分配和优先级排序。这跟操作系统管理内存是一个道理，你得决定哪些常驻、哪些换出、哪些压缩。
2.3 为什么“能塞下”和“用得好”是两回事
很多人有个误区：既然模型支持 128K，那我就把 128K 塞满，信息越全越准。实测下来恰恰相反。当上下文里存在大量与当前问题弱相关的信息时，模型的注意力会被分散，输出质量反而下降。原因在于注意力机制本身：它会给每个 token 分配权重，无关信息多了，相关信息的相对权重就被拉低了。
我做过一个对比实验，同一个问答任务，方案 A 塞入完整 20 页文档，方案 B 只塞入检索命中的 3 个相关段落。结果方案 B 的准确率明显更高，而且 token 消耗只有方案 A 的十分之一。这个结论在多个任务上都复现过。所以上下文工程不是“搬运工”，而是“编辑”——你要像编辑一样删繁就简，把最有价值的信息放在模型最容易注意到的地方。
3. 上下文工程为什么直接决定输出质量
3.1 注意力是有偏好的，位置很关键
模型对上下文不同位置的敏感度是不一样的。经验规律是：开头和结尾的信息权重最高，中间部分最容易被忽略。这跟人读长文档的体验很像，开头认真读，结尾认真读，中间容易走神。
这个规律直接指导我们的拼接策略。系统指令、核心约束、输出格式要求，应该放在最前面；当前这一轮的具体任务和用户输入，应该放在最后面；中间放背景知识和历史对话。如果你把最关键的任务描述埋在中间，模型很可能“看不见”。
我在一个信息抽取项目里踩过这个坑。当时把抽取字段的定义放在了一大段背景资料后面，结果模型经常漏字段。后来把字段定义提到系统指令里，漏字段的问题基本消失。同样的信息，换个位置，效果天差地别，这就是上下文工程的威力。
3.2 上下文污染会引发连锁错误
多轮对话里最怕的是上下文污染。所谓污染，就是前面某一轮的错误信息、过时信息、或者用户随口说的无关内容，被后续轮次反复引用，导致错误不断放大。
举个例子，用户第一轮说“帮我查一下 A 产品的价格”，模型答了。第二轮用户说“那 B 呢”，模型正确理解为 B 产品。第三轮用户说“再便宜点的”，这时候“便宜点”是相对 A 还是相对 B？如果历史记录里 A 和 B 的信息混在一起没有清理，模型很可能搞混参照系。这就是典型的上下文污染。
解决办法是对历史做结构化压缩，而不是原样堆叠。比如把每一轮压缩成“用户意图 + 关键实体 + 结论”这样的三元组，丢弃寒暄和冗余表述。这样既保留了必要的上下文，又大幅降低了污染风险。
3.3 成本和延迟是绕不开的现实约束
抛开效果不谈，上下文长度直接决定成本和延迟。token 是按量计费的，输入越长越贵；同时，长上下文意味着更长的推理时间，用户等待更久。在一个日调用量百万级的应用里，上下文从 8K 优化到 2K，省下的成本是相当可观的。
所以上下文工程不只是技术问题，也是成本问题。一个成熟的团队会把“上下文预算”当成一个明确的指标来管理：每类信息分配多少 token，超出预算怎么裁剪，哪些信息可以缓存复用。这些决策直接影响到产品的毛利和用户体验。
4. 核心实操：上下文组织与压缩的具体方法
4.1 分层组织：给上下文定一个骨架
我习惯把上下文分成三层来组织：
- 稳定层：系统指令、角色定义、输出格式、通用约束。这部分内容基本不变，可以缓存，放在最前面。
- 半稳定层：检索到的背景知识、few-shot 示例。这部分每轮可能变，但结构固定。
- 动态层：对话历史摘要、当前任务、用户输入。这部分每轮都变，放在最后。
这个骨架的好处是清晰、可维护。稳定层可以做成模板，半稳定层由检索模块填充，动态层由对话管理模块生成。每一层都有明确的 token 预算，超了就按优先级裁剪。下面是一个简化的预算分配示例：
| 层级 | 内容 | 建议预算占比 | 裁剪策略 |
|---|---|---|---|
| 稳定层 | 系统指令、格式约束 | 10% | 不裁剪，精简措辞 |
| 半稳定层 | 检索知识、示例 | 50% | 按相关度排序，截断尾部 |
| 动态层 | 历史摘要、当前输入 | 40% | 历史按轮次压缩，当前输入优先保留 |
这个比例不是固定的，要根据任务调整。比如纯问答任务，半稳定层可以多给；纯对话任务，动态层要多留。
4.2 历史对话的压缩技巧
历史对话是上下文膨胀的主要来源。我的做法是滚动摘要 + 关键实体表。
滚动摘要：每积累 N 轮对话，就用模型把这几轮压缩成一段简短摘要，替换掉原始记录。摘要只保留结论、决策、未解决的问题，丢弃过程性内容。
关键实体表：单独维护一个结构化的表，记录对话中出现的关键实体及其属性，比如产品名、价格、时间、约束条件。这个表每轮更新，以紧凑的格式放进上下文。这样即使原始对话被压缩了，关键信息也不会丢。
实测下来，一个 20 轮的对话，原始记录可能要 6000 token，压缩后摘要加实体表只要 800 token 左右，而且模型对关键信息的召回率反而更高，因为信息更集中了。
4.3 检索结果的拼接与重排
RAG 场景下，检索回来的片段怎么拼进上下文，直接影响效果。几个要点：
- 按相关度排序，但不要只按相关度。最相关的放最前面和最后面，次相关的放中间。
- 去重和去噪。检索结果里经常有大量重复或无关片段，先做一轮过滤。
- 加来源标注。每个片段前面标上来源编号，方便模型引用，也方便你排查问题。
- 控制单片段长度。一个片段太长会挤占其他片段的空间，必要时做二次切分。
我一般会把检索结果控制在 3 到 5 个片段，每个片段 200 到 400 字。片段太多，模型反而挑不出重点；片段太少，可能覆盖不全。这个数量需要根据你的知识库密度和问题复杂度来调。
4.4 用结构化格式降低理解成本
同样的信息，用自然语言描述和用结构化格式呈现，模型的理解效率是不一样的。结构化格式（如 JSON、表格、键值对）能显著降低模型的解析负担，减少歧义。
比如你要告诉模型几个约束条件，与其写“请注意，回答不能超过 100 字，不能使用专业术语，必须包含一个例子”，不如写成：
约束： - 长度：<= 100 字 - 术语：禁用专业术语 - 必须包含：一个例子后者模型更容易准确执行。这个技巧在复杂任务里尤其明显，我见过不少项目只是把指令从散文改成列表，输出合规率就上了一个台阶。
5. 多轮对话与 Agent 场景下的上下文管理
5.1 多轮对话的上下文生命周期
多轮对话里，上下文是有生命周期的。不是所有历史都值得一直保留。我的经验是把对话历史分成三个状态：
- 活跃状态：最近 2 到 3 轮，原样保留，因为和当前问题最相关。
- 压缩状态：更早的轮次，压缩成摘要和实体表。
- 归档状态：超出窗口的，直接丢弃或存到外部，需要时再检索回来。
这个生命周期管理能有效控制上下文长度，同时保证关键信息不丢。关键是压缩和归档的触发时机要设计好，不能等到窗口快满了才动手，那时候已经晚了。
5.2 Agent 任务里的上下文隔离
Agent 场景比普通对话更复杂，因为它可能同时处理多个子任务，每个子任务有自己的上下文。如果不做隔离，所有子任务的上下文混在一起，模型很容易串台。
我的做法是给每个子任务独立的上下文空间，主流程只保留任务调度所需的最小信息。子任务完成后，只把结果摘要回传给主流程，过程细节丢弃。这样既保证了每个子任务的专注度，又控制了主流程的上下文规模。
在一个多步骤数据处理的项目里，我用这个思路把主流程的上下文从 10000 token 压到了 1500 token，任务成功率反而提升了，因为模型不再被无关步骤干扰。
5.3 工具调用结果的精简
Agent 调用工具后，返回结果往往很长，比如一次搜索返回十几条结果，一次数据库查询返回几十行。这些结果如果原样塞进上下文，很快就爆了。
我的处理原则是：工具返回结果先在外部做一轮筛选和摘要，只把最相关的部分放进上下文。比如搜索结果只取前 3 条，数据库查询只取关键字段和聚合值。这个筛选逻辑可以写在工具封装层，对模型透明。这样模型看到的是精炼后的信息，决策效率更高。
6. 常见问题与排查技巧实录
6.1 模型忽略指令怎么办
这是最高频的问题。排查顺序建议是：
- 检查指令位置。是不是被埋在了中间？移到最前面试试。
- 检查指令长度。是不是太长太啰嗦？精简成列表。
- 检查冲突。是不是有两条指令互相矛盾？模型会随机选一条执行。
- 检查上下文长度。是不是接近窗口上限了？超长上下文里指令权重会被稀释。
我遇到过的案例里，八成以上是位置和长度问题。把指令提到最前面并精简后，基本都能解决。
6.2 多轮之后开始胡言乱语
这通常是上下文污染或窗口溢出的信号。排查方法：
- 打印出每一轮实际送入模型的完整上下文，看看里面到底有什么。
- 检查历史压缩逻辑是否正常工作，有没有把关键信息压没了。
- 检查是否有过时信息没被清理，被模型当成了当前事实。
我一般会在开发阶段加一个上下文快照功能，每轮把完整上下文存下来，出问题时直接回看，比猜要快得多。
6.3 检索增强反而让答案变差
RAG 不是万能的。如果检索结果质量差，或者拼接方式不对，反而会拖累模型。常见原因：
- 检索片段和问题不相关，模型被带偏。
- 片段太多太杂，模型抓不住重点。
- 片段之间互相矛盾，模型无所适从。
解决办法是提高检索精度（用更好的 embedding、加 rerank），控制片段数量，以及在指令里明确告诉模型“如果检索内容与问题无关，请忽略并基于常识回答”。
6.4 常见问题速查表
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 忽略指令 | 位置靠后、指令冗长、指令冲突 | 前移、精简、去冲突 |
| 多轮后混乱 | 上下文污染、窗口溢出 | 压缩历史、清理过时信息 |
| RAG 效果差 | 检索不准、片段过多、内容矛盾 | 加 rerank、控数量、去矛盾 |
| 输出格式不稳 | 格式要求不明确、示例缺失 | 结构化格式、加 few-shot |
| 成本过高 | 上下文冗余、未缓存 | 分层预算、缓存稳定层 |
7. 我踩过的坑和几条实用心得
第一个坑是过度依赖长窗口。早期我总觉得窗口越大越好，什么都往里塞，结果发现模型在长上下文里的表现并不稳定，而且成本飙升。后来转向“精准投喂”，效果和成本都改善了。窗口大小是能力上限，不是使用目标。
第二个坑是忽视上下文的顺序。同样的信息，换个顺序效果完全不同。这个认知是我在一个分类任务里建立的：把类别定义放在最后，准确率比放在中间高了近十个百分点。从那以后，我对上下文的每一段位置都会刻意设计。
第三个坑是不做上下文监控。上线之后如果不记录每轮的实际上下文，出了问题只能靠猜。后来我加了上下文日志，排查效率提升非常明显。这个投入是值得的，尤其是在多轮和 Agent 场景里。
几条实用心得：稳定层内容尽量缓存复用，能省不少钱；历史压缩要趁早，别等窗口满了才动手；结构化格式永远比自然语言描述更可靠；每类信息都要有明确的 token 预算，超了就裁，不要心软。
上下文工程这件事，说到底是在有限的资源里做最优的信息编排。模型能力是给定的，但你怎么组织喂给它的信息，是你完全可控的变量。把这个变量用好，往往比换一个更强的模型带来的提升还大。我在实际项目里的体会是，一个精心设计的上下文，能让中等模型跑出接近顶级模型的效果，而一个糟糕的上下文，能让顶级模型表现得像个新手。这个杠杆，值得每个做 AI 应用的人认真对待。
