context-mode：上下文工程的核心策略与落地实践

1. 从"上下文模式"这个词说起：它到底在解决什么问题

第一次看到"context-mode"这个说法，很多人会以为是某个具体框架里的配置项，或者某个编辑器插件的开关。实际上，它更像是一种处理信息的方式，一种在"当前任务需要多少背景信息"这个问题上做出的主动选择。我在过去几年里接触过不少项目，凡是涉及对话系统、智能助手、代码补全、内容生成这类场景，绕不开的一个核心矛盾就是：给模型或系统的上下文太少，它答非所问；给得太多，它又抓不住重点，还拖慢响应、推高成本。

"context-mode"这个词之所以能成为热词，本质上是因为大家在实际落地时发现，光有模型能力不够，怎么组织、裁剪、传递上下文，才是决定最终效果的那只隐形的手。你可以把它理解成做菜时的"备菜环节"——食材（原始信息）就那么多，但切多大块、哪些先下锅、哪些留着最后放，直接决定这道菜好不好吃。很多人把精力全花在"换一口更好的锅"（换更强的模型）上，却忽略了备菜方式才是最容易拉开差距的地方。

这篇文章适合三类人看：一是正在做对话类、助手类产品的开发者，二是需要把大段资料喂给模型做总结或问答的内容工作者，三是对"上下文工程"这个概念好奇、想搞清楚它和提示词工程有什么区别的技术爱好者。我会从概念拆解讲到实操落地，把我在实际项目里踩过的坑、总结的参数和判断逻辑都摊开来说，尽量让你看完就能上手改自己的流程。

需要先明确一点：context-mode 不是一个有官方标准的术语，不同团队对它的定义略有差异。但在绝大多数语境下，它指的是一套关于"在什么时机、以什么粒度、把哪些上下文注入到当前处理流程"的策略集合。它和提示词工程（prompt engineering）是互补关系——提示词管的是"怎么说"，context-mode 管的是"说之前手里攥着哪些牌"。

2. 拆开来看：context-mode 的三个核心维度

要真正用好 context-mode，得先把它拆成可以单独调节的几个维度。我在实践中习惯把它分成三块：上下文的来源、上下文的粒度、上下文的生命周期。这三块任意一块调错，效果都会明显打折。

2.1 上下文来源：别把"能拿到的"都当成"该拿的"

上下文来源指的是你手头有哪些信息可以往当前任务里塞。常见的来源包括：用户当前这轮输入、历史对话记录、用户画像或偏好设置、外部知识库检索结果、系统状态（时间、位置、设备）、任务相关的文档或代码文件。

新手最容易犯的错是"贪多"。我见过一个做客服助手的项目，把用户过去三个月的所有对话记录一股脑塞进上下文，结果模型经常把两周前已经解决的旧问题重新翻出来回答，用户一脸懵。问题不在于信息不够，而在于没有区分"相关"和"可用"。可用的信息很多，但真正和当前这轮对话相关的，往往只有最近几轮加上一两条关键历史。

我的做法是给每个来源打一个"相关性权重"，并且设定一个硬性上限。比如历史对话只保留最近 5 轮，外部检索结果只取相似度最高的 3 条，用户画像只注入和当前意图匹配的字段。这个上限不是拍脑袋定的，而是根据你实际场景里"信息过载导致效果下降"的临界点测出来的。

2.2 上下文粒度：摘要、原文、还是结构化字段

粒度说的是同一条信息你以什么形态放进去。举个例子，用户的历史订单信息，你可以放原始 JSON（几百字）、放一句自然语言摘要（几十字）、或者只放一个订单号让模型自己去查（几个字）。这三种粒度对效果和成本的影响完全不同。

我个人的经验是：能用摘要就别用原文，能用 ID 就别用摘要，除非任务本身要求逐字精确。比如做合同问答，涉及具体条款金额时必须用原文；但做"这个用户大概是什么消费层级"的判断，一句摘要就够了。很多人舍不得压缩，觉得信息越多越保险，实际上模型在长上下文里的注意力是会被稀释的，塞得越满，关键信息越容易被淹没。

2.3 上下文生命周期：什么时候注入，什么时候清掉

生命周期是最容易被忽略的一维。上下文不是注入进去就完事了，它什么时候失效、什么时候该被覆盖，同样重要。比如用户切换了话题，上一轮的检索结果就应该清掉，否则模型会拿着旧资料回答新问题。

我在项目里通常会给上下文打上"时效标签"：会话级（整个对话有效）、轮次级（只在当前这轮有效）、任务级（任务完成即失效）。清掉过期上下文这个动作，看起来是小事，但它能显著减少"答非所问"和"串台"的情况。实测下来，光是把轮次级上下文做对，多轮对话的准确率就能提升一截。

3. 为什么"上下文塞满"反而更差：注意力稀释的底层逻辑

这一节我想专门讲讲原理，因为不理解原理，你在调参数时就是瞎调。很多人有个直觉：信息给得越全，模型答得越准。这个直觉在短上下文里基本成立，但一旦上下文变长，就会失效。

