聊一个最近在技术群里被反复提起的词：context-mode。我看很多朋友的第一反应是“某个大模型新出的开关”，也有人以为是编辑器插件里的某个功能选项，还有人直接问“是不是把上下文窗口拉满就行”。其实 context-mode 从来不是某一个产品里的单一按钮，而是一类“如何组织、保留、使用上下文信息”的模式设计。我做了几年 AI 应用开发，也在编辑器插件、服务端调度上踩过不少坑，这个模式几乎无处不在——从 ChatGPT 这类对话应用背后的提示词策略，到 IDE 里代码补全工具的理解范围，再到操作系统 CPU 的进程调度，本质都在处理同一个问题：当前这段处理，到底需要知道多少前因后果？这些背景信息应该放在哪里、怎么交给处理者？

这篇文章我就从自己实际踩坑和调优的经验出发，把 context-mode 掰开揉碎聊一遍。适合正在做 AI 应用开发的工程师、重度使用 AI 编程助手的开发者，以及对系统性能调优感兴趣的运维同学。看完你至少能回答三个问题：我该在什么时候开启长上下文模式，什么时候用按需检索的模式；怎么给 AI 工具喂一套“不多不少正好够用”的上下文；以及底层系统里那个“上下文切换”为什么会影响整体性能、又该怎么优化。

1. context-mode 到底是个啥：拆开看就一句话

1.1 字面拆解与本质

把 context-mode 拆开，就是 context（上下文）加 mode（模式）。上下文指的是“为了让当前这一步处理更准确，需要带上的前置信息”，模式指的是“带上这些前置信息的方式”。一句话概括：context-mode 就是一套关于“哪些背景信息需要存在、以什么形式存在、在哪个环节使用”的策略组合。

这个定义有点抽象，我用厨房来类比。厨师做菜有两种风格：一种是提前把今天所有菜品的原材料洗好、切好、配好，放在备餐台上，做的时候随手就能拿；另一种是按单现做，客人点一道菜才去冰箱翻食材、现场处理。前一种就是“长上下文模式”——信息提前全部放到工作区，处理速度快但备餐成本高，工作台不够大的话反而转不开身；后一种就是“按需检索模式”——每次只把当前需要的食材拿出来，工作台干净但每次取料都有额外开销。真正的好后厨，往往是两者配合：常用的调料永远摆在手边，不常用的食材现取现用。

技术圈里的 context-mode，折腾的也是同样的平衡。AI 对话程序要决定把多少历史聊天记录塞进模型、IDE 里的代码助手要决定读哪些文件来理解你的代码、操作系统要决定切走当前进程后保留多少现场信息。所有这些决定的集合，就是一套 context-mode 设计。

1.2 最容易遇到的三种 context-mode

我梳理了一下，目前技术人最容易接触到的 context-mode 集中在三个层面，每个层面的目标和约束都不一样。

第一层是AI 对话与 LLM 应用层。这一层要回答的问题是：上下文窗口有限，系统提示词、历史消息、检索到的资料，各自占多少 token？用滑动窗口丢掉旧消息，还是用摘要压缩旧消息，还是干脆让模型按需去检索？做聊天机器人、智能客服、文档问答的人，每天都在调这个模式。

第二层是编辑器与 AI 编程工具层。这一层要回答的问题是：代码补全或自动修复的时候，工具应该看多少个文件？只看当前文件，还是把整个项目的索引都加载进来？跨文件调用的场景下应该优先带上哪些相关文件？我实测下来，这里的模式选错，直接体现为补全结果“像是换了一个人在写代码”。

第三层是系统软件与硬件调度层。这一层要回答的问题是：CPU 切换进程时要保存多少寄存器状态、要不要刷 TLB？协程和线程各自的切换成本差多少？虽然做业务开发不太会直接碰这部分，但你写的高并发服务里有大量的锁和线程切换，底层 context-mode 选得差，性能就会莫名地掉。

这三层看起来风马牛不相及，但共享同一条暗线：上下文不是越多越好，也不是越少越好，关键是把成本和质量平衡在最适合业务场景的位置。理解了这条暗线，后面所有实操细节都能串起来。

2. AI 对话里的 context-mode：为什么模型总在关键时刻“失忆”

2.1 上下文窗口、token 和记忆的三角账

