双层记忆架构：让 AI Agent 摆脱完整对话历史

将临时对话上下文与持久化用户偏好解耦，通过混合缓存和 KV 存储实现。

大多数开发者教程教你在构建 AI Agent 时，会把每条用户消息追加到一个本地 Python 列表里。在 Jupyter notebook 里这么写没问题，但一到生产后端就会立刻崩溃。

生产环境中的瓶颈

这种朴素做法把聊天历史直接存在进程内存里，或者在每次对话回合时把整个对话日志全部塞回 LLM 上下文窗口。

# 反模式：无界内存增长 & 易失性存储
chat_history.append({"role": "user", "content": prompt})
response = openai.chat.completions.create(model="gpt-4o", messages=chat_history)

这种模式会在三个方面出问题：

生命周期不稳定：容器重启或缩容时，用户的整个交互状态就消失了。

上下文膨胀与成本：发送 30 轮原始对话会拉高延迟、烧穿 Token 预算，却并没有增加有效信号。

关键事实丢失：当消息列表不可避免地触及上下文上限时，简单的截断会丢弃早期消息——抹掉dietary preferences、用户 ID 或系统约束这类核心细节。

系统架构与解决方案

要构建生产级的 Agent，必须将对话上下文（短期）与持久化的用户偏好（长期）解耦。

不要维护一个庞大的原始对话数组，而是实现两层记忆架构：

Tier 1（L1 - 短期会话缓存）：一个高速的内存存储（或 Redis），追踪当前会话中近期的对话回合和即时状态。

Tier 2（L2 - 长期持久化 KV 存储）：一个持久的键值存储（ DynamoDB、Postgres JSONB 或 S3），存放关于用户的、结构化的、长期有效的事实。

                  +-----------------------+
                  |      User Request     |
                  +-----------+-----------+
                              |
                              v
                  +-----------------------+
                  |    Agent Controller   |
                  +-----+-----------+-----+
                        |           |
       1. Read Session  |           | 2. Read Preferences
                        v           v
             +------------+       +-------------+
             |  L1 Cache  |       | L2 KV Store |
             |  (Redis)   |       |  (Database) |
             +------------+       +-------------+
                        |           |
                        +-----+-----+
                              |
                              v
                  +-----------------------+
                  | Merged Prompt Context |
                  +-----------+-----------+
                              |
                              v
                  +-----------------------+
                  |     LLM Provider      |
                  +-----------------------+

当请求到达时，Agent 从 Tier 2 加载结构化事实，与来自 Tier 1 的近期上下文合并，然后向 LLM 传递一个经过优化的上下文。