做AI应用的同学十有八九都会遇到一个很实在的问题聊着聊着模型就忘了前面说过什么。于是各种方案冒出来有人把历史消息无脑全塞进去有人干脆什么都不带。前者token爆炸后者体验断片。真正靠谱的做法是给系统设计一套明确的 context-mode——也就是在运行时以什么样的策略去收集、筛选、组织并注入上下文信息。这篇文章把这件事拆开讲透你既能看懂原理也能直接照着落地。咱们先把受众说清楚。如果你正在做客服机器人、办公助手、编程助手或者任何一个“需要记住用户上一句话”的产品这篇内容都值得看完。我聊的不只是理论更多是工程上怎么选、怎么实现、怎么排查。下面的内容会集中在 AI 会话类应用的 context-mode 设计上其他领域如果也有类似叫法思路同样可以迁移。1. 先搞清楚context-mode 到底解决什么问题1.1 没有上下文和有了上下文差别到底有多大我经常用订单查询这个例子来给同事讲上下文的重要性。用户第一句问“我买的那双鞋到哪了”第二句问“那还能退吗”。假如没有上下文系统拿到第二句时并不知道“那”指的是“那双鞋”只能先反问“请问您说的是哪件商品”多来几轮用户就烦了。有了上下文系统知道当前讨论对象是那双鞋、订单状态是运输中、用户的诉求是想退。它就能直接回答运输中的订单通常需要先签收再申请售后。这一来一回体现的就是 context-mode 在真实场景里的价值。它解决的不是“模型会不会说话”而是“模型有没有足够的背景信息去理解当前这句话”。没有上下文再强的模型也会变成一台没有记忆的复读机。1.2 context-mode 不是调参而是一整套取舍很多人会把上下文问题和模型参数混为一谈以为换个更大的模型或者调高 temperature 就能解决记忆问题。实际上模型参数决定的是生成风格和发散程度跟上下文是否完备完全是两回事。context-mode 的本质是一套关于“信息取舍”的显式规则。往大了看它至少决定了三件事第一哪些信息有资格进入上下文第二信息以什么形态进入上下文是原文、摘要、结构化字段还是检索片段第三进入之后按什么顺序排列、占多大权重。这三件事每一项都需要结合业务来做取舍。全量携带在短会话里没问题但会话一长要么超预算要么把模型的注意力稀释掉。什么都不带又回到了“失忆版”产品。好的 context-mode通常都落在两者之间并且可配置、可观测。1.3 什么场景下最需要较真地设计它我的经验是有三类场景最值得在 context-mode 上下重功夫。第一类是长会话客服。用户可能跟机器人聊了40轮涉及好几个订单和售后单如果上下文管理不好极容易把A订单的信息套到B订单上。第二类是编程助手模型需要同时知道当前文件、最近的报错信息和用户刚刚改过的函数这三者分属不同来源必须按规则动态合并。第三类是企业知识库问答此时不仅要有历史对话还要有“当前检索到的文档片段”历史信息决定了模型怎么理解问题检索片段决定了模型拿什么来回答。这三类场景的共性是数据来源多样、信息量随时变化、注入错误代价高。如果只是简单拼历史文本很快就会被各种信息淹没。2. 拆开看一个合格的 context-mode 要管哪几件事2.1 上下文的采集与建模先有数据才有策略很多人一上来就写过滤规则其实第一步应该是建模。先想清楚你的上下文里到底有哪些数据类型。以客服助手为例至少包含五类。用户画像比如会员等级、常用收货地址。会话元信息也就是session id、开始时间、当前所在流程。对话历史包括用户消息、助手消息、中间产生的情感标签或意图标签。业务状态比如当前正在处理的订单号、售后单状态。外部检索结果也就是从知识库召回的相关文档片段。把这些统一建模成结构化的上下文对象比直接拿一个长字符串当上下文要好得多。一方面它方便程序做筛选和排序另一方面它也方便在出问题时定位是哪个字段带错了。2.2 挑选与过滤不是所有历史都值得带上这一节是 context-mode 最核心的部分怎么从一堆候选信息中挑出真正有用的部分。我先说一个最常见的错误把最近20轮对话全部带上。看起来是“保留上下文”实则很多历史信息已经跟当前问题无关了。比如用户中途查过一次物流、问过一次优惠券然后回到售后问题物流和优惠券的细节就是干扰项。比较实用的做法是“时间窗口相关性”双通道。时间窗口保证近期信息一定在场相关性通道则从更长的历史里检索与当前意图匹配的片段。过滤规则可以包含重复内容只保留最近一次已经完结的流程只保留结论不保留过程与当前意图语义相似度低于阈值的直接丢弃。还可以做一些加权。我给历史消息打分时常用的公式是语义相似度占0.6时间新鲜度占0.3关键槽位匹配占0.1。分数低于阈值的就不注入。这个比例不是固定的但有了可计算的分值总比拍脑袋强。2.3 过期与衰减让旧信息合理退场上下文并不是越久越好。我见过最典型的翻车现场用户一个订单早就取消退款了系统还带着“订单运输中”的旧状态上下文导致模型一本正经地建议用户“留意签收”。这里的关键是要区分“静态历史”和“动态状态”。对话历史是静态的它只是记录当时说了什么可以保留业务状态是动态的比如订单状态、库存数量必须以业务数据库为准。旧对话里的状态描述只是“当时快照”不能作为当前事实。实操上我会给上下文里的每个信息块加一个 freshness 标记并配合事件驱动清除。比如订单状态从“运输中”变成“已取消”就把该订单相关的业务快照从上下文中移除而不是等它自然衰减。固定时间衰减适合用在对话题材上越老的语句权重越低但业务状态必须靠生命周期管理。2.4 budget控制与注入顺序别让超长上下文毁掉整个prompt上下文总量是有限资源尤其是输入token限制。我习惯把上下文预算当成硬约束来设计先算总量再定分配最后定顺序。举个例子。假如模型输入上限是8000 token系统提示词占1000输出预留500那么上下文最多只能占6500。在这6500里我会给业务状态留1000给用户画像留500给对话历史留3000给检索片段留1500其余500作为波动余量。注入顺序同样重要。模型往往对开头和结尾更敏感。硬约束和全局规则放最前面检索得到的资料放中间最新的用户意图放最后。很多人习惯把历史一股脑放在当前问题前面偶尔可行但一旦历史很长模型的注意力容易被旧信息分走导致答非所问。3. 实战落地给 AI 助手设计一套最小可用的 context-mode3.1 先把上下文的 JSON 结构定下来概念聊完了落地要看代码。我习惯先把上下文对象设计成 JSON Schema原因很简单有了结构后续做过滤、排序、序列化都有了抓手。{ schema_version: 1, mode: selective, session: { session_id: sess_001, created_at: 2025-06-01T10:00:00Z }, user_profile: { level: gold, region: 华东, last_seen_ts: 2025-06-01T10:32:00Z }, business_state: { order_id: ORD20250601, order_status: shipping }, history: [ { role: user, content: 我买的那双鞋到哪了, intent: check_order, ts: 2025-06-01T10:31:00Z }, { role: assistant, content: 订单OR20250601正在运输中。, ts: 2025-06-01T10:31:15Z } ], retrieved: [ { source: knowledge_base, doc_id: kb_return_policy, snippet: 运输中订单不支持直接退货需签收后申请售后。 } ] }字段的意义我就不啰嗦了重点说两个容易被忽视的细节。history 里每条消息都带 intent 和 ts这是后面做筛选和打分的重要输入。retrieved 单独拉出来不混在对话历史里是为了在组装 prompt 时能清楚地区分“模型自己说的”和“外部知识”。3.2 让过滤规则和优先级有数可算有了结构化数据接下来就要定规则。我建议把规则拆成两类。第一类是确定性规则不需要模型参与。比如相同问句只保留最近一次纯表情、纯语气词不进入上下文已完结订单相关的过程性消息只保留最终结论。这类规则简单直接跑起来快适合处理大量重复噪声。第二类是模型参与的相关性过滤比如用 embedding 给历史消息和当前用户输入算相似度低于阈值的丢弃。分两层的设计有个明显好处确定性规则先帮我们把体量降下来再做相似度计算成本和延迟都会低很多。优先级排序我也会显式地做出来。大体顺序是系统硬约束不可动摇的规则比如安全策略优先级最高接着是当前业务状态然后是检索到的知识片段再往后是近期对话历史最后才是长期偏好类信息。这个顺序不是绝对的但有一个原则越不能被篡改、越不能出错的信息越要靠前。3.3 最小可行的伪代码实现下面这版伪代码是我在项目里实际用过的结构去掉了业务细节保留了核心逻辑。def build_context(session, current_turn, rules, budget_tokens): context load_schema(session) # 读 JSON Schema candidates collect_candidates(session) # 收集候选信息块 # 先跑确定性规则快速降噪 candidates apply_deterministic_rules(candidates, rules) # 再算相关性分数按分数召回 scored [] for item in candidates: score (0.6 * semantic_sim(item, current_turn) 0.3 * recency_score(item) 0.1 * slot_match_score(item)) if score rules.score_threshold: scored.append((item, score)) scored.sort(keylambda x: x[1], reverseTrue) # 预算控制超出就丢掉分数最低的块 total estimate_tokens(scored) while total budget_tokens: item, _ scored.pop() total - estimate_tokens([item]) # 按注入顺序重新排列 ordered sort_for_injection(scored) return assemble_prompt(context, ordered, budget_tokens)几个细节值得说。score_threshold 通常设在0.35到0.5之间我一般先用0.4起步再根据线上召回效果调整。budget_tokens 是硬上限宁可在边界上丢掉低分内容也不能超预算导致请求失败。sort_for_injection 会单独处理排序逻辑把最新意图放在最后让模型把注意力集中在当前任务上。3.4 换个思路从“带多少”到“缺什么补什么”调试几轮之后你会发现按历史条数来设计上下文很容易掉进“带得越多越安全”的陷阱。我后来慢慢调整思路先问“当前这轮请求缺什么背景”再倒着去搜数据。举个例子。用户当前的问题是“那还能退吗”系统缺的信息是“那指的是哪个订单”和“这个订单当前是否允许退”。于是程序会优先去 business_state 里拿订单状态再去 knowledge_base 里检索“运输中订单的退换货政策”而不是把过去20轮对话全部搬进来。这种按需拉取的思路既控制了长度也提高了信息密度。实现上无非要做好两件事一是把“缺失项”定义清楚二是针对缺失项建好索引或检索路径。前者靠业务梳理后者靠向量检索或结构化查询都不算复杂。4. 常见问题与排查技巧实录4.1 上下文污染聊着聊着模型被旧信息带偏最常遇到的问题是上下文污染。典型症状是这轮明明是在聊新订单模型却还在参考旧订单的物流信息回答出来就是串台。排查思路是先看注入的数据。我会在日志里把每轮实际发送给模型的上下文打出来重点看两个地方业务状态有没有被更新旧的意图标签有没有残留在 history 里。解决办法通常有三个。第一业务状态字段在每次请求前都从数据库拉最新值绝不在内存里积攒。第二不同会话的上下文严格隔离session_id 是硬隔离边界。第三在关键节点主动触发 context reset比如用户说“算了换个问题”就把旧流程的上下文标记为废弃。我见过很多团队忽略第三点其实主动放弃旧上下文往往比费力挽留更省心。4.2 信息过时上下文里的“事实”已经变了上下文里最危险的不是没有信息而是有过时信息。特别是业务状态比如订单状态、库存数量、预约时间一旦上下文里的信息和数据库不一致模型就会一本正经地给出错误答案。我自己的处理原则很简单对话历史里提到的状态都只是“当时的说法”绝不当作当前事实。当前事实一律以 business_state 的实时查询结果为准。在代码上我还会给历史消息和业务状态分别打上 scope 标签组装 prompt 时用不同前缀区分。比如业务状态前缀是“[当前状态]”历史消息前缀是“[历史对话]”模型看到这两种前缀对信息可靠度的判断就会更准确。4.3 token预算怎么算超了怎么办很多项目出问题不是规则写得不好而是预算没算明白。我建议在代码里单独写一个 token 估算函数用模型的 tokenizer 对每个信息块做估算而不是粗略用“字符数除以4”。前者准后者偏差大。预算分配建议按这张表来设计数据类型分配比例说明系统硬约束15%安全规则、输出格式要求必须在场业务状态10%当前订单、用户、流程状态优先拉最新检索片段25%外部知识按相关性强弱截断对话历史40%时间窗口相关性过滤后剩余的部分余量10%给突发情况留缓冲避免请求失败如果还超优先丢对话历史其次丢检索片段里的低分段。业务状态和系统硬约束基本不丢。这个降级顺序可以写进配置让线上稳定运行时自动生效。4.4 调试点让上下文可观测context-mode 最怕黑盒。我看过不少项目上下文策略写得花团锦簇线上效果一塌糊涂问数据拿不出来只能靠猜。我的习惯是给每个请求打一条摘要日志记录这次注入了多少条信息、哪些来源、总 token 数、被丢弃的最具争议的信息块有哪些。不一定要全量保存内容但至少要保存元信息方便事后统计哪种来源的上下文对回答贡献最大。我还会定期抽样看三类数据历史信息的命中率被检索到并注入的比例、答非所问的比例、超预算后降级的比例。这三类数据能反映 context-mode 的健康度。如果答非所问比例突然上升先去看是不是注入顺序变了如果超预算降级比例过高再去看是不是过滤规则阈值太低。5. 最后分享一点个人心得聊到最后说点我自己的体会。context-mode 这种东西最容易踩的坑不是技术不会而是过度设计。我有段时间给调度任务排序加了一堆权重代码很漂亮结果调参比写功能还费劲。后来想明白了大多数业务先做好数据建模、预算控制、相关性过滤就已经能覆盖九成问题。剩下的花哨策略等数据告诉你确实需要再加。还有一个私藏的小技巧每次改动上下文策略先做小流量对比把“改了之后答非所问有没有下降”这类指标盯住。不要靠感觉判断让线上数据帮你做决策。这个思路顺手分享给你。