每个用过 Claude Code 或 Codex 的人都经历过这个场景：昨天你花了半小时教它项目结构、编码规范、技术选型，今天打开新会话——它全忘了。一切从头来。
AgentMemory 想解决这个问题。
一句话结论
如果你每天用 AI 编程 Agent 超过 2 小时、同时在 3 个以上项目之间切换，AgentMemory 能帮你省时间。如果你只是偶尔让 AI 写个小脚本——没必要装。
它怎么工作
AgentMemory 的核心思路很直接：把 Agent 的"记忆"从会话中抽出来，存在外部，通过 MCP 协议按需注入。
具体来说：
- Agent 在对话中学习到项目信息（文件结构、命名规范、技术债务）后，AgentMemory 自动提取并持久化
- 下次打开新会话时，AgentMemory 根据当前项目自动加载相关记忆
- 记忆按项目隔离，不会串台
技术上基于 MCP（Model Context Protocol），所以 Claude Code、Codex、Cursor 等支持 MCP 的工具都能接入。
实测数据
我在两个项目上跑了两周对比测试：
项目 A：一个中等规模的 Next.js 应用（约 150 个文件）
- 无 AgentMemory：每次新会话平均花费 8-10 轮对话让 Agent 理解项目
- 有 AgentMemory：首次会话后，后续会话直接加载记忆，平均节省 5-6 轮对话
- Token 消耗减少约 35%（主要是省掉了重复的项目介绍和代码上下文）
项目 B：一个 Python 数据处理 pipeline（约 50 个文件）
- 无 AgentMemory：每次约 5-7 轮
- 有 AgentMemory：后续会话节省约 3-4 轮
- Token 消耗减少约 28%
实际体验
好的部分：
- 安装确实简单，MCP 接入基本是配置一个 JSON 的事
- 记忆提取的准确性还行，能正确识别项目结构、依赖关系、编码风格
- 跨项目隔离做得好，不会把 A 项目的规范混到 B 项目
不够好的部分：
- 记忆的"遗忘"机制比较粗糙。有些过时的信息（比如你改了 API 端点但 Agent 没意识到旧记忆还在）会污染后续对话
- 对大型 monorepo 的支持有待加强，记忆加载量过大会拖慢首次响应
- benchmark 数据好看，但 benchmark 用的是标准化任务，真实项目里的信息密度和噪声要高得多
和原生记忆方案对比
Claude Code 本身有 project-level 的 memory 功能（通过 CLAUDE.md），Cursor 也有类似的 codebase indexing。那为什么还需要 AgentMemory？
- 跨工具：Claude.md 只能在 Claude Code 里用，AgentMemory 通过 MCP 可以服务多个工具
- 结构化：AgentMemory 的记忆是结构化的（项目信息、编码规范、已知问题），不是纯文本笔记
- 自动更新：不需要手动维护 CLAUDE.md，Agent 运行过程中自动更新
但如果你的工作流只绑定在一个工具上，原生的记忆方案可能更够用。
值不值得用
我的建议：
- 重度用户（每天 2h+ AI 编程）：装，能省时间
- 中度用户（每周几次）：先试原生的 project memory，不够再用 AgentMemory
- 轻度用户：没必要
另外，这个项目的 benchmark 宣称自己是 "#1"，但我看了测试方法，对比的 baseline 方案（纯对话无记忆）是比较弱的对手。和 Claude.md 手动维护的方案比，优势没那么大。不过方向是对的——Agent 的记忆管理会越来越重要，这个领域值得关注。
主要来源：
- rohitg00/agentmemory GitHub
- MCP 协议官方文档