前端 AI 对话历史存储与上下文回溯方案设计

前端 AI 对话历史存储与上下文回溯方案设计

在当前的大模型应用浪潮中，很多前端开发者切入 AI 领域的第一步往往是封装一个 ChatGPT 般的对话界面。起初，我们可能只是简单地将用户输入和 AI 回复 Push 到一个数组中，并在页面上渲染。然而，随着应用场景的深入，这种'玩具级'的架构很快就会面临严峻挑战。

背景：被忽视的'记忆'成本

很多前端同学在开发 AI 应用时，最容易踩的坑就是'只顾眼前交互，忽视持久化与上下文管理'。

痛点主要体现在三个方面：

1. 数据脆弱性：用户不小心刷新页面，长达几十轮的深度对话瞬间灰飞烟灭。这种体验在 Web 端是致命的，用户无法接受自己的'思考过程'因误操作而丢失。
2. 上下文窗口限制：大模型都有 Token 限制（如 GPT-3.5 的 4k，GPT-4 的 8k/32k）。如果前端只是无脑累加历史记录发给后端，很快就会报错 context_length_exceeded。前端必须具备'上下文回溯'与'裁剪'的能力。
3. 多会话管理：现代 AI 应用往往是多会话并行的（类似 ChatGPT 左侧列表）。如何高效索引、切换、存储多个会话的历史记录，对前端的数据结构设计提出了要求。

这不仅是存储问题，更是架构设计问题。我们需要在前端构建一套轻量级但健壮的'记忆管理系统'。

核心内容：分层存储与滑动窗口策略

针对上述痛点，理性的解决方案应当包含两个核心维度：存储介质的选择与上下文窗口的管理策略。

1. 存储介质：IndexedDB 优于 localStorage

虽然 localStorage 简单易用，但在 AI 对话场景下，它并不合适。AI 对话产生的数据量增长迅速，且单条消息可能包含大段的代码或 Markdown 文本。localStorage 有 5MB 的大小限制，且是同步操作，容易阻塞 UI 线程。

推荐方案：IndexedDB。
IndexedDB 容量大（通常几百 MB 以上），支持异步操作，非常适合存储非结构化的对话数据。我们可以设计一张 conversations 表，以 sessionId 为主键，存储整个对话树。

2. 上下文管理：滑动窗口与摘要回溯

前端不能把所有历史记录都塞给 API。我们需要实现一个滑动窗口机制。

• 窗口大小：设定一个阈值（如最近 10 轮对话）。
• 系统提示词保留：System Prompt 必须始终保留在上下文头部。
• 远期记忆裁剪：超过窗口期的对话，前端可以选择截断，或者调用单独的 API 生成摘要，将摘要作为一条新的 Message 塞入上下文。

下面我们通过代码实战来落地这套方案。

实战代码：构建前端记忆管理器

我们将使用 TypeScript 定义一个 HistoryManager 类，结合 IndexedDB（模拟逻辑，实际生产推荐使用 Dexie.js 等库封装）和滑动窗口算法。

1. 数据模型定义

首先，明确我们的数据结构。不仅仅是消息数组，还要包含会话元信息。

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

// 定义会话结构
interface Conversation {
  id: string; // 会话唯一标识
  title: string; // 会话标题（可由第一条消息生成）
  messages: Message[];
  createdAt: number;
  updatedAt: number;
}

2. 上下文窗口裁剪核心逻辑

这是前端与 AI 交互的关键。我们需要一个函数，从完整的 messages 中提取出符合 Token 限制或条数限制的'有效上下文'。

class HistoryManager {
  private db: IDBDatabase;
  // 设定保留的对话轮数（一轮 = User + Assistant）
  private readonly CONTEXT_WINDOW_SIZE = 10;

  constructor(db: IDBDatabase) {
    this.db = db;
  }

