你需要先搞清楚一件事context-mode不是一个具体的开源项目名也不是某个框架的官方术语。它是大模型应用、 Agent 系统甚至一部分编辑器/IDE 工具里对“上下文管理方式”的统称。从开发者视角看context-mode直接决定了 AI 能不能“记住该记的、忘掉该忘的”也决定了 token 成本、响应速度、回答质量这三者之间的平衡。我做 AI 应用落地这两年见过太多项目死在上下文管理上要么上下文塞得太满模型注意力被稀释回答开始胡说要么上下文剪得太狠模型把关键信息丢了开始一本正经地编。context-mode解决的就是这个核心矛盾怎么在有限窗口里装下最有价值的信息。这篇文章不聊概念只聊实操。我会从 context-mode 的核心设计思路讲起拆解几种主流模式然后给出一套可以直接抄作业的实现方案最后把我们实际踩过的坑和排查经验都摆出来。适合正在做 AI 应用、Agent 开发或者想优化现有 prompt 工程流程的同学参考。1. 理解 context-mode它到底是什么1.1 从“窗口”视角看上下文先打个比方。大模型的上下文窗口就像一张写字台。窗口越大桌面越大能摊开的资料越多。但问题是桌面再大你真正能同时专注处理的资料也就眼前那几份。你不可能把整间档案室的书都摊在桌上那样反而找不到重点。context-mode就是“整理桌面”的策略。它决定了几件事哪些资料上桌哪些资料收进抽屉哪些资料直接扔进碎纸机。更进一步它还决定资料在桌面上的排列方式——是按时间顺序摆还是按重要程度摆还是按类别分区摆。在实际项目里这个“桌面策略”直接影响效果。我见过有人把几万字的业务文档全部塞进 system prompt结果模型回答问题时连最基本的用户意图都抓不住。为什么因为 desk 上全是背景资料真正的用户问题只占一小块模型的注意力被背景资料带跑了。context-mode 的职责就是防止这种情况发生。1.2 为什么 context-mode 是 AI 应用的“隐形架构”很多团队初期不重视 context-mode觉得把内容拼起来扔给模型就行。等做到第三四个功能问题就集中爆发了第一token 成本失控。每次请求都把全量历史对话发给模型随着对话轮数增加成本指数级上涨。第二响应延迟拉高。输入 token 越多首字返回时间越长用户体感明显变差。第三模型输出质量下降。长上下文里的信息密度不够模型容易“迷路”生成内容开始跑题、重复、甚至自相矛盾。第四状态管理混乱。多轮对话里用户中途改了需求模型如果还记着旧需求就会两头打架。context-mode就是这套隐形架构的核心。它像水管工一样决定水怎么流、流多少、什么时候停。一个设计良好的 context-mode能让同样的模型、同样的 prompt效果截然不同。这也是为什么很多人发现明明用了同一个 GPT-4 级别的模型别人做的 bot 就是更聪明——差距往往不在模型而在上下文管理。1.3 主流的 context-mode 类型从我接触过的项目来看context-mode 大致分四类各有适用场景全量上下文模式Full-context mode所有历史全部保留适合对话轮数少、单次任务重的场景。优势是信息零丢失劣势是成本高、速度慢不适合长会话。滑动窗口模式Sliding-window mode只保留最近 N 轮对话更早的内容直接裁剪。实现简单适合闲聊型机器人缺陷是早期关键信息会丢用户提一句“我刚才说过的那个需求”模型就傻眼了。摘要压缩模式Summarized mode当对话超过阈值时把旧对话交给模型生成摘要再带着摘要继续后续对话。适合长会话场景能平衡记忆与成本代价是摘要本身会失真细节有损。结构化上下文模式Structured mode把上下文分成固定角色区——系统指令区、用户信息区、对话历史区、工具结果区。每块区域有独立的写入策略和裁剪策略。这也是我在生产项目里最推荐的方式后面会详细拆解。这四种模式不是互斥的成熟系统通常组合使用用结构化上下文做骨架内层跑滑动窗口窗口滑出去的内容再自动做摘要归档。这套组合拳就是 context-mode 的核心精髓。2. 核心细节解析上下文窗口、压缩策略与信息优先级2.1 Token 预算的分配逻辑设计 context-mode 的第一步不是写代码而是做预算。你得先明确一次请求给模型的总 token 上限是多少在这个上限内各部分怎么分以常见的 8K 上下文窗口为例我通常这样分配系统指令system prompt800 ~ 1000 token描述角色、规则、输出格式。用户/业务信息user profile / business context500 ~ 1000 token包含用户偏好、关键业务数据。对话历史conversation history3000 ~ 4000 token按滑动窗口策略动态调整。工具/函数结果tool results1000 ~ 2000 token临时拼入用完即弃。当前用户输入500 ~ 1000 token。预留缓冲200 ~ 500 token防止输出被截断。这张预算表不是拍脑袋定的核心原则是**优先级高的信息给固定配额优先级低的信息动态伸缩。**系统指令是骨架必须固定对话历史是变量可以压缩工具结果是一次性的用完必须清场。我见过很多失败的方案失败原因就是没做预算。什么内容都往 prompt 里塞最终模型输入被塞爆输出被截断用户看到一半的答案。做 context-mode 的人得像产品经理一样管理 token——它是硬资源不是无限供给。2.2 上下文压缩的三种级别当对话超过预算时我们需要压缩。压缩不是一刀切而是分级别操作越靠后的级别对信息的损耗越大第一级裁剪冗余Lossless 级别去掉重复内容、空白字符、无意义的语气词、上轮对话的系统提示标记、重复的 tool call 细节。这些内容删掉不影响语义是零成本瘦身。很多人忽略了这一步实际上对话历史里冗余信息常常占 30% 以上。第二级截断旧对话Lossy 级别超出滑动窗口的旧对话直接截断。智能截断比简单截断好得多——不是从某个固定位置砍而是检测对话的“语义分界点”比如用户切换了话题、完成了一个独立任务在这些节点截断后续内容依然连贯。第三级摘要化Abstractive 级别把截断掉的历史交给一个快速小模型生成结构化摘要然后把摘要放回上下文作为“长期记忆”的替代。这个摘要不能是自由格式必须有固定模板用户核心目标是什么、哪些需求已满足、哪些待办未完成、有哪些关键约束。这三级的调用逻辑就是一个 if-else 链超预算先看冗余不够再看窗口还不够就摘要。实际做的时候我会建议把这三步封装成一个函数统一对外暴露。2.3 信息优先级谁该留在上下文里这是 context-mode 最艺术的部分。同样的对话历史有的人裁剪之后模型表现反而提升有的人裁剪之后模型直接失忆。差别在于优先级判断的维度。我做项目常用的优先级规则用户明确表述的持久性需求 临时性需求。比如“以后所有回复都用口语化风格”和“把这份报告翻译成英文”前者要长期留在上下文后者任务结束就该清掉。关键约束 背景描述。用户说“不要用 OpenAI 的接口”是硬约束出了问题就是事故而用户介绍公司业务的背景描述丢了影响不大。最新意图 早期历史。用户改口了新的指令要占当前窗口的显要位置旧指令必须被覆盖。如果新旧指令同时存在模型会纠结到底听谁的。未完成的待办 已完成的结论。用户要求“先做 A再做 B”A 做完了A 的细节可以淡出B 的细节要补强。工具报错信息 工具成功信息。成功的调用结果通常已经内化到后续对话里失败的结果必须保留否则模型会重复调同一个失败的函数。把这些优先级规则写成一个rank_context()函数每次构建上下文前对候选片段打分排序高分的留下低分的压缩或删除。这个函数就是 structured context-mode 的心脏。我实操过一个项目客户总要反复确认“我们公司用的是私有化部署不是 API 调用”。这个偏好一开始写在说明文档里会话一长就被滑窗挤掉了模型就开始胡诌“调用 API 完成”每次都要人工纠正。后来我把这种偏好提取出来做成用户持久偏好字段放进系统指令区问题彻底消失。这种“优先级判断”带来的体验提升比换更强的模型更明显。3. 实操手把手实现一套结构化 context-mode3.1 准备基础能力三层架构建起来我这里写一套生产可用的 context-mode 实现思路基于 Python 伪代码不绑定具体框架你在 LangChain、LlamaIndex 或者原生 SDK 里都能落地。第一层是ContextManager负责统筹全局持有整个对话状态决定什么时候调用压缩什么时候调用摘要。第二层是MemoryStore负责存储用 Redis 或数据库做历史归档sqlite 也行关键是能和在线对话分离。第三层是Compressor负责压缩和摘要调用一个小模型做摘要或执行规则化裁剪。这三层合起来对外暴露一个统一的接口核心就是一个类class ContextManager: def __init__(self, system_prompt: str, max_tokens: int 8000): self.system_prompt system_prompt self.max_tokens max_tokens self.user_profile {} # 用户偏好持久字段 self.history [] # 对话历史 self.tool_results {} # 工具结果临时区 self.summary # 长期摘要 self.require_buffer 500 # 输出缓冲 def build_context(self, user_input: str) - list[dict]: # 核心按优先级组装上下文 pass def add_message(self, role: str, content: str) - None: # 写入一条新消息 pass def compress_if_needed(self) - None: # 检查 token 预算超了就走压缩管线 pass这套伪代码的核心价值在于把“上下文”从无结构的一堆字符串变成一个分区的、可量化的对象。每个区都有独立的生命周期——系统指令区只增不改用户信息区低频更新对话历史区高频滑动工具结果区请求间清空。3.2 分区分优先级把 prompt 组装变成工程build_context 是组装的核心。我的实现思路是严格按照优先级顺序拼装消息优先级高的靠前中间用清晰的分隔标记。给模型看的最终消息数组我会控制在 4~5 条消息以内而不是把每条历史都单独列一条。def build_context(self, user_input: str) - list[dict]: # 1. 系统指令区角色 规则 用户关键偏好 system_text self.system_prompt if self.user_profile: system_text \n\n[用户关键信息]\n for k, v in self.user_profile.items(): system_text f- {k}: {v}\n if self.summary: system_text f\n[历史摘要]\n{self.summary}\n # 2. 对话历史区滑动窗口内最近 N 轮 recent_history self.history[-6:] # 最近3轮对话每轮2条 # 3. 当前用户输入 messages [ {role: system, content: system_text}, *recent_history, {role: user, content: user_input}, ] return messages注意几个细节把用户偏好写进 system 而不是每次以 user 消息重复是为了让模型始终把偏好当成全局约束而不是某一次的指令。历史摘要放在 system 区尾部紧跟规则之后并在对话历史之前这样才能给模型建立“先知道背景再看近期细节”的阅读顺序。工具结果不直接拼进 messages而是存放在tool_results字典里在需要的时候临时注入一条roletool的消息用完立即从上下文清除。这样的组装逻辑配合上一条消息写入时的预处理就能让消息始终处于“结构井然”的状态。很多工程问题都是在这个组装层解决的。3.3 压缩管线滑动窗口 摘要的自动协作接下来是 compress_if_needed 的实现。这个函数在每次 add_message 之后检查 token 用量超过阈值就走压缩流程def compress_if_needed(self): current_tokens estimate_tokens(self.build_context()) if current_tokens self.max_tokens - self.require_buffer: return # 第一级清洗冗余 self.history remove_redundancy(self.history) # 第二级语义滑窗——找到不破坏语义的截断点 current_tokens estimate_tokens(self.build_context()) if current_tokens self.max_tokens - self.require_buffer: return # 第三级把滑窗出去的内容做成摘要 overflow self.history[:-6] # 把最早的历史摘出来 if overflow and overflow_has_key_info(overflow): new_summary summarize(overflow, self.summary) self.summary merge_summary(self.summary, new_summary) self.history self.history[-6:]整个过程看起来简单但会遇到几个实际问题estimate_tokens 怎么估最准确的是调模型的 tokenizer 接口但生产环境为了速度通常用近似公式。中文场景一个汉字约 1.5~2 token英文一个 token 约 4 字符。我习惯在开发时用 tiktoken 之类的工具离线校准一个比例线上直接乘。remove_redundancy 怎么判断冗余结合规则同一事件被反复提及的只保留第一个和最后一个重复的工具报错只保留第一条系统级的中间状态如“天气查询中...”直接删除。summarize 用哪个模型不需要用生产大模型用一个小而快的模型就好比如 7B 级别的本地模型或高性价比的托管小模型。摘要本身只需要信息提纯不需要创造力。这里也有一些厂商的低价模型策略可用具体参数不展开了核心是慢模型做对话、快模型做摘要。merge_summary 怎么合并新旧摘要不是简单拼接是“摘要的摘要”。要让新摘要吸收旧摘要的关键点同时按时间反转更新优先级——新信息覆盖旧信息除非旧信息是持久约束。这套压缩管线的目标是让长对话环境下窗口内的信息始终是“新鲜、高价值、结构清晰”的。用户感知到的是 AI 在聊了十轮以后还能记得最初的偏好也不会因为记忆太长而开始胡言乱语。3.4 工具调用结果的临时上下文管理Agent 类应用里工具调用是 context-mode 的重灾区。我见过最离谱的方案是把 50 次工具调用的完整 JSON 全部塞进上下文结果模型输入几千行 JSON输出质量惨不忍睹。工具结果的正确管理姿势第一结果必须提炼不能原样塞。比如搜索工具返回 10 条网页内容每条 2000 字你直接把原文塞进去一条结果就烧掉几千 token。正确做法是调用一个抽取函数把标题、核心结论、关键数字、URL 提炼成 3~5 行的结构化文本。这样一来10 条搜索结果一共才几百 token。第二无关结果必须清场。上一次工具调用的结果如果已经内化为上下文或者用户话题已经切换就直接从 tool_results 里删掉。典型场景Agent 先查了天气用户又问“那帮我订餐”天气查询结果就没有保留价值了。第三只保留最近一轮工具链的关键中间状态。Agent 多步推理时A 工具的结果是 B 工具的输入B 的结果是 C 的输入这时你需要保留整条链但不能把全量结果都留着。我的做法是每个工具的结果只保留“对下一步有用的结论字段”比如查了订单状态结论字段是“已发货预计周五到达”而不是完整物流轨迹 JSON。这三点做到位工具型 Agent 的上下文使用量能降低 70%响应速度会有肉眼可见的提升。3.5 可观测性给上下文加一个仪表盘context-mode 做得再精细如果不可观测出了问题就是灾难。怎么解决我给每个关键事件埋点每次构建上下文时把预算使用情况打出来def debug_context_report(self): messages self.build_context() tokens estimate_tokens(messages) return { system_tokens: estimate_tokens(messages[0][content]), history_tokens: sum(estimate_tokens(m[content]) for m in messages[1:-1]), user_tokens: estimate_tokens(messages[-1][content]), total_tokens: tokens, max_tokens: self.max_tokens, history_count: len(self.history), summary_length: len(self.summary), }生产环境里把这些数据打到日志中心按会话维度聚合。一旦发现某个会话的 history_tokens 一直高、summary_length 一直涨就说明压缩策略没生效或者摘要合并有 bug。这种“上下文仪表盘”是排查问题最快的抓手。另外每完成一次压缩我会额外记录一条日志为什么触发压缩、压缩了几轮、摘要新增了多少字。这样后续做效果评估时就能从数据回溯当时模型“失忆”是不是因为压缩切掉了关键信息。4. 常见问题与排查技巧实录4.1 模型“失忆”到底是谁的锅用户问“还记得我之前说的那个需求吗”模型答不上来先别急着骂模型。排查顺序第一步看这条需求当时有没有被记录。很多“失忆”其实是根本就没写进上下文——不是压缩裁掉的是压根没存。这种情况要从对话写入逻辑找问题看有没有漏存消息。第二步看这条需求是否被摘要压缩了。打开日志定位摘要生成语句看摘要里有没有保留这条需求。如果摘要里没有说明压缩时摘要的 prompt 没把“关键约束必须保留”这个指令说清楚。我踩过这个坑后来给摘要模型加了两个强制输出字段persistent_constraints持久约束和completed_tasks已完成事项失忆问题大幅改善。第三步看这条需求是否和后续新指令冲突。如果用户后来改了需求旧需求被新需求覆盖本来就是正常的。这个不是 bug是设计。需要确认的是覆盖逻辑有没有生效——如果新旧需求同时存在才会出问题。排查“失忆”问题时我强烈建议给每条进入上下文的用户消息打一个 message_id并记录“本条消息在何时以何种方式离开窗口”裁剪 or 摘要。有了这条链路失忆问题从“玄学”变成“可定位的工程问题”。4.2 Token 超限输出被硬截断上下文明明按预算算好了但模型输出还是被截断这是另一个高频坑。原因通常是两类第一类是 prompt 模型计算误差。tiktoken 等工具的预估是近似值不是精确值。尤其是在中文、代码混合文本场景误差可能到 10%。解决方法是把require_buffer从 500 上调到 700~800宁可少留输入空间也要保住输出完整。第二类是输出 max_tokens 参数没设。很多 SDK 默认的 max_tokens 是 4096如果你的上下文窗口是 8K系统指令占 1K历史占 3K用户输入占 1K那还剩 3K如果模型想输出 5K 的内容就会被截断。我习惯在调用 API 时显式设置max_tokens min(max_tokens * 0.3, 2000)这样的约束既保证输出空间又防止模型一次性吐太多内容导致响应过慢。4.3 摘要失真信息被模型“脑补”摘要压缩模式最大的风险就是失真。小模型做摘要时经常把原文没有的内容“脑补”进去比如把用户可能的意图写进摘要后续模型就拿着这个编造出来的“事实”继续推理。防御措施摘要 prompt 里明确写“只允许提取原文明确出现的信息禁止推测用户意图。”摘要输出限定为“用户说过的事实 完成状态”不允许出现“用户可能想/希望/需要”这类推测句式。摘要生成后做一轮“事实回捞”用一个分类模型判断摘要中每个断言是否能在历史原文中找到证据找不到的标红人工审核或直接丢弃。如果摘要质量持续不行考虑升级摘要模型或缩短单次摘要的文本量一次只摘要 10 轮不要一次压 50 轮。4.4 工具上下文污染工具结果留在上下文里导致后续回答异常也是常见问题。典型场景Agent 调了订单查询工具拿到“订单已取消”的结果用户在下一轮问“帮我推荐几个其他商品”模型却还在回应“你的订单已取消”这件事。这类问题的根因是工具结果没有被清场。排查方式打开 tool_results 的清理日志看上一轮工具结果在哪一步被清掉的。如果压根没有清理逻辑那 bug 就在管理逻辑缺失上。我的经验准则是工具结果的生命周期是“一轮对话”。也就是说无论用户有没有接着聊工具相关话题下一轮对话开始时上一轮的 tool_results 默认清空。只有当前轮内多步工具调用之间需要跨步骤传递结果时才做临时保留并且用明确的字段标注“本结果仅用于当前轮次”。4.5 长对话性能下降不只是 token 的问题有时候 token 数量没超限但对话越长响应越慢、质量越低。这涉及两层原因第一层上下文碎片化严重。滑窗把中间的历史丢了只留头尾模型对“中间发生了什么”完全没有概念推理时只能靠猜。这个确实会表现为质量下降。解法是摘要的更新频率要跟上滑窗——每次滑出去的对话都应该及时补进摘要里让模型永远有“全局概览”。第二层KV Cache 失效。很多大模型 API 服务端对长上下文的 KV Cache 命中率不高频繁变动的历史会导致每次都要重新计算注意力矩阵延迟上升。这个层面工程上很难直接优化唯一的建议是尽量让上下文保持稳定——不要每一轮都改变 system prompt 的内容因为任何改动都会触发全量重算。换句话说固定不变的信息角色、规则尽量放在 system 的前半段变动频繁的信息摘要、用户偏好放在后半段这样缓存命中率能好一些。4.6 快速排查清单把上面这些经验浓缩成一张排查表遇到上下文管理问题直接对照操作现象优先排查点常用解法模型答非所问上下文里冗余过多核心指令被稀释先跑 remove_redundancy再调优先级排序模型“失忆”消息未被写入 / 被摘要裁掉 / 被新指令覆盖检查写入日志优化摘要保留字段校验覆盖逻辑输出被截断max_tokens 未设或缓冲太小显式设置 max_tokens提高 require_buffer回复变慢上下文频繁变动 / token 超限固定 system prompt 结构简化工具结果摘要内容不实摘要模型自由度太高强约束摘要格式加“仅提取原文事实”指令多工具链路混乱工具结果残留每轮清空 tool_results跨步骤结果做临时标注长会话成本陡增历史一直在膨胀启动三级压缩管线监控 summary_length这张表说到底是 context-mode 的“体检指标”。上线前把这个表打印出来贴在工位上出问题快速定位不用每次都从头查。5. 进阶context-mode 与 Agent 记忆体系5.1 从短期上下文到长期记忆前面讲的所有内容本质是“短期上下文管理”解决的是当前窗口内怎么装信息。但一个真正完成的产品还得解决“跨会话记忆”。用户上周跟你说“我喜欢简洁的回答风格”这周打开新会话如果你忘了体验就很割裂。这个问题的解法是记忆分级工作记忆working memory当前会话的上下文context-mode 管理的主要对象。情景记忆episodic memory跨会话的对话摘要存在数据库里按时间戳索引。语义记忆semantic memory从多次对话中抽取的用户画像、偏好、长期目标。这是最高价值的信息。context-mode 和这三级记忆的关系是工作记忆是每一轮对话的动态组装情景记忆来自旧工作记忆的摘要沉淀语义记忆则是对情景记忆的二次提炼。一个会话结束的时候就是一个很好的提炼时机。我在实践里会在会话关闭钩子中调用一次汇总函数把本次会话的关键印象打包存库作为下次会话的 user_profile 更新来源。5.2 Agent 多步推理的上下文演进Agent 场景的 context-mode 比单轮问答复杂得多。单个问题可能需要多次工具调用、多步推理每步之间的上下文都在变。我把 Agent 推理时的上下文演进分成三个阶段防御阶段初始尝试上下文里只有用户请求和系统指令模型需要先判断该做什么生成第一步的工具调用。这个阶段上下文要干净不要塞太多背景让模型有足够的注意力去规划。执行阶段工具迭代上下文逐步注入工具调用结果信息密度逐渐增加。这个阶段的关键是保持“推理链可见”上一步为什么调这个工具、结果是什么、下一步决策是什么要能形成一条清晰的链路而模型输出的 reasoning 过程也应该保留在上下文里。收敛阶段生成答案工具结果已足够上下文开始收缩把工具链路的中间过程压缩成最终结论让模型基于结论生成答案。这时候不应该再把几十步工具过程全部留在上下文里而应精炼为“我查了 X、Y、Z最终确定了 B 方案”。这三个阶段的 context-mode 策略完全不同如果从头到尾用同一套组装逻辑要么前期信息太少导致规划失败要么后期信息太杂导致输出质量下降。5.3 结构化模式的“反模式”清单做 structured context-mode 绕不开几个常见反模式列出来给大家排雷把所有历史都转成 summary。不是所有对话都值得被记忆。闲聊、寒暄、临时性沟通直接丢弃就好硬塞进摘要只会稀释关键信息。我见过一个项目摘要里记录了用户说的“今天天气不错”结果模型每次回答前都要先确认天气荒谬至极。摘要更新过于频繁。每一轮对话都触发摘要重写既浪费 token 又可能引入前后不一致。合理频率是每 5~10 轮或每次触发压缩时更新一次。角色区不分离。system prompt、用户指令、对话历史全混在一起。这样模型无法区分“哪部分是系统约束、哪部分是用户临时意图”如果用户突然说“别听系统指令”模型可能真的会混乱。分区不仅是为了工程清晰更是为了模型理解信息层级。没有运行时监控。context-mode 是一套动态系统不在运行时监控就没法知道它在什么时候失效。上线前必须把日志和指标做起来至少包含 token 用量、压缩触发次数、摘要长度变化量、历史消息条数这四项。5.4 用 context-mode 做应用效果优化场景化一点你要做一个行业垂类问答助手比如企业内部的规章制度答疑。用 context-mode 的思路整个应用可以这样设计用户提问时先把问题做意图分类是问制度细节还是问流程步骤还是问主管意见。根据意图拉取相关的制度文档片段放进“业务上下文区”而不是把整本制度手册全部塞进 system。检索这一步用 RAG取 top 5 片段每段控制在 300 字以内。对话历史按滑动窗口管理历史窗口内用户的身份职级、部门、历史偏好会写入 user_profile。比如用户上次问了年假规则这次又问请假流程上下文就知道他的关注点给出符合他身份的答案。每个会话结束时把“用户关注焦点”更新进用户画像下次会话直接注入 system prompt。这是 context-mode 在实际产品里的完整样例——不只是“怎么存”更包括“怎么取、怎么用”。系统表现比简单拼接文档的做法无论是体验还是准确率都会好上几个台阶。6. 写在最后的实操心得我个人做 context-mode 这些项目的最大体会是这个“模式”从一开始就不是一个库、一个框架能解决的。它是一整套关于“信息取舍”的工程哲学。同一个模型用不用 context-mode效果可能差一个档次。这里有几个我从实战里沉淀出来的铁律分享给正在做的朋友第一条永远为输出预留空间。我做任何上下文组装时都会在系统层锁死一个最低输出缓冲。宁可让模型多看 500 token 的上下文也不能让一次关键回复被截断。用户能接受模型答得慢但不能接受模型答一半。第二条摘要模型必须和主模型分开。别让同一个模型既做对话又要压历史。主模型实时交互压不起小模型做后台任务划算得多。这也是成本控制的关键生产环境省 token 就是省真金白银。第三条优先级规则要接受“脏”数据。用户画像不是一次就能提取准的要允许通过后续对话不断修正。我在 user_profile 里加了置信度字段置信度低于阈值的偏好不注入上下文宁可少记不能记错。第四条先让系统跑起来再做优化。context-mode 的完美方案不存在滑动窗口多大、摘要多久更新一次这些参数必须在真实对话数据上调试。先做一版简单的上线收集数据再逐步调优。空想出来的参数落地基本都会遭打脸。如果你正准备给自己项目设计 context-mode我建议把本文第 2 节的预算分配表、第 3 节的压缩管线和第 4 节的排查清单抄下来直接当开发 checklist 用。踩过的坑都在这了剩下的就靠你的数据和场景去打磨了。