大模型上下文管理完全指南:从一次"对话越聊越久、AI 突然忘了开头还报 token 超限"看懂上下文窗口

2024 年我做一个多轮对话的 AI 助手。逻辑很简单:我维护一个 history 列表,用户每说一句、AI 每答一句,我都 append 进去;下一轮请求,就把整个 history 原样发给模型。第一版我做得很直接:history 只增不减,反正"历史给得越全,模型记得越清楚"。本地一测——很好:连聊七八轮,AI 上下文衔接得很自然,还记得我前面说过的话。我心里很踏实:"把所有历史都塞进去,这不就有记忆了嘛。"可上线之后,问题一个接一个冒出来,而且现象一个比一个怪。第一类:有用户聊得久了,某一轮请求突然报错——context_length_exceeded,整个对话直接卡死,再也发不出话。第二类更微妙:还没报错之前,AI 的回答就已经悄悄变差了——它会忘掉用户在对话开头说过的关键约定、会答非所问、会把前面聊过的事和后面的搅在一起。第三类:财务那边找过来,说这个 AI 助手的 token 账单涨得不正常。我盯着这三类问题查了很久才彻底想明白,第一版错在一个根本的认知上:我以为"把对话历史全塞进去,模型的记性就最好"。可这个想法处处都错。模型的上下文窗口,是一个有硬性 token 上限的、装不下无限内容的"工作台";history 只增不减,迟早会把这个工作台堆满、堆爆——这是第一类报错。而就算还没堆爆,把一大堆又长又杂、大半无关的历史无差别地铺在模型面前,反而会稀释它的注意力,让它抓不住真正重要的那几句——这是第二类答非所问。至于账单,每一轮都把越来越长的历史重发一遍,token 消耗自然线性飙升。上下文从来不是"越多越好",而是一件需要主动管理的事:在有限的预算里,放进当前这一轮最该让模型看到的内容。这篇文章就把它梳理一遍:为什么"把全部历史塞进去"会崩、怎么算清一次请求的 token 预算、滑动窗口怎么裁、摘要压缩怎么把旧对话压小、检索式记忆怎么按需召回,以及 system prompt 不能裁、token 要用 tokenizer 算、lost in the middle 这些把上下文管理真正做对要避开的坑。

问题背景

先把那三类问题和我的误判讲清楚,后面所有的设计都是冲着纠正这个误判去的。

现象:一个多轮对话 AI 助手,把对话历史无限 append 进 messages、一起发给模型。短对话一切正常,但长对话出现三类问题:一是某一轮突然报 context_length_exceeded、对话卡死;二是报错之前 AI 的回答就已悄悄变差(忘掉开头、答非所问);三是 token 账单随对话变长线性飙升。

我当时的错误认知:"把对话历史全部塞进去,模型的记性就最好、回答就最准。"

真相:模型的上下文窗口,是一个有硬性 token 上限的有限空间。历史只增不减,迟早撑爆这个上限(报错);即便没撑爆,把冗长、无关的历史无差别堆进去,会稀释模型的注意力(回答变差);而且每轮重发全部历史,成本线性增长。所以上下文要被管理:先用 tokenizer 算清预算,再用滑动窗口、摘要压缩、检索召回等手段,在预算内放进最相关的内容。

要把上下文管理做对,需要几块认知:

• 为什么"把全部历史塞进去"会崩——上下文窗口是有限的 token 预算;
• 怎么用 tokenizer 算清一次请求到底能装多少;
• 滑动窗口——只保留最近 N 轮,简单但会丢信息;
• 摘要压缩——把旧对话压成摘要,省空间又留住信息;
• 检索式记忆、system prompt 不能裁、lost in the middle 这些工程坑。

一、为什么"把全部历史塞进去"会崩

先把这件最根本的事钉死:模型的上下文窗口,是一个有硬性 token 上限的有限空间;对话历史只增不减,迟早会撑爆这个上限;而且即使没撑爆,无差别地堆砌冗长历史,也会让模型抓不住重点。

下面这段代码,就是我那个"聊久了必崩"的第一版——它把历史无限往里堆:

from openai import OpenAI

client = OpenAI()

history = [{"role": "system", "content": "你是一个友好的助手。"}]


def chat_naive(user_input: str) -> str:
    # 反面教材:把全部历史无限往 history 里堆,只增不减。
    history.append({"role": "user", "content": user_input})
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=history,          # 整个 history 一股脑发出去
    )
    answer = resp.choices[0].message.content
    history.append({"role": "assistant", "content": answer})
    return answer
    # 破绽:history 只会越来越长。聊到几十轮,messages 的
    # 总 token 数迟早超过模型上下文上限,请求被直接拒绝;
    # 而且每一轮都把越来越长的历史重发一遍,token 成本线性上涨。