  /**
   * 核心方法：获取用于 API 调用的有效上下文
   * @param messages 完整的历史消息列表
   * @param systemPrompt 系统提示词
   * @returns 经过裁剪的、可用于发送的消息数组
   */
  public getValidContext(messages: Message[], systemPrompt: string): Message[] {
    // 1. 始终保留系统提示词
    const systemMessage: Message = {
      id: 'sys',
      role: 'system',
      content: systemPrompt,
      timestamp: 0,
    };
    // 2. 滑动窗口算法：只取最近的 N 条记录
    // 这里简单按条数裁剪，生产环境建议按 Token 数估算
    // filter out system message just in case
    const historyWithoutSystem = messages.filter((m) => m.role !== 'system');
    // 截取最后 N 条
    const recentHistory = historyWithoutSystem.slice(-this.CONTEXT_WINDOW_SIZE * 2);
    // 3. 组装最终上下文：System Prompt + 最近对话
    return [systemMessage, ...recentHistory];
  }
  // ... 其他方法
}

3. 持久化存储实战（IndexedDB 模拟）

以下代码展示了如何将对话保存到 IndexedDB 中，确保刷新不丢失。

// 数据库操作封装
class ChatDB {
  private dbName = 'AI_Chat_DB';
  private storeName = 'conversations';
  public db: IDBDatabase | null = null;

  async init(): Promise<void> {
    return new Promise((resolve, reject) => {
      const request = indexedDB.open(this.dbName, 1);
      request.onerror = () => reject(request.error);
      request.onsuccess = () => {
        this.db = request.result;
        resolve();
      };
      // 创建表结构
      request.onupgradeneeded = (event: any) => {
        const db = event.target.result;
        if (!db.objectStoreNames.contains(this.storeName)) {
          // 以 id 为主键
          db.createObjectStore(this.storeName, { keyPath: 'id' });
        }
      };
    });
  }

  /**
   * 保存或更新会话
   * 实战中建议做'防抖'处理，避免频繁写入
   */
  async saveConversation(conversation: Conversation): Promise<void> {
    if (!this.db) await this.init();
    return new Promise((resolve, reject) => {
      const transaction = this.db!.transaction([this.storeName], 'readwrite');
      const store = transaction.objectStore(this.storeName);
      const request = store.put(conversation); // put 操作是 idempotent 的
      request.onsuccess = () => resolve();
      request.onerror = () => reject(request.error);
    });
  }
}

4. 综合应用示例

在实际的业务组件中，我们的调用流程如下：

// 业务逻辑伪代码
async function handleUserSend(userInput: string, currentConversation: Conversation) {
  // 1. 构造用户消息
  const userMsg: Message = {
    id: crypto.randomUUID(),
    role: 'user',
    content: userInput,
    timestamp: Date.now(),
  };
  // 2. 更新本地状态（乐观更新 UI）
  currentConversation.messages.push(userMsg);
  // 3. 计算上下文（裁剪逻辑）
  const manager = new HistoryManager(dbInstance);
  const context = manager.getValidContext(
    currentConversation.messages,
    "你是一个资深的前端架构师，请用简洁的语言回答问题。"
  );
  // 4. 发送给 LLM API
  const aiResponse = await fetchAIResponse(context); // 假设这是你的 API 调用函数
  // 5. 追加 AI 回复并持久化
  currentConversation.messages.push(aiResponse);
  currentConversation.updatedAt = Date.now();
  // 6. 存入 IndexedDB
  const chatDb = new ChatDB();
  await chatDb.saveConversation(currentConversation);
}

总结与思考

在前端侧设计 AI 对话历史存储，绝不仅仅是'存数据'那么简单。这本质上是在前端构建一个简易的'上下文管理引擎'。

通过这次重构，有几点深刻的体会：

1. 前端的价值在于交互与体验：后端的大模型是无状态的，前端必须承担起状态管理的责任。IndexedDB 虽然 API 繁琐，但在处理大量结构化数据时，其性能优势是 localStorage 无法比拟的。
2. 成本控制发生在客户端：很多开发者抱怨 Token 消耗快，其实往往是因为前端没有做好上下文裁剪。通过滑动窗口策略，前端可以有效控制 API 调用的 Token 消耗，直接为企业节省真金白银的成本。
3. 未来的演进方向：目前的方案是基于'条数'的简单裁剪。更高级的方案是引入向量数据库（Vector DB），将历史对话向量化存储。当用户提问时，通过语义检索提取最相关的历史片段注入上下文，实现真正的'长时记忆'。这也是目前探索的方向之一。

技术选型没有银弹，只有最适合业务场景的方案。希望这套方案能为正在转型 AI 开发的前端同行们提供一些务实的参考。