Coding Agent 个人记忆方案

基于共享 memory backend 加文件化指令层，为 Codex、Copilot、OpenCode 一类 coding agent 落地一套优雅、可演化、可审计的个人记忆方案。

#tech / ai #type / howto #status / growing #resource / mem0 #resource / mcp

[!info] related notes

Coding Agent 个人记忆方案

目标

这篇 howto 只回答一个问题：

现在如果你想给自己常用的 coding agent 做一套优雅的个人记忆方案，应该怎么落地。

这里的“优雅”指的是：

  • 跨工具可复用
  • 个人偏好和项目事实分层
  • 显式规则和可检索事实分层
  • 本地文件和托管服务职责清楚
  • 后面想迁移、替换、扩展时不至于推倒重来

当前更稳的一条路线是：

  • 共享 memory backend
  • 文件化 instruction layer
  • 各产品自带 memory 只做附加增益

如果拿当前 shortlist 来落地，最顺手的主组合通常是：

  • backend 用 Mem0
  • 接入层用 mcp
  • 规则层用 AGENTS.md / copilot-instructions.md
  • 产品内生记忆如 Copilot Memory 保留开启，但不当主存

先分清：什么该进 memory，什么不该

优雅方案的第一步不是上服务，而是先把信息分层。

应该写进 memory 的内容

这些内容适合放进长期记忆：

  • 代码风格偏好
  • 常用命令和验证习惯
  • 解释风格和输出偏好
  • 常见工作流偏好
  • 你在不同项目里反复强调的稳定事实
  • 需要跨 session 继续复用的项目约定

一句话说：

会变化、会增长、需要检索、未来还会继续用的事实和偏好，适合进 memory。

不该写进 memory，应该写进文件的内容

这些更适合放在文件化规则层：

  • 必须执行的检查步骤
  • 审批规则
  • 提交规范
  • 测试要求
  • 输出格式要求
  • 项目目录职责说明

也就是：

带强约束、要求明确遵守、最好被人类直接审计的规则，优先写文件。

一套最稳的分层架构

推荐直接按三层来做。

第一层：个人全局规则层

放这些文件：

  • ~/.codex/AGENTS.md
  • Copilot 对应的用户级 instructions 文件
  • 你本机其他 agent client 的全局说明文件

这一层负责：

  • 默认语气
  • 默认验证习惯
  • 个人代码风格偏好
  • 解释深度偏好
  • 风险边界

它更像：

默认人格和工作方式。

第二层：项目规则层

放这些文件：

  • repo 根目录的 AGENTS.md
  • .github/copilot-instructions.md
  • 项目级 client 配置文件

这一层负责：

  • 当前仓库的工程规则
  • build / test / lint 方式
  • 架构约定
  • 不可破坏的边界
  • 项目内目录职责

它更像：

当前现场的显式施工规则。

第三层：共享 memory backend

把这层交给像 Mem0 这样的 backend，通过 mcp 暴露给多个 client。

这一层负责：

  • 用户偏好事实
  • 项目长期事实
  • 常见坑
  • 历史 tradeoff
  • 未来还会被反复检索的信息

它更像：

你的共享长期脑子。

推荐的命名和命名空间

如果一开始不把命名空间分清，后面最容易乱。

推荐最小结构：

1. user namespace

例如：

  • user:<name>/preferences
  • user:<name>/workstyle
  • user:<name>/tooling
  • user:<name>/writing-style

里面存：

  • 代码风格偏好
  • 注释偏好
  • 测试习惯
  • 命令行偏好
  • 输出表达偏好

2. repo namespace

例如：

  • repo:<repo>/architecture
  • repo:<repo>/decisions
  • repo:<repo>/commands
  • repo:<repo>/gotchas

里面存：

  • 架构约定
  • 常见坑
  • 常用命令
  • 历史决策
  • 特殊上下文

3. optional task namespace

如果你长期做很长的任务，可以加：

  • task:<project>/handover
  • task:<project>/progress

但这一层不要一开始就做太重，否则会把临时状态和长期记忆混在一起。

步骤

1. 先写一份最小的全局 AGENTS.md

不要上来写很长。

先只写这些稳定项：

  • 你希望 agent 默认怎么解释问题
  • 改动前后要做什么验证
  • 遇到不确定信息时怎么处理
  • 输出偏好
  • 是否优先保守修改

它的目标不是当数据库，而是给所有会话一个稳定起点。

2. 给每个项目写项目级 AGENTS.md

项目级文件重点放：

  • 仓库目标
  • 关键目录职责
  • 常用命令
  • 修改边界
  • 测试或验证要求

这一层要尽量少放会频繁变化的小事实，因为那类内容更适合进共享 memory。

3. 选一个共享 backend，当主记忆库

当前这条路线里，Mem0 很适合做第一选择，因为它更像现成的“共享 memory backend”，而不是要求你搭完整 agent system。