这段代码没有任何语法错误,在对话还短时也工作得很好。它的问题不在代码本身,而在一个错误的容量假设:它默认"messages 这个列表想多长就多长"。可大模型的输入不是一个无底的口袋——它有一个上下文窗口(context window),这是一个用 token 计量的、有硬上限的空间。而且关键的是:这个窗口要同时装下两样东西——你发进去的全部输入(system 指令 + 历史对话 + 当前问题),以及模型即将生成的回复。history 只增不减,就是在让"输入"这部分无限膨胀,直到把整个窗口挤爆。更隐蔽的是:就算还没爆,当历史长到几千上万 token,里面大半是和当前问题无关的闲聊,模型要在这一大片文字里捞出真正相关的几句——它未必捞得准。问题的根子清楚了:你不能把"对话历史"当成一个可以无限增长的东西,你必须主动管理它的大小。而管理的第一步,是先学会量它。

二、token 预算:先算清楚一次请求能装多少

你没法管理一个你量不了的东西。所以上下文管理的第一步,是能精确地算出一组 messages 到底有多少 token。这件事不能靠"数字数"估——必须用模型对应的分词器(tokenizer)来真正编码一遍。OpenAI 系列模型用 tiktoken:

import tiktoken

# 不同模型对应不同编码,gpt-4o 系列用 o200k_base
_enc = tiktoken.get_encoding("o200k_base")


def count_tokens(messages: list) -> int:
    """用真正的分词器,估算一组 messages 的 token 总数。"""
    total = 0
    for msg in messages:
        # 每条消息除内容外,角色名、分隔符还有少量固定开销
        total += 4
        total += len(_enc.encode(msg.get("content", "")))
    return total
    # 关键:必须用 tokenizer 真正编码。中文、英文、代码、标点
    # 的 token 密度天差地别,用 len(字符串) 估会严重失真。

能量了,就能定预算。核心是想清楚:窗口的总上限,要切成两块——一块留给输入,一块留给模型的回复。你必须给回复预留出足够空间,否则模型话说到一半就因为没地方了而被硬生生截断:

MODEL_LIMIT = 128000          # 模型上下文窗口的总 token 上限
RESERVED_FOR_REPLY = 2000     # 给模型生成回复预留的空间


def input_budget() -> int:
    """算出一次请求,真正能留给【输入】的 token 预算。"""
    # 关键:窗口要同时装下"输入"和"输出"。
    # 留给输入的预算 = 总上限 - 预留给回复的空间。
    return MODEL_LIMIT - RESERVED_FOR_REPLY


def fits_budget(messages: list) -> bool:
    """判断这组 messages 是否还在输入预算之内。"""
    return count_tokens(messages) <= input_budget()

有了 count_tokens 和 input_budget,你就有了一把尺子和一条红线。接下来所有的管理手段,本质上都是在回答同一个问题:当历史快要越过这条红线时,砍掉什么、保留什么?最简单粗暴的答案——只保留最近的。

三、滑动窗口:只保留最近 N 轮对话

最简单的管理手段,是滑动窗口:只保留最近的 N 轮对话,更早的直接丢掉。这背后有一个朴素的假设——离当前问题越近的对话,通常越相关。但实现时有一个绝不能错的细节:system 消息永远不能被丢,它是模型的行为基准。

def trim_by_window(messages: list, max_turns: int = 10) -> list:
    """滑动窗口:system 永远保留,其余只留最近 max_turns 轮。"""
    system = [m for m in messages if m["role"] == "system"]
    convo = [m for m in messages if m["role"] != "system"]
    # 一轮 = 一条 user + 一条 assistant,所以保留 max_turns*2 条
    recent = convo[-max_turns * 2:]
    return system + recent
    # 它简单可靠,但有个硬伤:被丢掉的早期对话,信息就
    # 【彻底没了】—— 用户在开头说的偏好、定下的约定,
    # 模型再也想不起来,这正是"AI 忘了开头"的来源。

按"轮数"裁有个问题:每一轮的长短差别很大(有的回复一句话,有的回复一大段代码)。更稳的做法是直接按 token 预算裁——从最旧的一条开始丢,一直丢到整体装得进预算为止:

