提到context-mode很多人的第一反应可能都不一样搞 Android 的会想到 Context 对象做操作系统的会想到进程上下文做前端的甚至会以为是什么框架里的新名词。但在 AI 应用和智能体开发领域context-mode 其实指向一个非常具体、也非常要命的问题如何在有限上下文窗口里让模型始终拿到当前最需要的那部分信息并且在不同任务场景下自动调整信息组织方式。我做 AI 应用也有一段时间了踩过的坑不少。早期最典型的问题就是把所有对话历史一股脑塞给模型结果 token 超限报错后来改成粗暴截断模型又像失忆一样聊着聊着就把前面用户提过的关键需求忘了。真正开始系统地做 context-mode也就是给上下文管理引入模式这个概念之后这些问题才逐步收敛。这篇就从一个项目实践的角度把 context-mode 的完整设计和落地方案拆给你看。1. context-mode 到底是什么先厘清概念边界1.1 它不是内存指针也不是进程状态先说一个容易混淆的点context-mode 不是你查资料时经常看到的上下文切换context switch也不是 Linux 内核里的 task_struct 那些东西。在 AI 应用开发这个领域里context-mode 的核心含义是根据当前任务的类型和目标对上下文的内容、数量、结构、优先级施加不同的管理策略。举个简单的例子。同样一个 AI 客服机器人用户问帮我查一下昨天订单的物流状态和用户问我之前反馈过一个售后问题现在处理到哪一步了这两个场景需要模型看到的上下文是完全不同的。第一个场景模型需要的是当前订单信息 物流接口返回的最新数据第二个场景模型需要的是历史会话里用户描述的售后问题 工单系统里流转到哪一步的状态。如果把两种信息都混在一起塞进模型的上下文窗口就会出现几个问题一是无关信息占据 token 预算关键信息反而可能被截断二是模型面对冗余信息回答的稳定性会明显下降三是对应用来说每次请求都全量携带历史成本直线上升。context-mode 干的事就是把这团乱麻拆开。它定义了几套不同的上下文组装规则每一套规则针对一类任务场景。系统根据当前请求的语义或用户操作自动选择匹配的规则来组装上下文。这个选择规则 组装上下文 动态调整的完整流程就是我理解的 context-mode 的实质。1.2 从对话系统到智能体为什么上下文一定要有模式很多初学者会有个疑问我做一个聊天机器人直接把 messages 数组传给模型不就完事了吗为什么要搞这么多模式这里要分两个层面回答。第一个层面需求本身是分层的。一个只做你问我答的单轮工具确实不需要多复杂的上下文管理。但只要你涉及多轮任务型对话、涉及代码生成、涉及数据分析、涉及跨系统工具调用上下文就不再是单纯的历史消息了它还包括知识库检索片段、工具返回值、用户偏好记忆、系统提示词、中间推理结果等等。这些信息性质完全不同用途也完全不同如果统一对待效果必然打折扣。第二个层面上下文窗口是有物理上限的。模型允许的 token 数有限而任务需要的信息往往远超这个限制。这就逼着你必须在保留什么、压缩什么、舍弃什么之间做决策。既然要做决策就一定需要一套规则。而规则针对不同的任务场景天然就会分化成不同的模式。我后来设计的 context-mode 就是按这个逻辑来的核心思路是先定义模式再为每个模式设计独立的上下文装配管线。在工程实现上它有点像一个用于多类任务场景的上下文路由中枢——你给它一个 query它帮你决定走哪条装配管线最后产出一份干净的、给大模型使用的上下文。1.3 用生活类比理解它如果还是觉得抽象可以把它类比成一个厨师的工作台。一个合格的厨房不会把所有食材都堆在厨师面前而是分成几个台面备菜台放洗好切好的原料冷藏台放需要保鲜的食材出餐台放即将下锅的东西。context-mode 就是厨房里的那几个台面——它规定了什么信息放什么位置、什么时候用、用多少。这个类比能解释很多设计决策。比如为什么检索信息和高频偏好信息要分开存放因为它们的更新频率不同优先级不同有效期也不同。比如为什么严格模式下要限制指令的数量因为你不能把十个厨师同时塞进一个灶台指令越多模型越容易互相干扰。2. 模式拆解我实际用到的四种 context-mode2.1 Strict Mode严格模式给任务一个干净的起点严格模式是我用得最多的模式特别适合那种目标明确、不需要太多历史包袱的单次任务或开头阶段。在这种模式下上下文主要由以下几部分组成系统提示词只保留与当前任务直接相关的指令部分用户当前输入的内容少量必要的信息片段比如当前时间、用户 ID极少的对话历史通常只保留上一轮。我之前做过一个合同审查助手排查时发现它最大的问题不是模型能力不够而是对话历史里塞了太多早期无关交流导致模型抓不住当前这份合同的焦点。改成严格模式之后每次审查请求都只带本次上传的合同文本 审查规则 当前轮次用户要求错误率直接降了一半以上。不过严格模式也有代价它不适合需要连续推进的复杂任务。你要是让它从头到尾维护一个多阶段项目计划严格模式会因为上下文太薄出现失忆——模型不是不知道之前的决定而是它的注意力被当前输入的碎片信息占满了。2.2 Balanced Mode平衡模式多轮任务的默认选择平衡模式是我在智能客服和多轮任务型对话中最常用的配置。它要解决的问题是既要保留关键的对话历史又不能被历史淹没。它的装配规则大致是系统提示词 工具定义与当前问题相关的知识库检索结果如果有对话历史按相关性排序取总分最高的一部分而不是简单取最后 N 轮用户当前输入。关键点在于按相关性排序这步。我在项目里实现了一个轻量评分函数每一轮历史消息先判断它是否包含当前 query 里的关键词再看它所在的位置距离当前轮次有多远两者加权得到一个相关性分然后按分值从高到低截断。从效果看这种策略比简单取末尾 N 轮的方式在长会话场景下能提升不少命中率。2.3 Retrieval Mode检索增强模式让知识库真正派上用场检索增强模式专门用于知识密集型任务比如内部文档问答、售后问题排查、政策解读。它的核心不只是把检索结果加进上下文而是对检索结果做二次加工和排序。我踩过的坑是早期直接把向量搜索返回的前 N 条文本拼接丢给模型。结果模型经常被低相关度文本带偏或者因为重复信息增多而出现幻觉。后来在 context-mode 的检索分支里加了重排序rerank环节把候选文本按更精确的模型再打一次分只保留分数最高且互补性最强的几条效果才有明显变化。另外检索模式还必须处理检索不出结果的情况。我在系统里给这种情况预设了兜底回答模板避免模型自己编造知识库内容。这也是很多人容易忽略的一个安全隐患如果检索模块没返回内容而上下文装配逻辑又把空白结果当作正常数据传给模型模型的幻觉概率会急剧上升。2.4 Slim Mode极简模式给高并发低延迟场景准备的极简模式适合那种对响应速度要求极高、逻辑相对固定的场景比如快速判断意图、实体抽取、简单分类等。它几乎不携带历史上下文只包含最小化系统指令和当前输入。这套模式牺牲了一定程度的智能性换来的是成本和速度的显著优化。在我实际开发的一个路由系统里先用 Slim Mode 做一个 query 分类把是否需要查知识库这件事判断出来再决定是否切换到别的模式整体响应速度提升了近一倍。这种先用小模型判断再用大模型处理的分层设计成本优化效果非常明显。3. 核心设计与实现一个可运行的 context-mode 上下文管理器3.1 系统整体结构我实现的 context-mode 上下文管理器核心模块分四块模式路由、上下文存储、装配器、预算控制器。它们之间的关系是请求进来后先由模式路由判断当前应该使用哪种模式然后上下文存储从不同的数据源里拉取原始数据装配器按模式的规则对数据进行筛选、压缩、排序预算控制器保证最终产出的上下文不超过 token 限制。下面给一个简化版的 Python 实现方便你理解整体思路。这是一个真实项目经过简化后的版本去掉了网络 I/O 和缓存细节只保留核心逻辑。from dataclasses import dataclass, field from typing import List, Optional, Callable dataclass class ContextItem: content: str token_count: int priority: float 1.0 timestamp: float 0.0 source: str user dataclass class AssembledContext: items: List[ContextItem] total_tokens: int mode: str class ContextModeRouter: 决定当前请求应该使用哪种 context-mode def __init__(self, classifier: Optional[Callable[[str], str]] None): self.classifier classifier or self._default_classify def _default_classify(self, query: str) - str: q query.lower() if any(k in q for k in [查询, 查找, 文档, 知识库, 怎么处理, 支持哪些]): return retrieval if len(query) 30 and 会话 not in query: return strict return balanced def route(self, query: str) - str: return self.classifier(query) if self.classifier else self._default_classify(query) class ContextBudgetController: 控制总 token 预算并保证各部分的比例 MAX_TOKENS 8000 PROPORTIONS { strict: {system: 0.2, history: 0.15, retrieval: 0.0, input: 0.65}, balanced: {system: 0.15, history: 0.35, retrieval: 0.25, input: 0.25}, retrieval: {system: 0.12, history: 0.08, retrieval: 0.6, input: 0.2}, slim: {system: 0.3, history: 0.0, retrieval: 0.0, input: 0.7}, } classmethod def get_budget(cls, mode: str) - dict: proportion cls.PROPORTIONS.get(mode, cls.PROPORTIONS[balanced]) return {k: int(v * cls.MAX_TOKENS) for k, v in proportion.items()} class ContextAssembler: 根据模式组装上下文 def __init__(self): self.history_store [] # 对话历史 self.retrieval_store [] # 检索结果 def add_history(self, item: ContextItem): self.history_store.append(item) def add_retrieval(self, item: ContextItem): self.retrieval_store.append(item) def _fit_items(self, items: List[ContextItem], budget: int) - List[ContextItem]: # 按优先级排序再在预算内做贪心选择 sorted_items sorted(items, keylambda x: x.priority, reverseTrue) selected [] total 0 for item in sorted_items: if total item.token_count budget: selected.append(item) total item.token_count return selected def assemble(self, mode: str, system_prompt: str, user_input: str) - AssembledContext: budgets ContextBudgetController.get_budget(mode) items [] # 系统提示词部分 items.append(ContextItem(contentsystem_prompt, token_countself._estimate_tokens(system_prompt), priority10.0, sourcesystem)) # 检索内容部分 retrieval_item ContextItem(content, token_count0, priority5.0, sourceretrieval) retrieval_budget budgets[retrieval] selected_retrieval self._fit_items(self.retrieval_store, retrieval_budget) retrieval_item.content \n\n.join([f[检索片段{i1}] {it.content} for i, it in enumerate(selected_retrieval)]) retrieval_item.token_count sum(it.token_count for it in selected_retrieval) if retrieval_item.content: items.append(retrieval_item) # 历史消息部分 history_budget budgets[history] selected_history self._fit_items(self.history_store, history_budget) history_content \n\n.join([f[历史{i1}] {it.content} for i, it in enumerate(selected_history)]) if history_content: items.append(ContextItem(contenthistory_content, token_countsum(it.token_count for it in selected_history), priority2.0, sourcehistory)) # 用户当前输入 items.append(ContextItem(contentuser_input, token_countself._estimate_tokens(user_input), priority20.0, sourceinput)) total sum(it.token_count for it in items) return AssembledContext(itemsitems, total_tokenstotal, modemode) def _estimate_tokens(self, text: str) - int: # 生产环境建议使用 tokenizer这里用简化估算中文字符按1.5 token估算 import math if not text: return 0 return int(math.ceil(len(text) * 1.5)) # 使用示例 router ContextModeRouter() assembler ContextAssembler() query 产品 X 支持导出哪些格式 mode router.route(query) print(f路由结果: {mode}) # 模拟添加检索结果 assembler.add_retrieval(ContextItem(content产品X支持导出PDF、Excel和CSV三种格式..., token_count80, priority4.0, sourcedoc)) assembler.add_history(ContextItem(content用户: 我想导出数据, token_count25, priority1.0, timestamp1000.0, sourcehistory)) result assembler.assemble(modemode, system_prompt你是产品客服助手只根据检索内容回答。, user_inputquery) print(f组装完成token预算: {result.total_tokens}模式: {result.mode})这个简化版本已经能跑通路由—装配—预算控制的全链路。你可能会注意到我特意在_estimate_tokens里留了一个替换点因为实际生产环境一定要用目标模型专门的 Tokenizer 来计算 token 数量而不是靠字符长度猜测。不同模型的 tokenizer 差异很大一个中文字符在不同模型下可能是 1 个 token也可能是 2 到 3 个 token估算不准会导致上下文被截断或预算浪费。3.2 优先级与预算分配最容易被忽略的细节在 context-mode 里预算分配比例是比选什么模式更需要认真对待的环节。很多人会在网上抄一个现成比例但这其实是最不应该偷懒的地方。因为不同业务场景各部分上下文的价值完全不同。比如我做智能客服时历史会话记录非常关键因为用户经常说我刚才说的那个问题这时候历史预算占比 35% 都不够。但做内容生成工具时历史记录反而没那么重要用户改来改去的内容才是核心这时候输入占大头历史可以压到 15%。我在项目里用了一个简单的 AB 测试方案来调这个比例设置两到三组不同预算比例在相同测试集上跑模型输出请标注人员对输出质量打分选出最优比例后再拿生产环境的真实请求做回放验证。这个过程听起来繁琐但实际做下来效果提升非常直观。3.3 相关性排序与模式切换从能用到好用另外我在ContextAssembler里选择历史消息使用的是优先级排序但真实项目里历史消息的优先级应该由相关性分数动态生成而不是一个固定值。你可以维护一个简单的打分函数先对当前 query 做关键词抽取然后对每条历史消息计算命中词数量和位置距离的加权分值。模式切换是另一个关键点。我见过有项目用规则硬编码切换模式比如用户说查一下就走检索模式说写代码就走严格模式。这样简单但误判率高。更好的做法是在每次请求进入时由模式路由模块先做一次语义分类再用一个置信度阈值兜底。比如分类器觉得像检索意图但置信度只有 0.5 以下就默认走平衡模式宁可使用更全面的上下文也不要因为分类错误导致关键信息缺失。保留这个兜底的思路比通过反复调阈值提升那几个百分点的准确率更重要。4. 上线前必须想清楚的三件事4.1 超长对话到底怎么处理我要先把话放在前面上下文越长模型的表现越不稳定成本也越高。这不是某个模型的偶然问题而是自注意力机制的结构性问题。因此在做 context-mode 时一定要给上限设置预警机制。我自己做法是给对话历史设置两层上限第一层是逻辑上限控制最多保留多少轮对话第二层是 token 上限控制最多占用多少 token。两层同时触发时优先满足 token 上限。举例来说我的客服机器人逻辑上限设为 20 轮token 上限设为 3000两者取先触发值。如果 20 轮内容已经超过 3000 token那就把轮数往下调直到 token 数量达标。4.2 缓存与重复计算问题另一个容易踩的坑是上下文重复计算。如果你每条请求都从头组装上下文那么即便模型本身有 prompt caching 机制你的组装计算和检索重复一遍性能也会很难看。我建议在几个固定节点做缓存模式路由结果可以缓存历史打分结果可以缓存检索重排序结果可以缓存一小段时间。因为这些模块的输入变化频率不高缓存命中率能到 60% 以上。4.3 需要记录每一次模式的变更调试时最头疼的问题就是不知道某一次回答是在什么模式下生成的。这个问题可以在每次请求的元数据里加上mode字段并把模式切换的历史单独记录。这样后续做质量分析、问题回溯时能很快定位到是不是模式选择不当导致的输出异常。我的经验是前期多花一点时间设置好日志后期排查能省出十倍的时间。5. 常见问题与排查技巧实录5.1 为什么检索模式反而回答得更差这种情况我遇到不止一次。排查思路首先要看检索内容是否在组装时被正确保留了。很多时候不是模型不行而是重排序环节把关键内容过滤掉了。我见过一个案例评分模型偏好长文本导致短小但直接命中的答案被排到后面最后上下文里全是长篇大论。这种问题可以调整排序策略或者强制保证每个候选来源最少入围一条防止同质化内容刷屏。5.2 模式切换导致会话漂移有几次我遇到的情况是用户前面在聊 A 话题中途突然切换到 B 话题模式从检索模式切到严格模式结果模型把 B 话题的回复弄得像没经过大脑一样。原因很简单它丢失了 A 话题里对当前 B 问题的关键背景。解决方法是在模式切换时做一个上下文交集补全。哪怕切到严格模式也保留前文的一部分摘要信息而不是完全清空。我称之为软切换相当于给新模式一个缓冲带。5.3 token 超限和截断后的语义断裂最后也是最常见的返回给模型的上下文太长被中间层截断。截断发生在模型 API 层不是你能直接控制的但你能控制的是不要逼近上限。我在预算管理器里实际只按 80% 的额度装配留下 20% 缓冲给模型生成回复、工具调用参数等。这个缓冲比例看起来有点浪费但我用它能换取大量稳定性已经成了我所有项目默认的铁律。注意无论哪个模式你都应该先估算当前上下文真实 token 数再扣掉 max_tokens 中给生成回复预留的部分。很多人直接把上下文字符数乘以一个系数当 token 数结果算出 6000真正跑起来却超限就是因为忽略了中间层和生成部分的开销。下面整理成一张速查表供你在排查时直接对照症状可能原因排查步骤解决方案模型回答离题模式选择过于精简历史被清掉查看该请求的 mode 字段和上下文日志改用 balanced 模式或开启软切换检索答案质量差重排序把重要候选过滤了查看检索候选分数和最终入选列表调整排序策略保证最少一条来自不同来源频繁 token 超限预算比例设太高没有冗余检查预算控制器实际用量降到 80% 装配率早期信息被遗忘历史只保留末尾 N 轮检查历史筛选逻辑把筛选策略改为相关性打分截断响应太慢每次重新组装所有上下文查看缓存命中率对路由、打分、重排序增加缓存模型开始胡说检索结果为空但上下文仍有内容检查检索模块返回值增加空结果兜底模板6. 对 context-mode 的进一步思考我在做这套东西的过程中越来越觉得 context-mode 是 AI 应用从demo走向生产级的一道分水岭。模型本身的能力当然重要但上下文的管理方式决定了模型有多少能力能真正发挥出来。尤其在多智能体协作、工具调用、复杂工作流这些场景里context-mode 的价值还会进一步放大。如果你现在刚起步我建议你不要一上来就实现四个模式。先做一个最基础的两模式版本严格模式和平衡模式。把这两套装配规则跑通日志记录做好再逐步扩展。模式不是越多越好每多一个模式就多一批边界情况和测试工作量。等实际业务里明确出现了第三种需求再考虑加第三个模式也不迟。根据我自己的实战体会有几个方向是你后续值得投入精力的一是把模式路由从规则模型升级为内嵌小模型的分类器效果更稳二是加入语义压缩在超长对话场景里把历史记录压缩成摘要而不是简单截断三是把 context-mode 做成一个通用服务对外提供接口让多个应用共享同一套上下文管理系统。这些扩展按优先级排序的话我会先做语义压缩因为超长对话是每个 AI 应用迟早要面对的事。