作者:WiseAgent小而美智能体架构师
在 Agent 开发的早期，我也犯过很多“贪大求全”的错误。那时候，看到向量数据库（Vector DB）就像看到了救世主，恨不得把用户说的每一句话、系统的每一次日志都塞进去，美其名曰“全息记忆”。结果呢？系统上线后，不仅 Token 消耗如流水，更致命的是“信噪比”极低。
当上下文窗口被无关紧要的废话填满时，LLM（大语言模型）的推理能力会显著下降。这就是学术界常说的“Lost in the Middle”现象——给的越多，它越糊涂。而且，检索回来的内容经常似是而非，导致严重的幻觉。
经过几个项目的填坑和重构，我现在的架构设计原则非常简单：记忆不是存储，而是为了更精准的计算。在我的工程实践中，我砍掉了那些花里胡哨的“无限记忆”，只保留了这三类最核心、最可控的记忆形态。
第一类：短期记忆（Session Context）—— 它是“缓存”，不是“日志”
这是最基础的，当前对话窗口内的历史记录。很多新手直接把List<Message>往 Prompt 里塞，直到 Token 溢出。
我的工程判断：短期记忆的核心矛盾是“上下文长度”与“注意力分散”之间的博弈。你不能指望模型读完 50 轮对话还能精准记得第 3 轮的一个细节。
我现在怎么做：
滑动窗口（Sliding Window）是底线，但不够。我通常只保留最近的 N 轮（比如 10 轮）原始对话。
关键信息“快照化”。我不会依赖 LLM 去翻历史记录找“用户叫什么名字”或“刚才选了哪个套餐”。
在每一轮对话结束时，我会用一个轻量级模型（甚至就是写死的正则或 NLP 工具）提取关键实体（Slot），更新到一个结构化的 State 对象中。
下一轮对话时，Prompt 里放的不是冗长的聊天记录，而是这个精简的 State JSON。
定期总结（Summarization）。如果对话过长，触发一个后台任务，把前 20 轮对话压缩成一段 100 字的摘要，替换掉原始 Log。
别把 LLM 当成翻旧账的会计，它记不住。把非结构化的对话实时“坍缩”成结构化的状态，才是正解。
第二类：长期记忆（User Profile）—— 它是“数据库”，拒绝“向量化”
这是很多 Agent 系统最容易翻车的地方。很多人喜欢把用户的个人信息、偏好、历史订单都变成向量存进 Chroma 或 Milvus。这是工程上的大忌。为什么？因为向量检索是概率性的（基于相似度），而业务数据要求是确定性的。 当用户问“我的手机号是多少”时，你通过向量检索可能会找出一个“相似”的号码（比如前一位用户的），这在生产环境中是绝对的事故。
我的工程判断：对于事实性、属性类的数据，SQL和KV存储永远比向量数据库可靠。
我现在怎么做：
结构化画像。用户的 ID、权限等级、会员状态、硬性偏好（如“只看五星级酒店”），这些必须存在 MySQL 或 Redis 里。
显式注入。在构建 Prompt 时，通过代码逻辑直接查询数据库，将这些字段以 Key-Value 的形式硬编码进 System Prompt。
Bad Case:让 LLM 去向量库里搜“用户的会员等级”。
Good Case:代码查库 ->
user_level: "VIP"-> 拼接到 Prompt。
动态更新。这类记忆的更新必须由确定的业务逻辑触发（比如调用了
update_profile工具），绝对不能由 LLM 自己“感觉”应该更新了就去改库。
事实不容模糊。凡是能用 SQL 查出来的，绝不用 RAG。
第三类：程序性记忆（SOP & Knowledge）—— 它是“外挂”，不是“大脑”
这类记忆指的是 Agent 执行任务所需的知识库（RAG）和标准作业程序（SOP）。早期的做法是把所有公司文档切片扔进库里。结果发现，Agent 经常检索到过期的文档，或者把 A 产品的操作手册用在 B 产品上。
我的工程判断：RAG 的难点不在于 Retrieve（检索），而在于治理。垃圾进，垃圾出。
我现在怎么做：
知识分层。我不再维护一个大一统的向量库，而是按场景切分。
处理“退款”意图时，只挂载“售后政策”的知识库。
处理“技术支持”意图时，只挂载“API 文档”的知识库。
这需要在中控层（Controller）做精准的路由。
SOP代码化。很多团队试图把复杂的业务流程写在 Prompt 里让 LLM 记下来。这是不可靠的。
我会把 SOP（比如：先验资，再下单，后发货）写成代码逻辑（Code）或工作流（Workflow）。
Agent 的“记忆”里只需要知道当前处于 SOP 的哪一步（Step 2），以及下一步该调哪个工具。流程的跳转逻辑，由代码约束，不由模型记忆。
只有经过清洗和结构化治理的知识，才配成为 Agent 的记忆。流程逻辑要固化在代码里，别指望模型每次都能“背诵”对。
结语：做减法，才是高级的工程化
在 Agent 系统中，我们往往高估了模型的“理解力”，低估了记忆管理的“复杂度”。作为一个老工程师，我的建议是：不要追求让 Agent 记住所有事情。相反，你应该致力于设计一套机制，让 Agent在正确的时间，仅获取它解决当前问题所必须的最小量信息。
短期记忆要压缩，防止 Token 浪费和注意力涣散。
长期记忆要结构化，用 SQL 保障事实的准确性。
程序性记忆要代码化，用硬逻辑兜底业务流程。
只有把“记忆”关进工程的笼子里，Agent 才能在落地的道路上走得稳当。