落地原则：

  • 用一个 backend 存个人长期偏好
  • 用 namespace 区分用户记忆和项目记忆
  • 让多个 coding client 通过同一 MCP 能力访问

4. 只把高价值、长期复用的信息写进 memory

不要把每轮对话都塞进去。

推荐只沉淀这几类：

  • 经常被重复强调的偏好
  • 下次进入项目还会继续用到的事实
  • 明显会影响后续决策的历史 tradeoff
  • 常见踩坑结论

如果一条信息满足不了“未来多次复用”，大概率不该进长期 memory。

5. 给 memory 写简单的录入标准

最小录入模板可以是：

  • scope：user / repo
  • namespace
  • statement
  • confidence
  • source
  • last_reviewed

例如：

scope: user
namespace: user:arlon/preferences
statement: prefers concise explanations with explicit tradeoffs
confidence: high
source: repeated user corrections
last_reviewed: 2026-04-20

再比如：

scope: repo
namespace: repo:thought-forest/commands
statement: prefer rg for search and avoid destructive git commands
confidence: high
source: repository instructions
last_reviewed: 2026-04-20

6. 明确读取顺序，避免互相打架

推荐读取顺序：

  1. 当前用户请求
  2. 项目级 AGENTS.md
  3. 用户级 AGENTS.md / instruction files
  4. repo memory
  5. user memory
  6. 产品自带 memory 增益

这能避免“老偏好覆盖当前明确要求”，也能避免共享 memory 把项目显式规则冲掉。

7. 定期清理和收敛

优雅方案的关键不只是“记住”，还包括“忘掉过时内容”。

建议周期性做三件事：

  • 合并重复记忆
  • 删除过期事实
  • 把已经稳定的规则从 memory 提升到 AGENTS.md

这也是为什么 agent-memory 这一类方向值得看，它强调的就是 consolidation 和 defrag，而不是无限增长。

一套最小可用落地示例

假设你要同时给 Codex、Copilot、OpenCode 用。

文件层

  • ~/.codex/AGENTS.md
    • 放个人默认工作方式
  • repo/AGENTS.md
    • 放当前项目规则
  • repo/.github/copilot-instructions.md
    • 放 Copilot 专用说明

memory 层

  • user:<you>/preferences
    • 放偏好和工作方式
  • user:<you>/tooling
    • 放工具链偏好
  • repo:<repo>/architecture
    • 放架构事实
  • repo:<repo>/gotchas
    • 放历史坑和例外

client 层

  • Codex
    • 读 AGENTS.md
    • 通过 mcp 连共享 memory
  • Copilot
    • 读仓库 instructions
    • 可继续保留 Copilot Memory
    • 同时接共享 memory
  • OpenCode
    • 作为另一个 client 读相同 backend

这样做的结果是：

  • 规则在文件层显式可见
  • 事实在 memory 层可检索可演化
  • 产品自带记忆继续提供局部增益
  • 你不会被单一客户端锁死

验证

一套个人记忆方案是否真的优雅，可以用下面几条检查。

1. 跨会话是否真的减少重复解释

如果每次进入仓库还要重新解释：

  • 目录职责
  • 常用命令
  • 风格偏好

说明记忆层还没有真正发挥作用。

2. 换客户端后是否还能保持一致

如果从 Codex 切到 Copilot 或 OpenCode 后，偏好和项目理解完全丢失，说明你把太多东西锁在单产品原生 feature 里了。

3. 显式规则是否和 memory 职责清楚

如果 AGENTS.md 里写满了不断变化的小事实，说明文件层过重。

如果 memory 里塞满“必须遵守”的流程规则，说明 memory 层过重。

4. 是否能清理

如果半年后你不敢删任何 memory，说明这套系统已经失控。

常见问题

为什么不直接只用产品自带 memory

因为多数产品自带 memory 都有边界：

  • 只在单产品内部有效
  • 可能偏 repo-scoped，不是 user-scoped
  • 不一定方便跨工具共享

所以更稳的做法通常是：

  • 原生 memory 保留
  • 但主记忆库放在共享 backend

为什么不能只靠 AGENTS.md

因为 AGENTS.md 更适合规则，不适合承载持续增长、需要检索、需要按 namespace 管理的长期事实。

为什么不建议一开始做很重的知识图谱

因为大多数个人使用场景，先把“共享 backend + 文件层分工”做对，收益已经很高。图谱和更复杂的 memory-native 系统，应该在你真的遇到关系管理瓶颈时再加。

最短结论

当前更优雅的个人记忆方案，不是把所有东西都塞进某个产品的聊天记忆，而是：

用 AGENTS.md 管显式规则，用共享 memory backend 管长期事实和偏好，让 Codex、Copilot、OpenCode 这些 client 共同访问同一层长期记忆。

创建于 2026/4/20 更新于 2026/5/27