多轮对话-上下文管理

提示词工程：怎么把问题讲清楚。

上下文工程：动态选择放进去高质量的提示词，关注的是质量，不是什么都往进放，会淹没核心需求。

主要包含（提示词 + 动态判断是否需要tools信息 + RAG检索出的内容 + 动态抽取或总结 多轮对话的上下文）。

一、上下文管理

messages数组会随对话轮次增加而变长，最终可能超出模型的 Token 限制。可以通过以下方式，在对话过程中管理上下文长度。

1 上下文截断

滑动窗口机制，当对话历史过长时，保留最近的 N 轮对话历史。该方式实现简单，但会丢失较早的对话信息。

2 关键信息提取

不保留完整对话文本，只提取每轮对话的 “核心要素”（如用户需求、结论、关键参数），用结构化格式（列表、键值对）存储。

结构化保留核心上下文：
- 用户需求：代码实现批量读取100个Excel的“销售数据”sheet，计算每个sheet的“总销售额”，输出到新Excel
- 已解决：提供了基础代码（含read_excel和to_excel方法）- 下一轮用户问题：如何处理Excel文件名含特殊字符？

3 滚动摘要

为了在不丢失核心信息的前提下动态压缩对话历史，控制上下文长度，可几轮对话生成一次摘要，替代原始对话历史。

随着对话的进行对上下文进行摘要：

a. 对话历史达到一定长度（如上下文长度最大值的 70%）时，将对话历史中较早的部分（如前一半）提取出来，发起独立 API 调用使大模型对这部分内容生成“记忆摘要”。

b. 构建下一次请求时，用“记忆摘要”替换冗长的对话历史，并拼接最近的几轮对话。

4 向量化召回

滚动摘要会丢失部分信息，为了使模型可以从海量对话历史中“回忆”起相关信息，可将对话管理从“线性传递”转变为“按需检索”：

a. 每轮对话结束后，将该轮对话存入向量数据库；

b. 用户提问时，通过相似度检索相关对话记录；

c. 将检索到的对话记录与最近的用户输入拼接后输入大模型。  

二、成本控制

输入 Token 数会随着对话轮数的增加显著增加使用成本，以下成本管理策略供您参考。

1 减少输入上下文

通过上文介绍的上下文管理策略减少输入 Token，降低成本。

2 使用支持上下文缓存的模型

发起多轮对话请求时，messages 部分会重复计算并计费。qwen-max、qwen-plus等模型提供了上下文缓存功能，可以降低使用成本并提升响应速度，建议优先使用支持上下文缓存的模型。