Agent 记忆系统落地：先分清三类记忆，再谈向量库

给 Agent 加记忆，很多团队的第一反应是"上向量库"。但实际落地后常见的问题是：检索回来的内容要么全是历史对话的复读，要么根本对不上当前任务。问题不在向量库，而在没分清 Agent 到底需要哪类记忆。

第一类：工作记忆。即当前任务的上下文窗口内容。它最容易被滥用——把所有历史都塞进上下文，Token 成本线性上涨，且关键信息被稀释。工程上的做法是显式管理：任务开始时注入任务描述与约束，过程中只保留最近 N 轮对话加结构化的中间结论，结束后把结论沉淀、把过程丢弃。

第二类：情景记忆。即跨会话的交互历史：用户做过什么、项目里踩过什么坑。这类记忆适合向量检索，但要控制写入粒度。整段对话直接向量化，检索时噪声极大；应该由模型在任务结束时抽取"结论性事实"再入库，并附带时间、项目、可信度等元数据，检索时按元数据过滤再加向量排序。

第三类：语义记忆。即稳定的领域知识与规则，例如团队的编码规范、系统的接口约束。这类内容变化频率低、命中率高，用普通配置文件或数据库存就够了，根本不需要向量检索。把它们硬塞进向量库，反而引入了不必要的召回不确定性。

落地时还有两个容易忽略的点。一是记忆的过期与冲突处理：两条记忆互相矛盾时，谁赢？没有版本和时间戳的记忆系统，很快就会变成垃圾场。二是记忆的隔离边界：多租户场景下，用户 A 的记忆绝不能出现在用户 B 的检索结果里，这是安全问题而不仅是质量问题。

实践建议：先用最简单的结构（数据库加过滤条件）满足语义记忆，再用小粒度向量化满足情景记忆，工作记忆则完全靠上下文工程管理。向量库只是情景记忆的一种实现，不是记忆系统的全部。把三类记忆分清楚，Agent 的回答质量和成本才会同时改善。

举个例子说明三类记忆的差别。用户上周让 Agent 排查过一次数据库连接池耗尽的故障。这周再问"为什么服务总在凌晨超时"，Agent 应该先从情景记忆里找到上周的结论（连接池配置不足、凌晨有定时任务并发），再把结论注入当前上下文，而不是把上周几十轮对话原样塞进窗口。如果团队还有一条规范"所有连接池必须配置慢查询日志"，那属于语义记忆，应该每次任务都无条件携带，根本不该依赖检索命中。

很多系统的失败案例，本质是把这三类记忆混在一个检索池里：规范被当成普通历史召回，有时带有时不带；故障结论被淹没在对话碎片里；工作记忆则无节制膨胀。先分类、再选存储、最后设计读写时机，这套顺序不能反。