做 AI 应用这一年多，我被问得最多的一句话就是：“为什么我说过的事情模型还是忘了？”其实模型不是真的“忘”，而是你的 context-mode 设计让那段信息没有被送进上下文窗口。大语言模型本身没有长期记忆，它能“记住”的只有当前这次请求里拼接进去的全部内容——系统提示词、历史对话、工具返回结果、检索到的文档片段，所有这些一起构成了它的“工作记忆”。

这个工作记忆有两个硬约束：一是窗口大小，主流模型一般在 32K 到 200K token 之间；二是成本，输入 token 是要花钱的，而且输入越长，首字延迟越长。于是做应用的人必须反复算账：多塞历史消息，用户体验好但费钱、变慢；少塞历史消息，省钱、快，但对话质量立刻下降。怎么切就是 context-mode 的具体实现。

我之前做过一个客服机器人，早期实诚地把所有聊天记录原样拼进去，聊到第 20 轮的时候，光历史消息就占了 8000 多个 token，每次请求平均多付三倍的钱，响应时间从 1 秒涨到接近 3 秒。后来改成只保留最近 6 轮对话加一个自动生成的用户意图摘要，成本和延迟马上降下来，而用户体感几乎没有变化——因为 20 轮之前的细节本来就早就不重要了。

2.2 三种主流的对话上下文组织方式

实际项目里，对话上下文组织方式基本就三类，我分别说下适用场景和踩坑点。

滑动窗口（Sliding Window）：固定保留最近 N 轮对话，超出部分直接从上下文里丢掉。这是最简单也最稳的做法，特别适合客单价低、轮次短、话题切换频繁的场景，比如网页客服。缺点也很明显：用户两小时前提到的关键信息，比如订单号、收货地址，一旦被滑出去，模型就会“失忆”。我见过很多翻车事故都是这个原因，解决办法通常是把订单号这类关键实体在系统提示词里单独维护一份，不能只靠窗口留。

摘要压缩（Summarization）：当对话超过阈值时，用模型把旧对话总结成一段摘要，之后每次请求都带上摘要再加新对话。这种方式能保留比较长的记忆线，适合需要跨很多轮对话才能完成任务的场景，比如在线咨询、私人助理。但要注意摘要本身也有损耗，我试过模型在摘要里把“用户不喜欢辣”总结成“用户喜欢辣”，后面整个推荐链路全偏了。所以我的习惯是：涉及负面信息、禁忌、明确偏好这类内容，尽量原文保留，不丢给摘要去压缩。

检索增强（RAG）：不把所有历史都塞给模型，而是按当前用户提问去知识库/历史记录里检索最相关的片段，再拼到上下文里。这是现在做知识库问答的主力方案，也是 context-mode 里最灵活的一种。它几乎没有窗口焦虑，因为你只带“当前这一步需要的那几段资料”。但检索质量决定了最终质量，我之前自建的私域知识库早期召回率惨不忍睹，后来换成向量加关键词混合检索，只用了一个周末，回答准确率提了大概三成。

2.3 一个 10 轮对话的 token 估算实例

直接看数字会更直观。假设你做的是微信客服场景，用户聊到 10 轮，每轮平均用户说 30 个汉字（约 45 个 token），机器人回 80 个汉字（约 120 个 token）。10 轮下来的历史消息就是 (45 + 120) 乘以 10，大概 1650 个 token。再加上系统提示词（假设 400 token）、当前问题（50 token），一次请求差不多 2100 token。

如果什么都不管，用滑动窗口保留全部 10 轮，一天 1 万次请求，只是历史消息就要消耗 1650 万 token/天。按主流模型大约几十块人民币每百万 token 的价格算，每天光历史消息成本就上千块，这还不算延迟变高。而如果改成“最近 4 轮全文 + 前面轮次的摘要”，历史消息可能被压到 700 token 以内，成本直接砍掉一半多。

所以说，AI 应用调 context-mode，本质上是在调“保留哪些信息 + 丢弃哪些信息 + 用什么形式保留”的性价比模型。我建议每个做对话应用的人都把这个 token 估算表打印出来贴在工位上，每次调整上下文的保存策略之前，先算一遍账。

3. 编辑器与编程助手的 context-mode：让工具真正“读懂”你的代码

3.1 编辑器上下文感知从哪来

