Claude Code 源码拆解 harness 设计 - 记忆系统
- 常见做法
- 用一个文件，持久化保存 用户偏好、项目规范、历史决策、代码架构、文件路径
- 问题：文件越来越大，token消耗越来越高，目标可能产生偏移
- Claude Code 记忆系统工程量最大的部分 不是 怎么存 也不是 怎么取 而是 该不该存
- 应该存储的记忆
- 用户记忆
- 角色、技术背景、工作习惯、知识水平
- 面对不同的角色回复应该是不同的方向
- 如果是资深工程师，不需要解释基础概念，直接用技术术语，直奔主题，而初学者应该铺垫技术背景，解释专业术语，循序渐进的引导
- 源码约束
- 不要记录对用户的负面评价、不要记录与工作无关的个人信息，目的是怎么更好的帮助而不是给人画像
- 反馈记忆
- 用户纠正过什么，肯定过什么
- 源码约束
- 每条反馈记忆必须包含三个部分：规则是什么、为什么有这个规则、什么时候改应用这个规则（记录原因是为了让Agent在新的场景下做判断，而不是无脑遵守）
- 例如
- 规则：不要 mock(模拟) 数据库
- 原因：mock和生产环境行为不一致导致出现问题
- 什么时候应应用：集成测试不应该 mock
- 如果不记录原因，模型只会机械式的遵守不执行mock，但是如果它指导原因是 mock 和生产环境不一致导致迁移失败 它就能判断只是集成测试不能使用 mock 但 纯逻辑测试没问题
- 纠正+肯定都要记
- 源码注释：如果只记录 用户说不要做什么的约束 Agent会变得越来越保守，它只知道什么事错的，而不知道什么是对的，长时间累计Agent会回避一切不确定的做法，影响性能
- 但是 肯定信号往往比 纠正信号更难捕捉，需要让Agent更仔细
- 例如用户说 用大PR合并，不要拆开，则记忆 用户倾向合并提交，下次重构优先考虑 合并而并非拆分成小PR
- 反馈记忆要区分个人偏好和项目规范，存储在不同的目录
- 个人偏好
- 例如：不要在回复末尾加总结
- 范围：只对这个用户有效
- 存在私有目录
- 项目规范
- 例如：集成测试必须用真实数据库
- 范围：对所有用户有效
- 存在项目共享目录
- 项目记忆
- 引用记忆
- 不应该存储的记忆
- 代码模式/架构/路径
- 版本管理历史
- 调试方案/修复方案
- 配置文件
- 临时性任务细节