结论先说：日志不是记忆，能改变下次行为才算
智能体的长期记忆不是「把历史存下来」，而是把 trace 里的教训提炼成下次运行时能被检索、并且真能改变行为的结构化上下文。判断标准只有一条：这条信息在下次运行时能被取回，并让智能体做出不同的动作——做不到，它就只是一段日志。
这是很多人做记忆系统失败的根因：花了大力气做向量库，存了一堆对话原文，结果智能体行为毫无变化。
先分清短期与长期
| 类型 | 存什么 | 作用域 | 生命周期 |
|---|---|---|---|
| 短期（工作）记忆 | 当前线程、最近消息、工具结果、检索到的文档、中间产物 | 单次运行内 | 任务结束即弃 |
| 长期记忆 | 事实、偏好、示例、工作流、策略、指令、技能 | 跨运行 | 长期留存并可更新 |
两者的关系是读写循环：运行时从长期记忆读取相关上下文注入工作记忆；运行结束后，从本次 trace 里提炼信号回写长期记忆。少了任何一半，记忆系统都不成立。
长期记忆再拆三层
- 语义记忆——它知道什么：事实、用户偏好、领域常识。
- 情景记忆——它经历过什么：历史交互、具体示例、动作与结果。
- 程序记忆——它该怎么做事：指令、工作流、策略、技能、工具使用规则。
实践中收益最大的是程序记忆。当智能体反复把格式写错、工具调用顺序搞反、委派给错误的子智能体、或者无视语气要求时，问题几乎总是程序性的：规则写得不够明确、步骤顺序不对、或者这条行为该由某个专门的技能来负责。
一个很实用的判断法：出现重复错误时，先问「这是缺知识还是缺规则」。缺知识补语义记忆（加事实）；缺规则改程序记忆（改指令或改技能）。把规则问题当成知识问题去塞更多文档，是常见的无效努力。
记忆闭环：三步跑通
- 采集 trace：完整记录用户输入、模型调用、工具输入输出、检索内容、路由决策、延迟、错误与用户反馈。智能体和传统软件最大的区别是：你不看轨迹就不知道它到底做了什么。
- 分析 trace：找信号——显式反馈、评估失败、以及反复出现的模式（同样的错误输出、同样的非法工具调用、同样的路由失误、同样被忽略的指令）。
- 回写记忆：把诊断结果变成下次可用的上下文。既可能是修正（澄清一条指令、改一条路由规则），也可能是记住有用的东西（用户偏好、成功示例、可复用模式）。
诊断最容易出错的一步
分析这一步的难点在于：同一个症状可能对应完全不同的修复方式。智能体无视语气规则，可能是因为规则太含糊、放错了位置、没被相关技能加载、或者被另一条指令抵消了。四种原因的修法完全不同。
所以回写之前必须先定位到具体原因，而不是看到症状就直接改提示词。改错了地方，下一次还会再犯。
落地时的四个提醒
1. 不要什么都存
trace 里绝大部分内容应该留作历史，只有少数含信号的片段值得提炼成记忆。全量写入会让检索质量迅速劣化。
2. 给记忆加作用域与时效
用户偏好会变，业务规则会过期。每条记忆都要能回答：属于哪个用户/哪个场景、什么时候写入、什么时候该失效。
3. 程序记忆要可执行
与其写「回答要简洁」，不如写「回答控制在三句话以内，不使用项目符号」。前者无法验证，后者可以。
4. 保留可回滚
自动回写意味着系统能自己改自己的行为。必须有版本记录与回滚手段，否则一次错误提炼会污染后续所有运行。
记忆系统的验收清单
- 能否举出一条记忆，说明它在哪次运行中改变了智能体的行为？
- 重复出现的错误类别，是否在统计上确实减少了？
- 检索回来的记忆，有没有过期或自相矛盾的条目？
- 记忆写入有没有版本记录与回滚手段？
- 用户偏好变更时，旧条目会不会被覆盖或标记失效？
存下来的对话历史算长期记忆吗？
不算。历史只是证据，只有当其中的教训被提炼成下次可检索、且能改变行为的上下文时，它才成为记忆。
语义、情景、程序三层都要做吗？
不必一次全做。优先做程序记忆——绝大多数显性行为改进来自规则与技能的调整，投入产出比最高。
记忆会不会越存越占上下文？
会。所以要控制写入粒度并做检索裁剪，只把与当前任务相关的条目注入，而不是全量塞进提示。
怎么判断记忆系统真的有效？
看具体错误类别的复发率有没有下降，而不是看「记忆条数」有多少。条数增长不等于行为变好。
评论 (0)