结论
该存（关于人和上下文）
- 用户是谁（用户记忆）
- 纠正和肯定过什么（反馈记忆）
- 项目动机和时间线（项目记忆）
- 外部资源位置（引用记忆）
不该存（关于代码和状态）
- 通过代码能轻易得出的结论
- 通过工具能查询到的信息
- 配置文件中说明过的
- 临时状态、信息
记忆是代码的补集，代码能回答的问题不要让记忆系统来回答
- 常见做法
- 用一个文件，持久化保存 用户偏好、项目规范、历史决策、代码架构、文件路径
- 问题：文件越来越大，token消耗越来越高，目标可能产生偏移
- Claude Code 记忆系统工程量最大的部分 不是 怎么存 也不是 怎么取 而是 该不该存
- 应该存储的记忆
- 用户记忆
- 角色、技术背景、工作习惯、知识水平
- 面对不同的角色回复应该是不同的方向
- 如果是资深工程师，不需要解释基础概念，直接用技术术语，直奔主题，而初学者应该铺垫技术背景，解释专业术语，循序渐进的引导
- 源码约束
- 不要记录对用户的负面评价、不要记录与工作无关的个人信息，目的是怎么更好的帮助而不是给人画像
- 反馈记忆
- 用户纠正过什么，肯定过什么
- 源码约束
- 每条反馈记忆必须包含三个部分：规则是什么、为什么有这个规则、什么时候改应用这个规则（记录原因是为了让Agent在新的场景下做判断，而不是无脑遵守）
- 例如
- 规则：不要 mock(模拟) 数据库
- 原因：mock和生产环境行为不一致导致出现问题
- 什么时候应应用：集成测试不应该 mock
- 如果不记录原因，模型只会机械式的遵守不执行mock，但是如果它指导原因是 mock 和生产环境不一致导致迁移失败 它就能判断只是集成测试不能使用 mock 但 纯逻辑测试没问题
- 纠正+肯定都要记
- 源码注释：如果只记录 用户说不要做什么的约束 Agent会变得越来越保守，它只知道什么事错的，而不知道什么是对的，长时间累计Agent会回避一切不确定的做法，影响性能
- 但是 肯定信号往往比 纠正信号更难捕捉，需要让Agent更仔细
- 例如用户说 用大PR合并，不要拆开，则记忆 用户倾向合并提交，下次重构优先考虑 合并而并非拆分成小PR
- 反馈记忆要区分个人偏好和项目规范，存储在不同的目录
- 个人偏好
- 例如：不要在回复末尾加总结
- 范围：只对这个用户有效
- 存在私有目录
- 项目规范
- 例如：集成测试必须用真实数据库
- 范围：对所有用户有效
- 存在项目共享目录
- 项目记忆
- 当前项目中正在发生什么、谁在做什么、截止日期是什么、原因是什么
- 所有相对日期必须转换为绝对日期
- 因为以及是跨会话的如果存一个相对日期例如 周四，那么在其他会话中则无法区分是哪个周四
- agent做决策的时候应该参考项目记忆优先考虑合规性而不是技术
- 项目记忆衰减的很快，一周前的项目记忆就可能已经过时，所以项目记忆应该包含为什么这样即使记忆过时了也能让agent推导出合理性
- 引用记忆
- 外部资源位置、问题位置、设计文档位置等
- 不应该存储的记忆
- 代码模式/架构/路径
- 问题
- 存进记忆浪费空间，每次对话都要加载可以推导出来的信息
- 需要维护，一旦代码修改记忆没更新则会导致Agent使用过时的信息做出决策
- 这些信息可以从代码中推导出来，agent可以随时通过读代码和搜索获取当前的项目结构
- 原则：如果一个信息可以从当前项目状态推导出来，就不要存进记忆，记忆只存那些 无法推导或者推导复杂 的东西
- 版本管理历史
- 让Agent直接用版本工具查询实时信息即可，不需要记忆来存一份可能过时的信息
- 调试方案/修复方案
- 大部分情况中，修复已经在代码中了，存 “怎么修的没有意义” 因为代码本身就是最好的参考
- 配置文件
- 如果配置文件中已经定了编码规范，记忆系统不需要再存一份，重复存储会浪费空间还可能导致信息冲突
- 临时性任务细节
- 这些都是短期的记忆，属于当前会话的上下文，不该进入长期记忆
- 源码中的规则：即使用户明确要求记住但是如果属于上面五类则不记
- 正确示例
- 用户：记住这周的PR列表
- Agent：那些pr中有那些需要注意的
- 判断：活动日志 则不存，提炼出的洞察信息 则存