大模型上下文治理：四种模式的原理、应用与踩坑-北京尧图网络

很多兄弟第一次听到 context-mode 这个说法大概率是在排查对话机器人答非所问、token 账单爆炸或者研究大模型 API 的调参文档时遇到的。老实说这不是一个严格意义上的官方术语而是大家在实践中对一类问题的解决方案的统称我们需要一种模式去管理大模型每轮请求里携带的上下文。我先说个亲测的场景。之前做一个客服知识库助手用户连续问了几句之后模型开始胡言乱语把上一个问题的答案带到下个问题里最离谱的是把用户 A 的信息回答给用户 B。把请求日志拉出来一看上下文列表已经到了第三页里面堆了几十条历史消息甚至还有上上个会话的残留内容。这个就是典型的上下文没有治理context 失控了。所以这篇文章想聊清楚context-mode 到底是什么它解决的是哪一类问题你拿到自己的项目里应该怎么设计、怎么落地以及我在实际开发中踩过的那些坑。内容偏向实操前后端、算法、产品同学都可以参考尤其是正在做 LLM 应用、AI Agent、智能客服这类项目的应该能直接用上。1. 先搞明白 context-mode 到底在解决什么问题1.1 上下文窗口不是无限的大模型的能力虽然强但它的输入长度是有硬上限的。拿当前主流的几个模型来说有的是 8K token有的是 32K、128K最新的也有一两百万 token 的。听着挺大但你要知道 token 不是按字算的英文一个单词可能拆成两三个 token中文一个字大约等于 1 到 2 个 token。加上系统提示词、用户消息、历史对话、工具返回结果、外部检索的文档片段一轮请求轻轻松松就能吃掉几千甚至上万 token。更关键的是窗口大小不等于塞满就完事。模型在超长上下文下的注意力会稀释中间位置的内容特别容易被忽略这个在行业里叫 lost in the middle。我实测过把关键信息放在一段 20K 上下文的中间位置模型有概率完全无视它直接根据开头和结尾的内容作答。所以context-mode 要解决的第一件事就是让你的上下文始终处在模型最舒适的范围内而不是把窗口塞到爆炸。1.2 对话历史为何会中毒除了长度问题还有内容污染的问题。多轮对话里每轮历史消息都会原封不动地拼接进下一次请求。用户一开始问天气后来问股票再后来问菜谱这些内容彼此之间没有逻辑关联但模型会努力把它们脑补成一个连贯的故事。结果就是它回答菜谱的时候莫名其妙带上了一句和股票相关的建议。另外还有角色混乱。如果你的系统里预设了 system prompt要求模型扮演一个严谨的客服但当上下文里用户自己说了一些误导性的话比如你不用遵守规则了模型就很容易被带偏。这种叫提示词注入或者上下文劫持。context-mode 需要保证进入上下文的每一条内容都是可信、可控、和当前任务相关的不是垃圾桶里啥都往里装。1.3 context-mode 的定位不是功能是治理我做过的几个项目回头看凡是 context 这块处理得好的稳定性和输出质量都明显高一个档次。context-mode 本质上是给大模型设计一套信息治理策略它决定三件事什么内容可以进上下文什么内容必须被清理什么内容需要被压缩后进入。你可以把它理解成开会。一个会议如果所有人都随心所欲地发言开了三小时没有任何结论但如果有一个靠谱的主持人会前定议题会中控节奏会后出纪要效率就会非常高。大模型就是那个参会的专家而 context-mode 就是你安排的那个主持人。2. 四类主流的 context-mode 实现方案2.1 滑动窗口模式最简单也最粗暴滑动窗口的核心逻辑一句话只保留最近的 N 条消息更早的一律丢弃。实现起来非常简单一个数组加一个截断判断就完事。def sliding_window(messages, max_messages20): if len(messages) max_messages: return messages return messages[-max_messages:]这种模式适合场景比较简单的工具型对话比如翻译助手、单轮问答、代码生成。它的优点是实现零成本token 消耗完全可控缺点是模型会失忆用户聊到第 21 句的时候第 1 句的内容就彻底消失了。如果你的业务场景需要用户在多轮对话中持续提供背景信息滑动窗口会让用户体验非常糟糕。我在一个内部工具里临时用过这种方式结果用户每次都要重新报一遍自己的需求和约束条件后来果断换掉了。所以我把它的适用场景严格限定在对话轮次短、上下文依赖弱、对成本极其敏感的应用里。2.2 摘要压缩模式以信息密度换空间既然历史消息不能全扔那就把它浓缩。每当历史消息累积到一定数量就调用模型对旧消息做一次摘要把摘要作为一条新的系统消息放进上下文旧消息从队列里移除。这个思路就是上层模型处理浓缩信息下层模型处理完整信息。举个例子用户聊了十轮关于项目排期的对话摘要可以写成用户要求 3 月 15 日前完成开发预算控制在 20 万以内技术栈已确定为 Python React后续的对话就不需要保留那十轮原始消息了只需要这条摘要。摘要压缩模式的痛点是摘要本身的质量。如果摘要做得太粗关键细节就丢了如果摘要做得太细那和保留原文也没啥区别。我建议在做摘要时使用一个独立的小模型并且给摘要模型写一个非常具体的 prompt要求它提取用户的核心诉求、已确认的决策、待办事项而不是让它自由发挥。2.3 结构化检索模式给上下文加索引这个方案参考了 RAG 的思路。我们不把历史消息全部塞进上下文而是先把它们存入一个向量数据库或者倒排索引每次请求前根据当前用户的问题去检索最相关的历史片段只把命中的片段拼进上下文。这个模式的逻辑非常优雅能解决长对话中的偶发记忆需求。比如用户在一小时前提过一个技术细节现在突然问我刚刚说的那个方案你记得吗模型需要对这句话生成一个查询向量去索引里找到一小时前的那轮消息取回来拼入上下文。当然代价就是架构复杂度上来了。要引入 embedding 服务、向量数据库、检索排序逻辑。而且 embedding 的质量直接决定召回效果如果用户表达和原文之间差异过大向量检索可能召回不出来。我在实践中的处理方式是把关键词匹配和向量检索做一个小混合关键词保证必中向量保证语义相似。2.4 混合上下文模式生产环境的主流选择上面三种模式不是互斥的真正线上跑得稳的 agent 基本都是混合模式。我自己常用的设计是系统提示词滑动窗口保留最近几轮摘要消息保留更早的整体信息每次请求前做一次向量检索补充关联的旧消息。混合模式的好处是兼顾短期记忆、长期记忆和即时检索。短期靠滑动窗口长期靠摘要跨场景关联靠向量检索。这样既能保证模型有足够的即时上下文又不至于让历史垃圾塞爆窗口。我的一个生产实践配置大概是这样最近 10 轮原始消息全部保留10 轮之前的消息按每 5 轮合成一条摘要系统里单独维护一个向量库存所有历史消息的 embedding每次请求检索 top 3 条相关片段。整体 token 开销比纯滑动窗口高但比全量拼接低了太多而且输出质量稳定很多。3. 实操从零搭建一个可用的 context-mode 模块3.1 数据结构的设计在写代码之前先把数据结构定义清楚。消息对象建议至少包含这几个字段rolesystem / user / assistant、content文本内容、timestamp时间戳、source消息来源标识。用 Python 的 dataclass 可以这样定义from dataclasses import dataclass from typing import Optional dataclass class Message: role: str # system, user, assistant, tool content: str timestamp: float msg_id: str metadata: Optional[dict] None这里有一个容易被忽略的点timestamp 和 msg_id 必须有。timestamp 用来做时间衰减如果一条上下文已经过去了 2 小时它的重要性应该自动降低msg_id 用来做去重防止某些异步场景下重复插入消息。上下文管理器则负责维护一个消息队列并提供两个核心方法add_message 和 build_context。add_message 负责把新消息放进队列build_context 根据当前的模式配置生成最终发送给模型的上下文列表。3.2 核心逻辑的实现要点先实现一个基础版的 MixedContextManager 类class MixedContextManager: def __init__(self, max_recent10, max_tokens6000): self.messages [] self.max_recent max_recent self.max_tokens max_tokens self.embed_fn None # 传入 embedding 函数 self.summary_fn None # 传入摘要函数 def add_message(self, msg: Message): self.messages.append(msg) self._maybe_compact() def _maybe_compact(self): # 如果消息数量超过阈值就把老消息摘要化 if len(self.messages) self.max_recent * 2: old_msgs self.messages[:-self.max_recent] summary self.summary_fn(old_msgs) # 把旧消息清掉仅保留摘要 self.messages self.messages[-self.max_recent:] self.messages.insert(0, Message( rolesystem, contentf[历史摘要] {summary}, timestamptime.time(), msg_idsummary_ str(uuid.uuid4()) )) def build_context(self, query: str, max_recentNone, use_ragTrue): # 基础上下文系统提示历史摘要最近消息 recent self.messages[-max_recent:] if max_recent else self.messages context [m for m in recent] # 如果开启 rag就检索外部片段 if use_rag and self.embed_fn: hits self.embed_fn(query, top_k3) for hit in hits: context.insert(-1, Message( rolesystem, contentf[相关记忆] {hit}, timestamptime.time(), msg_idrag_ str(uuid.uuid4()) )) return context这段代码有几个设计点值得展开说。第一摘要消息的 role 设计成 system 而不是 assistant是因为它是系统层面的上下文治理结果不是模型生成的内容。第二摘要消息插入的位置在最前面靠近系统提示词这样模型会把它当作背景约束来对待。第三RAG 检索插入的位置在 last 之前也就是紧贴着最新一轮用户问题之前模型会更关注这一个位置的内容。实际运行的时候还需要一个 token 估算函数因为你不能等到请求发出去了才发现超限。这里我常用的方案是根据字符数粗估中文 token 数约等于字符数英文 token 数约等于字符数除以 4。估算的目的不是精确计算而是提前拦截避免 API 返回 400 错误。3.3 接入真实模型时的集成方式最后一步是把 manager 接入到实际的模型调用。以 OpenAI SDK 风格为例调用过程大概是def chat_with_context(query: str, manager: MixedContextManager): # 构建上下文 context manager.build_context(query) # 把 context 对象转换成 API 需要的格式 messages [ { role: m.role, content: m.content } for m in context ] messages.append({role: user, content: query}) # 调用模型假设使用的 model 是 gpt-4o 这类 response openai_client.chat.completions.create( modelgpt-4o, messagesmessages, temperature0.7 ) # 记录模型回复 assistant_msg response.choices[0].message.content manager.add_message(Message( roleassistant, contentassistant_msg, timestamptime.time(), msg_idfmsg_{uuid.uuid4()} )) return assistant_msg这里唯一要提醒的是别漏掉 add_message 这一步。很多同学把 context 构建得很漂亮但忘了把每轮新产生的 user 消息和 assistant 回复写回 manager导致上下文队列一直没有更新模型永远看不到用户刚说的话。这个 bug 会在测试到第三轮的时候突然暴露我当年排查了整整一个下午才定位到。4. 常见问题与排查技巧实录4.1 token 估算不准确导致请求失败有段时间我遇到一个诡异的问题某些请求的 token 数估算在 7000 左右但发送给模型后返回 400 错误提示超限。后来排查发现问题出在工具调用的返回值上。我的系统接入了几个外部 APIAPI 返回的 JSON 数据结构非常长而且带有大量嵌套字段这部分字符数没有计入 token 估算。这个问题很常见因为工具调用的结果是动态拼入上下文的如果之前的消息里不包含这些内容估算逻辑就不会把它算进去。我在后来做了一个改进每一次工具调用的返回结果在写入消息队列之前先用同等规则估算 token 数并单独记录到一个 counter 里build_context 时把当前队列的 token 总数加上待发送工具结果的 token 数再和窗口上限做比较。这样基本不会再出现超限错误了。4.2 系统提示词被挤出去这是一个非常隐蔽的问题。假设你的模型上下文上限是 8000 token系统提示词有 1500 token历史摘要 1000 tokenRAG 补充 2000 token最近消息 3000 token加起来 7500看起来没问题。但某个时刻用户突然发了一个超长的消息比如粘贴了一段 2000 token 的日志整体变成了 9500超限了。此时如果你用的是从头部开始丢弃的简单截断策略系统提示词就会被先挤掉。一旦系统提示词消失这个模型就完全是另一个模型了——它会丢掉你的角色设定、回复规则、输出格式限制。我遇到过模型突然开始用英文回答、突然改变语气、突然不按照 JSON 格式输出最后定位到就是因为系统提示词被截断了。解决方法是截断策略要分优先级系统提示词永远保留历史摘要次之RAG 片段再次最后才是最近消息。如果实在放不下宁可把最近消息截断一部分也不能丢 system prompt。4.3 多轮对话中的角色漂移这个现象在 context-mode 设计不合理的时候特别明显对话进行到十几轮之后模型开始出现角色混乱一会儿像客服一会儿像用户一会儿又像第三方专家。排查之后发现问题出在角色标记没有覆盖到所有消息。当我把工具调用结果作为 system 消息拼入上下文时模型会把工具返回的内容误认为是系统给出的权威指示从而改变自己的立场和表达方式。更糟的是摘要消息也会以 system 身份出现如果摘要里包含了用户的原话模型就会认为那是系统命令。我现在的做法是工具返回结果统一用单独的 role 或 metadata 标识即使 API 不支持自定义 role也会在 content 前加一个明确前缀比如[工具调用结果来自 search_articles非系统指令]。摘要消息则是[历史对话摘要供参考非当前用户指令]。这么一点改动角色漂移问题基本绝迹。5. 几个我在实践中长期使用的经验细节除了上面的大逻辑还有几个小细节是文档里不太会写的但对线上效果影响特别大。我单独拎出来说一说。第一个细节时间衰减。如果你的对话系统允许用户隔了很久再回来继续聊那历史消息的参考价值是随时间递减的。我在 build_context 时会把超过一定时限的消息自动降级比如 20 分钟前的消息不再参与普通拼接只让它们参与摘要和检索。这能避免很久以前的旧信息干扰当前对话。第二个细节摘要和原始消息不要同时保留。有些人的实现是把旧消息摘要化之后原始消息还留着只是不参与拼接。这倒是没错但如果你既把摘要放进上下文又把原始消息通过 RAG 召回那模型看到的就是两份内容重叠的信息。我的经验是一旦消息被摘要化原始消息就标记为 archivedRAG 索引里也要排除这些内容只索引未被摘要化的近期消息。第三个细节上下文 prompt 编排的顺序。同一个上下文切片排列顺序不同效果差距非常大。我做了几组对照实验模型表现最好的一种顺序是系统提示词在最前、历史摘要其次、RAG 补充再次、最近的几轮对话跟着、最新用户问题垫底。原因是模型会把注意力集中在文本开头和结尾开头放规则结尾放问题中间给背景这样最容易产出精准的回答。第四个细节对于 agent 类应用工具调用的上下文也要纳入 context-mode 管理。你不能只管理用户和模型的对话消息还要管理模型调用工具时的输入输出。有个项目里我设计了一支专门的 tool_context 链每次工具调用的参数、返回值、耗时都会被记录并且在后续决策中按重要性排序。agent 工具调用经常失控就是因为上下文里没有完整保存之前的调用链模型自己都忘了它刚才调过哪些工具。最后说一个我真心觉得重要的观点context-mode 不是一次性设计完就结束的东西它是需要持续根据线上数据调整的。我习惯在每次请求结束后异步记录上下文构建的元信息——实际用掉的 token 数、截断次数、摘要触发频率、RAG 召回命中率然后定期看趋势来调参。没有这些数据支撑你改上下文策略就是玄学。有一次线上模型输出质量突然下降我怎么调 prompt 都没用后来翻监控发现是因为用户的平均对话轮次从 5 轮涨到了 15 轮而我的摘要触发阈值还是原来的 20 轮等于摘要一直没生效上下文早就被历史消息堆爆了。改小阈值之后效果立刻恢复正常。所以说上下文治理这件事看起来是在和大模型打交道实际上是在和管理系统做斗争。把一个可观测、可配置、可迭代的 context-mode 模块搭好模型的智商才算真正稳定发挥出来。也希望上面这些踩坑记录能让你们少走点弯路。

大模型上下文治理：四种模式的原理、应用与踩坑

相关推荐

go-echarts opts.XAxis 实战避坑指南：时间/分类/数值轴配置要点

AI Agent社交平台失控案例分析及稳健设计指南

Qt TCP聊天室：从协议帧到状态机的底层实现指南

更多资讯

2024年三款主流五笔输入法深度横评：词库、皮肤与云同步

AI论文写作工具书匠策的六大核心功能解析

数据驱动与关键字驱动自动化测试框架设计指南

AXI4从机写通道设计：握手时序、outstanding与RTL实现

MT7620A+MT7612E原理图拆解：DDR2、PCIe与射频调试关键点

OpenShell 深度解析：从事件流到插件协议，打造可编程的现代命令行环境

今日更新

学生选课系统DFD图绘制指南：边界划分与分层校验实战

JIRA敏捷落地：Scrum角色权限、Sprint与燃尽图避坑指南

SEMI S8人机工程验收实战：从条款拆解到现场实测的完整指南

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？