杭州网站建设网站建设 企业

作者:WiseAgent小而美智能体架构师

在 Agent 开发的早期，我也犯过很多“贪大求全”的错误。那时候，看到向量数据库（Vector DB）就像看到了救世主，恨不得把用户说的每一句话、系统的每一次日志都塞进去，美其名曰“全息记忆”。结果呢？系统上线后，不仅 Token 消耗如流水，更致命的是“信噪比”极低。

当上下文窗口被无关紧要的废话填满时，LLM（大语言模型）的推理能力会显著下降。这就是学术界常说的“Lost in the Middle”现象——给的越多，它越糊涂。而且，检索回来的内容经常似是而非，导致严重的幻觉。

经过几个项目的填坑和重构，我现在的架构设计原则非常简单：记忆不是存储，而是为了更精准的计算。在我的工程实践中，我砍掉了那些花里胡哨的“无限记忆”，只保留了这三类最核心、最可控的记忆形态。

第一类：短期记忆（Session Context）—— 它是“缓存”，不是“日志”

这是最基础的，当前对话窗口内的历史记录。很多新手直接把List<Message>往 Prompt 里塞，直到 Token 溢出。

我的工程判断：短期记忆的核心矛盾是“上下文长度”与“注意力分散”之间的博弈。你不能指望模型读完 50 轮对话还能精准记得第 3 轮的一个细节。

我现在怎么做：

1. 滑动窗口（Sliding Window）是底线，但不够。我通常只保留最近的 N 轮（比如 10 轮）原始对话。

2. 关键信息“快照化”。我不会依赖 LLM 去翻历史记录找“用户叫什么名字”或“刚才选了哪个套餐”。

   1. 在每一轮对话结束时，我会用一个轻量级模型（甚至就是写死的正则或 NLP 工具）提取关键实体（Slot），更新到一个结构化的 State 对象中。

   2. 下一轮对话时，Prompt 里放的不是冗长的聊天记录，而是这个精简的 State JSON。

3. 定期总结（Summarization）。如果对话过长，触发一个后台任务，把前 20 轮对话压缩成一段 100 字的摘要，替换掉原始 Log。

别把 LLM 当成翻旧账的会计，它记不住。把非结构化的对话实时“坍缩”成结构化的状态，才是正解。

第二类：长期记忆（User Profile）—— 它是“数据库”，拒绝“向量化”

这是很多 Agent 系统最容易翻车的地方。很多人喜欢把用户的个人信息、偏好、历史订单都变成向量存进 Chroma 或 Milvus。这是工程上的大忌。为什么？因为向量检索是概率性的（基于相似度），而业务数据要求是确定性的。 当用户问“我的手机号是多少”时，你通过向量检索可能会找出一个“相似”的号码（比如前一位用户的），这在生产环境中是绝对的事故。

我的工程判断：对于事实性、属性类的数据，SQL和KV存储永远比向量数据库可靠。

我现在怎么做：

1. 结构化画像。用户的 ID、权限等级、会员状态、硬性偏好（如“只看五星级酒店”），这些必须存在 MySQL 或 Redis 里。

2. 显式注入。在构建 Prompt 时，通过代码逻辑直接查询数据库，将这些字段以 Key-Value 的形式硬编码进 System Prompt。

   1. Bad Case:让 LLM 去向量库里搜“用户的会员等级”。

   2. Good Case:代码查库 ->user_level: "VIP"-> 拼接到 Prompt。

3. 动态更新。这类记忆的更新必须由确定的业务逻辑触发（比如调用了update_profile工具），绝对不能由 LLM 自己“感觉”应该更新了就去改库。

事实不容模糊。凡是能用 SQL 查出来的，绝不用 RAG。

第三类：程序性记忆（SOP & Knowledge）—— 它是“外挂”，不是“大脑”

这类记忆指的是 Agent 执行任务所需的知识库（RAG）和标准作业程序（SOP）。早期的做法是把所有公司文档切片扔进库里。结果发现，Agent 经常检索到过期的文档，或者把 A 产品的操作手册用在 B 产品上。

我的工程判断：RAG 的难点不在于 Retrieve（检索），而在于治理。垃圾进，垃圾出。

我现在怎么做：

1. 知识分层。我不再维护一个大一统的向量库，而是按场景切分。

   1. 处理“退款”意图时，只挂载“售后政策”的知识库。

   2. 处理“技术支持”意图时，只挂载“API 文档”的知识库。

   3. 这需要在中控层（Controller）做精准的路由。

2. SOP代码化。很多团队试图把复杂的业务流程写在 Prompt 里让 LLM 记下来。这是不可靠的。

   1. 我会把 SOP（比如：先验资，再下单，后发货）写成代码逻辑（Code）或工作流（Workflow）。

   2. Agent 的“记忆”里只需要知道当前处于 SOP 的哪一步（Step 2），以及下一步该调哪个工具。流程的跳转逻辑，由代码约束，不由模型记忆。

只有经过清洗和结构化治理的知识，才配成为 Agent 的记忆。流程逻辑要固化在代码里，别指望模型每次都能“背诵”对。

结语：做减法，才是高级的工程化

在 Agent 系统中，我们往往高估了模型的“理解力”，低估了记忆管理的“复杂度”。作为一个老工程师，我的建议是：不要追求让 Agent 记住所有事情。相反，你应该致力于设计一套机制，让 Agent在正确的时间，仅获取它解决当前问题所必须的最小量信息。

• 短期记忆要压缩，防止 Token 浪费和注意力涣散。

• 长期记忆要结构化，用 SQL 保障事实的准确性。

• 程序性记忆要代码化，用硬逻辑兜底业务流程。

只有把“记忆”关进工程的笼子里，Agent 才能在落地的道路上走得稳当。