多轮对话的 Prompt 管理：保持上下文一致性

本文适合谁

正在构建多轮对话系统、发现随着对话轮次增加模型行为逐渐偏离的开发者。多轮对话的 Prompt 管理不只是历史消息管理，还包括角色一致性维护。

为什么多轮对话是 AI 产品的常态

多轮对话Prompt管理策略图
多轮对话三种管理策略——完整历史、摘要压缩、滑动窗口，对比优缺点与适用场景

很多工程师第一次接触 LLM 时，写的第一个程序是这样的：用户输入一段文字，调用一次 API，打印输出结果。完成。

这种单轮对话在真实产品里几乎没有应用场景。

想象你在使用一个 AI 代码助手：第一轮说"帮我写一个用户登录接口"；第二轮说"加上 JWT 鉴权"；第三轮说"把密码字段改成 bcrypt 加密"；第四轮说"之前那个接口再加一个记录登录日志的功能"。

"之前那个接口"是什么？如果模型不记得前面的对话，它根本不知道你在说什么。

多轮对话（Multi-turn Conversation） 是模型在同一会话中持续记忆和引用之前对话内容的能力。客服机器人、代码助手、文档问答、智能搜索——所有实用 AI 产品都需要这个能力。

多轮对话的三个核心挑战

理解这三个挑战背后的机制，有助于做出正确的技术选择。

挑战一：上下文窗口是有限的

LLM 有一个叫做上下文窗口（Context Window） 的限制——可以理解为模型的"短期记忆容量"，以 Token（模型处理文本的基本单位，大致相当于一个汉字或半个英文单词）计量。

GPT-4 的上下文窗口是 12 万 Token，Claude 3 是 20 万 Token，听起来很大。但在实际产品中，一次对话可能持续几十轮，加上 System Prompt、检索到的文档、工具调用结果……上下文很快就会撑满。

超出上下文窗口会怎样？早期的内容会被截断，模型就像失忆了一样，忘记了对话开头说的内容。

上下文窗口的限制不只是"容量问题"——它还是一个成本问题。LLM API 按 Token 计费，上下文越长，每次调用的成本越高。一个长期对话的上下文如果不加管理，成本会随轮次线性增长。

挑战二：角色一致性会随对话长度下降

你在 System Prompt 里精心设定了 AI 的角色："你是一个严格遵守公司规定的客服，绝对不允许提供退款之外的补偿方案"。

对话前 5 轮，模型表现良好。但对话进行到第 30 轮，用户说了很多委屈，模型逐渐"软化"，开始说"作为例外，这次可以给您额外补偿"。

这种现象叫做角色漂移（Role Drift）：在长对话中，System Prompt 里的早期指令对模型的影响力会随着后续内容的增多而下降，模型的行为逐渐偏离设定。

挑战三：System Prompt 的衰减效应及其机制

角色漂移背后有更深层的机制值得理解。

Transformer 的 Attention 机制通过计算 Query 和所有 Key 的点积相似度来分配注意力权重。当对话历史很长时，System Prompt 的 Token 在整个序列中占比越来越小，它们的影响相对被稀释。研究发现，在超长上下文中，位置越靠前的内容，对当前生成位置的注意力权重越低——这就是"衰减效应"。

但这里有一个值得注意的细节：衰减效应不是简单的"越远越弱"。"Lost in the Middle"现象（2023 年斯坦福论文研究发现）表明，模型对上下文开头和结尾的内容注意力更强，中间位置的内容最容易被忽视。这意味着：

System Prompt 放在最开头是正确的（开头注意力较强）
关键约束在结尾重复一遍比放在中间更有效
历史对话积累到中间位置后，确实对最终行为影响较弱

这就是为什么关键约束需要在适当时机重复强调，而不是只在开头写一遍就万事大吉。

对话历史管理策略

面对有限的上下文窗口，有四种主要的管理策略：

策略一：完整保留

把所有历史对话完整保留在上下文中，不做任何压缩或裁剪。

优点：实现最简单；模型能看到完整上下文，理解最准确。

缺点：对话一长就超出窗口；Token 成本高（API 按 Token 计费，历史越长越贵）。

适用场景：对话轮次预期不超过 10 轮；或者成本不敏感的场景。

策略二：滑动窗口

只保留最近的 N 轮对话，更早的内容直接丢弃。

