管理对话上下文
Qwen API 是无状态的,不会保存对话历史。要实现多轮对话,您需要在每次请求中传递对话历史。此外,您还可以使用截断、摘要和检索等策略来高效管理上下文并降低 Token 消耗。
要实现多轮对话,您需要维护一个
多模态模型的多轮对话与文本模型有以下区别:
思考模型会返回两个字段:
首先通过 Conversations API 创建一个会话,然后将
您可以手动向会话中添加消息(如补充用户消息或外部知识)。
列出会话中的所有消息,查看完整的对话历史。
更多 Conversations API 操作(更新会话、删除会话、删除消息等),请参见 Conversations。
多轮对话会消耗大量 Token,且可能超出模型的上下文限制。请使用以下策略管理上下文并控制成本。
当对话历史过长时,只保留最近 N 轮对话。这种方法实现简单,但会丢失早期的对话信息。
为了在不丢失核心信息的前提下动态压缩对话历史、控制上下文长度,可以随着对话推进对上下文进行摘要:
a. 当对话历史达到一定长度(如最大上下文长度的 70%)时,提取较早的部分(如前半段),单独调用模型生成该部分的"记忆摘要"。
b. 构造下一次请求时,用"记忆摘要"替换冗长的对话历史,并拼接最近几轮对话。
滚动摘要可能导致部分信息丢失。为了让模型能从大量对话历史中回忆相关信息,可以从线性传递上下文切换为按需检索:
a. 每轮对话结束后,将对话内容存入向量数据库。
b. 用户提问时,基于相似度检索相关的对话记录。
c. 将检索到的对话记录与最新的用户输入合并后发送给模型。
每轮对话的输入 Token 都会增加,导致成本上升。
使用上述上下文管理策略来减少输入 Token,从而降低成本。
如果调用失败,请参见错误信息。
本文介绍如何通过 Responses API、OpenAI 兼容 Chat Completions 或 DashScope API 实现多轮对话,并提供上下文管理策略。
工作原理
要实现多轮对话,您需要维护一个 messages 数组。每轮对话中,将用户的最新提问和模型的回复追加到该数组中,然后将更新后的数组作为下一次请求的输入。
以下示例展示了对话过程中 messages 数组的变化:
1
第一轮
将用户的提问添加到
messages 数组中。2
第二轮
将模型的回复和用户的最新提问添加到
messages 数组中。快速开始
- Responses API
- OpenAI 兼容
- DashScope
Responses API 简化了多轮对话的实现。通过传递 响应示例(第二轮):
previous_response_id 即可自动关联上下文,无需手动管理消息历史。如需更高级的会话管理,请参见使用 Conversations。请使用响应的
id(UUID 格式,如 f0dbb153-117f-9bbf-8176-5284b47f3xxx)作为 previous_response_id。不要使用 output 数组中消息的 id(如 msg_56c860c4-3ad8-4a96-8553-d2f94c259xxx)。响应 id 的有效期为 7 天。多模态模型
- 本节适用于 Qwen3-VL 和 Qwen3.5 等多模态模型。
Qwen-Omni请参见非实时。 - Qwen3-Omni-Captioner 专为单轮任务设计,不支持多轮对话。
- 用户消息的构造:多模态模型的用户消息除了文本外,还可以包含图像、音频等多模态信息。
- DashScope SDK 接口:使用 DashScope Python SDK 时,需调用
MultiModalConversation类;使用 DashScope Java SDK 时,同样调用MultiModalConversation类。
- OpenAI 兼容
- DashScope
思考模型
思考模型会返回两个字段:reasoning_content(思考过程)和 content(最终回复)。更新 messages 数组时,只需保留 content 字段,忽略 reasoning_content 字段。
将助手消息添加到
messages 数组时,请不要包含 reasoning_content 字段,否则会导致请求报错。- OpenAI 兼容
- DashScope
使用 Conversations
previous_response_id 适用于简单的链式对话。如果需要服务端会话管理、跨设备上下文延续或手动控制消息,可以使用 Conversations API 的 conversation 参数。
创建会话并对话
首先通过 Conversations API 创建一个会话,然后将 conversation 参数和 instructions(系统提示词)传入 responses.create。服务端会自动管理上下文。
向会话中添加消息
您可以手动向会话中添加消息(如补充用户消息或外部知识)。
查看对话历史
列出会话中的所有消息,查看完整的对话历史。
注意事项
- ID 有效期:响应
id和会话中的消息有效期为 7 天。conversation本身不过期,可持续使用,但其中过期的消息将不再参与上下文。建议通过instructions参数传递系统指令,而非通过创建会话时的 items,以避免系统指令因过期而丢失。 - 正确的 ID 来源:请使用响应的顶层
id,而非output数组中消息的id。 - 跨轮上下文:每次传入
previous_response_id时,系统会自动关联从首轮对话到当前轮次的完整上下文。 - 互斥性:
previous_response_id和conversation不能同时使用,否则会报错[400] INVALID_REQUEST: Mutually exclusive parameters: Ensure you are only providing one of: previous_response_id or conversation.
如何选择?
| 方式 | 适用场景 |
|---|---|
previous_response_id | 简单的链式多轮对话,无需创建独立会话 |
conversation | 服务端会话管理、跨设备上下文延续、手动增删消息 |
正式使用
多轮对话会消耗大量 Token,且可能超出模型的上下文限制。请使用以下策略管理上下文并控制成本。
1. 上下文管理
messages 数组会随着对话轮次增长,可能超出 Token 限制。
1.1. 上下文截断
当对话历史过长时,只保留最近 N 轮对话。这种方法实现简单,但会丢失早期的对话信息。
1.2. 滚动摘要
为了在不丢失核心信息的前提下动态压缩对话历史、控制上下文长度,可以随着对话推进对上下文进行摘要:
a. 当对话历史达到一定长度(如最大上下文长度的 70%)时,提取较早的部分(如前半段),单独调用模型生成该部分的"记忆摘要"。
b. 构造下一次请求时,用"记忆摘要"替换冗长的对话历史,并拼接最近几轮对话。
1.3. 向量化检索
滚动摘要可能导致部分信息丢失。为了让模型能从大量对话历史中回忆相关信息,可以从线性传递上下文切换为按需检索:
a. 每轮对话结束后,将对话内容存入向量数据库。
b. 用户提问时,基于相似度检索相关的对话记录。
c. 将检索到的对话记录与最新的用户输入合并后发送给模型。
2. 成本控制
每轮对话的输入 Token 都会增加,导致成本上升。
2.1. 减少输入 Token
使用上述上下文管理策略来减少输入 Token,从而降低成本。
2.2. 使用支持上下文缓存的模型
messages 数组会被重复处理和计费。上下文缓存(适用于 Qwen-Max、Qwen-Plus、Qwen-Flash 和 Qwen-Coder 等部分 Qwen 模型)可以降低成本并提升响应速度。
上下文缓存功能自动启用,无需修改代码。