context-mode 这个词你大概率在一些工具里见过切 Kubernetes 集群时要切 context编辑器里有工作区上下文到了大模型对话和 AI 辅助开发里它又多了层含义——你想让模型“带着哪些信息”去完成这一次推理。我以前根本没把它当回事不管什么任务都把所有文件、全部历史消息一股脑塞进 prompt直到连续踩了几次“上下文撑爆”的坑才意识到 context-mode 不是某个工具的开关而是一套需要主动设计的信息取舍策略。最近我把手头一个长期维护的 AI 辅助项目重新整理了一遍给会话加上了可切换的上下文模式生成质量、响应速度、token 费用都改善得很明显。这篇文章是这次改造的完整记录适合正在用大模型 API 做长文本任务、做 AI 辅助编程、或者被越来越长的 prompt 折磨过的开发者。你会看到我拆解的四种常见模式、一个可以直接抄走的小工具、以及实测中反复踩过的五个坑。先从头说起我为什么从“全量塞入”转向“显式决策”。1. 先从场景说起为什么“带更多上下文”反而更慢更差1.1 被上下文“撑爆”的三个真实瞬间第一次踩坑是整理项目周报。团队有二十多个 issue、三个版本的需求文档加上过去一个月的讨论记录我心想着“信息越全越好”直接把所有内容拼成一份超长文本交给模型。结果模型确实很“全”把几个月前已经废弃的方案又当成当前方案写进了正文还一本正经地编造了我根本没确认过的里程碑节点。我以为给它材料越多它越专业实际恰恰相反。第二次是代码重构。我想让模型帮我评估支付模块的拆分方案为了让它“了解全局”我把核心目录、接口定义、数据库脚本一起压进了上下文。问题来了总长度已经非常接近模型的上下文上限真实 API 内部还会做动态裁切于是最关键的那个老接口签名被裁掉了模型基于残缺信息给出了一个会破坏线上兼容性的建议。整个任务白做只能重新来一遍。第三次是内部知识库问答。我把几千条 FAQ 全文塞进 system prompt得到的响应延迟很高费用也涨得飞快还经常把不同业务线的细节混在一起回答。等我把知识库改成“先召回再回答”的检索模式之后同样的提问延迟降了大概一半正确率反而上去了。这三个场景有个共同规律我不是在“提供上下文”而是在“堆文本”。真正的上下文管理关乎的是信息价值的筛选而不是文本数量的堆积。1.2 context-mode 的本质质量、成本、速度的三角博弈重新设计这套机制时我在脑子里画了一个三角形质量、成本、速度。质量关键信息能不能完整抵达模型。上下文越长关键信息被淹没的概率越高模型对中段内容的关注度会明显下降。成本token 消耗直接对应费用很多长任务的 80% 成本都花在重复携带旧历史上。速度上下文处理本身耗时输入越长首字延迟越明显长上下文甚至会让超时率和出错率同步上升。没有一个模式能同时把三个角拉满。全量模式质量理论上最高但成本速度最差截断模式成本速度最好但可能丢关键信息摘要和检索则是中间路线。我特别喜欢用打包行李来类比这件事全量模式是把你整个衣柜托运过去东西是齐了但托运慢、运费贵到了目的地还要翻半天才能找到那条裤子截断模式是随手抓几件最近的衣物轻便但很可能忘带证件摘要模式是把行李压缩成一个登机箱需要舍得扔东西检索模式则是到了目的地再按需购买东西能不能买到取决于当地商业环境也就是检索质量。所以 context-mode 的核心不是“用哪个按钮”而是你愿不愿意为每一次任务显式地做这个取舍。2. 解构四种常用模式全量、截断、摘要、检索动手写代码之前我先把实际会用到的四种模式拆清楚。每种模式都有它最合适的任务类型也有明显不适合的场景。2.1 全量模式信息完整但只适合“一次性”任务全量模式就是把 system prompt 加上全部历史消息原封不动送进模型。它真正好用的地方是单次、短文、全文高价值的场景比如让模型精读一份几千字的合同或者基于一个 README 做架构评审。此时上下文里没有垃圾信息全量就是最优解。一旦进入多轮对话或涉及庞大资料全量模式的缺点就开始放大。首先是 token 线性增长每多一轮对话上一轮的所有内容都要重新编码一遍其次是注意力稀释我给模型的长上下文里真正相关的可能只有中间某两段但模型对长文“两头关注强、中间关注弱”是真实存在的现象相关片段很难被有效聚焦。我的判断标准是如果任务里不存在“旧信息”和“新信息”之分全量模式没问题只要有“哪些历史已经过期、哪些资料其实没用”的疑问就不该全量。2.2 截断模式最省事但最容易“丢魂”截断模式也叫滑动窗口保留最近 N 轮消息其余全部抛弃。实现成本最低长期对话下成本速度表现都不错但它有个非常隐蔽的危险很多简单实现会直接从消息列表头部砍掉这等于把用户的原始诉求、系统指令一并扔掉。我在自家工具里的做法是给消息分角色system 属于“不可变区”永远不参与截断user 和 assistant 的历史才参与滑动窗口。同时我不能只保留最近几轮就完事因为关键约束可能出现在很早的一轮里所以截断模式通常要配合摘要模式而不是单独使用。2.3 摘要模式把历史压缩成约束性价比最高的加法摘要模式是截断模式的进化版老历史不直接丢而是压缩成一段结构化摘要放在上下文最前面。好处是既保留决策脉络又控制 token 总量。我实际用的摘要模板很简单这个任务的目标是什么、已经确定的关键约束有哪些、当前待决策的问题是什么、已经被否决的方案是什么。四块内容就够了多了反而稀释价值。摘要不是把历史“简要复述”而是要提炼成后续推理仍然依赖的硬信息。比如“我们讨论过预算问题”是废话“预算上限 3 万元供应商 A 报价 2.8 万暂定选 A”才是有效摘要。摘要模式的代价是需要一次摘要运算。如果调用大模型来做本身就有 token 开销和延迟如果用规则抽取又容易丢语义。我的经验是控制摘要频率不是每轮对话都压缩而是历史超过一定轮数才压缩一次。2.4 检索模式按需召回长文档场景的最优解检索模式适合那种“资料很多但每次只需要一小块”的场景比如企业内部文档库、大型项目源码库、FAQ 集合。它的思路是先根据当前问题搜索相关资料再把这些片段和原始问题一起交给模型而不是把整个库塞进去。检索质量直接决定回答质量这没什么好避讳的。工程上可以选择 BM25 这类经典算法也可以上向量检索加 rerank。新手可以先从关键词召回做起把用户问题和历史消息切词找包含这些词最多的文档片段取前 3 到 5 条效果往往已经超过无脑全量。这里有个容易犯的错检索出来的片段不经过滤就全塞进去。我实测发现召回的 top 片段里往往有一两条和当前问题只有词汇重叠、没有语义关系这些噪声反而会误导模型。所以检索之后我会再加一个过滤层宁可少给不能乱给。2.5 四种模式一句话对比模式适用场景优点主要风险全量一次性的短文、全文都有价值信息最完整token 贵、延迟高截断多轮对话、全局依赖弱省 token、速度快容易丢关键约束摘要长对话、有历史决策脉络控制成本、保留脉络摘要失真检索资料多但相关片段少精准、可扩展召回质量决定上限这四种模式不是互斥的我最后实际用的是“摘要加检索”的混合结构后面会细讲。3. 手工落地一个支持三种模式的小工具3.1 需求拆解我要的不是库而是策略市面上有不少现成的上下文管理库但我最终决定自己写一个几十行的类。原因很简单现成库帮你解决了“存储信息”却帮不了你决定“哪些信息值得进入上下文”而我恰恰需要把决策权留在自己手里。这个工具只需要做三件事维护系统提示和对话历史提供不同模式下的上下文构建函数在上限附近做统一自检。我不追求通用只求在下一个项目里能直接复制修改。3.2 核心实现一个几十行的 ContextManager我用 Python 写了一个最小实现token 估算借用了 tiktoken。如果不想引第三方库也可以换成模型官方 tokenizer或者粗略按“中文一个字约一个 token、英文四个字符约一个 token”来估计核心逻辑不变。import tiktoken from typing import List, Callable from dataclasses import dataclass dataclass class Message: role: str # system | user | assistant content: str class ContextManager: def __init__(self, system_prompt: str, max_tokens: int 8000, model: str gpt-4o): self.system_prompt Message(system, system_prompt) self.history: List[Message] [] self.max_tokens max_tokens self.encoder tiktoken.encoding_for_model(model) def _tokens_of(self, messages: List[Message]) - int: # 模拟 API 的结构化开销每段消息附加 4 个 token total 0 for m in messages: total 4 len(self.encoder.encode(m.content)) return total def add(self, role: str, content: str) - None: self.history.append(Message(role, content)) def build_full(self) - List[Message]: return [self.system_prompt] self.history def build_truncate(self, keep_last: int 10) - List[Message]: recent self.history[-keep_last:] return [self.system_prompt] recent def build_summary(self, summarize_fn: Callable[[str], str], keep_recent: int 6) - List[Message]: if len(self.history) keep_recent: return self.build_full() old self.history[:-keep_recent] recent self.history[-keep_recent:] old_text \n.join(f{m.role}: {m.content} for m in old) summary_text summarize_fn(old_text) summary_msg Message(user, f[历史摘要] {summary_text}) return [self.system_prompt, summary_msg] recent def is_within_limit(self, messages: List[Message], ratio: float 0.8) - bool: return self._tokens_of(messages) self.max_tokens * ratio这里有个细节_tokens_of里的4 len(...)只是粗略模拟真实 API 还会有图片、工具定义、回复格式等额外占用所以我把安全阈值设在了max_tokens * 0.8。宁可本地多留 20% 余量也不要上线后反复撞限。主流程可以这样用cm ContextManager( system_prompt你是一名严谨的资深工程师回答前先复述用户的核心约束。, max_tokens8000, ) cm.add(user, 帮我把支付模块从单体拆成微服务约束是不能改数据库表结构。) # …… 多轮对话后 if cm.is_within_limit(cm.build_full()): next_messages cm.build_full() else: next_messages cm.build_summary(summarize_fnmy_summarizer, keep_recent6)你可能会问my_summarizer从哪来。最直接的方式是调用大模型 API 让它输出四段式摘要不想额外调用的话也可以先做启发式抽取把包含“不”“必须”“禁止”“上限”“最低”这类词的句子单独拎出来拼成摘要。本地兜底版本效果差一些但至少不会把关键约束直接丢进历史。3.3 怎么选模式一张决策清单我把选模式的逻辑固化成了四行判断团队其他人也能直接用任务信息量小、全文都没有冗余直接 full别折腾。历史很多、但后续依赖的是最近几轮用 truncate同时保证 system prompt 里已经写死长期约束。历史很多、且早期有重要的决策和约束truncate 加 summary摘要必须包含数字、名称、硬约束。外部资料多、当前问题只依赖其中碎片retrieval全文只留检索片段和当前问题。选择模式不是开发阶段的“配置项”而是运行时的动态判断。我建议把模式选择放到请求构造流程里像上面代码那样根据当前 token 占用自动降级而不是写死在某个配置文件中。注意切换模式的阈值不要设得太极限。我通常让 summary 触发点早于真正超限比如容量到 60% 就开始压缩历史。原因是模型输出本身也要消耗 token如果上下文已经占满 95%这次对话生成的内容很容易被中途截断。4. 实际跑下来要避开的五个坑代码能跑只是第一步真正让 context-mode 稳定工作的是那几个边缘问题。我把这段时间踩过的坑集中写在这里。4.1 截断位置不是从开头截而是守护系统指令刚开始实现截断时我写的是messages[-N:]结果发现模型越来越“没规矩”原来 system prompt 被一起截掉了模型既没有角色约束也没有安全边界。正确的做法是让 system prompt 永远处于不可变区只对 user/assistant 历史做裁剪。更进一步如果某条历史消息里写过“以后所有回复都用中文表格输出”这种长期规则也应该把它放进保护区不参与滑动窗口。我后来给 Message 加了一个protected: bool字段任何标记为 protected 的消息都不参与截断。成本几乎为零收益却是稳定的指令一致性。4.2 摘要不能只留主题词摘要模式最大的坑是“摘要完等于没摘要”。我试过让模型把三小时的讨论压成一段话它输出“双方就预算问题进行了讨论尚未达成一致”这种摘要进上下文完全没用。有效的摘要是可执行的必须包含三个要素涉及的具体对象名称、确定的数值、约束性动词。比如“讨论过 A 供应商报价 2.8 万、B 供应商报价 3.1 万目前倾向 A但未最终确认”就是合格摘要。如果你的摘要里没有任何数字、名称、或者“决定/拒绝/必须”这类词那它就是在浪费 token宁可不要。4.3 token 估算与实际超限的差异我有一段时间很信任 tiktoken 的计数直接拿它算出来的值去设计上下文长度结果生产上偶尔报超限。原因主要有两个一是 API 消息结构本身有额外开销角色标记、格式说明都会占 token示例里补的每段 4 个 token 只是演示二是某些长工具调用、函数定义、图片附件会带来远超文本本身的 token 消耗而这些在计数时常常被忽略。建议是本地估算只用于决定“长文本要用什么模式”真正判断能否发送时按估算值的 80% 做阈值并且把超限错误接入重试降级逻辑。别在 99% 的占用率下赌那 1% 的稳定性。4.4 模式切换时的状态一致性工具做到一半时我遇到一个非常隐蔽的问题从全量模式切到摘要模式后模型开始答非所问。排查半天发现切换时我只是把旧消息字符串拼了一版摘要但消息结构里原有的角色信息、终止标记全丢了新会话变成了一大段无人称的文本模型根本分不清哪些是用户说的、哪些是助手说的、哪些是自己总结的。正确做法是切换时保留消息结构。摘要生成后把它作为一条独立消息插入历史后续轮次仍然按照 user/assistant 交替推进而不是塞进 system prompt或者混在某个 message 的 content 里。这条规则我写进了团队规范任何上下文变形都必须保持消息数组的序列结构。4.5 上下文不是数据库最后一个坑属于认知层面。当项目历史超过十万 token 后我开始意识到无论截断摘要怎么优化总有一个成本上限。真正该做的不是把上下文管理器越写越复杂而是把历史落库只在需要时检索用外部存储替代长期上下文。大模型上下文的正确角色是“工作台”只放本次推理需要看到的信息而不是“仓库”用它装所有可能用到的知识。这句话值得反复强调context-mode 解决的是“本次推理带什么”解决不了“所有信息都存储在哪”。后者应该交给向量库、数据库、文件索引而不是塞给模型。5. 把它变成日常方法论分层上下文结构5.1 Agent 和长任务里的四层结构把模式跑通之后我在实际项目中把上下文整理成了四层结构现在做任何长任务都不容易乱第一层是系统指令层包含角色、输出格式、安全边界、不可变约束永远不动。第二层是任务背景层是本次请求最相关的项目背景、代码片段、文档片段按需检索得到不预置全量。第三层是最近对话层保留最近 6 到 10 轮原文用于维持连续性和短期意图。第四层是长期记忆层把更早的历史压缩成结构化摘要必要时再从摘要继续展开。这个分层结构的好处是每一层都有独立的淘汰策略系统指令层永不淘汰任务背景层每次请求动态重建最近对话层滑动窗口截断长期记忆层定期摘要压缩。你不需要一个“万能模式”只需要让每一层按自己的节奏保持更新。我在跑 agent 型任务时发现很多 agent 引擎自带的记忆功能本质上就是这四层中的一个子集。如果你理解了 context-mode 的分层思路再去看那些配置项基本一眼就能明白它背后在做什么也知道哪里可能在长任务中失效。5.2 落到团队的操作规范最后一步是把它沉淀成团队可执行的操作规范而不是停留在个人经验里。我给项目组定的“默认上下文清单”很简单目标描述不超过三句话。硬性约束编号列表只写不可妥协的部分。待决策问题最多五条超出部分先外部记录。相关资料只放路径、链接、关键片段不粘贴整个文件。最近对话保留十轮以内原文更早的压缩成摘要。这份清单不需要所有人都理解底层机制只要按照模板组织输入模型的稳定性就会提升一大截。尤其是面向复杂业务的项目核心收益往往不是省了几个钱而是每一次调用输出的可预期性。从我个人的实操体会来说context-mode 给我最大的影响不是省了多少 token而是改变了“信息准备”的态度。以前做任何任务的第一反应都是“把所有资料搬过来”现在第一反应是先问一句“这次推理真正依赖哪些信息哪些只是我出于焦虑才想塞进去的”这个习惯一旦建立不只大模型任务受益写文档、开会、做方案都顺了不少。如果你也在和长上下文搏斗建议先别急着换更大的模型把你现有的对话历史分成上面说的四层结构加一个动态构建函数大概率会有立竿见影的改善。等这套结构稳定了再考虑更重的向量记忆和外部存储会从容很多。