X记录空间前言
很多 AI Chat 项目一开始都很简单：
messages.push(user)
messages.push(assistant)
然后：
全部发送给模型。
前几天运行很好。
但用户越来越多之后。
问题开始出现：
- 成本暴涨；
- 响应变慢；
- 模型开始遗忘；
- 多轮对话质量下降。
原因并不是模型不够强。
而是：
上下文系统设计得太简单。
事实上，
上下文系统决定了 AI 产品的上限。
一个成熟系统的结构
推荐：
Current Question
↓
Working Memory
↓
Session Summary
↓
Long-term Memory
↓
RAG
↓
System Prompt
↓
LLM
而不是：
全部历史消息
↓
LLM
Working Memory
负责：
最近几轮消息。
例如：
10～20 条。
特点：
- 高频访问；
- 更新快；
- Token 消耗高；
通常存储在：
Redis。
Session Summary
负责：
总结整个会话。
例如：
用户正在开发 AI Chat。
技术栈：
Node.js
Redis
Nginx。
长度：
500 token 左右。
随着对话不断更新。
始终保持简洁。
Long-term Memory
负责：
长期偏好。
例如：
喜欢 TypeScript。
使用 Vue3。
不使用 Redux。
这些信息不会每轮都发送。
只有相关时才召回。
为什么不能全部发送？
因为：
Token 成本是线性增长的。
而模型注意力是有限的。
100K token 的上下文。
并不意味着：
100K token 都能得到同等关注。
实际上：
大量无关内容会稀释重点。
Session Summary 如何生成？
推荐：
定期压缩。
例如：
每 20 轮。
自动生成摘要。
保留：
- 当前任务；
- 技术栈；
- 用户目标；
- 关键结论；
删除：
无关闲聊。
Long-term Memory 如何召回？
不要：
全部加载。
推荐：
Embedding 检索。
当前问题：
Vue3
只召回：
Vue3 相关偏好。
而不是全部用户信息。
Message Tree
不要简单数组。
推荐：
树结构。
支持：
- 编辑消息；
- 重新生成；
- 分支对话；
类似 ChatGPT。
这样上下文更加灵活。
成本优化
推荐：
Working Memory：
Redis。
Summary：
数据库。
Long-term Memory：
向量数据库。
形成：
三级记忆系统。
Token Budget
建议：
System Prompt：
1000 token
Memory：
1000 token
History：
3000 token
RAG：
2000 token
Current Question：
500 token
总预算：
控制在：
7000 token 左右。
不要无限增长。
推荐架构
User
↓
Gateway
↓
Redis
↓
Summary
↓
Vector Memory
↓
RAG
↓
Prompt Builder
↓
LLM
↓
Streaming
↓
Save Memory
这是很多成熟 AI 产品正在采用的方式。
总结
上下文系统，
本质上是在解决：
如何让模型在有限窗口内，
始终看到最重要的信息。
未来 AI 产品的核心竞争力，
不只是模型。
而是：
Memory Architecture。
谁的记忆系统设计得更合理，
谁就能得到更稳定、更低成本、更高质量的 AI。