3.1 注意力机制不是"雨露均沾"

现在的模型处理上下文，靠的是注意力机制。简单类比：你让一个人同时看 50 份材料再回答问题，他不可能对每份材料都投入同样的注意力，总有一些会被"扫一眼就过"。模型也一样，上下文越长，每个 token 分到的注意力权重平均就越低，关键信息如果埋在一堆无关内容中间，很容易被忽略。

这就是所谓的**"大海捞针"问题**——你把一句关键信息藏在几万字的上下文里，模型能不能找出来，取决于这句话的位置、表述方式，以及周围有多少干扰。实测中，关键信息放在上下文开头或结尾，被正确利用的概率明显高于放在正中间。这个现象在很多评测里都出现过，位置的影响甚至比信息本身还大。

3.2 冗余信息会"污染"判断

除了稀释注意力，冗余信息还会直接干扰判断。举个我亲历的例子：做一个商品推荐助手，我把用户浏览过的 20 个商品全塞进上下文，结果模型推荐时经常推荐那些用户只是"误点"过的商品。后来我改成只保留停留时长超过阈值的商品，推荐准确率立刻上去了。

原因很简单：模型不知道哪个浏览是"真感兴趣"，哪个是"手滑点错"，它只能一视同仁。你给它的每一条信息，它都会当成"用户可能在意"的信号。所以上下文里的每一条内容，都应该是一个明确的信号，而不是模糊的噪音。这也是为什么我一直强调，注入上下文之前要先做一轮筛选和标注。

3.3 成本和延迟的连锁反应

还有一个现实问题：上下文越长，token 消耗越大，响应延迟越高。这在做实时对话产品时是致命的。用户等 5 秒和等 1 秒，体验完全是两回事。我做过一个粗略的测算，在同样的模型下，上下文从 2000 token 压到 800 token，首字响应时间能缩短将近一半，而效果在多数场景下不降反升。

所以压缩上下文不只是省钱，更是提升响应速度和稳定性的手段。当然，压缩要有方法，不能瞎删，下一节我会讲具体怎么压。

4. 落地实操：一套可复用的上下文组织流程

讲完原理，进入最实用的部分。我把实际项目里反复用的一套流程整理出来，你可以直接照着改。这套流程分五步：意图识别、来源筛选、粒度压缩、顺序编排、过期清理。

4.1 第一步：先判断当前任务需要哪类上下文

不要一上来就无脑拼上下文，先判断这轮任务属于哪一类。我通常分成四种：

• 事实查询类：用户问一个具体事实，比如"我的订单到哪了"。这类只需要精确的订单数据，历史对话基本可以不要。
• 推理判断类：需要综合多条信息做判断，比如"帮我看看这个方案行不行"。这类需要相关文档加少量背景。
• 闲聊陪伴类：不需要外部知识，重点是语气和连贯性，历史对话保留多一点反而更好。
• 创作生成类：需要风格参考和素材，上下文要精选但可以稍长。

判断清楚类别，后面的筛选才有依据。这一步可以用一个轻量的分类模型或者规则来做，不必上大模型，省时省力。

4.2 第二步：按相关性给来源排序，设硬上限

确定类别后，把候选来源按相关性排序。相关性的判断可以基于关键词匹配、向量相似度，或者简单的规则（比如"最近 3 轮对话"永远优先）。排完序之后，设一个硬上限，比如最多取前 5 条。

这里有个实操技巧：给不同来源设不同的上限，而不是一个总上限。比如历史对话最多 5 轮、检索结果最多 3 条、用户画像最多 2 个字段。这样能保证每个维度都有代表，不会出现某一类信息把额度全占了的情况。

4.3 第三步：粒度压缩，优先用摘要和结构化

压缩粒度是省 token 的关键。我的原则是：

1. 能用结构化字段表达的，绝不用自然语言。比如"用户等级：黄金"比"这位用户是我们的黄金会员，享受相应权益"省得多。
2. 需要自然语言的，先做摘要。摘要可以提前离线生成，也可以实时用一个小模型生成。
3. 只有必须逐字精确的内容，才保留原文。

摘要的质量很关键。我一般要求摘要包含"主体、动作、关键数值"三要素，去掉修饰和客套。比如把"用户昨天下午三点左右咨询了关于退款的问题，当时客服告诉他需要三个工作日"压成"用户咨询退款，答复：3 个工作日"。

4.4 第四步：编排顺序，把关键信息放两头

前面说过，位置影响注意力。所以编排顺序时，把最重要的信息放在开头或结尾，次要的放中间。我通常的结构是：

开头：当前任务的核心指令 + 最关键的一条上下文 中间：次要的补充信息 结尾：再次强调任务目标 + 需要模型输出的格式要求

这个"两头重、中间轻"的结构，实测比平铺直叙效果好不少。尤其是结尾重申任务目标，能明显减少模型跑偏。

4.5 第五步：设置清理规则，别让旧上下文赖着不走