def trim_by_tokens(messages: list, budget: int) -> list:
    """按 token 预算裁剪:system 保留,从最旧的对话开始丢,直到装得下。"""
    system = [m for m in messages if m["role"] == "system"]
    convo = [m for m in messages if m["role"] != "system"]
    # 一直丢最旧的,直到 system + 剩余对话能塞进预算
    while convo and count_tokens(system + convo) > budget:
        convo.pop(0)                       # 丢掉最旧的一条
    return system + convo
    # 比按轮数裁更精确:它盯着的是真实 token 数,
    # 不会因为某几轮特别长就意外超限。

滑动窗口简单、可靠、零额外成本,是绝大多数对话应用的合理起点。但它的硬伤也很明确:被丢掉的早期对话,信息就彻底消失了。如果用户在第一句就说了"我对花生过敏",聊了三十轮之后,这句话早被滑出窗口——模型再也不知道。直接丢太可惜,有没有办法既腾出空间、又不彻底丢掉信息?有——把它压缩。

四、摘要压缩:把旧对话压成一段摘要

滑动窗口是"把旧对话扔了",摘要压缩是"把旧对话压小了再留着"。思路是:在丢弃旧对话之前,先让模型自己把这批旧对话读一遍、压成一小段摘要,只保留关键事实和约定,然后用这段摘要代替那一大堆原始对话。

def summarize_old_turns(old_messages: list) -> str:
    """把一批即将被丢弃的旧对话,压缩成一段简短摘要。"""
    convo_text = "\n".join(
        f"{m['role']}: {m['content']}" for m in old_messages)
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content":
             "把下面的对话压缩成简短摘要,保留关键事实、用户的"
             "偏好和已达成的约定,丢弃寒暄与客套。"},
            {"role": "user", "content": convo_text},
        ],
    )
    return resp.choices[0].message.content

把摘要和滑动窗口组合起来,就得到一个实用的历史管理函数:最近几轮对话完整保留(细节最重要),更早的对话压成一段摘要(留个大意):

def manage_history(messages: list, keep_turns: int = 6) -> list:
    """摘要 + 滑动窗口:旧对话压成摘要,最近 keep_turns 轮完整保留。"""
    system = [m for m in messages if m["role"] == "system"]
    convo = [m for m in messages if m["role"] != "system"]
    if len(convo) <= keep_turns * 2:
        return messages                    # 还不长,无需压缩
    old = convo[:-keep_turns * 2]          # 要被压缩的旧对话
    recent = convo[-keep_turns * 2:]       # 完整保留的近期对话
    summary = summarize_old_turns(old)
    # 摘要作为一条 system 消息,接在原始 system 之后
    summary_msg = {"role": "system",
                   "content": f"【早前对话摘要】{summary}"}
    return system + [summary_msg] + recent

摘要压缩大幅缓解了"忘掉开头"的问题:那句"我对花生过敏",会被摘要当成关键事实保留下来。但你要清醒:摘要本身也是模型生成的——它可能漏掉某个细节,可能把意思压得走样。它是一种"有损压缩"。而且对一个要服务几个月、几千轮的助手来说,摘要套摘要,信息越压越糊。要做真正长期的记忆,得换一个思路——不靠"压缩",靠"检索"。

五、检索式记忆:把历史存进向量库,按需召回

无论滑动窗口还是摘要,本质上都在"遗忘"——区别只是忘多忘少。检索式记忆(retrieval-based memory)换了个根本思路:什么都不丢,把每一轮对话都原样存进一个向量库;等下一个问题来了,不是把全部历史都带上,而是按这个问题,从向量库里只捞出最相关的几条历史。

def remember(turn_text: str):
    """把一轮对话写入长期记忆:存下它的向量表示。"""
    vec = embed(turn_text)                 # 把文本转成向量
    vector_store.add(text=turn_text, embedding=vec)


def recall(question: str, top_k: int = 4) -> list:
    """按当前问题,从长期记忆里召回最相关的几轮历史。"""
    q_vec = embed(question)
    # 关键:用当前问题的向量,去向量库里做相似度检索。
    # 召回的不是"最近的",而是"和这个问题最相关的"。
    hits = vector_store.search(q_vec, top_k=top_k)
    return [h.text for h in hits]

把检索召回装进对话流程:最近几轮对话直接带(保证连贯),远期历史则按相关性召回(保证不漏掉重要的旧信息):

