核心论点LLM 的上下文窗口是硬上限而多节点部署下对话状态在哪直接决定请求打到哪台机器用 Redis 按会话 ID 分片存储 截断策略把有限窗口变成可跨节点复用的共享状态。问题定义上下文窗口有限 多节点不一致LLM 一次能看到的 token模型处理文本的基本单位数有上限视模型从几 K 到上百 K 不等。但客服对话可能持续 50 轮累计远超窗口。更棘手的是分布式用户上一轮打在节点 A这一轮被负载均衡到节点 B——如果上下文只存在 A 的内存里B 就是失忆的。所以上下文不能绑在进程内存必须外置成共享存储。这就引出三个独立问题存哪选型、怎么同步一致性、请求打给谁路由。分布式上下文存储选型高频短文本 · 需过期持久化检索 · 大文档语义检索 · 向量并非排他Redis 也支持向量检索上下文访问特征?Redis低延迟 TTL 自动过期MongoDB文档模型 长期留存向量数据库embedding 相似召回Redis毫秒级读写原生 TTL 过期最适合当前对话的近期消息。代价是无结构化查询长文本检索弱。MongoDB文档模型存完整对话适合需要回查历史的审计/复盘场景但延迟高于 Redis。向量数据库如 Milvus把历史转 embedding把文本转成一串数字向量语义相近的向量距离也近做语义召回适合从长对话里捞相关片段但每次写入都要额外算一遍向量、成本高。Shop-Agent 选Redis 作为主存储对话历史按会话 ID 分片存储每条消息落库前截断到 4096 字符防撑爆 Redis整体 24 小时过期当前为固定值尚未提为配置项。这是近期上下文高频访问特征下的最优选。这三者并非严格互斥——Redis 自身也支持向量相似度搜索近期存储与语义召回可以落在同一套基础设施上。上面的决策图是按主导访问特征划分不是排他选型。这里的存储选型针对对话历史低延迟 可过期 窗口连续与 RAG 检索的知识文档选型是两件事——前者保聊到哪了后者保知识召回虽都可用向量库但问题不同勿混为一谈。跨节点上下文同步选型定了同步要解决多节点看到同一份。Redis 本身是中心节点所有节点读写同一份天然规避了内存副本漂移。但仍有两点必须处理写入版本/时序并发写同一对话如用户连发两条需靠 Redis 原子操作或单写者模型避免后写覆盖先写。增量更新 vs 全量覆盖只追加新消息而非每次重写整个历史减少跨节点带宽与冲突面。落地上用一次流水线里的两个原子操作尾部追加新消息 头部裁剪只保留最近 N 条而非全量覆盖。事件驱动演进方向上下文变更可经发布/订阅广播触发压缩、摘要等下游动作当前 Shop-Agent 主要靠共享存储 取用时裁剪保证一致事件驱动留作扩展。上下文路由把请求打到有状态的节点选型定了、同步也兜底了还剩第三个问题请求到底打给哪台节点。如果状态在共享 Redis其实任意节点都能接——这是 Shop-Agent 的做法靠外部存储解耦不需要粘滞会话sticky session。负载均衡可用任意无状态策略如轮询因为节点间无状态差异。但代价是每次请求都要从 Redis 拉历史。拉取时再做一次窗口裁剪prompt 构建阶段从 Redis 取历史按配置的最大历史轮数保留单条按可配置上限截断单条长度、默认值等具体窗口策略见《上下文压缩与窗口管理》。这把无限历史压成窗口内的有效上下文既控 token 又保业务连贯。三个问题各自的答案已经清楚把它们拼到一张图上看整体形态。实战Shop-Agent 的对话历史存储架构共享存储层无状态节点集群写入增量追加写入增量追加读回裁剪 按配置截断读回裁剪 按配置截断用户请求负载均衡无状态策略 · 任意节点节点 A取历史 推理节点 B取历史 推理Redis按会话 ID 分片的历史列表要点状态外置到 Redis节点无状态可任意接管每条消息落库前截断 4096 字符、整体 24 小时当前为固定值尚未提为配置项过期取用时再按轮数 单条可配置上限裁剪进窗口。核心要点存储选型不是排他三选一Redis 自身也支持向量检索近期存储与语义召回可共用一套设施决策图按主导访问特征划分。上下文不能绑进程内存否则多节点部署必失忆必须外置为共享存储。共享 Redis 让任意节点可接管免去 sticky session但每次需拉历史并裁剪窗口。Shop-Agent按会话 ID 分片、单条截断 4096 字、24 小时固定过期取用时再限轮数 单条按可配置上限裁剪写入用增量追加而非全量覆盖。路由与同步解耦后上下文一致性问题退化为Redis 可用 裁剪策略正确。