代码补全或者 AI 编程助手能不能给出靠谱的 suggestion，关键看它能“看到”多少代码。这里说的看到，不是指它能把整个仓库都塞进窗口，而是指它实际把哪些文件的内容作为上下文送给了模型。我刚开始用 AI 编程助手的时候犯过一个典型错误：把一个 2000 行的单文件塞给工具做重构，结果它每次改动都基于对文件局部的理解，改完这一处，另一处调用就挂了。

现代 IDE 的上下文感知一般分几个层次：第一层是当前聚焦的文件；第二层是当前文件里的符号定义和引用关系，通过语言服务器（LSP）拿到的语义信息；第三层是工作区索引，包括最近打开的文件、git 变更文件、搜索结果命中的文件；第四层是用户手动固定到上下文里的文件。不同的 context-mode 就是给这几层分配不同的权重。比如你在改一个函数内部逻辑，当前文件就够了；如果你在改一个跨模块的重构，就必须把调用链上的文件都手动拉进上下文，否则工具只能“盲猜”。

还有一个容易被忽略的坑：打开的标签页数量。有些工具会把所有打开的标签页内容都算进上下文。我有一次开着十几个文件，发现补全质量明显变差，回答也开始慢，后来把无关标签页全部关掉，效果立刻回来了。所以编程场景的 context-mode，第一课就是管好你的标签页，别让无关代码占掉宝贵的上下文空间。

3.2 实操：给 AI 编程助手喂“最小必要上下文”

我自己经过很多次试错，总结出一套“最小必要上下文”的打法，现在基本稳定，分享出来可以直接抄。

第一步，动手之前先明确任务类型。改 bug、加小功能、写单测、跨模块重构，每种任务需要的上下文范围完全不同。改 bug 通常只需要当前文件加报错堆栈加最近改动的相关文件；跨模块重构则需要把调用链上下游全部拉进来，甚至要给模型画一张简单的模块关系说明。

第二步，关掉无关标签页，把相关的文件集中固定。以我用的编辑器为例，我会把核心文件用“固定到上下文”的功能钉住，确保不管我怎么切文件、滚动代码，这些关键文件都稳定在上下文里。同一时间固定的文件不要贪多，超过五六个反而会让模型抓不住重点。

第三步，用自然语言写清楚当前任务背景。别只甩给工具一个光标位置让它猜。我现在会习惯在写代码前先敲一段注释，比如“这个函数负责解析用户上传的账单文件，需要注意金额字段可能包含千分位逗号，需要兼容负数。下面开始修改解析逻辑。”这几行注释对模型来说就是你给它的 system prompt，补全和改写的准确度会明显上一个台阶。

第四步，如果工具支持定义项目级规则（比如项目说明文件或者自定义指令），花点时间把项目的目录结构、核心约定、常用技术栈写进去。这个属于长效投资的上下文模式，前期写的时候麻烦，后面每次补全都受益。

3.3 一个跨文件修复的完整过程

说一个我几天前实际处理的例子。线上反馈某个登录接口偶发 500 错误，调用链是这样的：前端请求 → AuthController → UserService → TokenProvider → UserRepository。我第一反应是让 AI 助手直接看 UserService，结果它说可能在 getById 返回了 null，让我加判空。但我直觉不放心，于是把 AuthController、UserService、TokenProvider 三个文件连同报错日志一起固定到上下文，补了一句说明：“TokenProvider 在校验时抛了 NPE，帮忙定位 null 是从哪里传进来的。”

这次 AI 给出了一条完全不同的线索：UserService 里用的是 findFirstByUsername，而 UserController 里缓存了一层用户对象，缓存过期时间比 token 有效期短，导致缓存里有 user 但缺失真实 userId。我把 UserController 也加进上下文追问确认，最后定位到是缓存对象序列化时丢字段。整个过程大概二十分钟，对比第一次只丢单文件的瞎猜，效率差了好几倍。这个例子说明，上下文范围的选择直接决定了 AI 工具是“懂行的搭档”还是“不懂装懂的实习生”。

4. 系统底层的 context-mode：上下文切换那笔性能账

4.1 上下文切换到底在切什么

很多做业务开发的同事觉得“上下文切换”是操作系统的黑话，跟自己没关系。直到某天压测发现 QPS 上不去、延迟毛刺多，排查下来才发现是线程开太多、切换太频繁。所谓的上下文切换，就是 CPU 从执行一个任务切到执行另一个任务时，需要保存上一个任务的运行现场（寄存器、程序计数器、栈指针），再加载下一个任务的现场。这个保存和加载的动作，就是最底层的 context-mode。