def chat_with_memory(user_input: str, recent: list) -> str:
    """检索式记忆:近期对话直接带,远期历史按相关性召回。"""
    related = recall(user_input)           # 召回相关的远期历史
    memory_block = "\n".join(related)
    messages = [
        {"role": "system", "content": "你是一个友好的助手。"},
        {"role": "system",
         "content": f"【可能相关的历史记忆】\n{memory_block}"},
        *recent,                           # 最近几轮完整对话
        {"role": "user", "content": user_input},
    ]
    resp = client.chat.completions.create(
        model="gpt-4o-mini", messages=messages)
    answer = resp.choices[0].message.content
    # 这一轮聊完,也存进长期记忆,供以后召回
    remember(f"user: {user_input}\nassistant: {answer}")
    return answer

检索式记忆的精髓,是把"记忆"从"一根越来越长、必须整根带上的链条",变成了"一个庞大的、但每次只按需取用一小部分的仓库"。无论用户是三个月前还是三分钟前说过的话,只要和当前问题相关,就有机会被精准召回。它不便宜(要维护向量库、每轮要做 embedding 和检索),但它是长生命周期 AI 助手记忆方案的主流答案。三种手段都讲完了,但要把上下文管理真正用在生产上,还有几个绕不开的坑。

六、工程坑:system prompt、tokenizer 与 lost in the middle

三种管理手段之外,还有几个工程坑,不处理就会在生产上出事。坑 1:system prompt 永远不能被裁掉。它是模型的行为基准——身份、语气、铁律全在里面。一旦它被当成"旧消息"裁掉,模型会瞬间跑偏。前面每个裁剪函数都单独把 system 拎出来保留,就是为这件事。坑 2:token 一定要用真正的 tokenizer 算。别用 len(字符串) 或"字数 ×1.5"之类的估算——中文、英文、代码、标点的 token 密度天差地别,粗估要么白白浪费预算,要么突然撑爆。坑 3:lost in the middle——别把关键信息埋在长上下文的正中间。研究和实践都发现:模型对上下文开头和结尾的内容更敏感,对正中间的内容容易忽略。所以重要的指令、检索到的关键资料,要放在开头或靠近结尾的位置。

坑 4:关键事实不要只靠自然语言摘要。摘要是有损的,可能把"订单号 A20240517"这种一个字都不能错的信息压糊。真正不能出错的事实(订单号、用户的明确约定、关键参数),应该结构化地单独存——存进一个字典或数据库,而不是混在自然语言摘要里赌它不被压坏。坑 5:图片、工具调用结果也吃 token。多模态的图片、Function Calling 返回的 JSON,都占用上下文空间。算预算时不能只算文本对话,这些"非对话内容"同样要计入。坑 6:成本要监控。把每一轮请求的 token 用量记下来,你才能看见账单为什么涨、管理策略有没有生效。下面这个带预算守卫的入口函数,把上面几点串了起来:

def chat_with_budget(user_input: str, history: list) -> str:
    """带预算守卫的对话入口:发送前裁到预算内,并记录 token 用量。"""
    history.append({"role": "user", "content": user_input})
    managed = manage_history(history)               # 先做摘要压缩
    managed = trim_by_tokens(managed, input_budget())  # 再按 token 兜底裁
    used = count_tokens(managed)
    log_tokens(used)                                # 记录用量,供成本监控
    if used > input_budget():
        # 裁到底仍超预算,通常是单条消息本身就过长
        raise RuntimeError("裁剪后仍超预算,需检查单条消息是否过大")
    resp = client.chat.completions.create(
        model="gpt-4o-mini", messages=managed,
        max_tokens=RESERVED_FOR_REPLY,              # 回复空间锁死在预留值内
    )
    answer = resp.choices[0].message.content
    history.append({"role": "assistant", "content": answer})
    return answer

下面这张图,把一轮对话从"拿到用户输入"到"装配出最终 messages"的完整管理链路串起来:

关键概念速查

避坑清单

1. 别让对话历史只增不减,上下文窗口有硬上限,聊久了必然撑爆报 context_length_exceeded。
2. 窗口要同时装下输入和回复,必须给回复预留空间,否则模型会说到一半被截断。
3. token 必须用模型对应的 tokenizer 真正编码来数,字符数或字数估算会严重失真。
4. 滑动窗口简单可靠是合理起点,但被丢掉的早期信息彻底消失,会导致 AI 忘了开头。
5. 按 token 预算裁比按轮数裁更稳,因为每轮长短差别极大,按轮数易意外超限。
6. 摘要压缩能省空间又留信息,但它是有损的,可能漏细节,关键事实别只靠它。
7. 订单号等一字不能错的事实要结构化单独存,不要混在自然语言摘要里赌不被压坏。
8. 长生命周期助手用检索式记忆,历史全存向量库按问题召回,而不是整根历史都带。
9. system prompt 是行为基准永远不能被裁掉,所有裁剪函数都要单独把它拎出来保留。
10. 关键信息别埋在长上下文正中间,模型存在 lost in the middle,放开头或结尾更稳。

