Coding Agent 的三层 Memory 为什么这样设计？

核心回答

以Claude Code为例，若“三层”指用户级、项目级、目录级指令，它的设计目的就是让通用偏好可复用、团队约定可共享、局部规则按需出现，从而减少重复和无关上下文。

不过“三层”是一种作用域归纳，不能说Claude Code官方只有固定三层记忆。当前文档还区分组织或本地项目指令，以及自动记忆；它们也不等同于“短期、中期、长期”这组按时间或用途划分的概念。先说清分类维度，后面的实现才不会混在一起。

三个作用域分别解决什么

• 用户级保存跨项目稳定偏好，比如语言习惯、常用工具和个人协作方式。不应该在这里写某个项目专用的接口地址与业务规则，否则容易污染其他仓库。
• 项目级保存团队共享的构建方式、测试入口、重要约束和特殊约定。随项目维护，让不同会话和成员获得一致背景；代码中容易查出的全部目录细节没必要重复抄一遍。
• 目录级描述局部模块差异。例如同仓库的后端与前端使用不同测试命令，进入对应目录才读取相关规则，避免每次都加载整个仓库的说明。

Claude Code当前文档说明，工作目录及上级目录的相关指令在启动时加载，子目录指令在访问对应文件时按需加载。这种“广范围常驻、窄范围按需”的组织兼顾连续性和上下文成本。指令是模型读取的上下文，不是天然强制执行的配置；互相冲突时不能想当然地依赖“离文件近就必然覆盖”，应消除冲突并检查实际加载范围。

自动记忆与这些指令有什么关系

人工维护的项目指令表达约定；自动记忆保存模型从纠正、偏好和工作经验中提炼的笔记。当前Claude Code会在项目记忆目录中维护索引和专题文件，索引有限量载入，细节按需读取。同一Git仓库的worktree会共享项目自动记忆，这与每个会话的临时消息历史又不同。

例如团队规则要求“运行该模块的测试”，用户长期偏好是“简单改动保持流程轻量”，本轮任务状态则是“已修改某文件、还没验证”。前两者适合各自范围的持续上下文，最后一个主要属于会话或任务状态；不能把“上次测试失败”永久变成这个项目永远不能运行的规则。

为什么这样设计，怎样避免越记越乱

主要收益是复用、隔离、按需加载和可维护。代价是检索遗漏、规则冲突及陈旧笔记，所以记忆应保留适用范围、来源和更新时间，允许查看、修正与删除；当前代码和明确的新要求仍要核对。

如果追问“做梦机制”，工程上可以用它形容后台整理经历、合并重复、淘汰过期内容，但具体产品是否实现、何时触发、是否自动写入，需要依据对应版本确认；不能仅凭这个比喻推断Claude Code会离线训练参数或保证每次自动优化。这里的亮点是把记忆的内容、作用域和加载时机分开设计。

对应教程

参考资料