为什么无状态 LLM 需要外挂记忆系统？
大语言模型本身是无状态的（Stateless），它无法在多次独立的交互之间自动“记住”用户的偏好、历史项目的约定或先前的纠错结论。
三级记忆系统架构模型
- 工作记忆（Working Memory）： 存在于当前上下文窗口中，包含当前执行步骤的 Scratchpad、未完成的 Checklist 与临时变量。
- 情景记忆（Episodic Memory）： 记录智能体“在什么时间、经历了什么事件、取得了什么结果”。适合通过向量数据库按相似事件进行语义检索与案例复用（Few-shot prompting）。
- 语义/程序记忆（Semantic & Procedural Memory）： 抽象出的规则、规范与技能。例如“当遇到 MySQL 死锁时，优先检查事物隔离级别”。这种记忆通常持久化在知识图谱或规范 Rules 文件中。
落地示例：一次任务的读写路径
记忆系统最容易忽略的是"什么时候写"。可落地的读写顺序如下：任务开始时，从语义记忆取该仓库的规则文件，按相似度从情景记忆取回若干历史案例，两者拼进系统提示；执行过程中，工作记忆只保留当前步骤的中间结论，一旦某步完成就压缩成一句话摘要；任务结束时，只在满足三个条件时才写回长期记忆——结论可复用、不依赖一次性上下文、且经过验证（测试通过或人工确认）。
写回这一步要设阈值。把每次试错都存进向量库，检索时会被大量低质量片段污染，通常按"同类事件累计出现多次才升格为规则"的方式做蒸馏，宁缺毋滥。
三层存储的选型对比
| 维度 | 工作记忆 | 情景记忆 | 语义/程序记忆 |
|---|---|---|---|
| 生命周期 | 单次任务 | 会话到跨会话 | 长期，随仓库演进 |
| 存取方式 | 直接拼入上下文 | 向量相似度召回 | 规则文件精确加载加图谱查询 |
| 容量策略 | 裁剪与摘要 | Top-K 召回 | 人工或半自动审核入库 |
| 典型故障 | 超限截断 | 召回噪声 | 规则过期冲突 |
| 成本特征 | Token 成本最高 | 检索与嵌入成本 | 维护人力成本为主 |
三层之间最有效的边界是"是否可验证"：能被测试或复现确认的结论才允许下沉，否则留在工作记忆里随任务一起消失。
验证方法
给记忆系统做一次回归：挑十个人工已解决过的历史问题，清空会话后重新提问，统计有多少比例能在首轮就复现出正确做法，这个数字是记忆召回质量的直接指标。再加两项检查：一是删除某条规则后任务是否仍能通过，用来识别从未被真正使用的死规则；二是把两条互相冲突的规则同时注入，观察模型偏向哪一条，从而判断优先级是否需要显式声明。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| 记了规则但行为没变 | 规则未命中注入位置或权重过低 | 前置到系统提示并加显式约束句 |
| 检索回一堆无关案例 | 嵌入粒度按整段会话切块 | 改为按"问题—结论"对切块 |
| 上下文频繁爆满 | 工作记忆只追加不压缩 | 每步完成即摘要替换原文 |
| 记忆与当前代码矛盾 | 缺少失效机制 | 绑定文件路径并在变更后触发复核 |
| 同类错误反复出现 | 结论未写回长期记忆 | 任务收尾强制走写回判定 |
小结
记忆体系是否工作，不看存了多少条，而看两个可量化现象：重复性问题的首次解决轮次是否随着任务数增加而下降；随机抽样十条记忆，是否至少有八成能在当前代码库中找到对应事实。前者衡量收益，后者衡量污染。裁剪与注入的配合可参考 上下文工程与 Token 预算管理：大模型长上下文的架构裁剪与注意力保真。