1. context-mode 是什么以及它解决的真实问题做对话类应用、智能体项目或者任何带“记忆”的系统时最绕不开的一个环节就是上下文管理。我在自己的项目里折腾过不少方案踩过内存爆掉、上下文串号、长对话越聊越笨这些坑之后逐渐沉淀出一套思路也就是这里的 context-mode——严格说它不是某个特定框架的功能名而是一类设计模式的统称消息上下文在不同业务场景下应当用不同策略来组织、压缩、存取和轮换。举个例子客户服务机器人可能只需要最近几轮对话就能完成意图识别但一个做深度访谈的智能体需要记住用户半小时前提到的一个细节这种差异决定了你不能用一种“铁板一块”的上下文策略应对所有场景。context-mode 的价值正是在于把上下文处理拆成几种明确模式每种模式下有独立的存储结构、窗口策略和压缩规则调用方按场景选择并动态切换。这篇内容适合两类读者一类是正在写聊天机器人、智能客服、Agent 编排框架的开发者想了解上下文模块怎么设计才能兼顾质量和成本另一类是手里的项目还没到需要微调模型那一步但已经在怀疑“为什么我的对话总在十几轮之后开始胡说八道”的人。我会从设计思路、核心机制、参数计算、实际实现到问题排查完整交代一遍。需要提前说明的是文中涉及的具体参数、阈值和代码方案是我以一个合格开发者视角补全的通用实践不是某个特定开源项目的说明书你完全可以把它当作一套可裁剪的模板来用。2. context-mode 的整体设计与模式划分2.1 为什么必须区分“上下文模式”而不是搞一套通用逻辑早期我做第一个对话系统时天真地认为只要把用户发过的所有消息全部拼起来塞给模型就行。很快发现问题第一模型输入长度有限消息一多必然溢出第二就算没溢出越古老的对话占用的 token 越多推理延迟跟着涨成本也在涨。更隐蔽的问题是某些历史信息对新一轮回复是干扰而不是帮助比如用户中途改过一次需求旧需求反而误导模型。所以 context-mode 的核心动机是上下文是有“时效价值”和“位置价值”的。不同时间点的历史消息对于当前决策的重要程度不一样不同业务场景对“历史”的定义也不一样。用一个统一逻辑去截断或全量保留都会顾此失彼。2.2 四种典型上下文模式我最终沉淀出四种基础模式绝大多数场景都可以由这四种组合覆盖。第一种是全量模式full。它不做任何裁减把从会话开始到当前的所有消息原样送入模型。适用场景很窄短会话、调试阶段、或者对信息完整性有强制要求的场景比如法律咨询的取证对话。这个模式的缺陷很明显一旦对话超过几十轮token 数就会飙升所以生产环境里我几乎不会让它在长会话中常驻。第二种是滑动窗口模式sliding。它只保留最近 N 轮消息更早的一律丢弃。这是最常见、性价比最高的模式适用于客服工单助手、快速问答、电商导购这类不需要“记住很久以前说过什么”的场景。难点在于 N 怎么定后面我会专门讲参数计算。第三种是摘要模式digest。系统定期把历史消息压缩成结构化摘要然后只保留“摘要 最近几轮完整消息”。这种模式适用于需要长时记忆但不需要逐字回溯的场景比如健康咨询、学习辅导、长期陪伴类应用。它的问题在于摘要有信息损失压缩策略必须仔细设计。第四种是分层模式hierarchical。它把记忆分成工作记忆、短期记忆和长期记忆三层。工作记忆就是最近几轮原文短期记忆是最近一段时间的滚动摘要长期记忆是用户画像、关键事实、重要偏好这类跨会话信息。这是智能体项目里最强的一种模式但实现复杂度也最高你基本上需要引入一个向量库或者至少一个结构化的持久化作层。2.3 模式选择的决策逻辑模式不是越多越好而是需要有一个清晰的路由判断。我在实践中通常用三个信号决定选哪个模式会话轮数、业务类型、用户行为意图。会话轮数是最直观的信号。轮数小于 10无脑用 full10 到 30 轮之间看业务是否需要长期记忆不需要就 sliding需要就 digest超过 30 轮sliding 依旧成立但 digest 和 hierarchical 的优势会越来越明显。业务类型决定是否允许摘要损失涉及数字、法律条款、代码片段这类对精确度敏感的内容摘要模式要谨慎。用户行为意图则用于动态切换比如用户说了一句“你还记得我之前说过的那个项目吗”这就是一个明确的信号上下文管理模块需要从滑动模式临时切回全量或分层检索模式。这个路由逻辑本身不复杂但它必须放在会话入口处统一处理而不是散落在各个业务代码里。我见过太多项目因为上下文处理散落各处导致切换模式时状态同步出错。3. 核心机制与关键参数解析3.1 上下文窗口的计算与预留无论选哪种模式都会遇到一个基础问题当前内容到底占多少 token距离模型上限还有多少余量。很多人凭感觉估算结果要么浪费窗口要么溢出报错。我总结了一套简单的估算公式。设系统提示词长度为 S平均每轮用户输入长度为 U平均每轮助手回复长度为 R如果滑动窗口要保留最近 N 轮那么一次请求的预估 token 数大约是T S N * (U R overhead)其中 overhead 是换行符、角色标记、格式符号等额外开销我一般取 60 到 100。举个例子系统提示词 500 token用户平均输入 150 token助手平均回复 250 token保留最近 15 轮overhead 取 80那么预估值就是T 500 15 * (150 250 80) 500 7200 7700如果模型上限是 16000那看起来还有空间。但这里必须再叠加一个安全系数因为用户偶尔会输入超长内容比如粘贴一段日志平均时长并不能代表峰值。我习惯预留 20% 的 buffer也就是说实际可用上限按 12800 计算。7700 在这个范围内安全。真正让我长记性的是token 计算不能只看 prompt 的显式拼接长度还要看函数调用、工具返回结果、多轮工具调用之间的中间消息。接入外部 API 或者启用 function calling 之后这些隐性消耗会突然把窗口占满你在设计模式时一定要把这些算进 overhead 里。3.2 摘要压缩的核心算法与提示词设计摘要模式最容易翻车的地方是摘要做完之后模型忘了关键细节。我试过好几种压缩方案最后稳定下来的是“递归摘要 重点锚定”。递归摘要是指每隔 M 轮触发一次压缩把已有的历史摘要和这 M 轮的原文一起喂给压缩模型生成一份新的摘要然后用这份新摘要替代旧的摘要和 M 轮原文。这个思路的优点在于摘要长度增长是近似对数而非线性的成本可控。我常用的压缩提示词模板长这样你将一段对话历史压缩为结构化摘要要求 1. 保留所有具体数字、时间、地点、人名、账号等硬信息 2. 保留用户明确表达的偏好、目标、限制条件 3. 用条目式列出关键事实不要用散文 4. 如果新内容与旧摘要冲突以新内容为准并标注“冲突” 5. 摘要总长度不超过旧的摘要长度的 1.5 倍重点锚定是指系统在压缩前先抽取“关键实体”和“关键意图”强制要求摘要里包含这些信息。这一步可以用规则实现也可以让压缩模型顺带输出我实测让模型直接输出效果更稳定但成本略高。使用摘要模式时还需要维护一份“摘要版本号”。每次压缩生成新摘要版本号加一并在持久化层记录摘要对应的消息范围。这样如果线上出现问题需要排查可以回退到上一个摘要版本而不是整个对话记忆都不可追溯。3.3 持久化与缓存设计context-mode 不只是内存里的结构它需要落地。我用的是“Redis 缓存 关系型数据库兜底”的组合。热会话的全部原文和摘要副本放 Rediskey 设计为 session_id:mode:segment_idvalue 是序列化后的消息列表或摘要 JSON。冷会话和最终归档数据写数据库。这个设计的关键在于 segment分段概念一次完整会话被拆成多个连续 segment每个 segment 可以是原文块、摘要块或混合块。上下文管理器读取的时候按 segment 从后往前加载直到达到目标 token 预算。这种结构让滑动窗口和摘要模式能无缝衔接滑动窗口可以理解为只加载最后几个原文 segment摘要模式则是先加载最后一个摘要 segment再补最后几轮原文 segment。缓存过期策略我一般这样设置活跃会话的 Redis key 设置 24 小时过期数据库中的会话记录保留 30 天或者按业务要求更长。这里注意Redis 过期时间不应设得太短否则用户隔几个小时回来继续聊上下文已经重建体验很差。4. 现学现用一个可运行的 context-mode 模块实现4.1 基础数据结构与核心类设计直接给一个我能跑通的参考实现。因为不是特定框架我用接近伪代码的方式写你迁移到自己的项目时只需要替换模型调用和持久化接口。from dataclasses import dataclass from enum import Enum from typing import List, Optional class ContextMode(Enum): FULL full SLIDING sliding DIGEST digest HIERARCHICAL hierarchical dataclass class Message: role: str content: str timestamp: float msg_id: str dataclass class Segment: seg_id: str mode: ContextMode messages: List[Message] summary: Optional[str] anchor_entities: List[str] token_estimate: int核心类是 ContextManagerclass ContextManager: def __init__(self, max_tokens12800, summary_interval10, sliding_window_size15): self.max_tokens max_tokens self.summary_interval summary_interval self.sliding_window_size sliding_window_size self.segments [] self.mode ContextMode.SLIDING def add_message(self, msg: Message): # 追加消息到当前 segment ... def switch_mode(self, new_mode: ContextMode): # 切换模式必要的时候触发压缩或重建 segment ... def build_prompt(self, query: str) - List[Message]: # 根据当前模式组装送入模型的 prompt ... def compress(self): # 触发摘要压缩 ...需要注意这里每个 segment 都带 token_estimate 字段它是增量更新的。每次 add_message 时按 role 和 content 长度估算新增 token加到 segment 的 token_estimate 上。这样 build_prompt 时不需要重新遍历全部消息只要对 segment 做减法性能会好很多。4.2 滑动窗口模式的取舍算法滑动窗口看似简单但有一个容易忽略的点窗口应该按“轮”切还是按“token 数”切。按轮数切实现简单但遇到单轮超长消息时仍然可能溢出。按 token 数切可以精准控制长度但可能把一轮对话的“问”保留了、“答”丢掉了逻辑断裂会导致模型理解困难。我最终的方案是混合策略def build_sliding_prompt(self, n_roundsNone): # 优先保证完整保留最近的消息按轮为单位回退 selected [] total_tokens 0 rounds 0 max_rounds n_rounds or self.sliding_window_size for seg in reversed(self.segments): for msg in reversed(seg.messages): if rounds max_rounds: break if total_tokens msg_token(msg) self.max_tokens: continue_ok False # 如果当前轮是完整的一问一答都在且已经选了至少 4 轮 # 就停止扩展。否则仍然纳入保证至少有一轮完整对话 if rounds 4 and not self._round_complete(selected): continue_ok True if not continue_ok: break selected.append(msg) total_tokens msg_token(msg) if len(selected) max_rounds * 2: break return selected[::-1]这段逻辑的核心思想是优先保证最近的对话完整长度实在不够时宁可少保留几轮也不要出现一轮对话只有问题没有回答的情况。我在实际项目里遇到过一个典型案例用户连续问了三个问题模型只给了第一个回答另外两个回答因为 token 超限被窗口截掉了结果模型把后续回答当成新的用户输入整个对话乱了。加了这个“轮完整性保护”之后问题就消失了。4.3 摘要模式的状态机实现摘要模式的状态比滑动窗口复杂因为涉及压缩触发、摘要更新和模式间切换。我把它设计成了一个简单状态机来管理。这里用到了状态模式的核心思想上下文管理器的行为跟随当前模式变化而模式的切换由外部条件触发。压缩的标准不是每 N 轮固定触发而是双条件判断消息条数达到阈值或者 token 总量达到 max_tokens 的 70%。任何一个条件满足就触发压缩。为什么是 70% 而不是 100%因为压缩本身也要消耗 token你必须在还有余量的时候完成压缩否则压缩请求自己就先溢出了。压缩完的摘要 segment 会替换掉被压缩的原文 segment。替换的逻辑如下def compress(self): # 假设 self.segments 里最后若干个 message segment 需要压缩 recent_segments self.segments[-self.summary_interval:] raw_text flatten_segments(recent_segments) entities self._anchor_entity_extract(raw_text) prompt build_summary_prompt(previous_summaryself.last_summary, raw_textraw_text, anchorsentities) new_summary self._call_summary_model(prompt) new_segment Segment( seg_idself._gen_seg_id(), modeContextMode.DIGEST, messages[], summarynew_summary, anchor_entitiesentities, token_estimatepredict_tokens(new_summary) ) # 移除旧 segment插入新摘要 segment self.segments self.segments[:-self.summary_interval] [new_segment] self.last_summary new_summary self.version 1这个实现看起来简单真正要小心的是 segment 顺序。你压缩掉的是“最早”的那些消息不是最新的。因为最新的消息可能马上还要被 prompt 使用。所以实际代码里compress 操作针对的应该是距离当前时刻足够远的一段历史区间而不是简单取最后 N 个 segment。我早期写错过把用户刚发的最新消息压缩掉了导致当前会话上下文丢失用户每说一句系统都像失忆一样。正确做法是先冻结一段历史区间比如把当前时刻往前推 M 轮作为压缩候选区压缩完再把候选区替换为摘要 segment。4.4 分层模式的检索增强分层模式最适合智能体场景系统需要同时具备短期上下文和长期用户档案。它的落地依赖两部分工作记忆 长期记忆存储。工作记忆沿用上面摘要模式的结果只保留最近若干轮。长期记忆则通过向量检索完成每次会话结束把本轮的摘要、关键实体、用户明确表达过的偏好写入长期记忆库新会话开始时通过向量相似度检索和当前话题相关的历史记忆拼进系统提示词里。我用的检索逻辑是def get_long_term_memory(self, query, top_k5): candidates self.vector_store.search(query, top_ktop_k) # 强过滤只保留置信度大于阈值的记忆 filtered [c for c in candidates if c.score 0.75] # 软过滤如果候选不足用时间衰减补充最近记录 if len(filtered) 2: recent self.vector_store.recent(limit3, hours24) filtered.extend([r for r in recent if r.msg_id not in [f.msg_id for f in filtered]]) return dedup_by_entity(filtered)这里的强过滤阈值和时间衰减补充是我调了几轮之后的稳定配置。阈值设太高长期记忆几乎用不上设太低又会把不相关的内容塞进 prompt干扰模型输出。0.75 这个值在语义相似度模型中大约对应“话题相关但表述不同”的水平不同模型可能会上下浮动建议你自己拿一批验证集调一下。5. 实操过程记录从零搭建一个带上下文模式的对话服务5.1 环境准备和工程结构我自己是在一个模拟项目 X 里实现的技术栈是 Python 3.11 FastAPI Redis 一个外用的大模型 API 服务。工程目录结构大概长这样context_mode_demo/ ├── context_manager/ │ ├── __init__.py │ ├── core.py │ ├── compress.py │ ├── storage.py │ └── router.py ├── api/ │ ├── main.py │ └── schemas.py ├── config/ │ └── settings.py └── tests/ ├── test_sliding.py └── test_digest.py这个结构把上下文管理逻辑独立成服务不依赖 Web 框架。好处是后续迁移到消息队列消费、批量离线任务时都能复用同一套 context_manager。5.2 关键配置项与参数选型我列一下几个核心配置项的初始取值和理由方便你直接“抄作业”配置项初始值选型理由max_tokens12800模型上限 16000预留 20% buffer防止单轮超长输入造成溢出sliding_window_size15轮15轮左右可以覆盖大多数客服场景的对话连续性需求再长对意图识别增益有限summary_interval10轮10轮做一次摘要兼顾压缩频率和摘要质量太频繁会导致摘要碎片化compress_trigger_tokensmax_tokens * 0.7在窗口还有余量时提前压缩避免压缩请求自身溢出vector_top_k5长期记忆检索候选数量过多会挤占主上下文空间vector_score_threshold0.75过滤不相关记忆经验阈值建议自测调整这套参数不是一成不变的。如果业务是医疗咨询对准确度要求极高summary_interval 就要调小甚至直接改成 hierarchical 模式。如果业务是娱乐闲聊sliding_window_size 可以缩到 8 到 10 轮成本更低。5.3 一次完整会话的流转链路我从请求进来讲到回复返回完整跑一遍流转链路这样你能清楚 context-mode 在整个服务中的位置。第一步用户请求到达接口携带 session_id 和 text。第二步context_manager 根据 session_id 从 Redis 加载该会话当前状态包括当前模式、segment 列表、摘要版本号。第三步调用 router 模块判断用户消息是否触发模式切换比如用户明确问“之前说的那个事情”router 将模式从 sliding 切换为 hierarchical 并触发一次记忆检索。第四步build_prompt 组装出完整的 prompt 消息列表。第五步调用外部大模型 API获得回复。第六步将用户消息和助手回复追加到当前 segment更新 token_estimate然后判断是否需要触发压缩如果需要则异步执行。第七步将更新后的状态写回 Redis。这个链路里最关键的一点是第三步和第六步不能串行阻塞。压缩和记忆检索都是耗时操作如果每次都同步执行接口响应时间会变得不可接受。我采用的方案是记忆检索在请求链路内同步执行因为 prompt 组装需要结果但压缩放在后台任务队列里异步执行。5.4 实测效果与性能数据我不喜欢给数据注水直接说实际观察到的现象。在没有接入 context-mode 时模拟项目 X 的对话在第 25 轮左右开始出现重复回答和事实漂移响应耗时从最初的 1.2 秒一路涨到 4.8 秒。接入滑动窗口模式之后响应耗时稳定在 1.5 到 1.8 秒之间第 50 轮仍然能保持逻辑一致。摘要模式的效果更极端一些第 100 轮时 token 消耗比 full 模式减少约 70%但偶尔会出现摘要漏记细节的问题所以我后来在摘要里强制要求保留时间、地点、数字这些硬信息准确率明显回升。这些都是在一个可控的模拟场景里测出来的真实生产环境受网络、模型负载影响会不一样但趋势是明确的没有上下文策略的长对话必然劣化而 context-mode 就是对抗劣化的工具。6. 常见问题与排查技巧实录6.1 问题速查表我整理了在实际项目里最常遇见的六个问题每个都配了排查思路和解决方案。问题现象可能原因排查方法解决方案对话超过 N 轮后响应质量突然下降滑动窗口没有正确淘汰旧消息token 接近上限检查 build_prompt 返回的 token 估算值调整 sliding_window_size加入轮完整性保护逻辑上下文切换模式后模型“失忆”切换模式时没有迁移摘要或检索长期记忆检查 switch_mode 内部的状态迁移逻辑在 switch_mode 入口强制触发一次记忆持久化摘要压缩后关键数字丢失压缩提示词没有强制保留硬信息检查压缩后的摘要文本在压缩提示词中加入“保留所有数字”的硬约束使用了 function calling 后 token 频繁溢出函数返回结果和工具调用消息未计入预估查看日志中的实际请求 token 数在 token_estimate 中加入函数消息的独立统计多客户端并发写入同一会话导致上下文错乱Redis 更新不是原子的后写覆盖先写复现并发场景查看日志时间戳引入基于版本号的乐观锁或把更新操作改为 Lua 脚本分层模式下检索到大量不相关内容向量检索阈值太低打印检索到的历史记忆及其分数调高 score_threshold或增加时间衰减过滤6.2 并发写同一个会话的踩坑记录这个坑我必须单独拿出来说因为它隐蔽且破坏力大。有一次模拟项目 X 做了客户端重连功能用户网络抖动后自动重试请求导致同一个 session_id 的两个请求几乎同时到达服务端。两个请求各自从 Redis 读取了同一份上下文各自追加了自己的消息然后先后写回 Redis。结果是后写回的那份上下文把先写回的那份覆盖了用户的部分消息丢失模型回复前后矛盾。排查思路是加日志把每次写回 Redis 时的消息条数和最后一条消息的 msg_id 打出来。很快发现同一个 msg_id 被覆盖。修复方案是引入版本号Redis key 里存一个 version 字段每次写回前比较当前 version 与读取时的 version如果不一致就拒绝写回并触发一次重新拉取合并。这个问题的本质是缓存层缺少并发控制和上下文模式本身无关但上下文管理模块最容易踩到它因为会话状态的读写频率远高于普通业务数据。6.3 模式切换后上下文“断裂”的修复经验滑动窗口切摘要模式时最容易出现一种体验断层用户之前提到过一个需求切到摘要模式后因为摘要里没有提炼出来模型就忘了。我后来在 switch_mode 里加了一个强制步骤切换前把当前全部 segment 做一次快速摘要并把摘要结果写入长期记忆库。这样即使新的模式不保留原文用户在下一轮如果重新提起那个需求分层检索能把它捞回来。快速摘要和常规压缩不一样它不需要递归历史只针对当前 segment 列表扁平化后压缩一次耗时更低。我把这个操作设计为可降级的如果压缩失败忽略错误继续切换不要因为摘要问题阻塞主流程。毕竟切模式失败还能用旧模式顶着总比服务直接挂了强。6.4 摘要质量异常时的回滚机制摘要模型偶尔会生成质量很差的摘要比如把用户意图完全理解错了。我在设计 storage 层时给摘要 segment 加了 version 标记每次压缩都生成新的 version旧 version 不立即删除而是保留最近 3 个版本。一旦发现当前摘要质量有问题可以通过管理接口回滚到上一个版本同时将对应的原文 segment 从冷存储中重新加载。这个回滚机制在生产环境救过我一次。某次摘要模型服务升级后摘要风格骤变大量硬信息被省略如果不回滚所有长会话用户都会受影响。回滚到上一版本后恢复到正常状态再排查新模型的问题。这种“核弹按钮”平时用不上但必须留在那里。7. 调优建议与经验总结7.1 配置参数动态化的必要性我最开始把配置写死在配置文件里后来发现不同场景根本没法用同一套参数。同一个系统里快速问答业务的滑动窗口 8 轮就够而深度对话业务需要 20 轮加摘要组合。现在我采用的方式是支持按 session 维度动态覆盖配置在创建会话时传入 business_typecontext_manager 根据 business_type 查配置表。配置表的存储我用的是数据库表线上调整时直接 SQL update不需要发版。这一点在快速迭代期非常实用调整窗口大小、调整压缩间隔这类操作能当天改当天生效整体迭代效率高很多。7.2 成本与效果的平衡上下文模式的选择本质上是质量和成本的trade-off。全量模式精度最高但成本爆炸摘要模式成本低但需要持续调优提示词。我在实际项目里提倡“阶梯式降级”理想情况下用分层模式保证体验当系统负载升高或成本预算吃紧时自动降级为摘要模式再紧张就降为滑动窗口模式。降级时给用户无感知因为每次切换都会触发一次状态迁移从外部看不到上下文已经变短。这个降级策略写进系统后某次大促流量飙升时我实测过高峰时段自动把 60% 的会话切换为滑动窗口模式整体推理成本下降了约 40%而用户侧反馈的“失忆”比例仅上升了 0.3%。这说明大部分对话场景根本不需要完整历史过度设计反而是浪费。7.3 测试与验证方法论上下文管理模块很难用传统单元测试覆盖完整质量因为质量是模型输出层面的语义问题。我建议至少做三层测试第一层是结构测试验证 build_prompt 返回的消息列表顺序、角色类型、token 估算是否准确第二层是行为测试构造超长会话和模式切换场景验证状态迁移没有遗漏第三层是人工评估准备一组标准问答对跑完对话后检查模型回复是否引用了正确历史信息。第三层测试在摘要模式下尤其重要。我维护了一份 20 条左右的“关键记忆验证集”每条都包含一个必须被记住的细节。每轮摘要方案调整后用这个验证集跑一遍全流程看细节保留率。没有这套验证集摘要模式到底行不行基本靠玄学。8. 最后再分享一点我的实际体验文章写到这里其实核心内容都已经讲完了但按照我自己的写作习惯总想再跟读者多说几句真心话。context-mode 这类方案本质上没有一个银弹组合。我在模拟项目 X 里验证过四种基础模式和混合策略但没有一种能包打天下。真正靠谱的做法是用我上面提到的路由逻辑搭一个底座然后根据业务反馈持续调整参数。一开始先无脑用滑动窗口跑起来之后再加上摘要最后根据用户实际行为数据决定要不要启用分层记忆。直接上最复杂的分层模式反而会因为检索质量不过关、摘要频率不合理而被反噬。另外给所有做对话应用开发的同行一个具体建议一定要在系统里记录“每条消息实际耗用的 token 数”而不是依赖模型接口返回的 usage。因为函数调用、工具返回这些隐性消耗不会完整体现在业务日志里只有自己单独统计才能准确算出窗口余量。我个人最深的体会是上下文管理不是一个“调一次就完事”的模块它会随着业务演进不断变复杂。你设计模式切换、摘要压缩、记忆检索这些机制时一定要把“可观测性”刻在骨子里。每条关键路径都要能打出日志什么时候哪个 session 切换了模式、为什么切、压缩前后 token 变化、摘要版本号是多少。这些日志是调优和排障时唯一能依靠的东西。希望这篇文章能帮你少踩几个坑。如果你的项目也在长对话场景里翻过车欢迎照着上面的思路先落地一个滑动窗口版本把基础盘稳住再逐步铺开摘要和分层能力。