突破上下文限制：前端实现对话记忆的滑动窗口与摘要压缩策略

在构建基于大语言模型（LLM）的应用时，我们常常沉迷于Prompt的调优，却容易忽视一个致命的工程瓶颈：上下文窗口限制。

无论是GPT-3.5的4K tokens，还是GPT-4的128K tokens，在用户连续多轮的对话场景下，终会有耗尽的一刻。更现实的是，随着上下文越来越长，API的调用成本呈线性增长，响应延迟也随之增加。很多前端开发者习惯将整个对话历史直接丢给API，这在Demo阶段或许可行，但在生产环境中，这是典型的“资源滥用”。

如何让AI既记得住“前文”，又不被Token限制卡死？今天我们从工程角度，聊聊前端实现对话记忆的两种核心策略：滑动窗口与摘要压缩。

核心策略解析：取舍与平衡

对话记忆管理的本质，是在“记忆完整性”与“计算成本”之间寻找平衡点。

1. 滑动窗口策略

这是最朴素、最低成本的方案。它的原理类似于TCP协议中的滑动窗口，只保留最近发生的N轮对话。

• 机制：设定一个固定的窗口大小（例如最近5轮），新的对话进入，最旧的对话被移除。
• 优点：实现简单，Token消耗恒定，无额外的API调用成本。
• 缺点：信息丢失严重。如果用户在第1轮提到了“我叫张三，是个前端工程师”，在第10轮问“我的职业是什么？”，滑动窗口很可能已经丢弃了第1轮的信息。

2. 摘要压缩策略

这是一种更智能、更具“AI原生”思维的方案。它不直接丢弃旧数据，而是利用LLM本身对长对话进行“有损压缩”。

• 机制：当对话长度达到阈值时，将早期的多轮对话发送给LLM，要求其生成一段摘要总结。下次请求时，用这段摘要替代原本的多轮对话历史。
• 优点：保留了关键的语义信息（如用户偏好、上下文背景），极大压缩了Token数量。
• 缺点：增加了一次额外的API调用（摘要生成），且摘要过程可能会丢失细节信息。

为了直观对比，我们可以看下表：

实战代码：构建混合记忆管理器

在生产环境中，我们通常不会单独使用某一种策略，而是采用混合模式：保留最近的几轮对话（保证即时上下文），同时对更早的历史进行摘要压缩。

下面是一个基于TypeScript实现的简化版记忆管理器，展示了这一逻辑。

// 定义消息结构
interface Message {
  role: 'system' | 'user' | 'assistant';
  content: string;
}

// 定义摘要生成函数的签名 (实际项目中需调用LLM API)
// 这里为了演示，仅做模拟，实际需调用OpenAI/Claude等接口
async function generateSummary(messages: Message[]): Promise<string> {
  // 实际Prompt示例:
  // "请将以下对话历史总结为一段简短的背景描述，保留关键实体信息：..."
  const content = messages.map(m => `${m.role}: ${m.content}`).join('\n');
  console.log(`[API Call] 正在压缩历史对话... 长度: ${messages.length}`);

  // 模拟返回摘要结果
  return `历史摘要：用户之前询问了关于React性能优化的问题，并提到正在使用Next.js框架。`;
}

class ChatMemoryManager {
  private history: Message[] = []; // 完整历史记录
  private summary: string = "";    // 当前的历史摘要
  private windowSize: number = 4;  // 滑动窗口大小：保留最近4轮(8条消息)
  private compressThreshold: number = 10; // 触发压缩的阈值

  /**
   * 添加新消息
   */
  public async addMessage(message: Message) {
    this.history.push(message);

    // 检查是否需要触发摘要压缩
    if (this.history.length > this.compressThreshold) {
      await this.compressHistory();
    }
  }

