用 Qwen 跑长多轮对话：在一把 key 上裁剪历史又不打断上下文

多轮长对话是 Qwen 这类模型的高频使用场景，但随着轮数增加，每次请求携带的历史消息会不断膨胀。如果不加控制，不仅响应延迟会上升，按官方价 ×1.3 扣费的 USDC 消耗也会随轮数线性增长。本文介绍两种互补的裁剪策略：轮次预算与摘要回灌，帮助你在保持连贯性的同时控制成本。

为什么需要裁剪历史

Qwen 的上下文窗口虽然较大，但每次 API 调用都会将完整的历史消息作为输入计费。当对话进行到几十轮时，输入 token 可能达到数万，每次请求都重复携带全部历史，成本会快速累积。此外，过长的历史也可能稀释关键信息，影响模型对当前问题的关注度。因此，裁剪目标不是简单截断，而是保留对当前回复有价值的内容。

策略一：轮次预算

轮次预算指为历史消息设定固定的轮数上限（例如只保留最近 N 轮），超出部分直接丢弃。这种方法实现简单，适合对话主题单一、近期信息主导的场景。

实施要点

• 按轮次而非按 token 计数：以「用户+助手」为一轮，维护一个固定长度的队列，新消息入队时淘汰最旧的一轮。
• 区分系统提示与历史：系统提示、指令模板始终保留，不参与淘汰。
• 为当前问题预留空间：确保最新用户消息和可能的工具调用结果完整进入上下文。

轮次预算的优点是逻辑清晰、成本可控，但缺点是可能丢失早期的重要设定（如用户偏好、任务背景）。为缓解这个问题，可以配合摘要回灌。

策略二：摘要回灌

摘要回灌指在裁剪历史时，不是直接丢弃，而是将旧历史压缩成一段简短的摘要，作为一条系统消息或前置说明重新注入上下文。这样既减少了 token 数量，又保留了关键信息。

实施要点

• 触发时机：当历史轮数超过预算阈值时，将超出部分（例如最早的 K 轮）送入一次摘要生成调用，输出一段限制长度的摘要。
• 摘要内容：聚焦事实性信息，如用户身份、目标、已确认的结论、待办事项，避免保留寒暄和重复内容。
• 注入位置：将摘要放在系统提示之后、近期历史之前，并明确标注「以下是早前对话的摘要」。
• 幂等更新：每次新增摘要时，可以将旧摘要与新摘要合并，避免摘要无限增长。

摘要本身会产生一次额外的 API 调用，但由于摘要长度远小于原始历史，长期来看净成本仍然下降。

组合使用：预算 + 摘要

实际应用中，两种策略可以组合：设定一个较宽的轮次预算（如保留最近 10 轮），当超出时，将更早的轮次压缩为摘要。这样近期细节完整，早期背景不丢失，同时输入 token 保持稳定。

参考流程

1. 收到新用户消息，追加到历史队列。
2. 如果队列长度超过预算，取出最早的一批轮次。
3. 将这批轮次与已有摘要合并，调用 Qwen 生成新摘要（可指定输出长度上限）。
4. 用新摘要替换旧摘要，并从队列中移除已压缩的轮次。
5. 组装请求：系统提示 + 摘要 + 近期历史 + 当前消息。

在统一 API key 下实践

使用聚合站的统一 API key 调用 Qwen 时，上述策略完全在客户端实现，无需关心底层路由。你可以在同一把 key 下切换不同模型进行摘要生成（例如用较小模型做摘要以降低成本），而对话主流程仍使用 Qwen。由于按官方价 ×1.3 扣费，控制输入 token 直接反映为 USDC 消耗的降低。

注意事项

• 摘要质量监控：定期检查摘要是否遗漏关键约束，必要时调整摘要提示词。
• 避免过度压缩：轮次预算不宜过小，否则近期上下文不足，影响连贯性。
• 测试不同场景：任务型对话与闲聊型对话对历史依赖程度不同，预算参数应分别调优。

小结

轮次预算和摘要回灌是两种轻量且有效的上下文裁剪手段。前者控制硬上限，后者保留软信息。组合使用可以在多轮长对话中维持 Qwen 的回答连贯性，同时让 USDC 消耗不随轮数膨胀。建议从简单的轮次预算开始，逐步引入摘要，并根据实际对话日志调整参数。