开头我来写一个实操向的开场然后展开。不管是跑AI Agent、做聊天机器人还是写AI辅助编程工具你早晚会撞上一个绕不开的坎上下文管理。Prompt写得好不好只是入门真正决定产品上限的是你能不能管好那几万、几十万token的上下文窗口。我最近半年一直在折腾这个方向把一套叫做 context-mode 的上下文管理模式拆成了可落地的东西这篇文章就把我的思路、踩坑和最终用的方案都摊开讲。很多刚接触的人容易把上下文理解成把对话历史全塞给模型实际上窗口再大也有极限而且越长越乱、越乱越蠢。context-mode 的核心不是塞得多而是给得准——在正确的时间用正确的形式把正确的上下文放到模型面前。这篇文章适合正在做AI应用开发、接大模型API、或者纯好奇为什么我的AI越聊越笨的读者我会从原理讲到代码实现最后附上排查实录。1. 为什么上下文模式成了AI应用开发的新门槛1.1 从提示词工程到上下文工程的必然转移过去两年大家谈AI应用开口闭口都是提示词工程仿佛只要把prompt写得花团锦簇模型就能稳定输出。我早期也这么干过后来发现一个残酷的事实在单次、短对话的场景里提示词确实决定下限一旦进入多轮、长流程、多工具的复杂场景提示词的边际收益会急速衰减真正卡脖子的变成了上下文本身。打个比方提示词是给新员工看的岗位说明上下文是这个人手边能查到的资料、聊天记录、项目文档。岗位说明写得再好你给员工一屋子乱七八糟的废纸他也干不好活。反过来如果资料整理得井井有条岗位说明写糙一点都无所谓。我接触的项目里几乎每个团队最终都会走到同一条路把注意力从怎么把prompt写漂亮转移到怎么设计一套上下文管理模式。这就是 context-mode 出现的背景。它不是某个库、某个框架而是一套关于上下文如何准备、组织、刷新、淘汰的方法论落地为具体模式后可以在不同场景里套用。1.2 窗口再大也装不下真实业务现在模型的上下文窗口越做越大从8K到32K、128K甚至200K看起来好像不用再焦虑了。但我实测下来这只解决了一小半问题。第一真实业务上下文增长的速度远超想象。一个带工具调用的Agent跑上二十轮每轮的系统提示、工具返回、中间推理结果累积起来很容易突破几十K token。你不可能把整个对话历史原封不动地丢给模型成本先不说模型对早期信息的注意力早就被稀释了。第二窗口大不等于用得好。我在长上下文模型上做过对比实验同样的任务一份6万token的完整历史和一份经过整理的1万token关键上下文后者的任务成功率反而更高。原因很简单模型在长文本里会迷失无关细节越多越难精准提取相关信息。这就像开一个堆满杂物的仓库仓库再大你找不到要找的那把扳手效率依然为零。第三token成本是硬约束。按现在的API定价每百万输入token的成本随着模型档次不同从几毛到几十块不等如果你的应用每天有上万个会话上下文每膨胀1K token成本就往上跳一大截。用户不会为你的上下文浪费买单。所以 context-mode 的第一条原则就是上下文不是背包塞得越满越好它是行李箱得按需打包。1.3 context-mode 到底解决哪三类问题我在实践中把 context-mode 解决的问题归纳成三类你可以对照自己的场景看看卡在哪一类第一类是容量问题。上下文增长太快超出窗口限制或者成本爆炸。需要压缩、裁剪、滚动淘汰。第二类是质量问题。上下文里杂质太多模型被无关信息带偏回答不稳定。需要重排、检索、去重、结构化整理。第三类是一致性问题。多轮交互里模型忘了早期约束或者不同任务切换时上下文互相污染。需要隔离、锚定、持久化记忆。注意这三类问题往往是叠加出现的。你压缩得太狠质量就会下降你为了保质量把关键信息全留着容量又吃紧。context-mode 的价值就在于提供一组可组合的策略让你针对具体场景找到平衡点。2. 四种核心上下文模式拆解什么时候用怎么选我在项目中总结出四种最常用的 context-mode 形态分别起名直通模式、压缩模式、检索模式、缓存模式。它们不是互斥的实际项目经常是两两组合甚至三种混用。2.1 直通模式Full Context Mode短会话的默认选择直通模式就是最朴素的把相关上下文全部塞进窗口不加任何处理。它适用于会话轮次少、上下文总量远低于窗口上限的场景。比如单轮问答、一次性的文档分析、简短的代码生成这类场景下直通模式效率最高因为省去了所有上下文处理的额外开销。我见过一些团队连这种场景都要强行上RAG或摘要纯属给自己找事。你要处理的就几千token窗口完全装得下直接传就是了。直通模式需要注意的只有一点给上下文做基本的结构化别把所有内容糊成一坨。系统指令放最前面背景资料放中间最近一轮的用户输入放最后这个顺序符合大部分模型的注意力分布规律。什么时候该从直通模式切换出去我给自己定过一个粗略的标准当会话上下文超过窗口上限的30%或者单轮请求的输入token费用超过业务可承受的阈值时就该考虑引入其他模式了。2.2 压缩模式Compaction Mode长对话的救命稻草压缩模式解决的是长对话场景。核心思路是与其保留对话全过程不如定期把已经聊完的部分提炼成结构化摘要只保留关键决策、约束条件、用户偏好、未完成事项。这里有个非常重要的实操细节压缩不能只让模型总结一下前面说了什么而是要有明确的信息提取目标。我常用的压缩模板包含这么几个区块用户核心需求用户到底想解决什么问题已确认的决策和偏好用户明确说过喜欢/不喜欢什么当前任务状态哪些已完成、哪些进行中、哪些卡住了关键约束格式要求、禁止事项、截止时间待办和下一步这种结构化摘要比一段自然语言总结有用得多因为它直接对应模型后续做推理时需要的工作记忆。我甚至会把每个区块定义为独立的上下文对象方便后续做拼接和检索。压缩触发时机我建议用双阈值上下文达到窗口上限的50%开始首次压缩达到70%进行二次压缩之后每增长15%压缩一次。压缩本身也要花钱花时间所以不要过于频繁。另外压缩后要把摘要和最新的未压缩内容合并打包进下一轮请求。2.3 检索模式Retrieval Mode从外部知识库按需取用检索模式对应大家熟悉的RAG但我想强调一个常被忽略的点RAG不只是给模型找参考资料它同样适用于管理对话历史。你可以把过去所有对话做成向量索引当新问题进来时先检索出最相关的历史片段拼进当前上下文。我最近做的一个人客服Agent就是这种思路。用户可能前面的对话已经过去一周了重新回来接着聊。如果每次都完整带上过去所有对话既超窗口又费钱如果什么都不带模型又忘了用户之前的诉求。方案是把每次会话的关键信息异步写入向量库下次用户进来时基于用户ID和历史语义检索出相关的几条上下文片段拼装进系统提示语。检索模式有三件事特别容易做砸一是切片单位不合适要么切得太碎导致信息不完整要么切得太大导致检索噪声高二是检索阈值没调好抓了一堆相似但无关的片段三是检索结果在上下文里的排版顺序不对让模型分不清哪个是当前任务、哪个是参考资料。我的建议是切片按语义段落而不是固定字符数阈值宁高勿低检索结果统一放到一个明确的参考信息区块里。2.4 缓存模式Cache Mode系统上下文的复用与降本缓存模式的核心是缓存不变部分。大多数AI应用的请求里都有一大段完全不变的内容系统指令、用户画像、工具定义、产品规则。这些内容如果每次都重新传给模型既浪费token又增加延迟。做法是把稳定上下文拆出来单独做持久化缓存。具体实现上可以用API层面的prompt缓存也可以自己在业务层做上下文模板的版本管理。关键点是变更管理系统指令一旦更新缓存要同步失效而且要确保同一缓存版本下的一致性。我真实项目的收益数据可供参考一个Agent应用的平均输入token从9K降到了5K左右延迟降低了约30%而效果没有任何可感知的下降。省下来的成本我投入到了更高频的压缩和检索上整体体验提升了一大截。为了帮你快速对照我把四种模式的适用场景、优势和代价整理成一个速查表模式典型场景核心优势主要代价直通模式短会话、单轮问答简单直接、信息无损场景一长就失效压缩模式长对话、多轮Agent控制体积、保留关键信息有压缩损失、需谨慎设计模板检索模式知识库问答、长期记忆突破窗口限制、按需取用检索质量直接决定效果缓存模式高频同前缀请求降本增效、降低延迟缓存失效管理麻烦3. 基于 context-mode 的落地实现一个可复用的上下文管理器理论说完了上实操。我写了一个轻量级的上下文管理器核心语言用Python你可以根据自己用的框架做迁移。这个管理器实现了三种模式的混合使用基础层用缓存模式存放系统指令对话层用滑动窗口压缩模式处理历史必要时用检索模式拉取外部记忆。3.1 上下文对象的结构设计我先把上下文建模成一组结构化的区块而不是一串文本。每个区块有类型、优先级、内容和元信息。这个设计是整个管理器的基础。from dataclasses import dataclass from datetime import datetime dataclass class ContextBlock: block_type: str # system, memory, instruction, reference, history priority: int # 决定区块在上下文中的排位顺序 content: str created_at: datetime metadata: dict None区块类型我分了五种system是系统级规则memory是经过压缩的核心记忆instruction是当前轮的用户指令reference是检索来的参考资料history是最近未压缩的对话历史。优先级数值越小越靠前比如system永远在最前面history放在最后。3.2 核心逻辑预算分配与自动降级上下文管理器的灵魂是token预算分配。我会设定一个总预算然后按比例分给不同类型的区块当实际用量超标时自动触发降级策略。class ContextManager: def __init__(self, total_budget: int, system_budget_ratio: float 0.2, memory_budget_ratio: float 0.25): self.total_budget total_budget self.system_budget int(total_budget * system_budget_ratio) self.memory_budget int(total_budget * memory_budget_ratio) self.blocks [] def allocate(self, blocks: list[ContextBlock]) - list[ContextBlock]: # 按优先级对区块先排序 ordered sorted(blocks, keylambda b: (b.priority, b.created_at), reverseTrue) remaining_budget self.total_budget selected [] for block in ordered: # 简单估算token数中文按1字1token英文按4字符1token实践中可换成tiktoken est_tokens self._estimate_tokens(block.content) if block.block_type system: if est_tokens self.system_budget: selected.append(block) self.system_budget - est_tokens elif block.block_type memory: if est_tokens self.memory_budget: selected.append(block) self.memory_budget - est_tokens else: if est_tokens remaining_budget: selected.append(block) remaining_budget - est_tokens return selected实际的token估算不要用手写的简单算法接入tiktoken这类分词库否则误差会很离谱后面我讲常见问题时细说。3.3 压缩执行器把长历史变成结构化记忆压缩是整个管理器里技术含量最高的一块。我实现了两个版本同步压缩和流式压缩。同步版适合轮次间隙的集中处理流式版适合边对话边更新记忆。这里展示同步版本的核心实现思路。def compress_history(history: list[dict], llm_call) - list[ContextBlock]: if not history: return [] # 把历史拆成几个主题段避免一次压缩大长文 segments split_by_topic(history) memory_blocks [] for seg in segments: prompt build_compress_prompt(seg) result llm_call(prompt) memory_blocks.append( ContextBlock( block_typememory, priority80, # 排在系统指令后面 contentresult[summary], metadata{source: compaction, topic: seg[topic]} ) ) return memory_blocksbuild_compress_prompt 里用的是我前面说的结构化提取模板要求模型输出JSON格式的摘要包含需求、决策、状态、约束、待办五个字段。用JSON而不是自然语言是为了后续能精确读取某个字段或者把记忆片段转成向量做检索。我踩过的一个坑是压缩时如果输入太长模型容易忽略中段信息。解决办法是先按主题分段每个段单独压缩最后合并。分段的实现我偷懒先用关键词聚类效果不够理想时再上embedding聚类实测embedding聚类效果好很多但成本更高大家按自己预算取舍。3.4 组合使用示例一个带记忆的客服Agent下面给一个组合使用的完整示例。场景是一个客服Agent需要处理用户多轮提问、跨会话记忆用户偏好同时还要遵守一系列服务规则。# 初始化总预算8000 token cm ContextManager(total_budget8000) # 系统指令走缓存模式不用每次重新构建 system_block ContextBlock( block_typesystem, priority100, contentload_from_cache(customer_service_system_v3), ) # 从向量库按当前问题检索历史相关记忆 retrieved_memories vector_search(queryuser_query, top_k3) memory_blocks [ ContextBlock(block_typememory, priority70, contentm) for m in retrieved_memories ] # 当前轮指令 instruction_block ContextBlock( block_typeinstruction, priority90, contentuser_query, ) # 最近几轮对话历史超过5轮就先进压缩器 recent_history get_recent_history(user_id, max_rounds5) if total_tokens(recent_history) 3000: recent_history compress_history(recent_history, llm_callcall_llm) history_block ContextBlock(block_typehistory, priority10, contentrecent_history) # 统一交给管理器做预算过滤 final_blocks cm.allocate([system_block, *memory_blocks, instruction_block, history_block]) final_prompt assemble_prompt(final_blocks)这个流程里缓存模式覆盖system_block检索模式覆盖memory_blocks压缩模式覆盖历史直通模式覆盖当前指令。四个模式在一个请求里同时生效这也是真实项目里最常见的组合形态。3.5 参数调优的经验值上下文管理器的参数没有银弹但我可以提供一组经过验证的起始值大家照着调能节省大量试错时间。总预算一般设为模型窗口上限的70%到80%给自己留出输出token的空间。如果你的模型窗口是128K输入侧预算可以定在90K左右剩下的是输出和冗余。如果某个任务经常要输出长文本输入侧预算要更低。各区块占比上我常用的起始配置是system占15%memory占20%reference占25%instruction占15%history占15%预留10%做弹性缓冲。前面代码里的比例是按这个思路来的实际项目里history的比重往往会被压缩因为它的信息密度最低。检索模式里的top_k单轮问答在3到5之间比较稳妥多步骤任务可以适当增加到8到10但超过10之后模型开始选择困难。压缩触发阈值就按前面说的双阈值法首次50%二次70%之后每15%一档。4. 常见问题与排查技巧实录这块内容是我最想写的因为照着文档做最多做到可用踩过坑才能做到好用。我把自己和身边朋友项目里反复出现的问题整理成一份排查实录按问题现象、原因分析和解决路径来写。4.1 模型越来越笨上下文污染导致注意力被稀释现象是Agent跑到后期早期明确交代过的约束会被遗忘回答质量肉眼可见地下降。很多人的第一反应是模型记忆力不行但多数情况下根源是上下文污染——无关信息太多挤占了关键信息的注意力份额。排查的方法是做上下文可视化。把每次请求实际发送的prompt打印出来按token数排序看看哪些区块占了大头。我遇到过最夸张的一个项目一万多token的历史里真正和当前任务相关的不到一千剩下全是早期调试时的中间产物和失败的工具调用记录。解决路径是强化压缩模式。我建议在History Block里做失败对话过滤把工具调用报错、重新尝试的过程折叠成一行状态说明而不是保留完整记录。另外所有上下文区块按前面说的优先级排序系统指令和核心记忆永远放在模型更容易注意到的位置。4.2 压缩摘要失真关键约束在压缩过程中丢失这是压缩模式最危险的副作用。模型压缩时为了连贯性会不自觉丢掉一些看似不重要的限定词比如不要调用外部API格式必须是JSON这类负面约束最容易丢。我排查过一个案例Agent第一次压缩后还能记得用户要求回复控制在50字以内第二次压缩后这个约束就消失了输出从简报变成论文。问题出在我用的压缩提示词里约束字段权重太低模型倾向输出事实性信息而忽略规则性信息。解决方法是给压缩模板里的约束字段单独加重磅描述并且把约束字段从摘要正文里再复制一份到系统指令区。也就是在system block里放一个持久约束区压缩出来的约束信息同步更新到这里双保险。另外压缩后做一次自动校验拿压缩前的文本和压缩后的摘要各跑一遍一个简单question-answer对如果摘要回答不出关键细节就判定压缩失败并回退。4.3 检索相关性不错但效果差检索片段上下文不完整RAG模式下很常见的一个问题是检索回来的片段单独看相关性很高拼进上下文后模型反而被误导。原因通常是切片太碎片段里引用信息不完整模型看到一知半解的内容后开始脑补。我调过的最成功的一次处理是用段落作为最小切片单位段落太长的再按语义切但保留前后各一句作为衔接检索时先按段落检索命中后把该段落所属的整个小节一起返回这样上下文是完整的。千万别直接按固定字符数硬切那是最省事也最容易翻车的方案。另外检索片段的排序也有讲究。不要简单地按相似度分数降序排我实际测下来把最相关的片段放最前面、并给每个片段加一行来源标签模型对检索内容的信任度和利用率会明显提高。4.4 token估算误差过大预算分配形同虚设代码里手工估算token数的方案看着方便实际误差能把预算分配直接带偏。中英文混合的场景里按字符数估算可以把实际token高估一倍以上或者反过来低估大半。我后来的做法是直接用tiktoken做估算初始化时指定模型的编码器然后对每个区块内容做精确计数。虽然算得慢一点点但在预算分配这种高频调用场景里准确性远比那点性能损失重要。如果你的内容里含大量代码还要注意代码的token密度远超自然语言预算分配时要额外加重代码类区块的权重。4.5 常见问题速查表把上面这些整理成一张表方便你排查时按图索骥。现象最可能原因优先排查项推荐解法模型忘记早期约束上下文太长、约束被稀释查看实际发送的prompt长度和内容压缩持久约束区压缩后信息丢失压缩模板字段权重不当检查压缩输出JSON的完整性约束字段双重记录、校验回退检索片段懂但无用切片太碎、上下文不完整检查切片单位与检索返回长度段落级切片小节回补预算分配失真token估算不准对比估算值和真实token数接入tiktoken精确计数多任务互相干扰上下文未做任务隔离检查多个任务是否共用同一区块不同任务分配独立上下文任务切换时清理缓存4.6 我的最终建议别追求单模式最优要设计模式切换规则折腾了这么久我最想强调的一点是从来不存在一个完美的上下文模式只存在一个合理的模式切换策略。直通模式简单但撑不长压缩模式省钱但会丢细节检索模式能延展记忆但依赖检索质量缓存模式高效但引入了缓存管理复杂度。我自己最终落地的方案规则只有三条上下文总量低于预算的30%时无脑直通超过30%后启用滑动窗口摘要压缩任何跨会话需求都必须走检索模式同时系统级指令永远走缓存。这三条规则覆盖了我95%以上的真实场景而且足够简单团队的工程师也好维护。你要是刚起步不用一上来就把四种模式全上齐先从一个直通模式跑通核心逻辑再逐步加压缩、检索、缓存每一步的收益都能算得清清楚楚。一点个人心得context-mode 叫模式本质是一堆取舍。我见过很多人把上下文管理做成无比复杂的管线结果系统既难调又难debug跑起来还慢半拍。好的上下文管理要做到大象无形——用户感知不到记忆的存在但Agent的行为始终前后一致、张弛有度。从一个简单的3000字Generator到上线的客服系统支撑我的不是花哨的技巧而是反复问自己一句话这轮请求里模型真正需要知道的最小信息集是什么想清楚这个上下文模式自然就清晰了。