1. 问题本质与截断的必要性
最早接触这个需求，是给一个智能客服机器人做多轮对话优化。用户在会话里连续问了十几个问题，客服机器人回复到后面明显开始“答非所问”——不是模型变笨了，而是历史消息把上下文窗口挤满了，早期真正关键的信息被挤了出去。
多轮对话的上下文管理，本质上是在跟 Token 预算打交道。每个模型的上下文窗口都是固定的，比如有的支持 8K Token，有的支持 128K Token。一问一答消耗的 Token 累积起来是非常快的，一个简单的问题大约几百 Token，走完 8K 上下文可能 20 轮对话就被撑爆了。而且不是只有历史消息会占空间——系统提示词、检索增强材料、当前问题、模型生成的回复，全都挤在同一个窗口里。你可以把上下文窗口想象成一个行李箱，你能带的东西有限，但真正需要带走的却是一路上所有重要物品的集合，这就必然需要做取舍。
我见过不少新手直接忽略这个问题，或者干脆在模型报错之后才被迫处理。实际上，上下文截断不是简单的“删掉前面的消息”，它是有策略的，而且不同场景差异很大。这个需求在对话型应用里几乎是绕不开的工程点：做智能客服的要把历史答疑记录下来，做学习助手的要保留用户目标和进度信息，做文档阅读助手的则要优先保住文档核心内容。本文基于实际开发多轮对话系统中的实践，把常用的截断策略和具体实现方式完整梳理一遍，希望能给正在做类似功能的开发者省一些踩坑时间。
需要特别说明的是，下面所有策略都建立在“让对话效果最大化”这个前提下，单纯为了节省 Token 而牺牲关键信息是最不划算的做法。明确这一点之后，我们再来看具体怎么做。
2. 常用截断策略与选型对比
2.1 基础策略：滑动窗口截断
滑动窗口是最直观的方案。假设窗口大小是 W，当前对话已经有 N 条消息，当 N > W 时，只保留最后 W 条消息，其余的全部丢掉。这个策略实现起来非常简单，几乎不需要任何额外计算，直接裁剪消息列表就行。
但它的缺陷也很明显：所有消息被一视同仁地对待，早期的重要信息会被无差别删除。比如在客服场景中，用户在一开始就说“我的订单号是 XG20240987”，这句话出现在第 3 条消息里，对话进行到第 25 轮时，这个订单号早就被滑出去了，模型后续根本无法理解用户在说什么。所以滑动窗口只适合那些历史信息相关性很弱的短对话场景，比如闲聊机器人、短期任务型助手，而且窗口设置不能太小，否则连基本的对话连贯性都保证不了。
实现上要注意一个细节：窗口计算的是消息条数还是 Token 数量，这两者差别很大。如果一条消息包含超长文本（比如粘贴了一整篇文章），而另一条只有两个字，按消息条数裁剪会造成 Token 分布极不均匀。稳妥起见，滑动窗口适合做消息级别的裁剪，但最好同时设置 Token 上限做兜底，防止单条超长消息直接撑爆上下文。我在实际项目中通常让消息条数窗口和 Token 上限同时生效，谁先超了谁触发裁剪。
2.2 进阶方案：Token 数量控制截断
Token 数量控制是更通用的做法，也是大多数生产环境的首选。思路很简单：预估对话中所有消息的 Token 总量，如果超出预设阈值，就从最早的消息开始逐条删除，直到总 Token 数量回到安全范围内。这里需要注意“预留空间”的问题——真正消耗掉的 Token 不应该占满整个窗口上限，因为模型输出的回复还会占据一部分空间，系统提示词也要占用一部分。
具体做法上，先估算系统提示词固定占用的 Token 数（比如 500），再预留出模型平均回复长度的 Token 数（比如 800），那真正可以分配给历史消息的空间，就是用总窗口减去这两个数。假设窗口是 8000，减去 1300 的固定开销之后，历史消息最多占 6700 Token。然后把保存消息的列表从头开始遍历，累计 Token 数，超出 6700 之后的部分全部丢弃。这个过程需要引入一个 tokenizer 来做精确统计，因为 Token 数量和字符数并不成正比，中英文混合场景尤其明显，同一个字符串在不同 tokenizer 下的切分结果可能差很多。我在项目中一般是直接用模型厂商提供的 tokenizer 库，如果厂商没有提供现成的接口，就用模型对应的开源 tokenizer 做本地切分，准确度在 5% 以内波动，足够用了。
一个比较反直觉的经验是：在裁剪策略里，“最后一次对话”本身永远不能丢，哪怕它再长再占空间。因为用户最后提出的问题决定了模型接下来要回答什么，这是每轮对话里权重最高的单条消息。所以实现逻辑上通常把最后一条消息单独拎出来，计算历史消息部分和最后一条消息的 Token 总和，如果超限，优先裁剪历史部分，最后一条除非万不得已才做截断或者摘要。
2.3 场景化策略：按消息角色差异化保留
如果不做任何差异化处理，同一个窗口里的用户消息、助手回复和系统消息会处于完全相同的裁剪优先级，这在实际业务里往往不理想。比如一段对话流中，用户连续问了好几个问题，助手逐一回复，历史的助手回复内容虽然长，但用户的问题核心其实都浓缩在一个简短的意图里——历史回答完全可以压缩或省略，用户的原始问题才是必须留住的。
常见的做法是设定消息角色的保留权重，优先级从高到低大致是：用户消息 > 助手最终回复 > 系统提示 > 工具返回结果。用户消息之所以留全，是因为它承载了用户意图和关键实体的传递。助手的历史回复可以适当丢弃细节，只保留结论，比如“我记得之前你回答过某个参数配置，但说不清原话了”，这种情况允许模型根据用户消息重新推断。工具返回结果最占体积（经常是几百行 JSON），而且时效性强，一般只保留最近一次的结果。
角色差异化截断和 Token 控制可以组合使用。先给每条消息打上角色标签和权重，再根据预算分配各角色的 Token 配额。比如历史总预算 6700 Token，其中用户消息分配 3000，助手历史回复分配 2500，工具结果分配 1200。超预算时按角色分别压缩。这个配额比例在不同业务中差异很大，不必追求绝对统一，关键是意识到“角色差异”本身就是一个可用的裁剪维度。
2.4 摘要式截断：用压缩代替删除
单纯的截断带来一个必然问题：被删掉的信息再也无法恢复。如果业务核心依赖早期对话，那就得考虑摘要式截断——对即将被裁剪的早期消息，先用模型生成一段摘要，把摘要作为一条特殊消息保留在上下文中，然后才删除原始消息。
举个例子，用户和客服谈到“手机屏幕碎了，需要换屏，预算 1500 元以内”，这个信息在前面几轮对话里反复出现。滑动窗口删除后，模型后续无法判断用户的经济约束。摘要式截断可以在早期消息达到裁剪条件时，生成一条总结消息，内容类似于“用户手机屏幕碎裂，换屏预算不超过 1500 元”，然后保留在窗口内。后续模型看到这条总结，依然能理解约束条件。
摘要式截断的代价是额外的模型调用，每触发一次摘要就要花一次推理时间，而且摘要质量直接决定信息保留的完整度。我自己的经验是：不要每条裁剪都触发摘要，而是在连续多轮对话后，每隔一段时间做一次“定期汇总”，把这段时间内的重要信息提炼成几条结构化要点。这样既能缩短上下文长度，又不会因为频繁调用模型而拖慢响应速度。
摘要消息在格式上建议单独标记，比如用系统级元数据字段标记为“summary”，而不是像普通消息一样参与后续裁剪。这样在后续的滑动窗口中，摘要消息有更高的保留优先级，甚至可以作为固定上下文的一部分永不删除。很多开源框架后续也沿用了这个思路，把“摘要消息”和“普通消息”分开存储，优先保证摘要的存活时间。
这里整理一下几种基础策略的对比，方便结合自身业务做选型：
| 策略 | 实现难度 | 信息保留度 | 额外成本 | 适用场景 |
|---|---|---|---|---|
| 滑动窗口 | 低 | 低 | 无 | 短对话、闲聊机器人 |
| Token 数量控制 | 中 | 中 | 无 | 通用生产环境 |
| 角色差异化 | 中高 | 较高 | 无 | 客服、咨询类对话 |
| 摘要式截断 | 高 | 高 | 每次摘要消耗模型调用 | 长会话、业务关键信息多的场景 |
3. 实操实现与核心代码解析
3.1 消息结构与前置准备
在动手写截断逻辑之前，先把消息的数据结构定下来。结构设计得合理，后续所有策略都能在一个基础上做扩展。我推荐至少包含这些字段：消息 ID、角色、内容、时间戳、Token 数、类型（普通消息或摘要消息）、优先级。
from dataclasses import dataclass, field from typing import Optional @dataclass class Message: msg_id: str role: str # "user"、"assistant"、"system"、"tool" content: str timestamp: float = 0.0 tokens: int = 0 # 预计算的 token 数 msg_type: str = "normal" # "normal" 或 "summary" priority: int = 0 # 数字越大越优先保留 def token_count(self) -> int: # 调用 tokenizer 计算 token 数的简化接口 return self.tokens为什么需要 timestamp？因为时间顺序是做滑动窗口的基础，而且多线程环境下，消息到达的顺序和实际发生顺序可能并不一致——用户发了两条消息，网络延迟导致第二条先到达，没有时间戳的话，裁剪时顺序就乱了。token 数提前计算也是同样的道理，不要等需要裁剪时才现场调用 tokenizer，那样每次请求的耗时都会增加，性能和用户体验都会受到影响。
前置准备阶段还要处理一个容易被忽略的点：消息入库时的清洗和合并。连续的相同角色消息尽量合并成一条，这样既减少消息条数，也减轻 tokenizer 的调用压力。比如用户连续说了两句“你好”“在吗”，合并成一条“你好在吗”，对对话语义几乎没有损失，但 Token 占用和后续裁剪的复杂度都会下降一个层级。
3.2 滑动窗口与 Token 控制实现
下面这段代码是把滑动窗口和 Token 控制结合起来的核心逻辑。窗口按消息条数裁剪，同时用一个预留空间后的 token 上限兜底，两条路径都覆盖到了。
class ContextManager: def __init__( self, max_token_limit: int = 8000, max_messages: int = 50, summary_msg_tokens: int = 500, reserve_for_response: int = 800 ): self.max_token_limit = max_token_limit self.max_messages = max_messages self.history_budget = max_token_limit - summary_msg_tokens - reserve_for_response def truncate(self, messages: list[Message]) -> list[Message]: """ 按消息条数和 token 预算裁剪消息列表。 保留最后一条消息，并按优先级保护摘要消息。 """ if not messages: return messages # 先做消息条数裁剪 truncated = messages[-self.max_messages:] # 按 token 预算裁剪 total_tokens = sum(m.token_count() for m in truncated) if total_tokens <= self.history_budget: return truncated # 从最早的消息开始逐条移除，直到满足预算 removable_indices = [] for i, m in enumerate(truncated[:-1]): # 不包括最后一条 if m.msg_type == "summary": continue # 摘要消息不参与普通裁剪 removable_indices.append((i, m.timestamp)) # 按时间从小到大排序，优先删除最早的 removable_indices.sort(key=lambda x: x[1]) dropped = 0 for idx, _ in removable_indices: adjusted_idx = idx - dropped # 删除后索引会前移 if total_tokens <= self.history_budget: break token_count = truncated[adjusted_idx].token_count() truncated.pop(adjusted_idx) total_tokens -= token_count dropped += 1 return truncated这个实现的细节在于“排除最后一条消息”和“保护摘要消息”。最后一条消息在循环里被排除了，这样无论预算多紧张，当前用户问题都不会被删。摘要消息被跳过，是考虑到它承载的是浓缩后的关键信息，空间占用小但价值高，应该优先保留。
还有一个小坑：删到剩余消息数量很少时，上下文可能只剩下一两条用户消息，这时对话的连贯性其实已经被破坏了。所以这里建议额外加一个“最低消息数”的保护机制，比如预算再紧，也至少保留最近 8 条消息，否则模型能看到的上下文过于碎片化。这个机制我在实际项目里很常用，它比单纯依赖 Token 数量更符合对话交互的自然需求。
如果希望 token 计算更精确，可以在调用前对每条消息的 content 做一次 token 统计：
def compute_message_tokens(encoder, message: Message) -> int: # encoder 是 openai 或别的模型对应的 tokenizer 封装 return len(encoder.encode(message.content))写一个批量处理函数，编码一次修改消息对象即可。注意 tokenizer 是带状态的对象，一般要按模型版本单独初始化，不要跨模型复用。
3.3 摘要式截断的工具函数
摘要式截断需要额外调用一次模型，因此实现上要区分“离线后台摘要”和“同步强制摘要”两种触发方式。离线后台摘要可以在用户不活跃的时候异步执行，比如某平台设定每完成 10 轮对话就做一次摘要，不阻塞当前请求。同步强制摘要则用于上下文即将超限且摘要消息不存在时的紧急处理，这通常会增加单次请求的延迟，要慎用。
def generate_summary( client, messages_batch: list[Message], anchor_info: str = "" ) -> Message: """ 对一段历史消息生成摘要消息。 anchor_info 用于锚定关键信息，比如订单号、用户目标等。 """ content = "\n".join( f"{m.role}: {m.content}" for m in messages_batch ) prompt = ( f"请提炼以下历史对话中的关键信息，输出不超过 300 字。\n" f"需要重点保留的信息：{anchor_info}\n" f"对话内容：\n{content}" ) # 调用轻量模型做摘要，不一定用主力对话模型 response = client.chat.completions.create( model="summary-model-version", messages=[ {"role": "system", "content": "你是信息提炼助手，只输出结构化要点。"}, {"role": "user", "content": prompt} ], temperature=0.2, max_tokens=300 ) summary_text = response.choices[0].message.content # 摘要消息用特殊类型标记，token 数也及时算好 return Message( msg_id=f"summary_{int(time.time())}", role="system", content=f"[历史摘要] {summary_text}", msg_type="summary", tokens=len(client.encode(summary_text)), priority=999 )摘要模型建议用更轻量的模型，因为摘要任务不需要完整生成能力，重点是信息提炼准确、速度快。我在生产环境实测过，轻量模型在摘要任务上的效果和主力模型差别不大，但延迟能降低一半以上。Prompt 里的 anchor_info 尤其关键，它把业务侧关心的字段显式传递给模型，避免模型抓到无关细节。
3.4 从裁剪到上下文拼装
截断逻辑写完之后，还有一个重要的拼装环节——把系统提示词、历史消息、摘要消息、最后一条消息按顺序组合成最终发送给模型的上下文。顺序不一定要严格按时间排序。对于多数模型，更有效的顺序是：系统提示词 -> 摘要消息 -> 历史消息 -> 当前问题。
摘要消息放在历史消息之前，目的是让模型在阅读完整历史前先接收一遍关键信息摘要，这相当于提供了一个“引导线索”，模型后续理解历史细节时不容易遗漏重点。某些模型对 prompt 中较早位置的内容注意力更强，摘要放在前面正好利用了这一特性。这条经验也是我在多次对比效果之后总结出来的，同样是摘要式截断，放在开头和放在末尾的效果差异可以达到明显程度。
拼装时也要注意系统提示词的长度控制。系统提示词如果过于冗长，会压缩历史消息的可用预算，反而让截断更频繁。我见过有人写了 2000 Token 的系统提示词，真正留给对话内容的空间所剩无几。系统提示词要尽量精简，能压缩到 300 Token 以内最好，如果确实需要长指令，考虑分成“固定指令”和“动态指令”两部分，动态指令在每轮中才拼接进去。
上下文的最终格式是 API 调用所需的 messages 数组。拼装完成后，还要把 token 总量重新统计一遍，作为请求发出前的最后检查。如果统计值超过模型窗口的 90%，即使截断了也要降级处理——比如缩减返回的最大 token 数，避免模型因为输出空间不足而被截断成不完整内容。
4. 多轮对话中的高级处理技巧
4.1 已有摘要消息时如何合并新对话
摘要式截断只处理了“早期消息被删掉”的情形，但后续对话中新产生的消息同样会累积。理想状态是：旧对话压缩成摘要，新对话保留原文，摘要和新对话一起进入上下文。不过随着新对话越来越多，它们也会超出预算，需要做下一轮摘要。
这时候要求摘要生成逻辑具备“增量合并”能力：不是对全部历史消息重新摘要，而是将旧摘要和新一轮对话合并摘要。这样旧摘要中的关键信息和新对话中的内容能够被同时纳入，不会出现“二次摘要把原来提取的内容丢了”这种问题。
def merge_into_summary( client, old_summary_msg: Message, new_messages: list[Message] ) -> Message: """ 将旧摘要和新消息合并，生成更新的摘要。 """ combined_content = ( f"旧摘要：{old_summary_msg.content}\n\n" f"新增对话：\n" + "\n".join(f"{m.role}: {m.content}" for m in new_messages) ) # 调用摘要生成接口，返回新的 summary 类型消息 return generate_summary_from_text(client, combined_content)这个函数的关键是保证摘要生成接口和前面那个工具函数的输入输出形式完全一致，方便后续替换。新摘要生成后，旧摘要消息直接删除，用新摘要替换它。整个过程看起来像有一个不定长的滚动摘要，但每次只处理增量部分，时间复杂度低，信息损耗也能控制在可接受范围内。
4.2 检索增强材料与上下文互相抢占的平衡
在实际的文档问答类对话系统中，上下文里除了历史对话，还经常要放检索增强材料——从知识库中召回的相关片段。这些片段通常比较长，它们和历史对话同时抢占有限的上下文窗口。如果只按一套 Token 预算做全局裁剪，可能出现历史对话把文档片段挤掉，或者文档片段把关键对话挤掉两种极端情况。
比较好的做法是给检索增强材料和历史对话分别设置预算。比如总 Token 8000，扣除系统提示和输出空间后剩 6500，其中检索材料分配 3500，历史对话分配 3000。检索材料按相关性排序，相关性低的先丢；历史对话按前面讲的策略裁剪。两条预算线独立执行，互不干扰，可以避免一方挤压另一方的空间。
这个方案的实现重点在于检索增强材料的结构化存储。每个检索片段不仅包含原文，还包含它的相关性得分、来源标记和覆盖的主题范围。裁剪时按得分从低到高删除，确保留下来的始终是信息价值最高的部分。对话和检索材料混合拼装时，通常按“对话 - 检索材料 - 当前问题”的顺序组织，这样模型在回答问题时能先看到对话上下文，再看到知识内容，最后锁定当前指令。
4.3 意图驱动的定向裁剪
有些场景中，早期对话里有相当一部分内容对当前问题毫无帮助。比如用户本来是问“怎么退换货”，后来话题转移到“你们的优惠券怎么用”，之前的退换货细节跟当前需求关联不大。与其保留整段历史，不如先判断当前意图，再只保留与当前意图相关的历史消息。
这种“意图驱动的定向裁剪”在工程上要稍微复杂一些，要先对当前用户问题进行意图分类，然后给历史消息打上意图标签，筛选出与当前意图匹配的消息保留。可以用轻量模型做分类，也可以用关键词匹配或规则触发，具体取决于业务的意图数量和复杂度。意图数量在几十个以内时，规则匹配足够；超过几十个甚至上百个时，建议用模型分类。
这个策略的优势在超长会话里体现得最明显。有些客服会话可能持续几十轮，话题来回切换，如果从头到尾全部保留，上下文空间很快不够用。定向裁剪可以让上下文里始终只保留与当前问题相关的消息，长度几乎不会随着会话总轮数增长而失控。它的代价是每轮都需要计算意图分类，会增加一部分计算开销，但从对话质量收益来看，这个开销是值得的。
4.4 截断策略组合的完整流水线
把前面这些策略串起来，可以形成一套完整的处理流水线。我的标准流程是：先做规则预处理（合并连续同角色消息），然后做角色差异化标记，再按意图筛选历史消息，接着汇总摘要并合并增量，最后执行 Token 预算兜底裁剪。每一步的目标都很明确：规则预处理减少冗余，角色差异化分配权重，意图筛选去掉无关内容，摘要汇总压缩长程信息，Token 预算兜底保证不超窗口。
这个流水线看起来步骤多，实际跑起来其实是纯函数式操作，可以把每个步骤封装成独立的处理函数，方便单独测试和调优。我建议先把流水线跑通，拿到一份真实对话日志，对日志进行离线回放测试，观察截断后模型回答的效果。离线回放阶段不依赖线上流量，可以安全地做参数调试，比如调窗口大小、调配额比例、调摘要触发频率。
流水线中每一步都可以加运行标记，记录这一步减少了多少消息条数、删除了多少 Token、是否触发了摘要。这些统计信息汇总起来，可以帮你精确评估不同策略的收益。我在项目里就是用这套统计结构来优化策略参数的，比如发现某种业务场景下角色差异化裁剪占比特别高，就会考虑给那个角色分配更多的预算。
5. 常见问题与排查技巧实录
5.1 截断后模型回答质量下降
这是最常见的现象，很多团队花了很久做截断，结果发现回答质量不升反降。排查的思路不能一上来就调参数，而是先做对比实验：用同一组对话，分别跑“无截断（人为拉长窗口）”和“有截断”两组，对比回答效果。如果无截断效果明显更好，大概率是截断的时候丢了关键信息。
关键信息丢失的方向通常有两个：一是角色权重设计不合理，助手历史消息占据了太多预算而用户消息被挤掉；二是摘要质量不稳，摘要把核心实体给漏了。第一个问题通过角色配额调整就能解决；第二个问题就要回头检查摘要模型的 prompt，确认它有没有覆盖预定义的锚点实体，比如订单号、人名、金额这些业务关键字段。
一个有效的小技巧是：在离线回放测试里，把每次截断前被删除的消息单独打印出来，逐条对照“这些被删的消息里有没有包含当前问题涉及的信息”。如果连续多轮都出现被删除消息和当前问题高度相关，说明截断粒度太粗或者意图筛选有误。我在排查时经常用这个办法，很快就能定位到具体的策略层次。
5.2 消息顺序错乱导致模型理解混乱
多路并行请求、消息异步到达的场景下，消息列表中的顺序可能和真实对话顺序不一致，导致截断后的上下文错序。表现是用户明明先问 A 后问 B，但模型看到的顺序变成了先 B 后 A，逻辑完全颠倒。
解决办法前面提过，一是消息必须有 timestamp，二是排序逻辑要和消息 ID 的唯一性配合起来。但在实际处理中，我建议对消息顺序做一次额外的校验：判断相邻两条消息的角色是否连续相同，如果连续出现两条用户消息，说明中间可能缺失了助手回复，这时需要提醒客户端补齐或重新拉取。这个校验虽然不能解决所有顺序问题，但能暴露异步消息丢失的风险。
排序建议基于稳定排序，用 Python 的 sort(key=lambda m: m.timestamp) 就能保证同时间戳的消息维持原有顺序。不要用不稳定排序算法处理消息列表，否则可能出现随机换位。
5.3 摘要触发过于频繁导致成本上升
摘要式截断每触发一次就要多一次模型调用，如果触发频繁，对小规模项目来说是一笔可观的成本开销。这个问题在配置摘要触发条件时往往没想清楚，触发阈值设置得太低，导致每几轮对话就摘要一次。
调优思路在于三个参数：摘要触发间隔的消息条数、触发间隔的 Token 增长量、最少对话轮数限制。前两个控制触发频率，最后一个保证至少在对话进行一段时间后才允许摘要，避免用户刚聊两句就触发摘要。比如设置成“至少 15 条新消息或者新增长 2000 Token 才触发摘要”，实际运行下来摘要频率会稳定在一个较低的水平。摘要模型本身也要选得合适，不要用最贵的大模型做摘要任务，等在离线回放里确认效果后再考虑是否升级。
5.4 窗口边缘的 Token 数预估偏差
tokenizer 统计结果和模型实际切分结果偶尔会有差异，尤其是用第三方 tokenizer 库的时候。差几 Token 没有明显影响，但如果偏差持续累积，最终请求时可能发现总长度超过了窗口限制。表现为偶发性的“上下文长度超限”报错，而且只出现在大量历史对话之后。
这种问题的处理方式是保守预留。在预算设置时，给自己留出 10% 左右的余量，比如窗口 8000，实际按 7200 来规划分配。调用前再做一次全量消息的最终 token 统计，如果超过安全线就对历史消息做最后一步裁剪。另外，tokenizer 要按模型的实际版本对齐，模型更新后 tokenizer 的切分规则可能变化，这时候要及时替换库，并重新跑一遍离线回放，避免旧统计值失真。
5.5 常见问题速查表
| 问题 | 可能原因 | 推荐排查路径 |
|---|---|---|
| 回答质量下降 | 关键信息被裁掉 | 打印被删消息，检查与当前问题相关性 |
| 上下文错序 | 消息无时间戳或排序不稳 | 统一 timestamp，使用稳定排序 |
| 摘要成本高 | 触发过于频繁 | 调整摘要触发间隔和 Token 增长阈值 |
| 偶发超限报错 | Token 预估偏差 | 设置 10% 预算余量，加大兜底裁剪 |
| 多角色信息混乱 | 角色权重分配不当 | 检查配额比例，增加用户消息预算 |
6. 实战心得与后续扩展方向
这些策略组合起来用，比我一开始只用一个滑动窗口方案的效果强太多。最早我用纯滑动窗口做客服机器人，窗口之外的信息全丢，用户重复追问时模型完全失忆。后来改了 Token 控制和角色差异化裁剪，核心信息保留率明显上来了，用户的重复提问次数下降了将近一半。再到后来引入摘要式截断，才真正解决了长会话场景的问题。这个演进过程说明，没有万能的策略，截断方案的复杂度必须和业务的信息保留需求匹配。
很多项目在执行这个过程中最容易犯的错误，是把截断当成“上线前最后一件事”来做，等对话效果已经明显退化才去补。实际上，截断策略应该和对话功能同步开发，从第一轮对话样本就开始跑，离线回放出问题就及时修。等到线上流量起来之后再动截断逻辑，风险会大很多，因为你很难预测哪次改动会影响多少用户。
后续如果还想继续扩展，可以往这两个方向走：一个是自适应截断，根据历史对话对当前问题的贡献度动态调整各部分的保留量，而不是靠人工固定配额；另一个是多层记忆结构，把短期会话上下文、长期用户画像、领域知识库分三层存储，各自维护独立的生命周期，在不同类型的问题时检索不同的层。这两种方向都已经是产品级对话系统的标配能力，但它们的基础，仍然是从一套稳定可靠的上下文字段管理开始的。
如果说有什么最重要的心得，那就是：截断策略的每一处细节都必须可观测、可回放。你用的窗口参数、摘要触发条件、配额分配，都要有日志记录和统计口径。否则出了问题，根本说不清是哪个环节弄坏了对话效果。我现在的项目里，任何一版截断策略的调优都会在离线回放集上跑一遍并留存结果，线上出现质量波动时就能快速回滚或者定位到具体策略变化。这套流程看上去笨重，但它在长期维护中的价值远超一开始多花的时间。