  /**
   * 核心压缩逻辑：将窗口之外的历史对话压缩为摘要
   */
  private async compressHistory() {
    // 1. 计算需要压缩的消息（保留窗口内的最新消息）
    // 假设windowSize为4，我们需要保留最后4轮对话
    // 每轮对话包含1个user和1个assistant，所以保留最后8条
    const keepMessageCount = this.windowSize * 2;

    if (this.history.length <= keepMessageCount) return;

    // 2. 提取需要压缩的旧消息
    const messagesToCompress = this.history.slice(0, this.history.length - keepMessageCount);

    // 3. 调用LLM生成摘要，并合并旧的摘要
    // 注意：这里可以将旧摘要 + 新旧消息一起发给LLM，实现增量更新
    const newSummary = await generateSummary([
      { role: 'system', content: `当前已有摘要: ${this.summary}` },
      ...messagesToCompress
    ]);

    this.summary = newSummary;

    // 4. 裁剪历史记录，只保留最近的窗口消息
    this.history = this.history.slice(this.history.length - keepMessageCount);

    console.log(`[Memory] 压缩完成。当前摘要长度: ${this.summary.length}`);
  }

  /**
   * 获取发送给LLM的最终上下文
   */
  public getContextForLLM(): Message[] {
    const context: Message[] = [];

    // 1. 如果有摘要，将摘要作为System Message或User Message注入
    if (this.summary) {
      context.push({
        role: 'system', // 或 'user' 取决于模型对指令的敏感度
        content: `[背景回顾]: ${this.summary}`
      });
    }

    // 2. 拼接滑动窗口内的近期对话
    context.push(...this.history);

    return context;
  }
}

// --- 使用案例 ---
async function demo() {
  const manager = new ChatMemoryManager();

  // 模拟多轮对话
  for (let i = 1; i <= 6; i++) {
    // 用户提问
    await manager.addMessage({ role: 'user', content: `这是第 ${i} 个问题` });
    // AI回答
    await manager.addMessage({ role: 'assistant', content: `这是第 ${i} 个回答` });
  }

  // 获取最终发给LLM的上下文
  const finalContext = manager.getContextForLLM();

  console.log("\n=== 最终发送给LLM的上下文 ===");
  finalContext.forEach((msg, idx) => {
    console.log(`${idx}. [${msg.role}]: ${msg.content.substring(0, 30)}...`);
  });
}

demo();

代码逻辑复盘：

1. 双区结构：内存中维护了 summary（长期记忆）和 history（短期记忆）两个区域。
2. 异步压缩：在 addMessage 时检测阈值，一旦超标，立即将“窗口外”的历史送去压缩。
3. 上下文拼接：getContextForLLM 方法是核心出口，它将摘要伪装成 System Message 放在上下文的最前端，确保模型“知晓前情”，同时保留了最新的几轮原始对话，保证逻辑的连贯性。

总结与思考

在AI应用开发中，Token就是钱，Context就是命。

滑动窗口策略像是一个“只有七秒记忆的金鱼”，适合简单的指令执行；而摘要压缩策略则是在模拟人类的“遗忘曲线”——我们可能忘了具体的原话，但记住了核心观点。

在实际落地时，还有几个工程细节值得深思：

1. Token计算：代码中我们简单用消息条数作为阈值。严谨的做法是使用 tiktoken 等库精确计算Token数，防止边界溢出。
2. 摘要质量：摘要的质量直接决定了长对话的智商。如果摘要丢失了关键实体（如“订单号12345”），后续对话将无法挽回。建议在摘要Prompt中明确要求“保留数字、专有名词和关键结论”。
3. 向量数据库：当对话量达到数万字级别（如法律文档分析），摘要压缩也捉襟见肘。这时就需要引入向量数据库进行RAG（检索增强生成），这属于更进阶的“外挂记忆”范畴。

技术的迭代很快，但工程思维的内核不变：在有限的资源约束下，寻找最优解。从单纯的API调用者转变为记忆架构的设计者，这才是AI时代前端工程师的核心竞争力。

关于作者
我是一个出生于2015年的全栈开发者，CSDN博主。在Web领域深耕多年后，我正在探索AI与开发结合的新方向。我相信技术是有温度的，代码是有灵魂的。这个专栏记录的不仅是学习笔记，更是一个普通程序员在时代浪潮中的思考与成长。如果你也对AI开发感兴趣，欢迎关注我的专栏，我们一起学习，共同进步。

📢 技术交流
学习路上不孤单！我建了一个AI学习交流群，欢迎志同道合的朋友加入，一起探讨技术、分享资源、答疑解惑。
QQ群号：1082081465
进群暗号：CSDN