最近排查一个 AI 应用的线上问题时我盯着日志看了老半天用户连续问了七八轮之后模型开始“胡言乱语”甚至把几分钟前自己刚给出的结论都推翻了。再一看代码模型调用永远是把整段对话历史原封不动丢进去system prompt 里还塞了三大段产品说明。这个场景你应该不陌生——很多基于大模型的工具真正影响体验的往往不是模型本身而是它面前那份“上下文”。我们聊的 context-mode其实就是一套关于上下文怎么选、怎么存、怎么喂、怎么省的策略。说人话就是告诉模型这一轮你需要看什么不需要看什么。它适合所有正在做 LLM 应用、写 Agent 或接 API 产品的开发者也适合想弄懂为什么自家对话机器人越聊越笨的产品和运营同学。1. 先拆解概念context-mode 到底在解决什么问题1.1 从一次“上下文崩坏”事故说起我遇到的那次事故表面上是模型问题实际上问题出在调用方式上。用户在对话框里问产品报价又问售后政策中间夹了一句无关紧要的“今天天气怎么样”。助手把这句话当成有效上下文记了下来到第八轮的时候答复里莫名其妙出现了“如果明天降温建议您联系售后……”这种串台内容。原因并不复杂模型每次只能读有限的内容喂进去的信息越多注意力就越分散。把所有历史、所有文档、所有规则不分主次地塞进同一个窗口等于让一个只能专注看三页纸的人一次性面对三十页杂乱材料。他当然能临场翻翻但重要信息必然会被淹没。这就是 context-mode 要解决的核心问题它不是某个具体函数或参数而是一套管理上下文的策略。你可以把它理解成给模型“断舍离”——决定哪些内容必须留在眼前、哪些内容可以存档、哪些内容干脆丢弃。没有这套策略的 AI 对话前期还正常一问长就崩几乎是个必然结果。1.2 我理解的四种基础形态在具体实现之前先明确 context-mode 有哪些基本玩法。根据我经手的项目大概可以归成四类一是全量直通模式。所有输入原样丢给模型不处理、不区分、不裁剪。适合一次性问答、单轮测试、原型验证因为它最简单也最容易“看起来有效”。但它的缺陷会在对话变长后集中爆发成本、延迟、准确性全部不可控生产环境我基本不推荐。二是滑动窗口模式。只保留最近 N 轮对话超过 N 轮就丢弃最早的记录。这个方案像自动翻页保证模型永远只看最近发生的事情适合客服机器人、闲聊场景。它的局限在于“旧信息”可能仍然关键比如用户第一轮就说了“我预算 2000 元以内”后面每轮都在纠结配置窗口一滑预算信息就丢了。三是结构化分层模式。把上下文分成几个固定槽位系统指令、用户画像、短期对话、任务结果、参考文档。每一部分都有自己的容量上限和优先级写入和裁剪都按规则执行。这种做法生产环境最常用因为稳定、可解释、好维护。四是动态检索模式。每次调用前先从外部存储器里检索出与当前问题最相关的 3-5 个片段再拼进上下文。典型例子是 RAG检索增强生成。这套方案对长文本、企业知识库类应用最合适但对检索质量依赖很强检索不准模型就会答非所问。这四种形态不是互斥的。我见过不少成熟系统是滑动窗口打底再加结构化分层特定场景触发动态检索。真正该选择哪一种取决于你的业务对“旧信息敏感度”有多高。如果用户必须在十分钟后还能记住自己最初设定条件那单纯滑动窗口肯定不够用。模式优点缺点适用场景全量直通简单直接易超窗口、成本高、易串台单轮问答、原型滑动窗口控制长度、易实现丢弃早期关键信息常规多轮对话结构化分层稳定可控、优先级明确需要额外设计生产级客服、助手动态检索海量知识可用依赖检索质量知识库问答、RAG2. 设计上下文模式前先把边界画清楚2.1 哪些该进哪些不该进很多人上来就写代码我劝你先拿一张纸把“这一轮调用模型时到底需要哪些信息”列出来。因为 context-mode 的第一步不是技术实现而是做减法。必须放进上下文的内容有这么几类当前用户的直接意图、完成该意图所需的指令或规则、必要的历史关键状态、模型生成回复时需要参考的证据片段。这几类信息直接影响本次输出质量缺了不行。不该放进来的内容也很多冗长的产品介绍全文、上一轮已经消化过的中间推理、隐私数据、与当前问题无关的寒暄对话、模型已经回复过的内容副本。这些信息不仅浪费宝贵的上下文空间还会主动干扰注意力。我用一个生活类比解释你给一位新同事交接工作只会给他三样东西——今天的任务清单、他需要遵守的流程规则、以及跟任务相关的历史结果。你不会把过去半年所有邮件全部转给他更不会顺手附上跟任务无关的会议纪要。模型本质上就是这个新同事喂什么决定了它干得怎么样。所以设计 context-mode 的第一条原则是每个字段进上下文之前都要通过一道“影响本次输出吗”的检验。不确定的内容宁可不放或者放到备用槽位里等用户追问时再动态加入。2.2 核心参数与预算计算进入技术层后你要盯住几个关键参数。首先是模型的上下文窗口长度比如 8K、32K、200K这是硬上限。然后是单次请求里各部分的分配system prompt 占用多少、历史对话占用多少、检索文档占用多少、工具定义占用多少以及给模型输出预留多少。这里最容易犯的错误是把上下文窗口当成输出空间以为窗口越大就能让模型写越多。实际上输入和输出共享同一块容量你输入塞得越满模型能输出的空间就越窄。卡在输出中途被截断的多半是输入占据了过多预算。拿一个 32K 窗口的模型举例我会这样分配预算system prompt 控制在 1K 以内存储必要的身份、任务、边界规则历史对话压到 8K 以下只保留最近 5-8 轮或按 token 截断检索文档视当前问题注入 3-6K工具定义单独算 2-4K。剩下的 10K 以上全部留给输出和不可预见的缓冲。这个分配不是拍脑袋而是我踩过“输出截断”这个坑之后总结出来的经验宁可少喂一点输入也要保证模型能把话说完。实际操作中我建议在代码里做一个简单的 token 估算函数每次组装上下文之前先计算长度。一旦超过阈值先裁剪历史对话、再缩减检索片段最后才考虑压缩 system prompt。裁剪顺序就是牺牲顺序哪部分对当前任务最不关键先动哪部分。2.3 用 system prompt 构建“隐式上下文模式”很多人低估了 system prompt 在 context-mode 里的作用。它其实是最省事的上下文控制手段因为每轮调用都会无条件加载相当于给模型装了一个“常驻记忆”。我的习惯是把 system prompt 写成三段式。第一段是身份与任务目标让模型知道自己在做什么第二段是工作流程或判断标准告诉模型遇到什么情况该怎么做第三段是行为边界明确禁止哪些行为和输出格式要求。三段加起来尽量控制在 800 token 以内每一句都要信息密度高不写废话。举个例子我做过一个售后客服助手system prompt 大概是这样的你是一名售后客服助手只能基于提供的对话记录和售后政策片段作答。你的目标是快速判断用户问题属于退货、换货还是维修并给出对应流程。如果信息不足直接说明缺少哪些信息不要猜测。回答时保持简洁不超过 150 字。这段 prompt 就隐含了 context-mode 的管理策略限定信息源“提供的对话记录和售后政策片段”、限定任务边界、限定输出长度。后面不管用户怎么绕模型都不会被带偏因为它已经被“框”在一个明确工作模式里。3. 实操实现一个可复用的 context-mode 管理模块3.1 工程结构与依赖准备接下来进入代码层面。我推荐的工程结构很简单只分三个文件context_manager.py 负责上下文组装与裁剪storage.py 负责人历史存储main.py 是调用示例。依赖方面不需要重框架Python 环境里装一个 openai 兼容的 SDK 就行另外加一个 tiktoken 用来估算 token 数。如果你用的是其他云厂商的模型只要接口风格兼容同样的代码可以平移到别的库核心逻辑不变。我在这里说一句重要的在生产项目里不要把上下文管理逻辑散落在各个业务函数里一定集中到一个模块。不然到排查问题时你会发现自己得在十几个文件里找谁改了消息列表那是最绝望的时刻。3.2 实现写入、读取、裁剪三个核心操作一个完整可用的 context_manager 模块至少要支持三个操作写入新消息、读取当前上下文、按策略裁剪。写入操作解决“新增内容怎么进上下文”读取操作解决“调用 API 时怎么组装消息”裁剪操作解决“超过预算时先丢谁”。三个操作合在一起才构成完整的生命周期管理。我用代码演示一个简化版实现。存储层先用内存列表正式项目可以替换成 Redis 或数据库# context_manager.py from dataclasses import dataclass, field from typing import List, Dict dataclass class ContextManager: system_prompt: str max_context_tokens: int 8000 output_reserve: int 1000 max_history_rounds: int 6 retrieved_chunks: List[str] field(default_factorylist) history: List[Dict[str, str]] field(default_factorylist) def add_user_message(self, content: str) - None: self.history.append({role: user, content: content}) def add_assistant_message(self, content: str) - None: self.history.append({role: assistant, content: content}) def set_retrieved_chunks(self, chunks: List[str]) - None: self.retrieved_chunks chunks def estimate_tokens(self, text: str) - int: import tiktoken enc tiktoken.get_encoding(cl100k_base) return len(enc.encode(text)) def compact(self) - None: while len(self.history) self.max_history_rounds * 2: self.history.pop(0) total self.estimate_tokens(self.system_prompt) total sum(self.estimate_tokens(m[content]) for m in self.history) total sum(self.estimate_tokens(c) for c in self.retrieved_chunks) while total self.max_context_tokens - self.output_reserve and self.history: removed self.history.pop(0) total - self.estimate_tokens(removed[content]) def build_messages(self) - List[Dict[str, str]]: self.compact() messages [{role: system, content: self.system_prompt}] if self.retrieved_chunks: chunk_text \n\n.join(self.retrieved_chunks) messages.append({ role: system, content: f参考以下资料作答如果资料中没有答案直接说明\n{chunk_text} }) messages.extend(self.history) return messages这段代码不长但每部分都有实际用途。compact() 方法就是核心裁剪逻辑先按“轮数”压缩历史再按“token 总量”二次裁剪。build_messages() 组装最终消息时把检索片段放在一个独立 system 消息里这样模型能明确区分“这是参考资料”和“这是用户说过的内容”。3.3 关键参数的计算过程上面的 compact() 里有一行很容易被忽略estimate_tokens。cl100k_base 是 OpenAI 系模型常用的 token 编码器我拿它做估算误差一般在 5% 以内。如果你用的是其他模型换对应编码器或直接调用服务商提供的 tokenizer 接口即可。关于预算计算我给一组真实案例。假设模型上下文窗口是 8000output_reserve 设为 1000那么可分配给输入的部分就是 7000。system prompt 写了 500 token检索片段整理完是 1200 token此时历史对话剩余可用空间是 5300 token。如果用户翻了 20 轮历史总长达到 4600 token那么上下文还能装下。但如果历史到了 9000 token就必须裁剪到 5300 以内。裁剪顺序我固定为“先丢最旧对话再抽稀中间轮次最后压缩检索片段”。因为最新对话和检索片段直接服务当前问题是最不可能牺牲的。这种确定性的顺序也让行为可预测不像某些“智能裁剪”方案这次丢的是这段、下次丢的是那段模型上下文前后不一致更容易出问题。3.4 完整接入 API 调用的示例有了 ContextManager调用 API 就非常简单了。下面这段示例展示了 main.py 里怎么把上下文管理器接进真实请求# main.py from context_manager import ContextManager def build_system_prompt(user_profile: str) - str: return ( 你是一名购物助手。请基于用户画像和对话记录推荐商品。 回答要具体直接给出推荐品牌和理由。 f用户画像{user_profile} ) def query_llm(cm: ContextManager, question: str, client) - str: cm.add_user_message(question) messages cm.build_messages() resp client.chat.completions.create( modelgpt-4o-mini, messagesmessages, max_tokenscm.output_reserve, temperature0.3 ) answer resp.choices[0].message.content cm.add_assistant_message(answer) # 记 token方便后面看账 print(resp.usage.prompt_tokens, resp.usage.completion_tokens) return answer if __name__ __main__: import os from openai import OpenAI client OpenAI(api_keyos.getenv(API_KEY)) profile 用户偏好数码产品预算3000左右重视售后 cm ContextManager( system_promptbuild_system_prompt(profile), max_context_tokens8000, output_reserve1000 ) print(query_llm(cm, 推荐一款适合拍视频的手机, client))这段代码里的关键是 resp.usage 字段。每次调用都打印 prompt_tokens 和 completion_tokens这是你优化上下文水平的核心数据来源。没有 token 账单意识的人做不好 context-mode。4. 生产环境常见的坑以及排查实录4.1 三个出现频率最高的生产问题先说最常见的三类问题。第一类是 system prompt 写得太长太满。我见过有人把产品手册里的三十条规则全塞进 system prompt结果模型在对话后期“失忆”连用户刚才说过什么都不记得了。这是因为 system prompt 占用了绝大多数输入预算历史对话被压缩得所剩无几。排查方式很简单看日志里 prompt_tokens 的分布如果 system 占了一半以上就该精简了。第二类是历史对话无限增长。很多团队上线时图方便把所有聊天记录存进列表不设上限。等到线上跑了一周一次请求的输入 token 稳定突破 10K账单以肉眼可见速度哭丧着脸。这种问题的根源是缺少 compact() 逻辑没有任何裁剪机制。排查方式是观察 token 曲线一旦发现单次 prompt 随轮数直线上升基本就中了。第三类是检索片段全量塞入。做 RAG 的同学容易犯这个检索接口返回十个片段不管是不是重复全部拼进上下文。结果模型被大量泛化信息包围给出的回答空洞、中庸完全丧失针对性。解决方法是限制检索片段数量与截断长度我一般控制在 3-5 个片段、每段不超过 400 token。4.2 我的排查四步法遇到线上上下文类问题我习惯按固定顺序排查效率和准确率都高。第一步看单次请求的 token 分布。把 system、history、retrieved、output 四个维度的 token 占比列出来一眼定位是哪部分超预算。第二步复现多轮对话场景写一个脚本自动模拟用户连续提问 10 轮观察模型从第几轮开始偏离。第二步比第一步更能暴露“上下文策略失效的临界点”。第三步检查裁剪日志。compact() 是否触发、触发时丢了哪些消息都要有日志可查。第四步回放旧会话用同一组输入对比不同策略的效果而不是只盯单次回答好不好。这套流程几乎能覆盖八成 context-mode 问题。实际工作中我发现大部分“模型笨”的投诉最后都查出了工程侧的原因而不是模型本身能力问题。4.3 问题速查表现象可能原因排查方法解决方案多轮后模型健忘历史被裁剪过度或关键词丢失查看 compact 日志提高旧关键信息的保留优先级输入 token 爆炸历史无限增长无裁剪看 usage 曲线加滑动窗口或按 token 硬截断回答空泛检索片段太多太杂检查检索片段 source限制片段数量与长度输出被截断输入预算过大看 completion_tokens 是否触及上限调高 output_reserve模型照着旧规则执行system prompt 权重过高对比新旧版本输出精简 system突出最新指令5. 如何衡量一个 context-mode 值不值5.1 量化指标库忙了半天总得有个交代。我建议从五个维度量化 context-mode 的收益。任务完成率是最直接的指标。在客服场景里可以定义为“用户问题被成功解决且有明确结论”的比例。连续对话轮数也很关键衡量的是模型在多轮后仍能保持关键信息的能力。成本维度就是单次对话输入的 token 总量直接决定账单金额。响应延迟反映上下文组装和裁剪带来的额外耗时。最后一个维度是引用准确率特指 RAG 场景下模型是否严格依据注入的检索片段作答。这些指标不需要全部上线找两三个核心的先跑两周。比如你优化了历史裁剪策略那重点看“连续对话轮数”和“单次 prompt token 均值”如果你优化的是检索注入就盯“引用准确率”和“回答相关性评分”。实际操作中我发现团队容易陷入“只看延迟和成本”的误区。省了钱、快了速度但用户问题解决率掉了五个点这显然不划算。所以指标之间要做权衡评估不要单看任何一项。5.2 用配置开关做 A/B 实验context-mode 调整是一种持续优化过程不是一次到位。为了安全迭代我建议把所有策略参数都放到配置里让不同实验组走不同配置。比如你可以设计两套配置正式环境走 A 配置滑动窗口 6 轮 分层结构化灰度环境走 B 配置滑动窗口 8 轮 动态检索注入。通过线上分流把用户会话分别导到两套策略下跑一段时间后对比任务完成率和 token 成本。这种实验思路比靠感觉调参稳妥得多。一个简单实现是在 ContextManager 构造函数里接收一包策略参数比如 max_history_rounds、use_retrieval、retrieved_chunks_limit。策略由配置文件或配置中心下发代码逻辑不写死。这样一来改策略就是改配置、发发布、看指标不用动一行代码。6. 再进一步从单会话上下文到全局上下文6.1 全局上下文模式的价值单会话 context-mode 解决的是“一次对话内怎么管理信息”。但做到一定程度后你会发现它还不够。用户第二次来模型不知道他上次问过什么不同部门的客服面对同一产品却掌握不同资料团队的知识沉淀无法跨会话复用。这时候需要把视角从“单个会话”提升到“全局上下文模式”。所谓全局上下文就是把用户画像、历史结单、团队规则、企业文档等跨会话信息统一管理起来在需要时注入当前会话。这不是简单的数据库查询而是要设计一套“哪些信息在何种场景下自动加载”的规则。比如检测到用户是老客户自动加载其历史工单摘要检测到问题涉及退换货自动检索对应政策片段检测到对话进入投诉场景自动切换更谨慎的话术模式。6.2 值得尝试的高级组合全局上下文模式不是推翻前面的方法而是叠加。我的建议是先做好基础的单会话分层再逐步扩展。一个行之有效的组合是“滑动窗口 摘要压缩”。当历史对话超过一定长度不是简单丢弃而是用模型把旧对话浓缩成一段摘要保留下来。这样既不丢失早期关键信息又不让完整历史无限占用空间。这个方案适合比较依赖早期信息的长任务场景。另一个组合是“分层记忆 动态检索”。把用户长期偏好放进持久记忆槽位把每轮对话结论写回记忆数据库每次请求时根据当前问题动态检索最相关记忆。这个方案适合智能助手类产品让模型真的有“越用越懂你”的感觉。这些组合都会显著增加工程复杂度所以我不建议一上来就全做。先把基础的分层上下文做好、把裁剪和预算算明白再按业务需要逐步加长记忆、加检索、加摘要压缩。context-mode 最终解决的不是某一个技术点而是让 AI 应用在“信息过载”与“信息不足”之间找到稳定的平衡点。最后分享一个我常提醒自己的原则上下文管理不是把系统 prompt 写好就结束而是一个持续度量的过程。每加一个“智能”功能都要问一句——它到底改善了哪个指标还是只是让代码看起来更复杂我在实际项目中砍掉过不少花哨但没收益的上下文策略留下的永远是能直接反映到任务完成率和成本上的东西。这个内容后续如果你打算继续深入可以往独立上下文服务的方向扩展做成一个所有 AI 功能共用的基础组件收益会更大。