AI Agent开发中 对话历史该如何设计

核心思想就一句话模型永远看不到完整历史完整历史只存在于存储层喂给模型的是一份被精心裁剪过的上下文。这是所有商用产品ChatGPT、Claude、客服机器人、企业知识助手的共识只是裁剪策略不同。一、商用系统的三层记忆模型几乎所有成熟产品都把历史拆成三层职责完全分离关键区别Layer 0 是给你看的、可回放的Layer 1 才是给模型算的。两者数据结构不同、存储不同、生命周期不同。Layer2 其实可以理解成skills、用户画像、系统的全局设置等等。二、长对话具体怎么处理滚动摘要Rolling Summary这是商用系统应对上万条的标准手法对话初期直接把最近 N 轮塞进上下文。当对话变长、逼近上下文窗口上限时把最旧的一批轮次交给 LLM 压缩成一段紧凑摘要钉在 prompt 顶部常作为一条 SystemMessage 或特殊标记。之后每轮上下文 一段滚动摘要 最近若干轮旧原始消息持续被吞进摘要里。模型对整段对话的记忆 摘要 近期窗口而非原始全量。ChatGPT 的记忆和 Claude 的会话压缩本质上都是这个机制差别只是触发阈值和摘要粒度。三、几个真实产品的做法对照产品完整历史工作上下文跨会话长期记忆ChatGPT全量存 DBUI 可回看近期窗口 滚动摘要独立 Memory 功能提取用户事实用户可查看/编辑/删除Claude会话存库窗口极大20 万 token 超长时摘要Projects 挂载文件作为持久上下文客服机器人银行/电商按工单归档仅本次会话窗口20~50 条从 CRM 检索身份/订单不靠聊天历史企业知识助手RAG几乎不用聊天历史近期窗口做连贯性知识从向量库检索历史只是对话粘性共性没有一家会把完整历史直接塞给模型——那会超 context、烧钱、且噪声大。四、生产环境必补的运营考量商用和 demo 的差距往往不在能对话而在这些成本控制大段摘要 System Prompt 每轮重复发送很贵。生产会用 Prompt Caching / KV CacheOpenAI、Anthropic 都支持把不变的摘要系统提示缓存只增量发新消息。隐私与合规留存 TTL、用户删除权被遗忘权、PII 隔离、多租户行级安全。你代码里 ttl-seconds: 0永不过期在生产必须改。延迟绝不在每轮请求里序列化/反序列化一个巨大的 blob存储层要支持分页和增量追加。可观测性token 用量、摘要触发次数、超窗口丢弃条数都要有指标。五、给你的生产级落地路线加滚动摘要Rolling Summary —— 在现有 Redis 上最快的长期记忆升级消息超阈值就把旧的压成摘要Redis 恒定有界且能记住更早上下文。拆存储与上下文 —— 完整历史移到支持分页的存储Redis 也可用独立 key 列表结构或 Postgres工作上下文只取窗口摘要。加 Prompt Caching TTL —— 直接省成本 合规。零算法难度。可选跨会话语义记忆 —— 抽取用户事实存独立表每次注入 System。对应 Layer 2。六、两套历史L1、L2的理解L0 全量历史L1 工作上下文模型看到的是什么你说的每一句话原封不动窗口 摘要 画像给谁用给人回看/审计给大模型会进 prompt 吗永远不进就是 prompt 本身有多大可以上万条恒定有界≤16 条 一段摘要存哪chat:history:{convId}chat:memory: chat:summary: chat:facts:用户说 10000 句L0 存 10000 句但模型每轮只看到一段摘要 最近十来句。 你在 UI 点查看历史看的是 L0模型永远不会读到那么长。七、五个 Redis key 各存什么八、一次对话流程图关键顺序先落 L0①③再动 L1④。L0 是记账L1 是做题时手里那几张纸。九、摘要生成标准配置maxMessages10、summaryTrigger6所以上限 10 6 16 条。规则只有一条窗口里的消息一旦超过 16 条 → 一次性把最旧的 (超出部分) 挤出去保留最近 10 条并把挤出去的那些交给 LLM 压成摘要。用每轮加 2 条简化走一遍所以摘要不是每轮都生成而是攒够一批才生成一次。这就是为什么它是有成本的、也是可控的。摘要是很久以前发生过什么的浓缩。画像是这个用户是谁、偏好什么。窗口是刚才几轮的原话。三者拼起来模型既有近期细节又有远期记忆还不用把上万条塞进去。类比历史是会议全程录像摘要是会议纪要。模型只看纪要 最近十分钟。