大模型 Token 机制与上下文窗口管理实战

上下文窗口管理

上下文窗口（Context Window）是模型生成响应时能引用的全部文本范围，包括系统提示、用户输入、对话历史及模型输出。它本质上是模型的'工作记忆'。

当前主流模型的上下文窗口持续扩张，GPT-4.1、Claude Sonnet 4 等已达 1M tokens。但更大的窗口不意味着更好的效果。研究发现，随着长度增加，模型会出现'中间遗失'（Lost-in-the-Middle）现象，即对开头和结尾信息检索较好，中间部分表现不佳。

这种随长度增长导致的性能下降被称为'上下文腐烂'（Context Rot）。根源在于 Transformer 架构的注意力机制——Token 越多，成对关系呈指数级增长，导致注意力聚焦能力被摊薄。因此，上下文应被视为有限资源，边际收益递减。

压缩上下文策略

多轮对话会导致上下文累积，逼近窗口上限时模型可能拒绝生成或丢弃早期信息。压缩上下文（Compaction）是一种解决策略：当对话接近容量限制时，利用模型自身能力对历史对话进行摘要提炼，用精简摘要替换冗长历史。

这类似于写读书笔记，保留关键意图、事实和决策，舍弃寒暄和试错过程。压缩后上下文通常只有原始的 10%~30%，大幅降低后续 Token 消耗和推理延迟。

提示词缓存优化

API 请求常携带大量重复内容（如系统提示）。提示词缓存（Prompt Caching）机制允许服务端复用之前的计算结果，无需重新处理相同前缀。

缓存命中条件是精确的前缀匹配。因此，建议按稳定性从高到低排列提示结构：

1. 系统指令、角色设定（几乎不变，放最前）
2. 少样本示例、工具定义（偶尔调整）
3. 用户消息、对话历史（每次变化，放最后）

这样静态内容始终位于前缀位置，稳定命中缓存。OpenAI 缓存命中部分费用通常为正常价格的 50%，Claude 则低至 10%，同时能显著缩短首 Token 响应时间。

实践建议

实际工程中，借助专用分词工具精确计数是成本控制的基础。OpenAI 提供的 tiktoken 是最常用的库。

import tiktoken

def check_token_limit(messages, model="gpt-4o", max_tokens=128000):
    """检查消息列表是否超出上下文窗口限制"""
    enc = tiktoken.encoding_for_model(model)
    total = 0
    for msg in messages:
        # 每条消息本身有固定的格式开销（约 4 个 Token）
        total += 4
        total += len(enc.encode(msg["content"]))
    return total, total < max_tokens

此外，API 响应中的 usage 字段可用于事后统计。养成关注 Token 消耗的习惯，有助于在项目早期建立合理的成本模型，避免上线后出现超预期费用。

总之，精心管理上下文内容与扩大空间同样重要。优先考虑将最相关、高质量的信息放入窗口，而非简单堆砌所有内容。