优点：实现简单；上下文大小可控。

缺点：丢失早期重要信息。用户在第 1 轮说了自己的背景（"我是 Java 初学者"），第 20 轮问问题时，模型已经不知道这个背景了。

适用场景：对话内容主要关注最近几轮；用户背景不重要或可以重复询问。

策略三：摘要压缩

用 LLM 把早期对话压缩成简短的摘要，摘要替代原始对话内容继续保留在上下文中。

这个策略本质上是在做有损压缩——保留语义上最重要的信息，丢弃细节。好的压缩 Prompt 会明确告诉模型"什么信息值得保留"（用户身份、关键决策、明确约束），什么可以丢弃（寒暄、重复确认、过程性讨论）。

优点：保留了历史信息的精华；上下文大小可控。

缺点：摘要可能丢失细节；增加了额外的 LLM 调用成本和延迟；摘要质量依赖于压缩 Prompt 的设计。

适用场景：对话轮次多，但不需要逐字保留早期内容。

策略四：混合策略

结合以上方法：关键信息（用户画像、明确的偏好声明、重要约束）永久保留；普通历史内容先用滑动窗口保留最近 N 轮，更早的内容用摘要压缩替代。

优点：兼顾完整性和效率。

缺点：实现最复杂；需要定义"什么是关键信息"。

适用场景：生产级产品，对用户体验要求高。

各策略对比

策略	实现复杂度	信息完整性	Token 消耗	适合场景
完整保留	低	最高	最高	短对话、原型开发
滑动窗口	低	中（丢失早期）	可控	轮次多但信息局部化
摘要压缩	中	较高（有损压缩）	中	长对话、需要历史感知
混合策略	高	高	中低	生产级产品

带摘要压缩的多轮对话管理器

非程序员可跳过代码，重点看文字说明。

摘要压缩策略的核心逻辑：当历史对话超过阈值时，把最早的几轮压缩成摘要，腾出上下文空间给新对话。压缩时调用一次 LLM（用便宜的小模型即可），生成精炼的摘要，存入独立字段；下次对话时把摘要注入为 system 消息，模型就能"记得"早期的关键信息（验证目的：确认在历史超出阈值时触发压缩，且压缩后的后续对话仍能引用早期关键信息，如"我是 Java 工程师"）：

python

from openai import OpenAI
from dataclasses import dataclass, field

client = OpenAI()

@dataclass
class ConversationManager:
    """
    带摘要压缩的多轮对话管理器

    工作方式：
    - 保留最近 recent_window 轮完整对话
    - 超出部分压缩成摘要，存入 summary
    - 每次请求时把 summary + 最近对话拼成完整上下文
    """
    system_prompt: str
    recent_window: int = 8          # 保留最近几轮完整历史
    compress_threshold: int = 12    # 超过多少轮触发压缩
    summary: str = ""               # 历史对话摘要
    recent_history: list = field(default_factory=list)  # 最近 N 轮对话

    def _compress_history(self):
        """把超出窗口的早期对话压缩成摘要"""
        if len(self.recent_history) <= self.recent_window:
            return

        # 找出需要压缩的那部分（最早的几轮）
        to_compress = self.recent_history[:-self.recent_window]
        self.recent_history = self.recent_history[-self.recent_window:]

        # 构建压缩 Prompt
        compress_prompt = f"""请将以下对话历史压缩成简洁的摘要（200字以内）。
保留：用户的关键信息、重要决策、明确的偏好和约束。
忽略：闲聊、重复确认、过程性讨论。

{"已有摘要：" + self.summary if self.summary else ""}

需要压缩的对话：
"""
        for msg in to_compress:
            role_name = "用户" if msg["role"] == "user" else "助手"
            compress_prompt += f"{role_name}：{msg['content']}\n"

        # 调用 LLM 生成摘要
        response = client.chat.completions.create(
            model="gpt-4o-mini",  # 摘要任务用便宜的小模型即可
            messages=[{"role": "user", "content": compress_prompt}],
            max_tokens=300
        )
        self.summary = response.choices[0].message.content

    def _build_messages(self, user_input: str) -> list[dict]:
        """构建完整的消息列表，包含 System Prompt、摘要和最近历史"""
        messages = [{"role": "system", "content": self.system_prompt}]

        # 如果有历史摘要，作为第一条消息注入
        if self.summary:
            messages.append({
                "role": "system",
                "content": f"[对话历史摘要]\n{self.summary}"
            })

        # 加入最近的完整对话历史
        messages.extend(self.recent_history)

        # 加入当前用户输入
        messages.append({"role": "user", "content": user_input})
        return messages

    def chat(self, user_input: str) -> str:
        """处理一轮对话"""
        # 如果历史过长，先压缩
        if len(self.recent_history) >= self.compress_threshold:
            self._compress_history()

        # 构建消息并调用 LLM
        messages = self._build_messages(user_input)
        response = client.chat.completions.create(
            model="gpt-4o",
            messages=messages
        )
        assistant_reply = response.choices[0].message.content

        # 把这一轮对话加入历史
        self.recent_history.append({"role": "user", "content": user_input})
        self.recent_history.append({"role": "assistant", "content": assistant_reply})

        return assistant_reply