我打个比方：一个人同时在写两篇文章，每写一段就要换一篇，换的时候要把上一篇文章的思路、草稿、资料在脑子里过一遍，这 20 秒的“重新进入状态”成本每次切换都要付。CPU 也是这样，而且它付的代价比人脑更硬：寄存器要全部存下来，内存地址映射缓存可能失效，下次再切回来的时候又要重新建立缓存。系统中进程、线程切来切去，看似每个切换都只要几微秒，但架不住量大。

这里还有一个容易误解的点：用户态线程和内核态线程切换的代价不一样。Java 这种原生线程模型，每次线程切换都要陷入内核完成保存和恢复；而协程（比如 Go 的 goroutine）是用户态调度，切换只发生在用户模式，不需要频繁陷入内核，代价小得多。所以从某种意义上讲，协程其实就是一种更聪明的 context-mode：在用户态就把上下文的保存和恢复成本给降下来了。

4.2 一次切换的代价有多大

我直接给一组经验数字。一次进程/线程上下文切换，实际耗时通常在 1 到 20 微秒左右，看起来毫不起眼。但在每秒处理几万请求的服务里，如果每个请求从接收、处理、DB操作、响应，中间要经历几十次线程切换，那累计下来每秒就有上百万次切换，光切换耗掉的 CPU 时间就可能占到总开销的 10% 到 20%，而且还会不断打乱 CPU 缓存。

怎么量化到底要不要优化？很简单，用perf或者vmstat看上下文切换次数（cs 列）。我做过一个服务的优化案例：连接池参数配错导致线程频繁阻塞唤醒，压测时 cs 每秒冲到 40 万次以上，延迟 P99 涨到 800ms。后来把线程池调小、连接池空闲检测改长、把短任务改成批量处理，cs 降到每秒不到 8 万次，P99 直接回到 120ms 以下。优化前后代码逻辑没怎么变，功能完全一样，变的只是“上下文的切换模式”。

所以当你遇到一个高并发服务“莫名其妙地慢”，把系统级 context-mode——也就是线程/协程的切换策略——纳入排查范围，往往会有惊喜。

4.3 减少无用切换的三个工程手段

我自己在项目里经常用的三板斧，供参考。

一、控制线程数量，别盲目堆线程池。很多同事以为“线程越多吞吐越高”，结果在 CPU 密集型任务上线程数远超 CPU 核数，大部分线程都在排队切换。经验公式是 CPU 密集型任务线程数设为 核数 + 1 左右，IO 密集型可以稍微多些，但也要压测验证。见过最离谱的是 4 核机器上一个接口配了 200 个线程，纯属浪费。

二、用协程替代线程处理短任务。Go 的 goroutine 切一个只要大概 100 纳秒级别，比线程切换低一两个数量级。Java 的话可以看看虚拟线程，本质上也是把上下文切换成本往下压。我自己把几个高频短任务从线程池改成协程/虚拟线程之后，切换开销基本可以忽略。

三、绑定 CPU 亲和性。把关键线程固定到特定 CPU 核上，减少在不同核之间迁移带来的缓存失效。这个在高性能网关场景比较有用。Kafka 或者 Nginx 这类组件里都有相关配置，属于“同样上下文模式，但切换更少”的思路。

这三招并没有改变业务处理逻辑，改的是系统底层的 context-mode 设计。顺便说一句，应用层的 RAG 按需检索、数据库里的连接池复用、消息队列里的批量消费，本质上都是在一个更高的层级里做“减少无谓切换/按需取上下文”的操作。你有了这套统一的视角之后，再看很多中间件的设计，思路会清晰很多。

5. 设计一套自己的 context-mode：判断、模板与避坑

5.1 判断清单：什么时候拉满，什么时候按需

聊清楚了理论，落到实践上，最重要的就是判断。我给自己整理了一份简单的决策清单，遇到具体场景直接对照查。

适合拉满上下文（长上下文模式）的情况：任务需要全局视野才能下手，比如让模型通读一份 100 页的 PDF 并做整体分析；代码重构涉及多个模块且调用链很长；一次性事件，不频繁调用，对成本和延迟不敏感。这种情况下，把能给的资料一次性都交给模型，通常收益最大。

适合按需上下文（检索模式）的情况：高频对话场景，比如客服机器人每来一条消息都要处理一次，上下文塞越多成本越高；知识面很广但每个具体问题只涉及其中一小块的场景，比如企业内部文档问答；对响应速度敏感的场景。