最后一步是清理。给每条上下文打上生命周期标签，会话切换、话题切换、任务完成时触发清理。这一步最好做成自动的，靠人工判断容易漏。我的做法是在上下文对象里加一个expire_at字段，每次组装上下文前先过滤掉过期的。

def build_context(session, current_turn): now = time.time() valid = [c for c in session.contexts if c.expire_at > now] # 按相关性排序并截断 valid.sort(key=lambda c: c.relevance, reverse=True) return valid[:MAX_ITEMS]

这段逻辑不复杂，但能省掉很多"模型拿着旧信息瞎答"的麻烦。

5. 几个真实场景下的 context-mode 调优记录

光讲方法有点干，我挑三个实际做过的场景，把当时的判断和调整过程还原出来，你能更直观地感受到 context-mode 怎么调。

5.1 场景一：多轮客服对话里的"串台"问题

之前做一个客服助手，用户经常在一个会话里问好几件不相关的事，比如先问退款，再问发票，再问物流。最初的实现是把整个会话历史都塞进去，结果模型回答物流问题时，老是把退款的处理进度也带出来，用户觉得很混乱。

我的调整是引入"话题分段"：用一个小模型判断当前问题是否和上一轮属于同一话题，如果换了话题，就把上一话题的上下文标记为"低优先级"，只保留一句极简摘要（比如"此前咨询过退款"），把额度让给当前话题。改完之后，串台率明显下降，用户反馈也好了很多。

这个案例的教训是：上下文不是越多越连贯，有时候"断得干净"反而更连贯。

5.2 场景二：代码补全里的上下文取舍

做代码补全时，上下文来源特别多：当前文件、打开的其他文件、项目结构、最近的编辑历史、光标附近的代码。全塞进去 token 直接爆炸，而且补全质量并不好。

我的做法是分层：光标前后各 50 行是必给的（最高优先级），当前文件的其他部分按需给，其他打开的文件只给函数签名和注释，项目结构只给目录树。这样既保留了最相关的信息，又把总量控制住了。实测补全的接受率比"全量塞入"高出一截。

这里有个细节：光标前后的代码要保留原文，不能摘要，因为补全需要精确的语法上下文。而其他文件的内容摘要就够了，反正只是提供参考。

5.3 场景三：长文档问答里的检索增强

做长文档问答时，核心是检索增强（RAG）。很多人以为 RAG 就是把检索到的段落全塞进去，其实检索结果的质量和数量同样关键。我踩过的坑是：检索返回 10 条，全塞进去，结果模型被无关段落带偏。

后来我改成：检索返回 10 条，但只取相似度最高的 3 条，并且对每条做一次"是否真的回答了问题"的二次判断，不相关的直接丢掉。同时把文档的标题和章节路径也带上，给模型一个位置感。改完之后，答案的准确率和可追溯性都提升了。

这三个场景的共同点是：效果提升的关键都不在模型本身，而在上下文怎么组织。这也是 context-mode 这个概念的价值所在。

6. 常见误区与我的避坑清单

最后这部分，我把这些年踩过的坑和见过的误区整理成一份清单，你可以对照检查自己的实现。

6.1 误区一：把上下文长度当成能力指标

很多人炫耀"我支持 100 万 token 上下文"，但实际用起来，塞满 100 万 token 的效果往往不如精心组织的 1 万 token。上下文长度是上限，不是目标。你的目标应该是"用最少的上下文达到最好的效果"，而不是"用满上下文"。

6.2 误区二：忽略上下文的顺序和格式

同样的内容，换个顺序、换个格式，效果可能差很多。我建议在格式上做统一：用清晰的分隔符区分不同来源，给每段上下文加一个小标题说明它是什么。比如：

【历史对话】 用户：... 客服：... 【相关知识】 ... 【当前问题】 ...

这种结构化的呈现，比把内容揉成一团效果好得多。

6.3 误区三：不做 A/B 测试就上线

上下文策略的调整，一定要做对比测试。我见过团队凭感觉改了一版上下文组织方式就上线，结果效果反而下降。建议至少准备一组固定的测试用例，每次调整都跑一遍，用数据说话。

6.4 我的避坑清单

• 注入前先问一句："这条信息对当前任务真的有用吗？"
• 给每类来源设独立上限，别让一类信息挤占全部额度。
• 关键信息放开头或结尾，别埋在中间。
• 能用结构化字段就别用自然语言。
• 给上下文打生命周期标签，过期就清。
• 每次调整都做对比测试，别凭感觉。

context-mode 这个东西，说到底是一种"克制"的艺术。你手里能拿的信息永远比该拿的多，学会做减法，比学会做加法更重要。我在实际项目里最大的体会就是：当你开始认真对待"给模型看什么"这件事时，很多原本以为是模型能力问题的毛病，其实都能自己解决掉。后续如果场景里出现了新的信息源，比如多模态的图片、语音，这套"来源筛选、粒度压缩、顺序编排、过期清理"的思路依然适用，只是每个维度要重新校准一遍阈值而已。