1. 项目概述context-mode 到底在解决什么问题先直接说结论context-mode 是一套针对大语言模型应用中的上下文进行模式化管理的机制核心目标是根据不同的任务场景用不同的策略来采集、筛选、组装、压缩和传递上下文让模型在有限的上下文窗口里始终获得最有效的信息。做 LLM 应用的人基本都遇到过这种场景同一个模型同一个 agent 框架换了个任务需求之后回答质量忽上忽下。有时候是上下文太长把关键信息挤掉了有时候是塞进来的背景信息太杂模型抓不住重点。问题不在模型本身而在上下文没有按照任务特点去组织。context-mode 想做的事就是把什么时候该带什么上下文怎么带带多少这件事从凭感觉变成一套可配置、可复用的模式化方案。我最早意识到这个问题是在做一个多轮对话工具的时候。用户连续追问产品细节模型越来越偏最后甚至开始一本正经地编造参数。后来排查发现历史对话中最早几轮的内容已经被截断而产品文档又太长被截断的恰恰是跟当前问题最相关的部分。这不是模型的问题是我给模型喂信息的方式出了问题。从那以后我开始系统性地研究上下文管理模式并在多个项目里反复验证最终沉淀出上下文模式化这套思路。这篇内容适合正在做 LLM 应用开发、Agent 编排、RAG 系统优化的工程师也适合刚接触提示词工程、想在项目里建立一套稳定上下文管理方案的产品和技术人员。它解决的不是某一个具体的代码问题而是一类模型理解偏差、答非所问、幻觉频出这类根因在上下文组织方式的综合问题。2. 核心思路拆解为什么模式化比经验化更可靠2.1 context-mode 的本质是给上下文建立分类学很多开发者都有自己的一套上下文处理经验。比如 把完整的对话历史都塞进去、把所有知识库都检索一遍然后拼接、把 system prompt 写得越长越好。这些经验在 demo 阶段往往好用但一旦进入真实业务缺陷立刻就暴露出来。context-mode 的思路是把上下文处理从一次性手艺活变成可复用的模式库。具体来说就是把每一个任务场景抽象成一组固定的上下文配置参数当前需要加载哪些信息源、每类信息的最大长度、信息之间的组织顺序、历史上下文的裁剪策略、是否需要重新整理信息结构等等。这样做的优势在于可预测性和可调试性高。同一类任务无论谁来配置跑出来的上下文结构都是稳定的出了问题也能快速定位是哪个环节出了问题。我通常把上下文模式分为四个基础类别。第一是对话续接模式适用于多轮聊天和客服场景核心是保留完整的对话意图链同时压缩冗余表达。第二是知识问答模式适用于 RAG 类场景核心是检索片段的高效组织与重排。第三是任务执行模式适用于 Agent 多步骤工具调用核心是维护当前执行计划、中间状态和工具反馈。第四是生成创作模式适用于写作、摘要、文案生成核心是风格约束和结构指导。在实际项目里这四个基础模式再组合出十几种细分场景。比如文档型问答是知识问答模式的变体但需要额外引入文档结构信息代码修复助手则是任务执行模式与对话续接模式的混合体。有了这套分类框架上下文处理就不再是一团浆糊而是可以逐项设计、独立优化的工程模块。2.2 上下文窗口的本质限制是信息预算为什么要做模式化而非简单地把所有信息都塞进去核心原因是 LLM 的上下文窗口虽然越来越大但有效信息密度并不会自动提高。当输入长度接近窗口上限时模型对中间部分信息的关注度会显著下降这在业界通常被称为lost in the middle现象。我自己的理解是上下文窗口本质上是一个信息预算问题。窗口大小不是 200k token 就真的能高效利用 200k token可用预算往往要打个对折甚至更低。context-mode 做的事情就是像一个精打细算的预算师知道每一类信息大概值多少 token优先保障高价值信息的位置和长度把低价值信息压缩到最小甚至彻底丢弃。举个例子同样是在代码仓库里做问答如果你把整个 README 和项目配置文件全部塞进上下文模型确实能读到但回答问题时可能因为噪声太多而忽略关键逻辑。而如果采用代码问答模式只加载项目结构概览、核心模块目录、最近改动的文件以及当前问题涉及到的具体函数定义信息量虽然变少了但模型回答的准确度反而明显提升。这就是预算思维带来的收益。另一个容易被忽视的点是上下文模式不只是输入侧的取舍也包含输出侧的规划。在设计一个上下文模式时我会同时规划模型回答的格式、长度和风格。这看起来跟上下文没关系但实际上输出约束会影响模型如何理解输入的上下文。比如在任务执行模式下要求模型每一步先输出一个简短决策再调用工具这种输出方式会迫使模型更加结构化地利用给定的上下文信息减少无效推理。2.3 为什么需要模式切换而不是一种模式走天下刚开始设计 context-mode 的时候我确实想过做一个万能上下文模板用一套配置应对所有场景。但实践下来的结果是所有的效率优化几乎都是针对特定场景的万能模板必然牺牲精度。这背后的原因并不复杂。不同的任务类型对上下文的敏感性存在显著差异。对话续接场景里最重要的上下文是最近几轮对话中用户表达出的意图变化而早期对话只有一个大致印象就够了但在多文档对比场景里每一个文档的细节段落都可能是关键证据任何粗粒度的压缩都可能丢失决定性信息。还有一类重要差异来自模型行为本身的交互方式。纯文本问答场景里上下文是一次性投喂的静态信息而在 Agent 场景中上下文是动态的、每一步都在更新的过程信息。前者适合用快照式模式一次性把信息组织好交给模型后者适合用流式模式每完成一个工具调用就重新整理一次当前上下文。两者没有优劣之分但混用就会出问题——你不可能给 Agent 的一个中间步骤投喂一次完整的历史快照那会让模型分不清当前状态到底是什么。所以我最终放弃了一模板打天下的思路转向模式注册表 运行时选择器的设计。应用启动时注册好所有场景对应的上下文模式运行时根据任务意图动态选择使用哪种模式组装上下文。工程上并不复杂但效果提升非常显著。3. 实操过程手把手搭建一个 context-mode 系统3.1 场景定义与信息源盘点在写任何代码之前先把场景和信息源盘清楚。这条经验是我踩坑换来的——早期我直接进入代码实现结果信息源一变整个上下文组装逻辑就要重写。现在我的做法是先做一个简单的表格。我以一个典型的客服知识库问答项目为例说明。这个场景的输入信息源包括产品手册、历史工单记录、用户当前问题、最近若干轮对话、用户的基础信息如会员等级、当前售后政策的版本号。输出要求是先判断问题类型再给出基于知识库的准确回答如果知识库中没有答案明确说不知道并给出人工客服入口。这个场景对应的 mode 可以定义为客服问答模式。各信息源的 token 预算分配我一般这样设定产品手册和知识库类的权威信息分配 60% 的预算历史对话和当前问题分配 30%用户画像信息分配 5%政策版本和系统提示分配 5%。这个比例来自对实际行为反馈的观察——用户信息给太多容易让模型看人下菜碟反而影响回答的客观性。理清这些之后我用一个结构化的配置对象来描述这个模式。每个信息源定义了获取方式、最大长度、压缩策略和放置顺序。这样后续新增一个售后工单分析模式时只需要重新组合这些信息源并调整参数就行不用写新逻辑。3.2 核心实现上下文组装器的三段式设计有了配置之后进入实现环节。我习惯把上下文组装器设计成三段式信息采集层、压缩优化层、组装格式化层。每一层只负责一件事这样替换任何一个环节都不会影响其他环节。信息采集层负责从不同数据源拉取原始信息。这里的关键设计是统一采集接口。不管是数据库查询、向量检索、还是 API 调用最终都返回一个统一的SourceChunk对象里面包含文本内容、元数据、来源类型和原始长度。这样后续的压缩和组装逻辑完全不用关心数据是从哪儿来的。压缩优化层是 context-mode 的核心。在这里我实现了三类压缩策略。第一类是截断压缩适用于低优先级的上下文比如过长且不关键的对话历史直接砍掉最早的部分。第二类是摘要压缩使用一个小模型或规则算法把长文本压缩成保留关键信息的短文本适用于需要保留完整语义但 token 占用过高的信息。第三类是结构化提取只从长文本中抽取出与当前任务相关的字段适用于产品手册、合同、日志这类信息密度不均的文档。组装格式化层负责将压缩后各个信息源按预设顺序拼接成最终的 prompt。这里有两个非常关键的细节。第一每个信息源之间必须加清晰的分隔标识并且给模型说明每个部分的作用。比如用knowledge_base和conversation_history这类标签包裹不同部分。第二必须在 prompt 中明确告诉模型如果知识库中没有答案不要猜测直接说明不知道。这一步看起来微不足道但能显著降低幻觉率。下面给一个简化版的代码示例展示 客服问答模式 的组装核心逻辑dataclass class SourceChunk: content: str source_type: str metadata: dict priority: int def assemble_context(conversation, user_question, user_info, knowledge_chunks, mode_config): # 1. 信息采集层把原始输入统一封装为 SourceChunk sources [] sources.append(SourceChunk(user_question, user_question, {}, 100)) for chunk in knowledge_chunks[:mode_config.max_kb_chunks]: sources.append(SourceChunk(chunk, knowledge_base, {}, 80)) # 2. 压缩优化层根据优先级策略处理 compressed [] for src in sorted(sources, keylambda x: x.priority, reverseTrue): compressed.append(compress_source(src, mode_config)) # 3. 组装格式化层拼接为最终 prompt sections [] sections.append(system mode_config.system_prompt /system) sections.append(user_info user_info /user_info) sections.append(conversation_history summarize_conversation(conversation) /conversation_history) sections.append(knowledge_base \n.join(compressed) /knowledge_base) return \n\n.join(sections)这个代码已经是高度简化的但展示了核心结构。真实项目中信息采集层往往是异步的压缩优化层会有缓存、并发控制、成本统计等逻辑。但核心思路不会变把上下文组装这件事组件化、流程化。3.3 模式选择器让系统知道现在是哪一种 context-mode在很多实际应用中输入并不会主动声明这是哪种任务。所以我们需要一个模式选择器在运行时判断当前请求适合哪一种模式。我实践下来最可靠的方式是意图分类 规则兜底的双层结构。意图分类层使用一个轻量级分类模型输入是用户当前的问题和最近一轮对话输出是预定义的几个任务类别。因为类别通常只有十几个不需要用大模型做完整推理用小模型甚至简单的关键词规则就能跑出不错的效果。我有一个项目里直接用text-embedding-3-small做语义匹配把用户问题与每个模式的定义向量做相似度比较准确率也到了九成以上。规则兜底层负责处理边界情况。比如检测到用户消息里包含错误、报错、修复这类词时直接强制路由到技术排查模式不再等待分类模型的结果。再比如检测到用户连续多次追问同一个问题就自动切换到深度澄清模式让系统引导用户补充信息。这套双层机制的好处在于模型负责理解语义规则负责兜住硬性场景两者互补异常情况大大减少。模式选择器还有一个非常实际的作用——方便的测试。当模式判断错误时你可以直接看到输入是什么、选择器选择了哪个模式、正确应该是哪个模式。这个反馈回路让模式选择器的改进速度快了很多。相比之下如果你把模式选择和上下文组装混在同一个环节里出了错根本不知道是选错模式还是组装逻辑出了问题。3.4 部署与运行时的关键参数配置context-mode 能否在生产环境稳定运行参数调优比设计架构更费时间。我整理了一份常用的参数配置参考表都是实测得出来的经验区间并不是绝对标准参数项建议范围说明单模式最大上下文预算窗口总量的 60%-75%必须为模型输出预留空间否则生成会被截断知识库检索 top_k3-8 个片段太少漏信息太多引入噪声需要根据片段长度动态调整对话历史保留轮数5-15 轮超过这个范围模型对早期意图的记忆迅速衰减摘要压缩触发长度单来源超过 1500 token 时短文本摘要收益低还可能丢失细节模式切换冷却时间同 session 内 2 轮对话内不反复切换模式频繁切换会让模型失去上下文连贯性向量检索重排数量先检索 top_20再重排取 top_5一阶段直接取 top_5 容易漏掉高相关但词汇不匹配的信息这些参数不是一次性定死的。我一般会在项目上线前跑一轮上下文调试集把典型的用户问题输入进去人工检查模型回答质量。如果出现明显偏差优先调整对应模式的预算分配和检索参数而不是急着改模型或框架。部署时还有一个容易被忽略的点context-mode 的日志。我强烈建议在上线版本中把组装好之后的完整 prompt 落盘保存同时保存一份各信息源实际 token 消耗的统计日志。这些数据对后续优化非常有价值。有了 prompt 日志你才能准确判断模型回答问题的依据到底是什么有了 token 统计你才能知道是不是某个信息源悄悄占了太多预算。很多线上问题光看模型输出根本定位不了看 prompt 日志一眼就明白了。3.5 进阶设计动态上下文刷新与分层记忆基础版的 context-mode 已经能解决大部分业务问题但在 Agent 场景里还需要一个进阶能力动态上下文刷新。所谓动态刷新是指 Agent 每执行一个工具调用系统不是简单地把工具结果追加到上下文尾部而是重新评估当前计划是否仍然有效、哪些中间结果已经过时、下一步还需要哪些新信息然后重新组装一份最新的上下文。这和每次追加一段话的效果差别非常大。前者让模型每一步都基于最新的整体状态做决策后者则让模型逐渐在越来越长的历史里迷失重点。我在做一个多步骤信息整理 Agent 时用过这种方案。Agent 需要去多个系统查数据、汇总、再生成报告。如果只是把每一步查到的结果全部追加到上下文里跑到第三四步时模型就开始忽略最初的用户目标甚至重复执行已经完成的步骤。后来我把采用的分层记忆方式引入了 context-mode短期记忆保存当前步骤的工具结果和临时推算中期记忆保存用户目标与已完成步骤摘要长期记忆保存项目的背景规则。每一步开始前重新组装这三层记忆。效果立竿见影跑十步以上的任务完成率从不到一半提升到八成以上。4. 常见问题与排查技巧实录4.1 上下文溢出明明窗口够大怎么还是溢出很多人以为上下文溢出只会在接近模型窗口上限时发生。实际上在我接触过的项目里不少溢出事故发生在窗口只用了七成左右的情况下。原因通常是组装时没有考虑到模型的输出保留空间也没有考虑到系统提示词和工具定义本身占用的 token。排查思路分三步。第一步看 token 统计日志确认是哪个信息源占了大头第二步检查是否有重复注入比如同一个知识库片段同时被检索和摘要各放了一份第三步看是否存在对话历史重复累积——我遇到过有项目把已经摘要过的历史又原样拼回去了导致 token 翻倍。解决方式也很直接给每个上下文段加上 hash 标记组装时做去重。另外还有一个隐蔽的坑部分模型的上下文窗口统计并不包括预留的系统 token。比如你在 API 参数里设置了max_tokens4096这部分空间是留给输出的不参与输入上下文计算。如果不仔细看很容易把窗口利用率算错。建议修改代码时统一按总窗口 输入上限 输出上限来规划预算不要只看模型的宣传参数。4.2 信息丢失模型回答不知道但知识库明明有这个问题最让人头疼。知识库检索出来的片段确实没错也组装进了上下文但模型还是答不上来或者答错。我排查过多次发现根因通常是三个。第一检索片段与问题的相关性其实不够。向量检索在某些语义表达下表现并不稳定尤其当用户问题中包含很多业务术语或简称时检索结果可能命中一段相关内容但遗漏了更关键的段落。解决方式是引入检索后重排不要直接用 top_k 的原始结果而是用一个重排模型或规则做二次筛选。这个利润提升非常明显。第二上下文组装顺序不合理。如果知识库片段被放在大量无关的对话历史之后模型很可能在长上下文中丢失了对知识库片段的注意力。解决方式是让知识库内容尽量靠近用户当前问题并且用特殊标记强调其重要性。第三信息的表述形式与用户问题不一致。知识库里面写的是90 天内可无理由退货用户问的是能不能退款语义上是同一个事情但字面差异大。模型在短上下文里往往无法做这种推理。解决方式是在知识库预处理阶段做同义改写和 FAQ 对齐把同一类问题的高频表述预先建立索引。4.3 模式切换冲突同一次请求命中了多个 context-mode模式选择器有一个典型问题是冲突用户说帮我看看这个报错是不是因为我配置错了另外顺便说一下之前的订单怎么处理这句话兼顾了技术排查和订单查询两个场景。硬切一个模式必然会漏掉另一个方面。我采用的方案不是非此即彼而是主模式 辅助模式叠加。主模式决定上下文的主体结构辅助模式只允许向上下文额外注入一小段特定信息。比如技术排查是主模式订单查询作为辅助模式就额外注入最近一笔订单的状态信息。这样既不会让上下文变得臃肿又能覆盖用户的复合诉求。叠加信息的总 token 占用被限制在主模式预算的 15% 以内避免喧宾夺主。4.4 模式失效同一个模式在不同模型上表现差异巨大context-mode 的配置有一个隐含假设模型的指令遵循能力足够强。早期我用一个参数较小的开源模型跑模式 A 效果不错后来项目切换成另一个能力更强的模型结果同样的配置反而表现更怪。排查后发现问题出在 system prompt 的措辞上——能力弱的模型对复杂的模式指令理解力差需要把指令拆成非常直白、结构化的句子能力强的模型则会过度理解把一些原本只是提示性的话当成硬性约束。这个坑的解决方式是为同一套模式维护两套 prompt 版本一套是显式指令版用于指令遵循能力一般模型一套是提示引导版用于能力强模型。在模式配置里给每条指令增加一个instruction_strength参数运行时根据当前模型的特性动态调整措辞力度。投入不大效果却非常直观。4.5 性能与成本上下文组装太慢、token 开销太大没有做 context-mode 的系统每次请求都会全部塞满做了模式化之后开销反而可能上升。原因是压缩和检索重排本身也是计算成本。一度我的 RAG 系统因为增加了重排环节单次请求的 p99 延迟从 600ms 涨到 1200ms。我的优化思路按性价比排序。首先做缓存对相同用户问题的检索结果在 5 分钟内直接复用这个优化能覆盖大量重复提问场景。其次做分层检索先用一个快速的粗排模型从库里筛出 top_20然后只对 top_20 做精排精排模型的调用量瞬间减少到原来的 1/10。最后才是考虑换更快的模型或降精度因为前两个方案基本零成本效果已经够用。成本方面摘要压缩如果每次都调用大模型费用确实吃不消。我的实践做法是只在信息源超过阈值长度并且确实需要保留时触发摘要对于一些本来就短的内容直接跳过。另一招是使用成本更低的小模型来做摘要质量损失在可接受范围内但成本降了七八成。5. 一条特殊的进阶经验用上下文自省机制提升模式稳定性在做 context-mode 一段时间后我发现一个更精细的优化方向——上下文自省。具体来说是为每个模式增加一个自省提示让模型在正式回答问题之前先用自己的语言复述一遍它对当前上下文的理解。这听起来会多消耗一点 token但回报非常明确。我常见做法是在 prompt 里增加一小段在回答问题之前请先用不超过 50 个字概括你对当前任务背景的理解以及你从知识库中找到的关键依据。然后要求模型把这段概括放在回答里。这样做有三个好处第一倒逼模型真正读完上下文减少忽视上下文直接生成的情况第二你可以在日志里看到模型对上下文的理解如果概括出现偏差就说明当前模式的上下文组装有问题可以提前发现第三概括本身会定位模型的注意力让后续回答更准确。这个机制在多文档对比和长对话总结两个模式下效果尤其好。有一次用户问两个版本合同之间的差异最开始模型总是只对比开头几页忽略后面几页的关键条款。加了自省机制后它会在概括中列出它关注的篇章范围人工一看就知道模型漏掉了什么进而调整上下文组装顺序。这种模型帮你调试 prompt的思路是我觉得 context-mode 最有意思的地方。顺着这个思路我还做过一个更激进的扩展把自省结果作为下一轮对话的持久化记忆。当用户追问某个话题时系统不是重新组装全部上下文而是把上一轮模型的自省概括和当前问题一起送入上下文。这种方式把长对话的 token 占用大幅降低同时关键信息几乎不丢失。从效果来看这比单纯压缩历史对话更可靠因为它保留的是模型提炼后的高价值摘要而不是原文中可能被埋没的细节。6. 工具选型与生产落地建议6.1 框架选择自研组装逻辑 vs 依赖现成框架市面上有不少 LLM 应用的框架比如 LangChain、LlamaIndex 有内置的上下文管理相关模块。我的态度是可以借鉴它们的思路但最好不要直接依赖那些封装好的高级组件尤其是做生产级应用时。原因很简单框架内置的上下文组装逻辑往往是一个大杂烩为了适配多个场景做了太多抽象的取舍。你真到线上排查问题的时候需要的是对自己代码细节的绝对掌控。我认识不少团队从 LangChain 切换到自研组装逻辑主要原因都是出问题的时候没法调试。context-mode 的核心价值就是可预测、可调试如果这个前提被框架的黑盒破坏了就失去了意义。不过框架本身提供的检索、压缩、向量库封装这类基础能力还是值得用的。我自己是框架做引擎自研做组装的思路——向量检索用现成的库但上下文的模式定义、组装流程、切换决策全部掌握在自己手里。这样既不用重新发明轮子又保留了对核心环节的掌控力。6.2 上下文模式的版本管理与回归测试context-mode 本质上是一个不断迭代的配置体系。随着业务变化你一定会不停调整各种参数和模板。如果不做版本管理很容易出现昨天改了一个压缩阈值今天线上回答质量全面下降但完全找不到原因的情况。我用的是一个很土但很有效的方法每个模式配置对应一个版本号记录在代码仓库里同时在每个 prompt 日志中记录使用的模式版本号。如果线上出现问题直接按版本号回溯配置改动定位速度非常快。回归测试方面我维护了一个标准问题集里面覆盖每个模式下的典型场景、边界场景和负向场景。每次调整模式配置就把这个数据集跑一遍人工检查关键输出指标。这个数据集只需要二三十条问题维护成本很低但收益极大能防止改一个场景弄坏另一个场景的连锁事故。这里有另一个经验回归测试不能只看回答内容还要看token 消耗和是否触发检索、是否触发压缩这类行为指标。比如你调整了 top_k某些问题的回答可能确实变好了但 token 消耗可能上涨了 30%在流量大的场景下这个成本增量可能不可接受。把行为指标纳入回归测试才能做出真正靠谱的决策。