总结

回头看那次"对话越聊越久、AI 突然忘了开头还报 token 超限"的事故,以及我后来在上下文管理上接连踩的坑,最该记住的不是某一段裁剪代码,而是我动手前那个想当然的判断——"把对话历史全塞进去,模型的记性就最好"。这句话错在它把模型的上下文窗口,想象成了一个可以无限装东西的口袋。可它根本不是。它更像一张面积固定的工作台:台子就那么大,你要在上面摊开所有要参考的资料(system 指令、历史对话、当前问题),还要给模型留出一块动笔写答案的地方。你不停地往台上堆历史,先是把那块写字的地方挤没了(回复被截断),再是整张台子堆到放不下(报错),而即便还没堆满,台上东西多得太杂,模型也会在一堆纸里翻不到真正要紧的那一张(答非所问)。上下文管理这件事想清楚的,正是这个:它不是"把记忆喂得越多越好",而是在一张固定大小的台子上,做一名称职的整理者——决定什么该一直摊在台面上、什么该归档压缩、什么该收进抽屉等用时再取。

所以做多轮对话,真正的工程量不在"history.append"那一行主干上。那一行,任何教程的第一页就教完了。真正的工程量,在于你要沿着"历史会无限增长"这个必然趋势,提前把每一步都安排好:你要先有一把尺子,用真正的 tokenizer量清每一轮到底吃掉多少预算;你要划出一条红线,把窗口切成给输入的和给回复的两块;然后,当历史逼近红线,你要按信息的价值分层处理——最近的对话原样留,较旧的对话压成摘要,更久远的则沉入向量库、用时再按相关性召回。这篇文章的几节,其实就是顺着这条思路展开的:先想清楚为什么"全塞进去"会崩,再学会用 tokenizer 算预算,接着是滑动窗口、摘要压缩、检索式记忆这三种由浅入深的管理手段,最后是 system 不可裁、lost in the middle 这几个把上下文管理真正做扎实的工程细节。

你会发现,上下文管理的思路,和现实里一个人怎么整理自己的办公桌完全相通。一个没条理的人,会把所有文件都平铺在桌上,觉得"东西都在眼前,找起来才快"——结果桌子很快堆成一座山,真正在用的那份文件反而被压在最底下。而一个有条理的人会怎么做?他桌面上只留当下正在处理的那几份(这是近期对话);这周用过、但暂时不用的,他写张便签记下要点、原件收进抽屉(这是摘要压缩);更早的资料,他分类归进文件柜,需要时按标签去找(这是检索式记忆);而那张写着办公守则的纸,他始终钉在桌前,从不收走(这是永不裁剪的 system prompt)。桌子的大小是改不了的,一个人办事利不利索,差别从来不在桌子有多大,而在他懂不懂得把什么放在手边、什么收进柜子。

最后想说,上下文管理做没做扎实,差距永远不会在 Demo 里暴露——Demo 里你来回聊三五句,历史短得很,管不管理看起来完全一样,甚至那套裁剪、摘要的代码还会让你觉得多余。它只在真实的、用户会一聊几十上百轮、会断断续续用上好几个月的生产环境里才显形。那时候它会用最难堪的方式给你结账:做不好,你会像我一样,看着用户的对话聊到一半突然卡死、再也发不出话,看着 AI 信誓旦旦地忘掉用户开头交代过的关键约定,看着 token 账单随着对话变长而失控地飙升。而做对了,无论用户聊得多久、多深、多杂,你的 AI 都始终在一个稳定、可控、成本心里有数的上下文里工作:该记的关键约定一直记得,无关的闲聊悄悄沉了下去,久远但相关的信息用时还能精准捞回。所以别等那条 context_length_exceeded 的报错、等失控的账单找上门,在你写下第一行"history.append"的代码时就该想清楚:这个 history,会涨到多大?涨大了谁来管?哪些信息必须一直留着,哪些可以压缩,哪些该沉进仓库等召回?这几个问题都有了答案,你的多轮对话才不只是 Demo 里那个"聊几句很顺"的样子,而是一个无论聊多久都能稳稳带着记忆、把每一轮都答好的可靠助手。

—— 别看了 · 2026