#AI Agent #记忆系统 #向量检索 #工程实践
大多数 Agent 跑不起来的原因不是模型不够强，而是没有记忆：每次对话都从空白开始，用户上轮说过的偏好、项目里已确认的决策、查过的资料，全部丢失。结果就是重复提问、重复犯同样的错、任务一长就前后矛盾。本文给出可直接落地的三层记忆架构，以及不需要重型基础设施的文件系统实现方案。
参考人类认知的分工，Agent 记忆拆成三层，每层解决一类问题，各自的读写频率和存储介质完全不同：
短期工作区就是当前会话的上下文窗口。它负责：当前任务的步骤衔接、上一条工具调用的输出、用户刚做的修正。这一层不需要持久化设计，交给 LLM 的上下文窗口即可，但要养成两个习惯：一是在关键节点把结论「落盘」到长期记忆，二是用显式的状态摘要压缩上下文，避免窗口被历史对话占满。
长期记忆存放跨会话稳定的事实：用户的称呼与语言偏好、项目的技术栈与目录结构、已经拍板的架构决策、常用命令的别名。这层的特征是「写入少、读取多、更新慢」，适合用结构化的纯文本或 JSON 文件存储，每条记录带时间戳和来源，方便回溯与修正。
任务工作记忆介于两者之间：它是某个正在进行的任务的进行时状态。典型内容是「已完成步骤列表」「待办清单」「遇到的坑」。它必须可回滚——任务中断后重启，Agent 读回这份状态就能从断点继续，而不是从头再来。落地形式是一个简单的任务清单文件，每完成一步就更新一次。
很多团队一上来就上向量数据库，其实 80% 的记忆需求用文件系统就能满足，而且可读、可审计、可手工修正。只有到了「需要按语义模糊召回」的阶段，才值得引入向量检索。
当长期记忆超过几百条、且「精确匹配文件名」已经找不到需要的内容时，再考虑向量化：给 memories/refs/ 里的条目生成嵌入，检索时做 Top-K 召回再交给模型重排。务必备份原始文本文件——向量库只是索引，文本才是真相。日常单 Agent 或小团队场景，文件系统 + grep 级检索通常已经够用。
记忆不是模型参数的附属品，而是工程产物。先分层、后落地：短期靠上下文，长期靠文本文件，跨任务靠工作记忆文件；向量检索只在语义召回成为瓶颈时引入。按这个顺序做，最小的改动就能让 Agent 从「每次重新认识你」进化到「记得住、接得上、能复盘」。