AI API 长对话上下文管理与截断策略实战：如何在有限窗口内保留关键信息

本文属于方法论/工程实践类的常青内容，讲清楚一个几乎所有构建多轮对话类 AI 应用都会遇到的问题：随着对话轮次增加，历史消息迟早会撑满模型的上下文窗口，这时候该截断什么、保留什么，直接决定了用户体验的好坏和调用成本的高低。

问题的本质：上下文窗口是有限资源

无论模型的上下文窗口是 32K、128K 还是 1M tokens，只要对话持续足够久，历史消息累积的 token 数终会超过窗口上限。这时会出现两种糟糕的结果：

1. 直接报错：请求因为超出上下文长度限制被拒绝，用户体验中断

2. 强行截断但策略不当：比如简单粗暴地"只保留最近 N 条消息"，可能把最早提到的关键约束条件（比如用户说"我对某个方案不感兴趣，别再提"）直接丢掉，导致模型"失忆"、重复犯错

更麻烦的是，即使窗口没有被撑满，过长的上下文本身也会拉高每次调用的成本和延迟（每次都要把全部历史重新传入并计费）。所以上下文管理不仅是"防止报错"，更是主动的成本和体验优化手段。

策略一：滑动窗口截断（Sliding Window）

最简单的方案：只保留最近 N 轮对话，超出部分直接丢弃。

def sliding_window_truncate(messages: list, max_messages: int = 20) -> list:
    """
    保留系统提示 + 最近 N 条消息
    system 消息永远保留在最前面
    """
    system_msgs = [m for m in messages if m["role"] == "system"]
    other_msgs = [m for m in messages if m["role"] != "system"]

    # 保留最近的 max_messages 条非系统消息
    recent_msgs = other_msgs[-max_messages:]

    return system_msgs + recent_msgs

优点：实现简单，几乎零额外成本（不需要额外调用模型）。

缺点：早期的重要信息会被无差别丢弃，如果用户在对话早期设定了重要约束，后续容易被模型"遗忘"。

适合场景：闲聊类、客服类对话，早期上下文重要性随时间快速衰减的场景。

策略二：摘要压缩（Summarization）

被丢弃前，先用一次模型调用把旧消息压缩成一段摘要，保留关键信息但大幅减少 token 占用。

def summarize_old_messages(client, old_messages: list, model="gpt-4o-mini") -> str:
    """
    用一个轻量模型把旧消息压缩成摘要
    注意：这里应该用便宜的小模型做摘要，而不是主对话模型，控制额外成本
    """
    conversation_text = "\n".join(
        f"{m['role']}: {m['content']}" for m in old_messages
    )

    response = client.chat.completions.create(
        model=model,  # 用性价比更高的小模型做摘要任务
        messages=[
            {"role": "system", "content": "请将以下对话历史压缩为一段简洁摘要，保留关键事实、用户偏好、已达成的结论，去除闲聊和重复内容。"},
            {"role": "user", "content": conversation_text}
        ],
        max_tokens=300,
    )
    return response.choices[0].message.content


def context_with_summary(client, messages: list, keep_recent: int = 10) -> list:
    if len(messages) <= keep_recent + 1:
        return messages  # 消息量不大，无需压缩

    system_msgs = [m for m in messages if m["role"] == "system"]
    other_msgs = [m for m in messages if m["role"] != "system"]

    to_summarize = other_msgs[:-keep_recent]
    recent = other_msgs[-keep_recent:]

    summary = summarize_old_messages(client, to_summarize)
    summary_msg = {"role": "system", "content": f"[历史对话摘要]: {summary}"}

    return system_msgs + [summary_msg] + recent

优点：既控制了 token 占用，又不会完全丢失早期信息。

缺点：摘要本身需要额外一次模型调用（增加成本和延迟），且摘要质量取决于所用模型的能力，压缩过程中仍可能损失细节。

适合场景：客户支持、咨询顾问类应用，需要长期记住用户背景信息但又要控制成本的场景。

策略三：关键信息锚定（Pinned Context）

让应用主动识别并"锚定"关键信息（比如用户的核心需求、重要约束条件），无论对话进行多久都强制保留在上下文最前面，不参与滑动窗口或摘要压缩的淘汰逻辑。

class ConversationManager:
    def __init__(self, system_prompt: str):
        self.system_prompt = system_prompt
        self.pinned_facts: list[str] = []  # 锚定的关键信息，永不淘汰
        self.messages: list[dict] = []

    def pin_fact(self, fact: str):
        """将关键信息标记为永久保留，比如用户的核心约束"""
        if fact not in self.pinned_facts:
            self.pinned_facts.append(fact)

    def add_message(self, role: str, content: str):
        self.messages.append({"role": role, "content": content})

    def build_context(self, max_recent: int = 15) -> list:
        pinned_block = ""
        if self.pinned_facts:
            pinned_block = "\n[需要始终记住的关键信息]:\n" + "\n".join(f"- {f}" for f in self.pinned_facts)

        system_content = self.system_prompt + pinned_block

        recent_messages = self.messages[-max_recent:]

        return [{"role": "system", "content": system_content}] + recent_messages


# 使用示例
conv = ConversationManager("你是一个专业的旅行顾问。")
conv.pin_fact("用户对海鲜过敏，所有餐厅推荐必须排除海鲜")
conv.pin_fact("预算上限为每人每天500元")
conv.add_message("user", "帮我规划一下东京5天的行程")
context = conv.build_context()

优点：重要约束不会因为对话轮次增加而丢失，实现成本低（不需要额外调用模型）。

缺点：需要应用层主动识别哪些信息该被锚定，如果识别逻辑设计不好，仍可能漏掉重要信息；锚定内容过多也会侵占上下文空间。

适合场景：任何对"一致性"要求较高的场景，比如带约束条件的规划类、决策辅助类应用。

三种策略的成本对比参考

实际生产环境中，三种策略往往是组合使用的：用锚定机制保留最核心的约束信息，用摘要压缩处理中间段的历史，用滑动窗口保留最近几轮的完整细节，兼顾成本和体验。

中转站场景下的额外考量

1. 摘要压缩建议用更便宜的模型：不要用主对话模型（往往是较贵的旗舰模型）来做摘要这种相对简单的任务，通过中转站接入性价比更高的小模型专门处理摘要，能显著降低整体成本

2. 计算 token 数时留意中转站计费口径：不同中转站对于"输入 token"的计费统计口径可能存在细微差异，长对话场景下建议实测确认，避免预算超支

3. 缓存机制可以配合上下文管理一起用：如果所用模型和中转站支持 Prompt Caching，将锚定的关键信息和 system prompt 放在固定不变的位置，配合缓存机制能进一步降低重复调用的成本

总结

长对话上下文管理没有放之四海而皆准的最优解，核心是根据业务场景的"信息保留需求"和"成本敏感度"权衡选择策略。滑动窗口简单省钱但容易丢信息，摘要压缩平衡但有额外成本，关键信息锚定精准但需要额外的识别设计。多数生产级应用会组合使用这几种策略，构建更稳健的长对话体验。

如果你在为长对话类 AI 应用寻找支持完整 Prompt Caching、计费透明的中转站，可以前往 openairouter.net 中转站排行榜 查看实测对比，选择更适合的接入方案。