最近大半年我一直在折腾LLM应用尤其是带记忆、带工具的Agent方向。做得越多越发现一个绕不开的坎上下文。模型本身确实聪明但上下文窗口就那么大把几十轮对话、工具返回结果、历史总结一股脑塞进去第一是贵第二是慢第三是模型容易“看花了眼”——它会把很老的信息当成最新依据一本正经地给出错误结论。为了解决这个问题我整理了一套方案内部代号就叫context-mode。它核心是给上下文处理加了一个“模式”概念在保留信息密度和压降成本之间做动态权衡。如果你也在做AI应用、做智能化工作流或者只是用LLM API写一些复杂的自动化任务这篇笔记应该能帮你少走不少弯路。我会把设计思路、核心实现、参数调优和踩坑记录全部摊开讲代码部分直接可以抄。1. 为什么需要一套 context-mode先聊聊我踩过的上下文坑1.1 上下文窗口不是“越大越好”很多人一开始的想法是上下文窗口不够换更大的模型不就行了。但实际用下来会发现大窗口带来的问题比想象中多。第一个问题是费用非线性增长。OpenAI、Anthropic 这些家的 API 都是按 token 计费的输入和输出分开计价。你以为多塞几万字历史记录没多少钱算一下吓一跳。假设每轮对话有 30K token 的历史一个用户来回聊 10 轮就白白烧掉 300K token 的输入费用而且这些历史里可能一半以上是无关紧要的寒暄。我自己有个项目上线第一周 token 账单比服务器账单还高问题就出在上下文上。第二个问题是**“Lost in the Middle”效应**。研究早就证明LLM 对位于长上下文中间部分的信息最不敏感。你把关键约束放在第 80K token 的位置模型大概率直接忽略。我做过实验同样的一个需求放在 prompt 开头和放在第 60K token 位置模型输出质量差异非常明显后者经常漏掉关键条件。第三个问题是延迟。上下文越长模型处理时间越长用户的体感就是从“秒回”变成“转圈圈”。尤其在做 Agent 的时候调用工具本身就要好几秒上下文再一膨胀整个流程可以用“窒息”来形容。所以“大窗口”不是银弹真正要解决的是如何把必须的上下文留下来把不必须的挡在外面。1.2 不加管理的现场到底有多乱我早期做过一个项目管理的 Agent它会调用代码检索工具、文档搜索工具还要记录用户的项目偏好。最初版本非常天真每次请求都把完整的聊天记录、所有工具返回结果、好几份项目文档塞进 context。跑了不到一周问题集中爆发第 4 轮对话时Agent 还在参考第 1 轮的错误信息导致它反复推荐一个已经被用户否掉的方案。工具返回了大量代码片段有些是 500 行起步。这些代码确实被模型读进去了但真正要用的可能是第 300 行那个函数模型反而抓不住重点。一次长会话结束后我去后台看日志发现单次请求的输入 token 超过了 90K其中 70% 是重复的、过时的、低价值的内容。那个阶段我几乎每天都在“救火”不是修 bug而是在修上下文。后来我决定彻底重构参考操作系统里的上下文切换思路设计了一套带模式的上下文管理模块也就是现在的 context-mode。2. context-mode 的三种模式我是怎么设计的2.1 Flow 模式忠实传话但别乱用Flow 模式是“完整携带”策略。在这个模式下系统把所有对话原始记录、工具返回、系统状态直接拼装成 prompt 传给模型中间不做删减最多做格式化处理。什么场景下必须用 Flow我认为有三类代码生成与重构模型需要看到完整函数、完整文件结构才能保证改动不破坏其他逻辑。这时候压缩反而有风险。多步推理链复杂的数学推导、逻辑推理场景中间过程丢失会直接导致结果错误。用户强依赖上下文的创作类任务比如让模型帮你写小说角色设定、前文伏笔、人物关系都是核心资产不能丢。我把 Flow 模式设成系统默认模式但不是因为它最好而是因为它最稳。稳的意思是输出的下限有保障但上限被窗口限制。Flow 模式通常配合一个阈值使用——当上下文体积超过设定值必须自动切换到其他模式否则就是烧钱。2.2 Compact 模式把故事讲短把关键信息留住Compact 模式是“压缩携带”策略。它的思路和给人做工作汇报一样不是把一整年的聊天记录一页页贴给老板看而是提炼成“目标、进展、决策、风险、下一步”。在做压缩时我提炼了五类必须保留的信息用户明确表达过的偏好和禁忌比如“我不喜欢用 Elasticsearch”这种强约束。已经做出的决策和结论比如“技术方案选型定为 Python FastAPI”。未完成的任务和待办事项模型需要知道接下来该干什么。关键事实和数字比如配置的服务器地址、接口返回的核心数据。正在执行的计划状态当前进行到哪一步。Compaction 不是简单调一次 summarize 接口就完事。我在实践中发现一次性压缩长上下文容易丢失细节所以我会分层压缩先按对话轮次切块每块压缩成短文再把短文压缩成最终摘要。这个过程类似“先做章节摘要再做全书摘要”信息丢失率明显降低。Compaction 模式适合多轮客服、教学辅导、项目协作这类场景用户不会每次都把需求从头说一遍模型需要记住之前聊过什么但又不值得把原始记录全部带上。2.3 Retrieval 模式把记忆从 prompt 里搬出去Retrieval 模式是“按需携带”策略。思路是把所有原始信息存到外部存储里prompt 只带当前最相关的内容。这彻底摆脱了“全部塞进窗口”的思维惯性。实现上我用了两套存储结构化存储数据库存用户信息、项目信息、任务状态这些强结构化数据。查询精确开销低。向量存储存对话历史、文档片段、代码片段。用 embedding 做相似度检索。每次构造 prompt 之前系统会根据当前的用户输入、任务类型、活跃实体主动查一次最相关的片段。比如用户在问“上次那个数据库连接池的问题”系统就去从向量库里检索“数据库连接池”相关的对话记录和文档片段只返回最相关的几条。Retrieval 最大的好处是理论上的上下文体积可以控制得很小。哪怕历史有 1M token每次实际带进 prompt 的也可以压在 5K token 以内。坏处是检索质量直接决定生成质量——如果召回的内容不对模型再聪明也白搭。所以 Retrieval 模式不能单独用通常要搭配一个低成本的确认机制比如让模型先列一下它找到的关键信息确认后再往下走。三种模式我做了个对比方便你按场景选型模式上下文体积信息密度成本适合场景Flow高全量中噪声多高代码重构、推理链、创作Compact中压缩高中多轮对话、客服、协作Retrieval低按需高有取舍低知识库问答、长期记忆、Agent 工具链3. 核心实现细节这些代码才是跑得稳的关键3.1 先算清 token再谈管理上下文管理的第一步不是压缩也不是检索而是准确计算 token 数。很多初学者用 Python 的 len() 数字符这完全不对。同一个字符串不同模型用的 tokenizer 不同算出来的数量可能差两三倍。我自己的项目早期犯过这个错设置了一个 8K token 的压缩阈值结果 8K 字符就触发了压缩上下文根本没利用满。现在我的所有项目统一用 tiktoken 来计算 OpenAI 系模型的 token其它模型用对应官方的 tokenizer 库。一个标准的封装长这样import tiktoken def count_tokens(text: str, model: str gpt-4o) - int: 估算文本对应的 token 数 try: encoder tiktoken.encoding_for_model(model) except KeyError: # 如果模型不在 tiktoken 的预置列表里可以手动指定编码 encoder tiktoken.get_encoding(cl100k_base) return len(encoder.encode(text)) def count_messages_tokens(messages: list, model: str gpt-4o) - int: 计算多轮消息的 token 数包含角色标记和格式开销 total 0 for message in messages: total 4 # 每条消息的格式开销 total count_tokens(message.get(content, ), model) if message.get(role): total 1 total 2 # 回复助手的格式开销 return total注意 count_messages_tokens 里那几行固定开销不是乱写的OpenAI 官方文档里明确了每条消息的格式会计入 token 消耗。做上下文管理如果不算这些最终统计会和账单对不上。3.2 自动模式切换的逻辑怎么写设计模式是一回事系统怎么决定“什么时候用哪种模式”是另一回事。我给 context-mode 设计了一个轻量的自动判断流程核心逻辑就是判断当前上下文体积和会话阶段。伪代码如下def decide_mode(context: Context) - Mode: # 1. 如果当前会话 token 数低于安全阈值直接用 Flow if context.total_tokens context.flow_max_tokens: return Mode.FLOW # 2. 如果上下文已经很大但当前是一个需要精确信息的任务走 Retrieval if context.task.type in (code_generation, multi_step_reasoning): return Mode.RETRIEVAL # 3. 如果上下文很大且任务对历史有依赖但不需要全量细节走 Compact if context.total_tokens context.compact_trigger_tokens: return Mode.COMPACT # 4. 兜底默认还是 Flow保证下限 return Mode.FLOW这套逻辑看起来简单但有个关键点容易被忽略模式切换本身不能太频繁。如果系统每轮都在三种模式之间横跳模型每次收到的 prompt 风格都不一样反而会导致它困惑。我后来加了一个“模式粘滞”机制切换模式后至少保持 3 轮除非上下文体积超出硬性上限否则不切。另外切换时机也很讲究。我踩过的一个坑是在对话中间切换模式会导致模型丢失正在处理的任务上下文。比如用户正在让模型分步骤实现一个功能步骤进行到一半系统做了压缩切换模型就忘了当前步骤了。解决办法是不在任务执行中途压缩而是等当前任务一轮完整结束后再触发切换。3.3 压缩时到底保留什么Compact 模式的实现我换过好几个版本最早是简单粗暴地调用 LLM“请总结以下对话”。效果能看但信息丢失很严重。特别是那种“用户说过一句不经意的要求二十轮之后开始验收”的场景普通摘要根本留不住这种细节。后来我改成基于“信息分类”的压缩提示词效果好了很多。每次压缩时我要求模型严格按以下类别输出压缩结果用户画像用户的角色、风格偏好、明确喜好。需求闭环用户提过的所有需求标注哪些已完成、哪些进行中、哪些被拒绝。关键决策凡是出现过“确定用 A 方案”这类表述的必须记录。悬而未决的问题用户表示过疑虑、需要进一步确认的点。技术事实代码结构、接口约定、数据格式等硬信息。压缩的提示词模板大概长这样请将以下对话压缩为结构化摘要。要求 1. 只保留重要信息忽略寒暄、对当前任务无影响的闲聊。 2. 明确区分【已完成】【进行中】【已拒绝】的事项。 3. 任何带否定含义的偏好必须记录例如“不需要XX”“不要用XX”。 4. 数字和专有名词必须原文保留不得改写。 5. 输出格式使用 Markdown 列表按照用户偏好、关键决策、进行中任务、已完成任务、待讨论问题、技术事实 六个标题组织。另一个值得注意的是压缩的触发频率。我试过每轮都做增量压缩结果 token 开销反而更大而且增量压缩会越压越“失真”——模型在不完整信息上做二次压缩错误会被放大。现在的做法是只压缩一次压缩结果以独立消息追加到会话里并清理被压缩的原始消息区域。后续对话基于压缩摘要继续而不是反复压缩同一段内容。3.4 Retrieval 模式里的存储与召回Retrieval 模式要落地核心是两个东西切分策略和召回排序。切分策略上我踩过比较深的坑是“固定字符切分”。最开始把对话记录每 500 个字符切一段存进向量库结果检索出大量语义断裂的碎片。后来换成按对话轮次切分——每一轮完整的用户提问 AI 回答作为一个单元。如果单轮内容太长再按 Markdown 标题或段落边界拆分。实测召回结果的质量提升非常明显因为每一段都是完整的意义单元。召回排序上我一开始只用向量相似度问题是有时候检索回来的内容确实是“相似的”但不是“有用的”。比如用户问“帮我看看日志里的报错”检索回来的可能是之前另一次报错的讨论虽然关键词相似但不解决当前问题。我现在的做法是混合排序向量相似度作为一个维度同时用 BM25 做一次关键词匹配最后做加权融合。权重我调到了 0.6 向量 0.4 关键词效果最均衡。别小看这个融合它能同时兼顾“语义相近”和“字面匹配”对技术问答场景特别管用。4. 参数配置与调优经验4.1 核心参数速查表context-mode 能跑起来很大程度靠参数。我把自己项目里沉淀的参数写成了一张表这些值来自多轮压测可以作为一个起步参考但具体项目还是要自己测。参数默认值经验范围说明flow_max_tokens80006000-12000低于该值直接走 Flow不压缩compact_trigger_tokens1200010000-16000上下文超过该值且任务适合压缩时触发 Compacthard_limit_tokens2000016000-24000硬性上限超过必须走 Retrieval 或裁剪retrieve_top_k53-8每次检索返回的片段数量retrieve_chunk_size1500800-2000单个检索片段的 token 上限mode_sticky_rounds32-5模式切换后最小保持轮数cache_ttl36001800-7200上下文缓存过期时间秒summary_max_tokens1000800-1500压缩摘要的目标 token 数需要注意max_tokens不是说设得越大越好。我试过把flow_max_tokens从 8000 提到 16000以为能多撑几轮再压缩结果模型在 12K token 的时候就开始“找不到重点”答非所问。后来我才意识到模型的注意力是限量的不是上下文能装多少它就能用好多少。设置阈值时宁可保守一点也要保证模型在“舒适区”内工作。4.2 从 200K 压到 16K一次真实调优记录我有个知识库问答项目早期是直接让模型读一个 200K 字符的项目文档再回答用户问题。结果就是响应慢、费用高、准确率低。后来我把它接入 context-mode一步步压体积。第一步把文档拆成段落存进向量库设置retrieve_top_k5和retrieve_chunk_size1500。这样单个文档片段被控制在 1500 token 以内5 个片段最多 7500 token加上用户问题和其他系统提示词总上下文可以压在 10K 以内。第二步测试发现有些问题需要跨章节信息单纯检索召回不到。我引入了“二次检索”第一轮用用户问题召回然后把召回结果拼接成一个临时摘要再基于摘要做一次检索。这个策略对“多个功能组合”类的问题特别有效比如“我想在登录页面加上验证码同时记录登录日志”第一轮检索可能只找到验证码相关的章节二次检索才能把日志功能的章节也带出来。第三步给高频问题加了一层静态缓存。完全相同的用户问题直接命中缓存不再跑任何检索和生成流程。这个改动省了大头成本因为知识库场景里用户问题高度重复。调优过程的跟踪数字大概是这样的优化前单次请求平均输入 50K token响应时间 15 秒准确率 68%。优化后单次请求平均输入 9K token响应时间 6 秒准确率 87%。有意思的是准确率反而提升了。原因很直接模型拿到的信息更聚焦干扰少了回答自然更准。4.3 结合业务定好评估指标上下文管理做得好不好不能靠感觉必须量化。我自己的项目里长期跟踪四个指标任务完成率模型是否正确完成了用户目标。这是最宏观的指标。单轮 Token 消耗包含输入和输出。它直接反映成本。单轮 P95 延迟最慢的那批请求耗时不至于拖垮体验。上下文命中率检索回来的片段里有多少真正被模型引用。这个指标偏软性但能反向验证检索质量。这四项里我会死死盯住“单轮 Token 消耗”。它是先行指标token 涨起来后面三项大概率跟着出问题。我习惯每天看一次这个数字的走势如果连续三天上涨就去查是不是某个工具返回的内容变大了或者会话轮数增加了。5. 常见问题与排查技巧实录5.1 问题速查表我把实际运行中遇到的典型问题汇总成了一张速查表基本覆盖了会踩的大坑问题可能原因解决方式模型重复使用旧信息过期内容没及时从上下文移除在工具返回结果里加入“数据时间戳”让模型能分辨新旧压缩后模型“忘了”关键要求压缩提示词没强制保留偏好类信息在压缩模板中单独设置“用户偏好”分类并注明“必须保留”检索结果与问题无关向量切分粒度太粗或太细改为按对话轮次切分配合 BM25 混合排序Token 统计和账单对不上忘了计算消息格式开销用官方 tokenizer 按消息维度统计加入角色标记开销模式切换后回答风格突变切换频率过高模型无所适从设置模式粘滞轮数至少保持 3 轮工具返回大 JSON 导致上下文爆炸没有对工具返回做结构化裁剪提取关键字段移除无用字段必要时用摘要替代完整返回长会话中前期信息被后期覆盖上下文窗口有容量上限前期信息被物理丢弃定期对转折点做摘要并主动写入新的会话状态其中“工具返回大 JSON”是 Agent 场景里最常见的问题。我建议对工具返回一律做一次“字段裁剪”比如一个返回用户详情的接口有 30 个字段实际用到的可能就 5 个其余全是冗余。写一个白名单配置比让模型自己判断高效得多。5.2 我一直在用的一个 debug 小技巧排查 context 问题最痛苦的是“黑盒”——模型给了错误答案你猜不到它是哪一步拿错了上下文。我养成了一个习惯给每次请求都打一个 tracking_id并记录一份“上下文快照日志”。快照里包含三样东西当前使用了哪种模式Flow / Compact / Retrieval实际发送给模型的消息列表完整内容放在日志里检索召回的所有片段以及各自的相似度得分有了这个日志模型回答不对时我可以直接回放“当时模型看到了什么”。很多时候问题一眼就能定位比如发现检索召回了 5 个片段但相关的内容只出现在第 3 个而被模型忽略的恰是第 3 个。这种情况就去调召回排序而不是盲目调 prompt。这个技巧的成本并不高就是在中间件里多写一段日志代码但对排查问题的效率提升是指数级的。没有日志的 context 调试就像闭着眼睛开车有了日志相当于给了你一盏远光灯。5.3 几个容易忽视的细节坑最后分享几个特别容易被新手忽视的坑。第一个是检索降级。Retrieval 模式不是万无一失召回结果可能为空也可能质量很差。一定要设计降级策略当所有检索片段的相似度都低于某个阈值比如 0.3时不要硬把不相关内容塞给模型而是直接告诉模型“外部知识库未检索到相关信息请基于已有知识回答”。否则模型会被一个看起来相关但实际毫无帮助的片段带着跑偏。第二个是摘要递归失真。连续多次压缩摘要最后模型记住的内容可能已经面目全非。我的对策是每轮摘要都带上原始时间范围标记并保留压缩前的关键实体名称禁止在压缩时改写专有名词。如果摘要内容超过两次迭代必须回到原始记录重新压缩。第三个是缓存要注意会话隔离。如果你做多租户系统缓存 key 必须带上用户维度否则 A 用户的上下文会被 B 用户请求命中轻则串味重则造成信息泄露。我见过有人因为缓存 key 少了 user_id导致用户 A 的问题里出现了用户 B 的项目信息这种事故要坚决避免。6. 我在实践中的几个建议跑了大半年 context-mode我自己形成的默认策略是系统默认走 Compact复杂任务显式切 Retrieval所有任务设置 Token 硬上限。Compact 作为日常模式的好处是它总能保住“关键信息 最近对话”不会像 Flow 那样烧钱也不会像 Retrieval 那样有召回失败的风险。等任务变得复杂了比如用户在做一个多文件重构系统便自动切到 Retrieval用外部存储分担窗口压力。另外强烈建议在所有接入了 context-mode 的请求上都做一次空跑测试把实际 prompt 打出来人工读一遍问自己“如果你是这个模型你能根据这段 prompt 完整回答用户问题吗”不用多每个功能测两次就能过滤掉 80% 的上下文设计问题。很多你觉得理所应当的信息模型实际上看不到只有把 prompt 真正打出来复盘才会发现那些隐藏的信息缺口。context-mode 不是某个固定的库或框架它更像一套关于“如何对待上下文”的方法论和代码结构。只要理解了模式的价值、核心实现逻辑、参数调优思路你可以把它应用到任何 LLM 项目里。希望这篇笔记能帮你少踩一些我踩过的坑。