1. 从"context-mode"这个词说起：它到底指什么
第一次看到"context-mode"这个标题时，我脑子里冒出来的第一个念头是：这词太泛了。上下文模式？语境模式？还是某个具体框架里的一个配置项？正因为输入信息几乎为零——没有正文、没有关键词、没有摘要，只有一个孤零零的标题和它作为热搜词的身份——反而逼着我去认真想一件事：一个词能成为热词，通常不是因为它生僻，而是因为它精准地戳中了某个正在被大量讨论的痛点。
我的判断是，"context-mode"之所以被频繁提起，核心场景大概率落在大模型应用开发和智能体（Agent）系统设计这两个方向上。原因很直接：过去两年里，围绕模型能力的讨论逐渐从"模型本身有多强"转向了"怎么把模型用好"，而"用好"的关键，几乎全部落在上下文的管理上。上下文窗口有限、上下文成本高昂、上下文里塞什么不塞什么直接影响输出质量——这些问题堆在一起，就催生了一个专门的概念：上下文模式，也就是我们怎么组织、裁剪、注入、复用上下文的一套策略。
所以这篇内容，我想把它当成一个"概念落地"的活儿来做。不是去考据这个词最早出自哪里，而是把它当成一个真实存在的工程问题来拆：当你的系统需要处理多轮对话、长文档、多工具调用、跨会话记忆时，context-mode 到底该怎么设计、怎么选、怎么踩坑、怎么优化。适合谁看？如果你正在做 RAG、做 Agent、做客服机器人、做代码助手，或者只是单纯被"上下文塞不下"折磨过，那这篇就是写给你的。哪怕你只是刚接触这块，我也会尽量用生活化的类比把原理讲透，让你看完能直接上手改自己的配置。
我先把结论摆前面：context-mode 不是一个开关，而是一整套关于"信息在什么时机、以什么形态、进入模型视野"的决策体系。理解这一点，后面所有的细节才有落脚点。
2. 上下文模式的本质：模型视野的"取景框"设计
2.1 为什么说上下文管理是模型应用的第一性问题
很多人做模型应用，第一反应是调 prompt、换模型、加 few-shot 示例。这些当然有用，但真正决定系统稳定性的，往往是上下文管理。我打个比方：模型就像一个能力很强但记性有限的顾问，你每次找他咨询，只能带一箱资料进去。这箱资料装什么、怎么摆放、按什么顺序给他看，直接决定他给出的建议质量。你带错了资料，再强的顾问也白搭。
这就是 context-mode 要解决的问题。它管的不是模型权重，而是"每次调用时，模型能看到什么"。具体来说，它要回答四个问题：哪些信息必须进、哪些信息可以丢、信息以什么格式进、信息在什么时机进。这四个问题看似简单，但每一个都对应着一堆工程取舍。比如"必须进"的信息，是全文进还是摘要进？摘要进的话，摘要本身准不准？"可以丢"的信息，丢了之后模型会不会答非所问？这些都不是拍脑袋能定的。
我见过太多项目，模型选的是顶配，prompt 写得也漂亮，但一到多轮对话就崩，一到长文档就胡编。排查下来，八成是上下文模式没设计好——要么把历史对话无脑全塞进去，导致关键信息被淹没；要么为了省 token 把上下文砍得太狠，模型直接失去事实依据。所以我说，context-mode 是模型应用的第一性问题，一点都不夸张。
2.2 三种基础上下文模式及其适用边界
在实际工程里，我习惯把上下文模式先粗分成三类，每类对应不同的场景和成本结构。理解这三类，是选型的第一步。
第一类是全量模式（Full Context）。顾名思义，把能塞的都塞进去。它的优点是信息最完整，模型不容易因为缺信息而瞎猜；缺点是成本高、延迟大，而且当上下文超过一定长度后，模型对中间部分的注意力会下降，也就是常说的"lost in the middle"。这类模式适合短对话、单轮问答、或者对准确性要求极高且预算充足的场景，比如法律文书的一次性分析。
第二类是检索模式（Retrieval Context）。不把所有信息都塞进去，而是先用检索（关键词、向量、混合）从知识库里捞出最相关的若干片段，再拼进上下文。这是 RAG 的典型做法。它的优点是成本可控、可扩展性强，知识库可以无限大；缺点是检索质量直接决定上限，检索错了，模型再强也救不回来。这类模式适合知识密集型场景，比如企业知识库问答、文档助手。
第三类是状态模式（State Context）。不依赖原始文本，而是维护一份结构化的状态，比如用户画像、任务进度、已确认的事实，每次只把状态注入上下文。它的优点是极其省 token、可控性强；缺点是需要额外的状态维护逻辑，且状态设计不好会丢失细节。这类模式适合长周期任务、多轮复杂交互，比如订票助手、项目管理 Agent。
| 模式类型 | 核心思路 | 优势 | 主要风险 | 典型场景 |
|---|---|---|---|---|
| 全量模式 | 能塞就塞 | 信息完整 | 成本高、注意力稀释 | 短对话、单次分析 |
| 检索模式 | 先捞后拼 | 可扩展、成本可控 | 检索质量决定上限 | 知识库问答、文档助手 |
| 状态模式 | 维护结构化状态 | 省 token、可控 | 状态设计复杂、易丢细节 | 长周期任务、复杂交互 |
实际项目里，这三类往往不是单选，而是组合使用。比如一个客服 Agent，可能用状态模式维护用户身份和工单进度，用检索模式拉取产品文档，再在关键轮次用全量模式把最近几轮对话完整带上。这种组合，才是 context-mode 设计的真正难点。
2.3 上下文窗口不是越大越好：一个反直觉的结论
很多人有个误区：既然模型支持 128K 甚至更长的上下文，那我全塞进去不就行了？我实测下来的结论是：窗口大不等于效果好，甚至可能更差。原因有两个。
一是注意力稀释。模型在处理长上下文时，并不是均匀地关注每个位置。大量实验和工程经验都表明，位于上下文中间部分的信息，被有效利用的概率明显低于开头和结尾。你把关键信息埋在 5 万字中间，模型很可能"看过了但没记住"。这就像你把一份合同的关键条款藏在第 80 页，审阅的人翻到那儿时已经疲劳了。
二是成本与延迟。上下文越长，推理成本越高，首 token 延迟越大。在交互式场景里，用户等 3 秒和等 8 秒，体验是天壤之别。而且很多信息其实是冗余的，塞进去只是白白烧钱。
所以正确的思路不是"能塞多少塞多少"，而是"在保证关键信息不丢的前提下，塞得越少越好"。这句话听起来像废话，但它是 context-mode 设计的核心原则。后面讲裁剪策略时，我会具体说怎么判断"关键信息"。
3. 动手设计一套可落地的上下文模式
3.1 先定义"信息优先级"，再谈裁剪
设计上下文模式，第一步不是写代码，而是给信息分级。我的做法是把所有可能进入上下文的信息，按"缺失后果"分成四级：
- P0 致命级：缺了它，回答必然错误或无法进行。比如用户当前的问题、系统必须遵守的硬约束。
- P1 重要级：缺了它，回答质量明显下降。比如最近几轮对话、检索到的核心文档片段。
- P2 辅助级：有它更好，没它也能答。比如用户的历史偏好、背景资料。
- P3 冗余级：基本可以丢。比如寒暄、重复确认、已过期的中间结果。
分级之后，裁剪就有了依据：P0 永远保留，P1 按预算保留，P2 视情况保留，P3 直接丢。这个分级不是一次性的，而是要在项目里形成文档，让所有参与的人对"什么重要"有共识。我踩过的坑就是：不同模块对信息重要性的判断不一致，结果 A 模块觉得该丢的，B 模块当成宝贝塞进去，上下文里全是噪音。
提示：信息分级最好在项目初期就定下来，并且随着业务迭代定期 review。我一般会把它写成一个简单的表格，放在项目文档里，谁改谁负责。
3.2 裁剪策略：滑动窗口、摘要压缩与关键帧提取
分级定完，接下来是具体怎么裁。我常用的有三种策略，各有适用场景。
滑动窗口是最简单的：只保留最近 N 轮对话。它的优点是实现容易、延迟低；缺点是会丢失早期的重要信息。比如用户在第 2 轮说了"我对花生过敏"，到第 20 轮时这条信息已经被滑出去了，模型可能推荐含花生的餐厅。所以滑动窗口适合信息时效性强的场景，比如闲聊、简单问答。
摘要压缩是把历史对话或长文档用模型压缩成摘要，再注入上下文。它的优点是能保留长期信息、省 token；缺点是摘要本身可能失真，而且摘要生成有额外成本。我的经验是：摘要要分层做，近期对话保留原文，中期对话做轻度摘要，远期对话做重度摘要。这样既保住了细节，又控制了长度。
关键帧提取是我个人比较喜欢的一种策略，灵感来自视频压缩。它的思路是：不按时间均匀保留，而是识别出"关键节点"——比如用户做出重要决定的时刻、任务状态发生变化的时刻、出现异常的时刻——把这些节点完整保留，其余部分压缩或丢弃。这样上下文里留下的都是"剧情转折点"，信息密度极高。
| 策略 | 实现难度 | 信息保留度 | 成本 | 适用场景 |
|---|---|---|---|---|
| 滑动窗口 | 低 | 低（仅近期） | 低 | 闲聊、简单问答 |
| 摘要压缩 | 中 | 中 | 中 | 长对话、文档助手 |
| 关键帧提取 | 高 | 高（关键节点） | 中 | 复杂任务、Agent |
实际项目里，我通常会把三者组合：滑动窗口保近期，摘要压缩保中期，关键帧提取保长期。这样一套下来，上下文既不会爆，也不会丢关键信息。
3.3 注入顺序也有讲究：把最重要的放在开头和结尾
前面提到"lost in the middle"，所以注入顺序很关键。我的做法是：把 P0 信息放在上下文的最前面和最后面，P1 放中间，P2 和 P3 尽量不放。具体来说，系统指令和当前问题放开头，检索到的核心片段和最近对话放结尾，中间放辅助信息。
这个顺序不是拍脑袋的。模型对开头和结尾的注意力最强，把最关键的信息放在这两个位置，能显著提升利用率。我做过一个简单的对比测试：同样一组信息，按"重要-次要-重要"排列，比按"次要-重要-次要"排列，回答准确率能高出十几个百分点。这个差距在关键业务场景里是致命的。
另外，注入时的格式也很重要。我习惯用清晰的分隔符和标签，比如用【系统指令】、【相关文档】、【对话历史】这样的标记把不同来源的信息隔开。这样模型更容易区分信息的角色，不容易混淆。别小看这个细节，我见过因为格式混乱导致模型把用户输入当成系统指令的案例，后果很严重。
4. 真实场景里的上下文模式踩坑记录
4.1 多轮对话中"记忆丢失"的完整排查链路
说一个我印象最深的坑。当时做一个健康咨询助手，用户反馈说：聊到第 10 轮左右，助手会忘记用户之前说过的症状。我一开始以为是模型能力问题，换了更强的模型，没用。然后怀疑是 prompt 问题，改了几版，还是没用。最后才定位到上下文模式上。
排查过程是这样的：第一步，我把每次调用的完整上下文打印出来，发现历史对话确实被滑出去了——因为用的是固定窗口，只保留最近 5 轮。第二步，我检查了信息分级，发现"用户症状"被归到了 P1，而 P1 在预算紧张时会被裁掉。第三步，我意识到根本问题在于：症状信息是跨轮次持续有效的，不应该按"轮次新旧"来裁，而应该按"信息类型"来保留。
修复方案是引入"持久事实"机制：把用户明确陈述的关键事实（症状、过敏史、用药情况）单独抽出来，存成一个结构化列表，每次调用都强制注入，不参与滑动窗口的裁剪。改完之后，记忆丢失的问题基本消失。这个坑让我明白一个道理：上下文裁剪不能只看时间维度，还要看信息维度。有些信息是"一次性"的，过期就废；有些信息是"持久"的，必须一直带着。
4.2 检索片段塞太多反而答不准：一个典型的"信息过载"
另一个坑发生在 RAG 项目里。当时为了让模型"有据可依"，我把检索返回的 top-20 片段全塞进上下文。结果发现，回答质量不升反降，模型经常把不同片段的矛盾信息混在一起，给出自相矛盾的答案。
排查下来，问题出在两点。一是片段之间有重复和冲突，模型不知道该信哪个；二是片段太多，关键信息被淹没。后来我做了两件事：第一，加了一层重排序（rerank），把最相关的片段排前面，并且只保留 top-5；第二，对片段做去重和冲突检测，如果两个片段说法矛盾，就标记出来让模型知道存在分歧。
改完之后，准确率明显回升。这个经历告诉我：检索模式的关键不是"捞得多"，而是"捞得准"。宁可少给几个高质量片段，也不要塞一堆噪音。这跟前面说的"塞得越少越好"是一个道理。
4.3 状态模式下的"状态漂移"问题
状态模式听起来很美，但有个隐蔽的坑叫"状态漂移"。我做一个任务型 Agent 时遇到过：Agent 维护了一份任务状态，但随着对话进行，状态和实际情况逐渐对不上。比如用户已经改了需求，但状态里还记着旧需求，导致 Agent 按旧需求执行。
根因是状态更新逻辑不完善——只在特定触发条件下更新状态，而用户改需求的表达方式千变万化，很多没被识别到。修复方案是：把状态更新从"被动触发"改成"主动校验"，每隔几轮就让模型根据最近对话重新确认一遍关键状态，发现不一致就修正。同时，状态里加上"最后更新时间"和"置信度"，低置信度的状态在使用前先跟用户确认。
这个坑的教训是：状态模式不是一劳永逸的，状态需要持续维护和校验。把状态当成静态数据，迟早会漂移。
5. 上下文模式的性能与成本优化实战
5.1 Token 预算怎么算：一个可复用的估算方法
做上下文模式，绕不开 token 预算。我的估算方法是：先确定单次调用的总预算（比如 8K），然后按比例分配。一个典型的分配是：系统指令 10%、当前问题 5%、检索片段 40%、对话历史 30%、预留 15%。这个比例不是固定的，要根据场景调。比如知识问答场景，检索片段占比可以更高；闲聊场景，对话历史占比更高。
分配完之后，每个部分都要有"超预算怎么办"的降级策略。比如检索片段超了，就减少片段数量或缩短单个片段；对话历史超了，就触发摘要压缩。关键是：降级策略要提前设计好，不能等超了再临时想办法。我见过因为没设计降级策略，导致上下文超限直接报错、服务中断的案例。
另外，token 估算本身有误差，不同模型的分词方式不一样。我的做法是留 10%-15% 的 buffer，宁可少塞一点，也不要卡在边界上。实测下来，这个 buffer 能避免绝大多数超限问题。
5.2 缓存与复用：别每次都重新拼上下文
很多系统的上下文是每次调用都从头拼一遍，这其实很浪费。如果系统指令、知识库片段这些内容在多轮之间不变，完全可以缓存起来复用。我的做法是把上下文拆成"静态部分"和"动态部分"：静态部分（系统指令、固定知识）缓存，动态部分（当前问题、最近对话）每次更新。这样能省下不少重复计算和 token。
更进一步，如果用的是支持 prompt caching 的模型接口，把静态部分标记为可缓存，成本能进一步下降。我实测过一个场景，开启缓存后，重复部分的成本降了将近一半。这个优化对于高频调用的服务来说，收益非常可观。
5.3 监控与迭代：给上下文模式装上"仪表盘"
上下文模式不是设计完就完事的，它需要持续监控和迭代。我一般会监控几个指标：平均上下文长度、超限触发次数、检索命中率、回答准确率、用户满意度。这些指标能帮我判断当前模式是否健康。
比如，如果超限触发次数很高，说明预算分配不合理或裁剪不够；如果检索命中率低，说明检索环节有问题；如果准确率下降但上下文长度没变，可能是信息分级需要调整。把这些指标做成仪表盘，定期看，能提前发现很多问题。
我还会做 A/B 测试：同一批问题，用不同的上下文模式跑，对比效果。这种数据驱动的迭代，比拍脑袋改配置靠谱得多。踩过的坑告诉我，上下文模式的优化是个持续过程，没有一劳永逸的方案。
6. 几个容易被忽略的细节与我的个人经验
6.1 上下文里的"噪音"比你想的更致命
很多人只关注"该放什么"，忽略了"不该放什么"。实际上，上下文里的噪音——无关的寒暄、重复的确认、格式混乱的片段——对模型输出的干扰非常大。我做过对比：同样的问题，上下文里混入 20% 的噪音，回答准确率能掉 10% 以上。
所以我在设计上下文模式时，会专门加一层"清洗"：把明显的噪音过滤掉，把格式统一，把重复内容去重。这一步看起来不起眼，但效果立竿见影。尤其是从多个来源拼接上下文时，清洗几乎是必须的。
6.2 不同模型对上下文的"脾气"不一样
同一个上下文模式，换一个模型，效果可能完全不同。有的模型对长上下文更鲁棒，有的模型对格式更敏感，有的模型对指令位置更挑剔。所以我的经验是：上下文模式要和模型一起调，不能分开设计。换模型时，一定要重新验证上下文模式是否还适用。
我一般会准备一组标准测试用例，换模型后跑一遍，看哪些用例退化了，再针对性调整。这个习惯帮我避免了好几次"换模型后效果暴跌"的事故。
6.3 给上下文模式留"人工干预"的口子
再好的自动化，也有失灵的时候。所以我会在系统里留一个口子：允许人工在必要时手动调整上下文。比如某个用户的问题特别复杂，自动裁剪可能丢信息，这时候可以手动把某些片段强制加入。这个口子平时不用，但关键时刻能救场。
实现上，可以做一个"上下文预览"功能，让运营或开发能看到每次调用实际注入了什么，发现问题能及时干预。这个功能在排查问题时特别有用，强烈建议加上。
6.4 别忘了测试边界情况
上下文模式的 bug，往往在边界情况下才暴露。比如空上下文、超长上下文、全是噪音的上下文、包含特殊字符的上下文。我一般会专门写一组边界测试用例，覆盖这些情况。踩过的坑包括：空上下文导致模型胡编、特殊字符导致解析失败、超长上下文导致超时。这些在正常测试里很难发现，但线上一定会遇到。
最后分享一个我自己的习惯：每次上线新的上下文模式，我都会先在小流量上跑一段时间，观察指标，确认稳定后再全量。上下文模式的影响面很大，一旦出问题，整个服务都可能受影响，所以灰度发布是必须的。这个习惯帮我挡掉过好几次潜在事故，虽然麻烦一点，但值得。