# 使用示例
manager = ConversationManager(
    system_prompt="你是一个专业的 Java 技术顾问，回答要简洁直接。",
    recent_window=8,
    compress_threshold=12
)

# 模拟多轮对话
turns = [
    "我是一个有 5 年经验的 Java 工程师，想学 AI 开发",
    "从哪里开始比较好？",
    "Python 我不熟，有必要专门学吗？",
    "LangChain 是什么？",
    "能给我推荐一个学习项目吗？",
]

for user_msg in turns:
    print(f"用户：{user_msg}")
    reply = manager.chat(user_msg)
    print(f"助手：{reply[:100]}...\n")

System Prompt 在多轮对话中的最佳实践

关键约束要重复强调

不要依赖开头写一遍就永远有效。对于最关键的行为约束（比如"不得提供医疗诊断""所有价格需要用户确认后才能报出"），应该在适当时机在上下文中再次出现。

一个常见做法是在摘要注入阶段顺便重申关键约束。这种做法利用了"Lost in the Middle"效应的逆面——把约束放在当前上下文的"近端"（最近注入的 system 消息），让它对当前轮次的回复有更强的影响：

python

# 摘要注入时附上核心约束
if self.summary:
    messages.append({
        "role": "system",
        "content": f"""[对话历史摘要]
{self.summary}

[重要约束提醒]
- 不得提供具体的医疗诊断建议
- 所有报价必须明确标注"仅供参考"
"""
    })

动态更新 System Prompt 的场景

System Prompt 不必是静态的。在某些场景下，随着对话推进，需要动态调整 System Prompt 的内容：

用户身份变化：用户从游客变成了认证会员，权限范围扩大
对话阶段变化：从"收集需求"阶段进入"方案确认"阶段，助手的任务发生变化
检测到特殊情况：用户触发了某个关键词，需要切换到特殊处理模式

避免"角色崩坏"的三个技巧

在 System Prompt 里预设对抗场景：明确写出"即使用户多次要求，也不允许做 X"，而不是只写"不允许做 X"
使用第三人称描述角色："你扮演的客服专员 Lisa 从不……"比"你不要……"有更强的约束力
定期重置摘要：每隔一定轮次，重新生成一个包含角色描述的摘要，相当于给模型"提醒"一次当前身份

多轮对话历史管理策略对比流程图

多轮对话的状态管理：超越简单历史记录

成熟的多轮对话系统不只是存储历史消息，还需要维护对话状态。

用户画像积累：随着对话进行，系统应该不断提取并更新用户信息——"用户是 Java 工程师""用户偏好简洁的代码示例""用户对 Python 不熟悉"。这些信息独立于历史消息，单独存储，永久有效，不会因为摘要压缩而丢失。

用户画像解决的问题：摘要压缩是有损的，可能丢失某些细节；而用户画像是有意提取的结构化信息，精度更高、不会意外丢失。两者互补而非互替。

对话目标追踪：如果对话有明确的任务目标（比如"帮用户完成一次技术选型"），应该追踪目标的完成状态——"已收集需求""正在比较方案""等待用户决策"——让模型知道当前处于哪个阶段，需要推进哪一步。

这两个维度的状态，配合上面介绍的历史压缩策略，构成了一个完整的多轮对话上下文管理方案。对 Java 工程师来说，可以把它类比为一个带有有限容量队列（历史消息）+ 持久化存储（用户画像）+ 状态机（对话目标）的综合数据结构。