做一个 AI 助手或者 Agent 项目时我踩过最大的坑不是模型选型也不是提示词写得不好而是“上下文”这玩意儿管理得太粗糙。项目做到一半功能全对但只要对话一长模型就开始“失忆”同一次会话里让它先做报表分析再写周报它会莫名其妙把报表数据揉进周报里搞得整个输出变得一团糟。后来我把整个系统的上下文策略重做一遍拆成了明确的“context-mode”——按场景划分上下文可见范围效果立刻不一样了。所谓 context-mode说白了就是给对话系统的“上下文”加一个可切换的模式开关。过去我们习惯把所有历史、所有知识一股脑塞给模型看似省事实际上窗口装不下、token 烧得快、干扰信息还会带偏推理。context-mode 的核心思路是把模型能看到的上下文分成几个档位让每一次请求都只携带当前任务真正需要的那个上下文切片。它适合做智能客服、Copilot 类工具、知识库问答、Agent 编排等任何依赖长对话记忆的 LLM 应用也适合还在纠结“到底该喂多少历史”的开发者参考。这篇文章就围绕我在实际项目里的 context-mode 设计、实现和排障过程展开尽量把每一步背后的依据都说清楚。1. 整体设计思路为什么上下文要“分模式”而不是全量塞给模型1.1 先看清问题上下文不是越多越好很多人对上下文窗口有个误解觉得窗口越大模型就越聪明。这个理解在方向上没错但实际操作中完全不是这么回事。窗口只是“能装多少”模型在生成下一个 token 时理论上会“关注”所有输入内容但注意力的分配是有限的。你塞进去 20 条客服记录里面真正影响回答的往往是最近的两三条其余全变成了背景噪声。如果噪声里恰好出现了某个订单号、某个过期的活动价模型很可能把它当成交付依据直接开始一本正经地胡说八道。我做过一个内部知识库问答助手最初就是把用户的聊天记录和企业文档全部拼在 prompt 里。结果有用户问“我们公司的调休规则是什么”模型一本正经地回答了去年已经废止的旧政策因为检索出来的相关文档片段没做时间过滤而系统又没把“以最新制度为准”这条全局约束放进上下文。这类事故给我一个非常明确的信号上下文不是原料越多越好而是“够用且精准”最好。只有把可见范围收窄到当前会话真正需要的东西模型才能把注意力放在对的地方。1.2 context-mode 的三档划分全局、局部、临时在设计 context-mode 时我参考的是人处理信息的习惯长期记住的东西、当前手上的事情、临时翻出来看一眼的资料三者是分开的。于是我把上下文分成三个档位全局上下文Global跨会话长期有效的记忆。包括用户偏好、项目背景、企业制度、角色设定、固定规则。特点是不轻易变每次请求都要带但要精简。局部上下文Local当前会话最近 N 轮的对话历史。用来承接多轮追问、修正、补充说明。特点是变化快但只影响当前这个会话。临时上下文Transient单次任务执行过程中临时获取的数据。比如调用 API 返回的实时库存、用户当前输入的报销单内容、检索出来的指定文档片段。特点是用完即弃不写入长期记忆。把这三类分开后每个档位对应的 token 预算就可以分别控制。我的项目里全局上下文一般控制在 2k token 以内局部上下文按最近 6 到 8 轮对话滚动临时上下文根据单次任务的实际需要动态分配。这样整体上下文打包量比以前动不动就 10k、20k 的情况健康得多模型回复的稳定性和响应速度都有明显提升。1.3 为什么不做全自动裁剪而是要手动“切模式”有过做搜索系统经验的朋友一定马上会想到能不能做一个自动裁剪上下文模块根据用户问题自动决定带什么历史这个方向我也试过。自动裁剪在简单场景下效果不错比如用户问“刚才那个方案里的数据源是哪里”系统能定位出“刚才”是哪个片段。但一旦涉及多轮任务切换自动判断的准确率就下来了。用户可能在同一个会话里先后聊了三个完全不同的话题系统很难精确判断“当前话题”的边界经常多带一段无关历史或者把修改过的问题当成原始问题来理解。更重要的是全自动方案出了问题以后极难排查。你在 prompt 里看不到任何“当前处于什么模式”的标记一旦模型答错你不知道是裁剪策略错了还是检索漏了还是历史窗口切错了位置。手动切模式虽然多一步操作但带来的收益是可预期、可调试、可回放。就像相机有全自动档但专业的拍摄场景你还是会切到光圈优先或快门优先因为你清楚自己要什么。context-mode 就是给 AI 应用提供的这种“专业档”。切换模式的指令可以来自用户也可以来自业务流程的节点无论如何系统的状态是明确的。2. 核心细节拆解上下文边界、压缩策略与模式切换2.1 上下文边界怎么划分才不容易“串味”这是整个 context-mode 设计里最容易出错的地方。边界不是简单按“会话”来切而是要结合会话、用户、任务三个维度看。会话维度解决的是“最近几轮该带谁”的问题。我用的做法是给每条消息打上会话 ID本地模式只消费同一个会话 ID 下的最近 N 条消息。这里有一个容易踩的坑很多 IM 工具或者前端会把一次页面刷新当成新会话结果用户刚刷新完模型就“失忆”了。我在实现里加了一道合并逻辑如果新会话 ID 在 3 分钟内产生且用户 ID 相同就自动继承上一会话 ID从用户角度看就是无缝衔接。用户维度要解决的是“跨会话的长期偏好该不该带”的问题。全局模式的边界非常适合承载这个。比如一个用户多次使用助手助手逐渐记住了他偏好的报告格式、常用术语、工作角色这些存进全局上下文。这部分的写入要有严格的入口控制不能把所有消息都塞进长期记忆否则全局上下文会越来越臃肿。我采用的策略是只有被用户明确标注“记住”的信息或者系统在会话结束后自动总结出的“长期事实”才有资格写入全局上下文。任务维度则是临时上下文的核心。一次独立的 API 调用、一次文档检索、一次信息查询都属于任务级数据。这类数据不仅不能进全局上下文甚至不应该跨任务残留。比如用户先查了 A 客户的订单再问“B 客户的订单呢”如果临时上下文没有正确清理模型很可能把 A 客户的数据当作上一轮提到的信息来理解这就是典型的“串味”。我通过给每个临时上下文对象绑定任务 ID任务结束时强制丢弃避免跨任务污染。2.2 上下文压缩当历史太长该怎么“瘦身”无论怎么切模式局部上下文里的历史总有超过预算的时候。这时候不能简单粗暴地把最老的消息丢掉——那会导致关键信息莫名其妙消失。我试过三种压缩手法最终的做法是组合使用。第一种是摘要压缩。当会话超过预设轮数后把前半段对话交给模型做一次总结提炼出“已完成事项、用户偏好、待办事项、关键数值”四个字段保存成结构化摘要。后面的对话如果还需要此前的事实模型读摘要就够了。这里的关键是摘要提示词要足够目标导向我常用的模板是“将以下对话压缩为任务事实清单只保留会影响后续回答的事实去除所有寒暄、重复和过程性描述。”摘要后必须再由程序校验关键字段是否存在防止模型漏掉重要数据。第二种是结构化提取。有些对话本身就是为了收集结构化信息比如客服在收集用户的姓名、地址、需求描述、期望时间。这类信息如果压成自然语言摘要后续读取效率不高。我在项目里直接维护一个 JSON 状态字段对话每进行一轮就尝试更新这个 JSON。查询时把 JSON 当作上下文的一部分传入比塞整段对话占用更少 token且信息更稳定。第三种是向量召回。对于确实需要在很长的历史里翻找某段内容的场景摘要会丢失细节结构化提取又覆盖不了所有自然语言信息。这就要靠向量化每个会话的每轮消息都异步写入向量数据库本地模式在组装上下文时先用当前用户问题做检索召回最相关的 3 到 5 条历史片段。这套方案虽然引入额外依赖但在长会话场景里非常值得它的召回精度直接决定了模型的“记忆力”。2.3 模式切换时的交互与状态记录模式切换本身也要做成有状态的操作。我的系统支持用户通过前导命令切换也支持内部业务逻辑自动切换。前导命令的设计尽量简单我给用户开放的是“/ctx global”“/ctx local”“/ctx transient”三条指令含义一目了然。切换完成时系统会返回一条提示告诉用户当前已经进入什么模式、哪些上下文会被加载、哪些不会。这条提示本身也会放进新会话的上下文里让模型明确知道自己当前处于什么模式。这里有一个值得注意的细节切换模式的瞬间上一个模式里产生的上下文不能直接丢。比如用户从 local 模式切回 global 模式如果 global 模式不带任何历史模型会突然“断片”。我的做法是在切换时生成一份“交接摘要”把之前对话中最重要的三条事实带进新模式。这就像换工作岗位时的交接文档不需要把所有聊天记录都带过去但必须把关键进展讲清楚。在状态记录层面每个请求的日志里都必须包含模式字段这是后面排查问题的重要线索。我会记录“请求进来时的模式”“实际加载了哪些上下文片段”“每个片段的 token 数”“模型回复里是否包含超出当前模式范围的信息”。这套日志做下来排查上下文异常的效率能提升一大截。3. 实操落地context-mode 的核心实现细节与示例代码3.1 模式数据结构的清晰定义下面给出我在实际项目里用过的核心数据结构代码不长但边界划分要靠它撑住。# context_mode/models.py from enum import Enum from dataclasses import dataclass, field from typing import Optional, List, Dict class ContextMode(str, Enum): GLOBAL global LOCAL local TRANSIENT transient dataclass class ContextPackage: mode: ContextMode system_prompt: str history: List[Dict] field(default_factorylist) memory_prompt: Optional[str] None # 全局长期记忆 transient_data: Optional[str] None # 临时任务数据 token_budget: int 8192 # 当前请求的上下文预算 session_id: str task_id: str property def used_tokens(self) - int: # 真实项目里可以用 tokenizer 计算这里用粗略估算 return len(self.system_prompt) len(self.memory_prompt or ) len(self.transient_data or )注意这里有个小细节token 预算不是固定的不同模式可以给不同预算。Global 模式因为要跨会话常驻预算要控制得比较紧Transient 模式下因为要容纳临时查询结果可以给更大的预算。我在配置文件里维护了一张“模式预算表”而不是在代码里硬编码这样调参不用改代码。3.2 上下文构建器的实现逻辑上下文构建器的职责很单纯根据模式把各个来源的内容组装成最终发送给模型的 prompt。听起来简单但组装顺序很讲究。系统提示词在最前面然后是全局记忆接着是任务指令最后是历史对话或临时数据。这个顺序是模型最习惯的阅读结构。# context_mode/builder.py from context_mode.models import ContextMode, ContextPackage class ContextBuilder: def __init__(self): self.global_prompts { assistant_role: 你是一名资深业务助理回复要简洁、准确、有依据。, user_profile: 用户偏好使用表格化的输出格式。, } def load_global_memory(self, user_id: str) - str: # 实际项目从数据库读取长期记忆这里返回拼接结果 return .join(self.global_prompts.values()) def build(self, request, package: ContextPackage) - List[Dict]: messages [{role: system, content: package.system_prompt}] if package.mode ContextMode.GLOBAL: messages.append({ role: system, content: f[全局上下文]\n{self.load_global_memory(request.user_id)} }) elif package.mode ContextMode.LOCAL: messages.append({ role: system, content: f[局部上下文] 只加载当前会话最近 {self.max_local_rounds} 轮对话 }) recent_history package.history[-self.max_local_rounds:] messages.extend(recent_history) elif package.mode ContextMode.TRANSIENT: messages.append({ role: system, content: f[临时上下文] 以下是当前任务数据用完即弃。\n{package.transient_data} }) messages.extend(package.history[-2:]) # 临时模式只保留最近两轮 return messages实际运行中我还会在组装完成后做一次 token 估算如果超出预算优先裁剪历史轮数其次裁剪临时数据最后才裁剪全局记忆。这个优先级是刻意的全局记忆一旦裁剪影响的是所有后续请求历史少一两轮影响范围小得多。如果你在做类似功能建议把这个裁剪优先级也明确写出来否则程序在触顶时往往会选择最省事的处理方式——直接丢掉临时数据这反倒会让当前任务的完成质量大打折扣。3.3 一个真实场景三种模式下的回答对比这里用一个企业知识库客服的例子来跑一遍。用户问的是同一个问题“我昨天提交的报销什么时候能到账”但三种模式下的结果完全不同。Global 模式下模型能读到“该用户是高级成员报销通常优先处理”这类长期画像但读不到昨天的具体对话内容。所以回答是“根据您的身份报销会优先处理一般 3 个工作日内到账。如需查询具体进度请提供报销单号。”这个回答虽然不够具体但足够稳定。Local 模式下模型能看到最近几轮对话。假设用户之前已经说了“编号 EXP-2025-001”那模型就能准确回答“编号 EXP-2025-001 的报销目前显示已进入财务审核环节预计明天到账。”这种模式下模型表现得像“记得我刚刚说过的话”体验最好。Transient 模式下临时数据里塞了从财务系统实时查到的报销状态模型回答时会直接基于最新数据“EXP-2025-001 已于今天 14:23 完成打款请您查收。”但它不会去预测全局规律也不会依赖历史。这就是三种模式各司其职的样子。3.4 在现有应用里集成 context-mode 的最小改动如果项目已经上线不想大改架构那可以用“请求拦截 字段注入”的方式做渐进式接入。第一步在网关或对话服务入口处维护一个 mode 字段默认值可以是 local因为大部分多轮对话都属于局部上下文场景。第二步接一个前置处理器只负责根据 mode 加载对应的上下文片段然后把这些片段注入原始请求的 messages 里不改动下游任何逻辑。第三步把模式切换入口暴露成一个内部接口业务层在合适时机调用。这套最小改动方案的核心价值是低风险。你不需要一上来就重构对话核心只需要在入口处加一道“上下文装配层”。等跑顺了再把全局记忆的写入策略、临时数据的自动清理等功能逐步加上去。我自己的项目就是这么一步步演进过来的前后大概花了两周没有阻塞任何正常功能上线。4. 常见问题与排查技巧实录4.1 真实排障记录四类高频问题与解法第一批典型问题基本都出现在模式切换的边界上我整理成了一张速查表。现象根因处理方法切到 global 模式后模型忘了用户刚才说过的需求global 的上下文包根本没带历史交接摘要没生成切换时强制生成“交接摘要”把最近三条关键事实写入新模式的上下文中local 模式下历史轮数用的是固定值对话稍长就超出窗口滚动窗口没有按实际 token 做预算控制把“最近 N 轮”改成“最近 N 轮且总 token 不超过 X”按预算动态截断transient 模式下临时数据频繁串到下一任务临时上下文对象被复用任务结束后未清理任务结束时显式调用清理方法并把 task_id 校验作为读取前置条件全自动上下文裁剪时好时坏很难排查系统没有记录每个请求实际加载了什么上下文给每次请求打上“上下文快照”日志复现问题时先看快照这其中最难排查的是第三类临时数据串任务。表面上看模型答错了某个数值你以为是不稳定实际是上一任务的临时数据残留在了当前请求里。这种问题在纯对话模型时代不太明显因为对话历史天然线性但一旦引入任务编排、多工具调用任务边界的清理就必须成为一等公民。4.2 参数与策略调优的几条经验调优不要靠感觉要有个可观测的闭环。我在项目里做了三件事一是给所有上下文组装过程加了 token 计数日志每次请求都记录各段的 token 占比二是把模式切换事件、压缩事件、检索事件统一写入事件流方便回放三是对回复做了一次简单的“范围一致性检查”如果模型回复里出现临时上下文里才有的数据而在当前模式下不该出现就标记为异常。在这个基础上我有几个比较实用的参数建议。局部模式的滚动窗口一般不要超过 8 轮如果发现超过 8 轮还在反复引用早期信息优先考虑是不是该把某些事实提炼进全局记忆。临时模式的检索 top_k 控制在 3 到 5 之间太少了容易缺依据太多了噪声会把依据稀释掉。全局记忆的更新频率不要太高每 10 次会话结束后的总结写入一次就好频繁写入会让长期记忆变得不稳定。4.3 几个越用越稳的隐藏窍门最后分享几个不太会写在文档里的窍门。第一模式状态的持久化要做在服务端而不是前端。用户刷新页面、切换设备服务端依然记得他处于什么模式。如果只存前端用户换个设备就回到默认模式体验会断层。第二global 模式里维护的“用户画像”要分事实和推断两层。用户自己说的“我现在是产品经理”是事实系统根据行为推断出的“此用户偏好简短回复”是推断。事实层可以直接进上下文推断层必须经过用户确认否则一旦推断错误模型会在一长段时间内带着错误画像回答所有问题。第三压缩摘要不要只存一份可以按时间分桶。比如每周生成一份摘要合订本是日积月累的事实当天生成一份细粒度摘要用于即时调用。分桶处理能让长期记忆和短期记忆互相之间不打乱。5. 最后想说的一些打磨体会用 context-mode 这套思路重构系统之后我最大的感受是AI 应用的稳定性很多时候不取决于模型的聪明程度而取决于你给它划定的关注边界。把上下文管理从“塞得越多越放心”转变成“分模式精准投喂”看起来是技术方案上的取舍本质上是在帮模型排除干扰让它把注意力放在真正重要的事实上。每次做这类优化我都会提醒自己一个经验无论设计多么优雅的模式最终都要通过日志和可观测性来验证它真的在起作用。模式切换的命令、压缩动作、临时数据的进出每一步都值得被记录。这些记录不只是为了排查问题更是为了下一次调整策略时能拿出依据而不是凭感觉改参数。如果你也在做类似的 LLM 应用不妨先从 local 模式开始试等稳定了再逐步把 global 和 transient 模式的细节补上。这个路径不算复杂但每一步都值得认真对待。