和你根本当 AI 应用开始“记住事情”，架构需要变化什么？
最近和几个做 AI 应用的朋友聊技术方案，聊来聊去都会撞上同一个话题：应用开始有记忆了。不是那种会话级的临时缓存，而是真正的、跨越多轮对话、跨越多天的记忆。这个需求一出现，原本跑得好好的架构就开始别扭。有的团队选择硬塞进 Redis，有的把记忆全量丢给向量库，有的直接在业务代码里维护一个全局变量——各有各的临时方案，但没人觉得踏实。
我自己的体会是，当 AI 应用从“无状态调用大模型接口”进化到“有状态地使用记忆”，架构层面的改动不是加个缓存那么简单。这背后涉及数据流方向、服务拆分逻辑、检索策略、甚至容错机制的整套调整。今天把这几个月折腾出来的经验整理一下，重点聊聊当 AI 应用开始“记住事情”，我们的架构到底要变化什么、为什么必须这么变，以及落地时会踩到哪些坑。
1. 先说清楚：“记忆”在技术层面到底指什么
聊架构之前，得先把概念对齐。很多人一听到“AI 应用有记忆”，脑子里浮现的还是人脑那样模糊的“记得以前聊过什么”。但从工程实现角度看，记忆是一个非常具体的、由不同存储和检索策略组合出来的能力。若这部分定义含糊，后面讨论架构必然一团乱。
1.1 三种记忆类型，背后是三种截然不同的技术需求
我在实际项目里会把 AI 应用的记忆拆成三类，类别不同，对架构的要求也完全不同。
第一类是短期会话记忆，指当前会话内、围绕本次任务产生的上下文信息。本质上就是 Prompt 里拼的那一大段历史消息。实现方式很直观，把聊天记录按时间顺序存下来，调用模型时按窗口截取最近 N 轮。以前很多应用直接存 Redis，设置一个过期时间，简单粗暴。但随着上下文窗口扩大、单轮携带的信息量暴涨，Redis 里的大 value 读写压力会很尴尬，而且这里还涉及 token 成本控制，不是单纯存储问题。
第二类是长期事实记忆，指跨会话保存的用户偏好、个人信息、项目背景等。比如用户上次提到“我儿子今年上小学三年级”，过了两周再次使用应用时，AI 应该还记得这个信息。实现上通常是两条线并行：一条是结构化数据，比如用户画像表、标签表，适合精确查询和规则过滤；另一条是向量化存储，把语义信息 embedding 后存进向量库，靠相似度检索命中。很多团队只做第二条线，结果项目一复杂就发现纯向量检索不够准，还得退回结构化存储做约束。
第三类是工作记忆，指 Agent 在执行多步骤任务时临时产生的、需要在多个工具调用之间传递的状态。比如 Agent 先查天气接口，再根据天气结果安排行程，这个“天气结果”就是工作记忆。这部分通常不需要持久化，但随着任务链拉长、并行分支增多，工作记忆的管理直接在代码里维护会导致状态散布在多个函数间，很难追踪。
1.2 为什么“有记忆”会让架构从舒适区里走出来
传统 Web 架构和微服务架构的核心假设是无状态。服务实例可以随意扩缩容、重启、负载均衡，因为每个请求都自带完整上下文——要么从请求体里拿参数，要么从数据库里查数据，服务本身不保存任何业务状态。这个假设让整个分布式体系变得简单可靠：任何节点挂了，换一台接着跑，数据不丢，状态不坏。
但 AI 应用一旦引入记忆，这个假设就被打破了。记忆天然是状态，而且是有依赖关系的状态。上一次对话的内容会影响这一次的回复，用户三天前的偏好会影响今天的推荐。若架构不主动设计状态的管理方式，就会出现：请求被负载均衡转发到不同实例后，实例 A 记得的东西实例 B 不知道，AI 表现像失忆了一样，体验断崖式下降。
一句话总结：记忆的引入，让 AI 应用从“无状态计算”被迫走向“有状态服务”。这个转变正是架构必须变化的根本原因。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 记忆对传统架构的三大冲击点
既然核心矛盾是有状态化了，那就要看传统架构具体在哪些环节承压。我梳理下来，冲击集中在服务层、数据层、以及调用链三个位置，每个位置都有典型症状。
2.1 服务层：无状态设计的墙开始处处透风
先看服务层。经典的微服务架构里，业务服务被设计成无状态，方便横向扩展。用户状态放 Session 中心或者 Token 里，订单状态放订单服务里，各司其职，互不干扰。
当 AI 应用开始有记忆，最直接的方案是给服务加一个“记忆中间件”，比如集成 Redis 或向量库。听起来简单，但实际改造时就会碰到问题：AI 应用的记忆不只是数据存取，还涉及记忆的写入时机、更新策略、版本管理。比如用户说了一句“我不喜欢吃辣”，这个信息什么时候写入长期记忆？是每轮对话都写入，还是等用户重复确认后才写入？写入时是追加一条新的，还是覆盖旧的？一旦需要动态决策，服务就不再是纯 IO 逻辑了，它变成了有决策逻辑的状态机。那些坚持无状态设计的服务层，在这里会非常别扭。
更麻烦的是，Agent 场景下的记忆经常不是单个服务内部状态，而是跨越多个服务的数据。比如一个旅游规划 Agent，需要同时读取用户偏好服务里的口味数据、行程服务里的历史