昨天花半小时跟 Agent 解释清楚的业务逻辑，今天一开新会话，它又什么都不记得了。
我和 Agent 的"失忆"日常
上周我在赶一个支付模块的重构。项目用的是一套比较冷门的内部框架，文档不全，很多设计意图藏在老代码的注释里。
我打开 Coding Agent，花了将近四十分钟，把我们项目的分层架构、命名规范、几个核心领域模型的业务含义一点点喂给它。终于，Agent 开始"上道"了——它理解了为什么我们的 Service 层不直接依赖 DAO，为什么状态机要用枚举而不是字符串，为什么某些字段必须做幂等校验。
那天下午的协作效率很高，我几乎觉得找到了一个懂我项目的 AI 搭档。
然后第二天，我开了一个新会话。
"请帮我给 OrderService 添加一个超时取消的逻辑。"
Agent 自信地给我生成了一段代码——直接调了 DAO 层，状态字段用了硬编码字符串，完全没有幂等处理。
那一刻我真的想摔键盘。
这不是 Agent 的错
冷静下来想想，这事怪不得 Agent。当前主流的 Coding Agent——Claude Code、Cursor、GitHub Copilot——它们的"记忆"本质上都是会话级的。
每次对话就像一次短期合同：你在这次会话里告诉它的一切，会话结束就没了。下一次对话，一切归零。
这带来三个很具体的痛点：
重复劳动。 每次开新会话，你都要把项目背景、技术栈、架构约定重新说一遍。对于一个复杂项目，光是"前情提要"就要花掉 10-20 分钟。
知识无法积累。 你和 Agent 在调试过程中发现的 Bug 根因、总结出的最佳实践、踩过的坑——这些上下文，全都没有地方沉淀。
上下文窗口有限。 即便在同一次会话里，当对话足够长时，早期的上下文也会被截断。Agent 的上下文窗口再大，也装不下一个完整项目的全部知识。
现有方案的局限
你可能会说，不是有 .cursorrules 或者 CLAUDE.md 这类文件吗？
确实，很多开发者已经开始用项目级的指令文件来给 Agent 提供上下文。编码规范、技术栈声明这些静态信息确实可以写进文件，能解决一部分问题。
但另一类问题它解决不了：动态积累的经验知识。
比如：
- "上次那个 NullPointerException 的根因是下游服务在灰度期间返回了空列表"
- "这个接口的超时时间不能设太短，因为合作方响应慢"
- "用户反馈这个页面的加载体验不好，因为首屏要等三个接口全部返回"
这些知识是在日常开发中逐渐产生的，不适合写成文档，但又很关键。你不可能每次都手动更新一个规则文件。
也有人尝试用 Mem0 之类的 Agent Memory 方案来补这块，效果有好有坏——记忆提取的准确率不稳定是个真实的问题，记错了比不记更麻烦。这个话题后面再展开。
如果 Agent 能"记住"呢？
这是我最近接触到 ContextDB 后觉得有意思的地方。
它做的事情很明确：给 Agent 一个持久化的记忆层。
听起来好像没什么——不就是个数据库吗？但仔细想想，Agent 缺的不是"存储"，而是结构化的、可检索的、有生命周期的记忆管理。
它设计了三层记忆结构：
- 原子事实（Atomic Fact）：每次交互中提取的最小知识单元。比如"用户偏好使用枚举而非字符串来表示状态"，带有一个置信度分数和时间戳。
- 记忆实体（Entity Card）：多个原子事实聚合形成的画像。关于"项目编码规范"这个实体，可能聚合了十几条从不同会话中提取的原子事实。
- 记忆图谱（Memory Graph）：实体之间的关联关系，形成知识网络。"支付模块"关联到"幂等设计"，"幂等设计"又关联到"分布式锁"。
这三层结构让 Agent 的记忆不再是扁平的文本堆积，而是一个有层次、有关联的知识体系。
说实话，这套设计在概念层面我觉得是对的。但实际效果多大程度上能达到预期，取决于记忆提取的准确率和检索的召回率——这两个指标在不同项目、不同领域的表现可能差异不小。
接入过程
接入比较简单。对于大多数主流 Coding Agent，一条 CLI 命令：
curl -fsSL 'https://context-database-client.oss-cn-hangzhou.aliyuncs.com/install.sh' | bash -s -- --agent <agent> --api-key <api-key>
把 替换成你用的 Agent 名称（比如 claude-code、qoder）， 替换成你的 API Key。
目前支持的 Agent 包括 Qoder、Claude Code、Codex、OpenClaw、OpenCode、Hermes、QoderWork。
接入之后，Agent 会自动从每次对话中提取有价值的信息沉淀下来。下次新会话开始时自动检索相关记忆。
不过有一点要提：目前这个方案是基于 RDS MySQL 的，如果你用的是其他数据库引擎，暂时还接不了。另外冷启动阶段的效果会差一些，需要跑一段时间积累足够的记忆才能明显感受到差别。
一个粗略的对比
接入之后，我做了一个简单的对比测试：
不用持久化记忆：
- 开新会话，花 15 分钟描述项目背景和架构
- Agent 给出一个中规中矩的方案
- 我指出方案不符合项目规范，Agent 修正
- 又花 10 分钟解释为什么这个模块要这么设计
- 终于得到可用的代码
用了持久化记忆：
- 开新会话，直接说需求
- Agent 自动检索到之前的项目记忆，给出的代码直接符合规范
- 一轮就得到可用代码
在我的项目上效率差距大概 3-5 倍。不过这个数据仅供参考——我的项目比较特殊，框架冷门、规范多，本身"前情提要"的成本就偏高。对于用主流框架、规范比较少的项目，差距可能没这么大。
记忆这件事，被低估了
写这篇文章主要是想聊一个观察：Agent 的记忆能力正在成为影响开发效率的关键变量，但大家讨论得太少了。
我们聊 Agent 的代码生成能力、推理能力、工具调用能力，聊得很热闹。但"记忆"这个能力，看起来不够酷，反而没多少人关注。偏偏是记忆，决定了 Agent 能不能从一个"通用助手"变成一个"懂你项目的队友"。
ContextDB 提供了一种做法，但不是唯一的思路。也有人用向量数据库 + 自定义 pipeline 来做类似的事，各有取舍。关键是想清楚你的场景需要什么——如果你每天都在跟 Coding Agent 打交道，而且项目周期长、规范多，给 Agent 一个持久化的记忆层是值得考虑的方向。那种不用每次从头解释的感觉，确实挺好的。