适合摘要模式的情况：长程任务，比如一个 AI 助理陪用户聊了一小时，中间涉及多轮上下文，但最近几轮之外的信息只需要“记得大概”就行。

这份清单不一定完全通用，但能帮你快速圈定方向。真正的模式组合通常不是单选，而是混用：系统提示词固定不变，历史消息用摘要加滑动窗口，外部知识用检索，关键实体用单独字段持久化。这才是工程上稳定可维护的 context-mode。

5.2 一套可直接复用的上下文管理模板

我把自己常用的上下文管理结构分享出来，在好几个项目里都用过，适合中小团队快速落地。

模板分四块：固定层、短期层、长期层、检索层。固定层是永远在系统提示词里的内容，比如机器人的人设、规则、不允许回答的范围；短期层是最近几轮对话的原文，控制在最近 6 到 10 轮以内；长期层是过去对话的摘要和关键实体，每次请求和短期层拼在一起；检索层是用户问题触发后，从知识库或历史记录里实时检索出来的片段。

在代码实现上，我一般用一个上下文管理器来维护这四块内容。每次用户请求进来的时候按顺序组装：先拼固定层，再拼长期层摘要，再拼短期层原文，然后跑检索，把命中的检索片段按相关度排序插入，最后拼当前问题。如果拼完发现超出上下文窗口，先砍检索层里相关度最低的片段，再合并短期层的旧轮次，绝对不动固定层和最近两轮对话。

用这套模板，我之前的客服机器人从“20 轮后必乱”变成了“聊几十轮也能稳定记住关键信息”，而且成本可控。团队里有人问我为什么每次都要把摘要单独存一份而不是存全部原文，答案很简单：摘要负责“还记得有这么回事”，原文负责“具体怎么回事”，检索负责“其他所有事”。三层各司其职，成本和质量才能同时兼顾。

5.3 高频问题与排查记录

这一路踩过的坑不少，挑几个高频的列出来，你大概率也会遇到。

问题一：加了大段历史之后回答反而变差。很多人以为给模型越多上下文它越懂你，实际上一堆无关的历史消息会把注意力稀释掉。排查思路是逐个模块做消融：先去掉检索层，再缩短摘要层，看回答质量是否回升。如果去掉某段内容后效果反而变好，说明那段上下文就是噪音，直接砍。

问题二：上下文窗口一超就报错。遇到这种情况不要无脑加大窗口，很多模型在长上下文下确实质量会衰减。我之前也碰到过连续几次超限报警，后来分析发现是个别用户一次性上传了超大附件，直接被截断导致组装失败。处理方案是把大文档做分段索引，每次只取相关段落，而不是把整个文档塞进去。你要做的不是扩大容器，而是学会切分内容。

问题三：代码补全经常给出一堆看似合理但编造的函数名。这种情况十有八九是相关文件没有进上下文，模型凭“印象”在编。我排查过一些案例，加了项目级规则和关键文件引用之后，编造率明显下降。记住：让工具“看见”真实代码，比让它“猜”真实代码，靠谱得多。

问题四：系统压测延迟毛刺多。检查上下文切换频率，用 vmstat 看 cs 列，如果数值极高，结合线程池配置调整。这个方向很多业务开发想不起来，但往往就是根因。

写到最后，分享点实在体会

我个人的心得是：context-mode 的核心不是“更大”，而是“更准”。无论你面对的是大语言模型、代码补全工具还是操作系统调度器，真正决定效果好坏的都是同一件事——在合适的时机、用合适的格式、把合适的信息放到合适的位置。这个“四合适”说来简单，做起来要反复调，但它一旦理顺了，往往能解决一串表面看似不相关的问题。

最后再分享一个小技巧。我建议团队里维护一份“上下文配方”文档，把项目里常规任务的固定上下文内容固定下来，比如客服机器人的提示词模板、代码仓库里各模块的功能说明、常用检索语句。每次新同事接手，照着配方就能很快调出和资深同事差不多的效果；每次发现配方导致翻车就立刻修订。这份文档是最容易长期收益的资产，比临时抱佛脚去调参数值钱多了。

如果你现在正被“模型失忆”、“代码补全不靠谱”、“服务莫名变慢”这三类问题轮番折磨，不妨先从 context-mode 的视角把系统重新过一遍，很可能这些问题本来就是一棵树的几根枝。