很多人说 AI Agent 需要“代码库记忆”。
但这个词太宽。
有的人想让 Agent 记住项目规则。
有的人想让 Agent 找到函数调用链。
有的人想让 Agent 不要每次都重新扫描全仓库。
还有的人想让 Agent 自动执行固定审查流程。
这四个问题听起来相似，实际需要的工具完全不同。
Claude.md、AGENTS.md 更像项目规则文件。
code-review-graph 更像代码关系图和审查辅助工具。
codebase-memory-mcp 更像跨工具共享的代码索引服务。
Codex Skills 更像可复用工作流说明书。
选错以后，结果不是功能少一点，而是维护成本变高。
这篇文章不重复单个工具教程，而是做选型。
选型结论先说清楚
小项目先用 AGENTS.md 或 Claude.md。
中型项目加 Codex Skills，把重复流程固定下来。
代码审查任务优先看 code-review-graph。
多工具共享代码索引时，再考虑 codebase-memory-mcp。
不要一开始就把四种都装上。
更好的顺序是：规则文件先行，流程沉淀第二，结构索引第三，MCP 服务最后。
如果你已经读过 AI Agent 代码库记忆工具对比，这篇可以作为更窄的实操选型表。
四类工具解决四类问题
| 工具 | 主要解决的问题 | 最适合场景 | 最大风险 |
|---|---|---|---|
Claude.md / AGENTS.md |
项目规则和长期约定 | 小团队、单仓库、固定规范 | 写太长，污染上下文 |
Codex Skills |
重复任务流程 | 发布、翻译、部署、SEO、审查 | 把没跑顺的流程固化 |
code-review-graph |
调用关系和变更影响 | PR 审查、架构影响分析 | 图谱过期或排除目录不准 |
codebase-memory-mcp |
跨工具共享代码索引 | 多 Agent、多 IDE、大仓库 | 服务权限和索引维护成本 |
| 这张表里的重点是“主要解决的问题”。 | |||
| 它们不是同一种工具的四个品牌。 | |||
| 它们更像四层能力。 | |||
| 规则层告诉 Agent 怎么做。 | |||
| 流程层告诉 Agent 反复做什么。 | |||
| 结构层告诉 Agent 代码之间怎么连。 | |||
| 服务层让不同 Agent 通过统一接口查同一份索引。 |
先判断你缺的是哪种记忆
选工具前先问四个问题。
- Agent 是忘了项目规范吗？
- Agent 是找不到相关代码吗？
- Agent 是每次都重复同一套步骤吗？
- Agent 是多个工具之间上下文不同步吗？
如果只是忘了规范，写
AGENTS.md就够了。 如果只是重复同一套工作流，写 Skill 更直接。 如果经常漏调用链和影响范围，用代码图谱。 如果 Codex、Claude Code、Cursor 都要查同一份结构化索引，再接 MCP。 不要因为“记忆”这个词就把所有工具混在一起。
Claude.md 和 AGENTS.md：项目规则层
Claude.md、AGENTS.md 的价值在于短。
它们应该告诉 Agent 稳定规则，而不是保存项目百科。
适合写进去的内容包括：
- 项目启动命令。
- 测试命令。
- 代码风格。
- 禁止修改的目录。
- 发布前检查。
- 常见陷阱。
- 安全边界。
- 语言和文案要求。 不适合写进去的内容包括：
- 完整业务背景。
- 过期讨论记录。
- 每个模块的详细说明。
- 长篇设计文档。
- 一次性任务日志。
- 没验证过的个人偏好。 一个好的规则文件应该像路标。 它提醒 Agent 不要走错路。 它不应该变成一本厚手册。 如果你想专门优化规则文件，可以看 Claude.md 不是越长越好。
Codex Skills：工作流记忆层
Skill 不是代码索引。 它记住的是“做事方式”。 例如这个站点的新文章流程：
- 判断是不是新建文章。
- 找到下一个编号。
- 只创建
index.zh-cn.md。 - 设置 front matter。
- 控制发布日期。
- 检查行数。
- 不生成其他语言。 这些步骤不适合每次都写在提示词里。 它们适合沉淀成 Skill。
Skills 适合的任务
- 内容发布流程。
- 多语言翻译流程。
- 部署流程。
- SEO 冷却期检查。
- 本地转写流程。
- 安全检查清单。
- 固定格式报告。
- 代码审查步骤。
Skills 不适合的任务
- 单次问题排查。
- 仍在摸索的流程。
- 需要大量临场判断的任务。
- 没有稳定验收标准的任务。
- 只为了让回答更长的提示词集合。 Skill 最好的形态是“少解释，多约束”。 它应该减少 Agent 犯固定错误的概率。 如果你想从零写，可以看 Codex Skills 怎么写自己的工作流。
code-review-graph：变更影响层
code-review-graph 的重点不是让 Agent 记住聊天记录。
它更关注代码结构。
它用图谱思路帮助你回答：
- 这个函数被谁调用。
- 这个路由影响哪些模块。
- 这个 PR 改了哪些调用链。
- 哪些测试可能需要补。
- 哪些文件应该一起审查。 这类问题靠普通提示词很难稳定回答。 因为 Agent 如果只读 diff，容易漏掉间接影响。 如果让它全仓库搜索，又容易浪费上下文。 图谱工具的价值就在这里。 它把代码结构提前算好。 Agent 需要时再查。
code-review-graph 适合谁
- 经常做 PR 审查的人。
- 仓库模块之间调用复杂的人。
- 想让 Codex 或 Claude Code 审查变更影响的人。
- 不想每次都让 Agent 扫全仓库的人。
- 想把审查流程接入 GitHub Actions 的团队。
code-review-graph 不适合谁
- 只有几个文件的小脚本。
- 没有 PR 或 diff 流程。
- 只想保存聊天记忆。
- 不愿维护索引生成结果。
- 无法区分生成文件和源代码目录。 如果你要上手，可以看 code-review-graph 怎么用。 如果要接 CI，可以看 code-review-graph 接入 GitHub Actions。
codebase-memory-mcp：共享索引层
codebase-memory-mcp 更适合多工具环境。
如果你只用一个 Agent，未必需要它。
但如果你同时用 Codex、Claude Code、Cursor、Gemini CLI，问题会出现。
每个工具都有自己的上下文。
每个工具都可能重新扫描代码。
每个工具对项目结构的理解可能不一致。
这时 MCP 形式的代码索引就有价值。
它可以把代码库结构作为一个服务暴露给不同 Agent。
Agent 不需要每次重新构建理解。
codebase-memory-mcp 适合的场景
- 大仓库。
- 多语言仓库。
- 多个 Agent 共享同一项目。
- 需要本地优先的代码索引。
- 需要通过 MCP 统一接入。
- 需要减少重复扫描成本。
使用前要想清楚
它是一个服务。 服务就有运行状态。 服务就有端口、权限、索引目录和升级问题。 如果团队没人维护，这类工具很容易变成“装过但没人敢动”。 所以它适合已经有稳定 Agent 使用习惯的团队。 不适合还在试用阶段的人。 安装教程可以看 codebase-memory-mcp 使用教程。
按仓库规模选择
仓库规模会明显影响选型。 一个脚本仓库和一个大型单体仓库，不应该用同一套记忆方案。
10 个文件以内
这类项目不需要复杂记忆。 建议只保留：
README.md。AGENTS.md。- 基础测试命令。
- Git diff 审查。 如果 Agent 还找不到文件，问题通常不是工具少，而是任务描述太宽。
10 到 200 个文件
这类项目开始需要轻量结构说明。 建议增加：
- 模块目录说明。
- 常用命令清单。
- 一个开发或发布 Skill。
- 必要时加 code-review-graph。
这时规则文件仍然要短。
不要把每个模块都写进
AGENTS.md。
200 到 2000 个文件
这类项目开始出现影响范围问题。 建议增加：
- 调用关系图谱。
- 变更影响审查。
- CI 中的最窄测试策略。
- 团队共享规则。
- 忽略生成目录的索引配置。
code-review-graph在这一层更有价值。 它帮助 Agent 少靠猜。
多语言大仓库
这类项目需要共享索引和服务化能力。 建议增加：
codebase-memory-mcp。- 统一 MCP 配置。
- 索引更新策略。
- 权限白名单。
- 服务监控。
- 版本升级记录。 这时工具本身已经是基础设施。 不能只靠个人习惯维护。
按任务类型选择
不同任务对记忆的要求也不同。
修 Bug
修 Bug 最需要复现步骤和相关文件。 优先级是：
- 错误日志。
- 复现命令。
- 最近改动。
- 相关测试。
- 调用关系。 如果 Bug 很局部，不必上 MCP。 如果 Bug 跨模块，再用图谱。
写新功能
写新功能最需要边界。 优先级是：
- 需求范围。
- 不改动范围。
- 数据结构。
- API 契约。
- 测试入口。 规则文件能防止 Agent 乱改架构。 Skill 可以保存固定实现流程。
代码审查
代码审查最需要变更影响。 优先级是：
- diff。
- 调用方。
- 被调用方。
- 路由入口。
- 测试覆盖。
- 安全边界。 这里 code-review-graph 比长提示词更合适。
文档和发布
文档和发布最需要流程记忆。 优先级是：
- front matter。
- 文件命名。
- 构建规则。
- 多语言同步。
- 链接检查。
- 发布检查。 这类任务更适合 Skills。
数据更新策略
代码库记忆如果不更新，很快就会误导 Agent。 不同工具的更新方式不同。 规则文件靠人工维护。 Skills 随流程变化更新。 code-review-graph 需要在代码变更后重建或增量更新。 codebase-memory-mcp 需要维护索引服务和数据目录。
什么时候必须更新
- 新增模块。
- 删除目录。
- 路由结构变化。
- 测试命令变化。
- 构建工具变化。
- 代码生成目录变化。
- 团队权限规则变化。
- CI 流程变化。
- Agent 工具升级。
- MCP 服务升级。
更新后的验收
- Agent 能说明入口文件。
- Agent 能找到相关测试。
- Agent 不会扫描生成目录。
- Agent 能解释一次真实 diff。
- Agent 能遵守禁止修改范围。
- Agent 能正确调用 Skill。
- MCP 查询返回的是最新文件。
- 图谱结果和实际代码一致。
失败案例和修复
规则文件太长
表现是 Agent 每次都读得慢，还会引用无关规则。 修复方法是删。 保留稳定约定。 把流程移到 Skill。 把背景移到文档。
Skill 写得太泛
表现是每种任务都套同一个流程。 修复方法是拆。 一个 Skill 只服务一类工作。 例如发布、翻译、部署、审查分别写。
图谱没有排除生成目录
表现是 Agent 关注构建产物，而不是源代码。
修复方法是更新 ignore 配置。
把 dist/、public/、node_modules/、缓存目录排除。
MCP 权限过大
表现是 Agent 能访问太多不相关资源。 修复方法是分级。 只读工具先行。 写入工具单独审批。 生产工具默认关闭。
四种工具可以怎么组合
个人小项目建议：AGENTS.md、少量项目文档、Git diff、最窄测试命令。
中型 Web 项目建议：AGENTS.md、一个发布或测试 Skill、code-review-graph、PR 审查模板。
多 Agent 团队项目建议：AGENTS.md、团队级 Skills、code-review-graph、codebase-memory-mcp、CI 审查、权限边界文档。
内容站和自动化工作流建议：发布 Skill、翻译 Skill、SEO 冷却期规则、部署 Skill、少量站点目录说明。
这类组合的关键不是工具多。
关键是每一层解决的问题不重叠。
选型决策树
先问：Agent 是否经常违反项目规则？
是，就写 AGENTS.md 或 Claude.md。
Agent 是否经常重复同一套步骤？
是，就写 Skill。
Agent 是否经常漏掉调用链或影响范围？
是，就用 code-review-graph。
是否有多个 Agent 需要共享代码索引？
是，再考虑 codebase-memory-mcp。
否，先不要加工具。
这个顺序能避免把简单问题复杂化。
和已有文章怎么串起来
这篇文章适合作为选型入口。
单工具安装继续交给已有文章。
code-review-graph 的具体命令看 7/99。
GitHub Actions 接入看 7/137。
codebase-memory-mcp 安装看 6/113。
规则文件思想看 4/118。
通用记忆路线看 7/42。
这样读者不会在一篇文章里被所有命令淹没。
他们先选方向，再进入具体教程。
最终选择建议
如果你只想让 Agent 不犯固定错误，选 AGENTS.md 或 Claude.md。
如果你想让 Agent 按固定流程办事，选 Codex Skills。
如果你想让 Agent 做变更影响分析，选 code-review-graph。
如果你想让多个 Agent 共享代码结构，选 codebase-memory-mcp。
真正成熟的代码库记忆，不是把所有东西都记住。
而是把规则、流程、结构和服务放到合适的位置。