做AI应用开发的同学一定经历过这种时刻AI明明很聪明却在长对话里突然“失忆”或者把上一个任务的旧信息硬塞进当前回答里。我前阵子在做企业内部问答助手时被这类问题折磨得不行最后把上下文管理单独拎出来做了一个小模块名字就叫context-mode。这篇文章是那个模块从设计、编码到踩坑的完整复盘。context-mode解决的核心问题用一句话说清在同一个AI助手/Agent里按场景决定“让AI记住多少、读取多少、忘掉多少”。它不碰模型参数不做微调纯粹靠上下文工程的规则和流程把交给模型的材料控制好。如果你正在做RAG、智能客服、代码助手、Agent编排或者只是好奇为什么大模型应用聊天久了会变笨这篇都值得往下看。1. 先别急着写代码拆解context-mode要解决的真实需求1.1 一个真实的翻车案例我接手的项目是给运营团队做的一个AI数据助手。运营同学的习惯是在一个会话里连续问几十个问题先问上周转化率再让AI写一段广告文案接着又让对比两个渠道的ROI。表面上看这很自然但对模型来说这三个任务全被塞进了同一个上下文窗口。模型并不知道哪个是当前重点于是经常出现“写文案写到一半突然还在念叨转化率数字”这种串味现象。更离谱的一次运营同学先问了A渠道的数据隔了十分钟问B渠道时AI居然还引用A渠道的结论理由是“根据之前的分析”。运营同学觉得AI不聪明但我心里清楚问题不在模型智商而在上下文根本没有边界。这个案例给了我一个很直接的启发AI助手不能只有一个“全记住”状态它需要能根据任务切换读上下文的方式。这就是context-mode的起点。1.2 上下文的三个失控方向成本、精度、隐私把问题进一步拆开上下文失控其实表现在三个维度上。第一是成本失控。对话越长每轮调用携带的历史内容就越多token费用直线上升。一个100轮的会话如果每轮都带着全部原文聊天记录可能轻松消耗几万token而且其中大部分在单轮问答里根本没用到。第二是精度失控。Transformer架构下有个被反复验证的现象叫lost in the middle模型对长上下文里开头和结尾的内容记得最牢中间区域容易被忽略。你把历史全部塞进去看起来是“信息量足”实际上模型根本读不仔细。噪音越多关键信号越容易被稀释。第三是隐私与合规失控。运营助手会接触到财务数据、客户信息、合同摘要如果这些历史内容被无关的后续任务读取就会产生越权访问的风险。上下文不应该始终“全员可见”必须可以有条件地关闭。1.3 解法不是“更多上下文”而是“按需切换”当时我们调研了一圈结论很清晰治理这个问题不能靠加大模型窗口而要靠工程手段划分上下文边界。就好比人的工作记忆写代码时你不会时刻想起昨天开会的每一句话切到写文档时脑子里又是另一套信息。人脑尚且有注意力的切换AI助手更应该主动管理自己的“工作记忆”。所以context-mode的核心理念就是一句话每个任务只让它看到自己该看的上下文。要么全量检索要么锁定范围要么干脆忘掉重来。基于这个理念我设计了三种模式对应三种典型交互场景。2. 模式设计三种context-mode的选型逻辑2.1 Full Mode全量检索适合开放对话Full Mode是最接近普通聊天机器人的模式。它的定义是模型可以读取当前会话的历史记录并在需要时从知识库检索相关内容来补充回答。但这里有个重要细节Full Mode不等于把原文全部塞进prompt。我实际做的是“滚动窗口分层摘要向量检索”三件套的组合最近20轮原文完整保留20轮之前的历史被压缩成摘要每次用户提问时用问题去向量库检索top-k相关片段。为什么这么设计因为如果全量原文都塞进去很快会超出窗口上限。Full Mode的本质是“摘要保底检索补充”保证模型在开放对话中既不丢失大局又能抓到细节。它适合开放闲聊、跨任务连续对话、头脑风暴这类没有硬性边界的场景。2.2 Scoped Mode锁定范围适合任务型交互Scoped Mode是我整个模块里后期用得最多的一个模式。它的设计思路正好和Full Mode相反先划定范围再读上下文。具体来说调用方需要显式传递一个scope参数。比如“只看order-service仓库的order_service.py和order_worker.py”或者“只针对营销活动A的数据分析结果回答”。服务端拿到这个scope之后从历史存储和知识索引中只提取属于这个范围内的内容来构造上下文。我认为这个模式才是真正的“项目感”所在。因为在内部工具里用户绝大多数时候是有明确目标的改某个模块、分析某份报表、查某个Bug。目标一旦明确上下文就该被锁死防止无关历史串门。Scoped Mode适合代码生成、定向问答、数据分析这类任务。2.3 Reset Mode主动失忆适合敏感场景Reset Mode是最容易被人忽略、但价值极高的一种模式。它的定义很简单当前这轮调用完全不携带任何历史上下文只保留系统提示词和用户当前输入。有人觉得这太“笨”了AI什么都记不住还怎么用但实际场景中它非常有用。比如你处理一批独立的临时请求每条消息之间没有逻辑关联再比如你在公共终端上让AI处理一段敏感文本你根本不想让上一次处理的内容残留在模型输入里还比如Agent系统里某个子任务需要“外包”给一次独立调用如果它继承了父任务的全部历史反而容易被噪声干扰。这里需要强调一个容易混淆的点Reset Mode不等于删除存储。会话历史仍然在后台保留只是在构造prompt时不读取让模型在“不知情”的状态下处理当前消息。2.4 模式决策表什么时候用哪种我在项目落地时做了一张决策表团队后来讨论需求时直接拿它对照选用效率提升不少场景推荐模式核心理由开放闲聊、头脑风暴、跨任务连续对话Full需要最大范围的背景信息修改指定文件、分析特定报表、查具体BugScoped上下文边界清晰避免串味一次性处理、敏感数据操作、公共设备Reset不需要历史且必须防泄露长会话但任务边界中途发生变化Full并显式标记切换点摘要兜底检索补充旧的让位给新的Agent子任务之间互相独立Reset隔离上下文防止任务间干扰多步Agent流程内部分工Scoped每个子Agent只接触自己负责的上下文切片这张表不一定适用于所有业务但它背后的逻辑值得参考先判断任务的边界感强不强再决定上下文开放程度。3. 核心实现一条上下文管线拆开讲3.1 管线总览从输入到prompt的五个环节把三种模式落地成代码我抽象出了一条固定的上下文处理管线。它和大家熟知的RAG管线有些像但多了模式判断和状态管理这一步消息进入 - 模式判断 - 上下文采集 - 预算裁剪 - prompt组装 - LLM调用 - 异步回写模式判断在第一环节因为后续所有操作都依赖这个决定。比如Reset模式下上下文采集直接跳过Scoped模式下采集器必须带上scope过滤条件Full模式下才需要走完整的“摘要滚动窗口检索”流程。预算裁剪是给采集来的原始内容做减法。因为即使按模式取了内容也可能超出模型窗口限制。最后一步的异步回写负责把新的对话内容更新进历史存储和摘要层让下一轮调用可以基于最新状态工作。3.2 上下文采集层分层存储与生命周期实现时我设计了四层存储各司其职会话消息表保存完整原始消息这是唯一不会丢信息的层摘要层按时间窗口或轮次生成会话摘要供Full Mode使用知识索引层面向文档、代码、报表内容做向量化索引供检索使用热缓存层把最近高频使用的上下文装配结果缓存起来降低延迟。摘要层我采用的是分层摘要策略。具体来说就是先在本地按每20轮消息生成一个初级摘要再在需要时对多个初级摘要做二次合并形成更上层的概览。这样既能控制摘要粒度又能在追溯时定位到具体轮次。关于生命周期我的原则是“原始消息留足、摘要层常更新、缓存层设短过期”。原始消息是保底资产摘要算错了可以重新生成摘要层必须随会话推进异步更新不能等用户提问了才算缓存层一般设置10到15分钟过期防止上下文已经变化还返回旧装配结果。3.3 摘要器与检索器压缩和召回如何配合摘要器和检索器在管线里是互补关系。摘要器负责把长历史“压薄”检索器负责从知识库里“捞准”。实现摘要器的关键点是保真度。我第一版用的一句话总结太暴力经常把关键数字吞掉。后来改成一版结构化的摘要指令要求摘要必须保留所有数字、日期、文件名、接口名和实体关系并在产出之后做一次实体覆盖率校验。简单说就是从原文随机抽取若干关键实体去摘要里查它们是否还在低于阈值就强制重新摘要。检索器方面我采用了双路召回加RRF融合一路走向量语义检索一路走BM25关键词检索再把两路的top结果按倒数排名融合Reciprocal Rank Fusion得到最终列表。这样既不会漏掉语义相关的说法也不会漏掉精确关键词命中的情况。这里有个工程红线Scoped模式下检索操作必须发生在过滤之后而不是召回之后再过滤。否则全局索引会把范围外的内容先捞回来即便你后面把它删掉排序分数已经污染了。3.4 Token预算分配一个可落地的公式采集完上下文后如果内容超长就需要按预算裁剪。我用的分配公式不复杂可用预算 B 模型上下文上限 - 输出预留 实际占用 系统提示词S 历史摘要H 检索片段K 滚动窗口W我的分配比例参考是系统提示词固定占最小头历史摘要默认不超过30%检索片段默认40%滚动窗口默认30%。当模型需要生成较长内容时输出预留就要调大比如从8k调到16k相应压缩历史和检索的比例。举个例子一个128k上下文的模型输出预留8k可用预算就是120k。其中系统提示词1.5k历史摘要约35k检索片段约48k滚动窗口约35k。如果实际采集不到这么多内容剩余预算就留白不硬塞历史。宁可让模型“少看一点”也不能让它看一堆噪音。3.5 最小可运行代码骨架我用Python写了一份极简但逻辑完整的骨架代码核心逻辑大概长这样from enum import Enum from dataclasses import dataclass from typing import Optional class ContextMode(Enum): FULL full SCOPED scoped RESET reset dataclass class ContextRequest: message: str mode: ContextMode ContextMode.FULL scope: Optional[dict] None session_id: Optional[str] None def assemble_context(req: ContextRequest, store) - str: if req.mode ContextMode.RESET: return if req.mode ContextMode.SCOPED: return store.query_history(req.session_id, scopereq.scope, limit20) summary store.get_summary(req.session_id) recent store.query_history(req.session_id, limit20) retrieved store.search(req.message, top_k8) return f[摘要]\n{summary}\n[最近记录]\n{recent}\n[检索片段]\n{retrieved} def trim_context(context: str, budget: int) - str: if len(context) budget: return context return context[:budget]这段代码省略了存储实现细节但你可以看出模式判断如何控制数据流向。assemble_context是个纯函数输入模式和存储对象输出字符串非常容易单元测试。我强烈建议你的生产代码里也把这一层拆成纯函数后面你会发现在测试和排查时它帮了大忙。4. 实操过程从接口定义到联调落地4.1 第一步把模式变成API参数接口设计上我把context_mode作为必填字段同时加了一个可选的context_scope。请求体大致长这样POST /v1/chat { message: 帮我看下order模块这段代码有什么问题, context_mode: scoped, context_scope: { repo: payment-service, files: [order_service.py, order_worker.py] } }服务端接收后先校验scope里的路径是否都在白名单内避免有人传入不该暴露的目录。这一步既是功能要求也是安全要求。如果scope非法直接返回参数错误而不是默默降级成全量模式。我特别想提醒一点context_mode不要设计成可选字段并默认Full。因为一旦默认是Full调用方就会偷懒不传Scoped和Reset就形同虚设。强制必填逼着调用方想清楚这次交互到底是什么任务长期来看对系统健康很有帮助。4.2 第二步模式状态机的流转模式的切换需要状态管理。最朴素的做法是给会话记录加一个current_mode字段每次请求带着目标模式进来服务端比对后决定是否更新。但这里有个隐蔽的坑模式切换后如果不做任何标记命中缓存的概率很高而缓存里的上下文还是旧模式的。用户明明切到了Reset模型却可能因为缓存命中继续读到老历史。我的解法是引入一个context_version字段。只要模式或scope发生任何变化这个字段就加一。缓存key把context_version带进去f{session_id}:{mode}:{context_version}:{model_name}。这样模式一变旧缓存自然失效不会串味。另外状态机的流转路径上我没有做任何限制。Full可以切ScopedScoped可以切ResetReset也能切回Full。每一次切换只要触发context_version更新即可。限制太多反而会让前端和产品同学在边界情况里抓狂。4.3 第三步用“记忆隔离测试”验证切模式没串味我在这类系统上最怕的Bug就是“切了模式但上下文没换”。为了能自动发现这种问题我把测试重心放在prompt组装结果上而不是模型输出上。因为在测试环境里调用真实LLM又慢又贵而且输出有随机性。但assemble_context是纯函数给它喂不同的模式直接断言返回的字符串又快又稳定。具体写了三组用例Full模式下先给会话注入A项目的对话记录断言装配结果包含A项目内容切到Scoped模式scope指向B项目再调用assemble_context断言返回的字符串中不包含A项目内容切到Reset模式断言返回的字符串为空或者说只剩当前消息前缀。第三组用例看起来简单但当时确实救了我一次。有一种情况是system prompt里被写过全局上下文导致Reset模式下依然有历史痕迹。测prompt纯函数就能把这个隐患暴露出来。4.4 实测效果三组数据说话联调完成后我用一组模拟的运营对话数据做了对比测试方向就是衡量不同模式下prompt尺寸和调用延迟的变化。数据是近似值但趋势很说明问题处理方式100轮会话平均每轮token预计每次调用费用系数首token延迟感受全量历史原文直接塞25k左右高明显偏慢Full模式摘要窗口检索8k到12k中明显改善Scoped模式锁定范围5k上下较低流畅Reset模式无历史2k以内最低最快费用系数我不在这里贴具体单价因为各家模型和渠道差异太大了。但数量级大家可以自己套上一轮原发的全量请求如果花1块钱Scoped可能只需要两毛Reset甚至不到一毛。对高频内部工具来说这是肉眼可见的成本节省。5. 踩坑记录与排查速查表5.1 模式切换后旧记忆“诈尸”了这是上线后第一个被运营同学抓到的BugScoped模式回答到一半突然引用了一个根本不在范围内文件的函数名。排查过程让我印象深刻。先抓了线上prompt发现prompt里的检索片段部分几乎没有scope过滤痕迹。后来定位到问题发生在缓存层旧的Full模式上下文被缓存了新的Scoped请求命中了同一个缓存key把旧内容原封不动拿了过来。这就是我前面说context_version的由来。修复方法是所有涉及上下文的缓存key必须带上模式标志和version并且模式切换时强制使旧缓存失效。不要依赖“缓存过期时间”兜底那是一种侥幸心态。5.2 摘要压缩把关键数字吞了摘要器初版有个严重的问题压缩得太猛。100轮对话压成一大段概述后里面“转化率3.2%”“上周四的订单量下降了15%”这类关键信息全都不见了。模型回答时就只能说“根据历史数据趋势比较平稳”等于没说。后来我调整摘要指令明确要求保留全部数字、日期、文件名、接口名。同时加了实体覆盖率校验从原始对话里随机抽出20个关键实体检查摘要里是否都能找到覆盖率低于90%就重写摘要。上线后这类“说废话”的现象明显减少。5.3 Scoped模式下漏进来外部内容另一个高频问题是scope过滤失效。指定了只看order_service.py但模型回答里依然出现user_service.py的内容。刚开始我以为是向量检索的top-k飘了后来查代码发现检索器是先在全量索引里召回再根据scope做过滤。这样的顺序设计会导致排序分数被范围外内容污染即便过滤本来应该排在前面的范围内内容很可能已经被挤出了top-k。修复方案是把scope下推成检索服务的前置过滤条件让向量检索在正式召回前就限定文件路径前缀。同时给prompt里每条检索片段标注来源文件方便出问题时直接追溯。5.4 高并发下上下文缓存被冲垮有一次发布新版本后线上出现了大量超时告警。原因是摘要更新逻辑写在了请求链路的同步部分某个session的上下文摘要需要重新生成时所有指向这个session的请求都在等同一个摘要任务完成。后来我把摘要更新彻底改为异步请求链路只读取已有摘要不等待生成结果。如果摘要不存在先用滚动窗口顶住摘要由后台任务队列生成生成完再回填。这个改动看似简单却直接把接口的P99延迟降下来了。5.5 排查速查表把这段时间踩过的坑整理成一张速查表方便后续同学快速定位症状可能原因排查方法解决方案切换模式后仍读到旧内容缓存未失效prompt组装读取旧装配打印实际prompt检查缓存key引入context_version强制失效摘要后关键数字丢失摘要比例过大实体保真度不足随机抽取实体做覆盖率校验摘要指令强制保留关键实体Scoped范围外内容泄漏过滤在召回之后执行查看检索片段source字段过滤条件下推到召回之前Reset模式token依然高system prompt里嵌入了历史抓prompt前300字符历史挂载只能发生在模式判断之后高并发时超时同步生成摘要阻塞请求看耗时集中在哪个环节摘要改为异步队列更新切Scope后回答不变前端没传scope服务端用了默认值看请求日志里的context_scope字段强制校验scope缺失即报错这张表不只是排查工具更像是我和AI应用对手打架半年的“病历本”。遇到类似症状时先查表往往比翻日志更快。6. 最后聊几句个人体会这个context-mode模块做下来我最大的感受是上下文模式并不是一个多么高大上的算法它本质上是工程上的职责边界。模型本身没有边界感你给它什么它就用什么你不给它边界它就自己胡乱关联。我们要做的是把任务边界用代码清晰表达出来让每一次调用都知道自己“应该知道什么、不应该知道什么”。另外一点如果让我重来一次我会从第一天就把prompt组装写成纯函数并配套测试而不是先接好模型再回头补测试。纯函数化带来的收益在后期的Bug排查中几乎是无价的——你能直接对字符串做断言而不用对着每次结果都不一样的模型输出猜来猜去。这个经验我建议所有做LLM应用的朋友都记住先让你的数据管线可测试再让它变智能。