为什么你更新了文档，Codex 还是在按旧内容回答？

这两天看到一个很典型的问题：有人在项目里加了文档，后来又更新了文档，但 Codex 依然输出旧文档里的内容，好像完全没有读取新的资料。

这个问题表面上看是“Codex 没有加载新文档”，但本质上不是一个单纯的文件更新问题，而是很多人对 Projects、Memory、项目上下文、AGENTS.md、MCP 这几个概念混在一起了。

我简单说结论：

Projects 不应该被当成长期知识库来用。

Memory 不应该被当成事实来源来用。

AGENTS.md 更适合放规则和工作约定。

MCP 才更适合做动态知识源的入口。

如果你把这几个东西的职责分清楚，很多“AI 为什么又按旧资料回答”的问题就能解释清楚了。

一、Projects 的本质不是长期知识库，而是短期项目上下文

很多人会误以为：我在 Project 里上传了文档，AI 以后就会一直、稳定、实时地按照这份文档工作。

这个理解是不准确的。

Projects 更像是一个短期工作空间。比如你正在做一个编程项目、写一篇论文、整理一份方案、开发一个网站，你把相关资料、聊天、文件放进去，让 AI 在这一段时间内围绕这个项目工作。

它的价值是“聚焦当前任务”，不是“充当长期知识库”。

一个项目完成了，这个 Project 理论上也就完成使命了。它适合承载阶段性上下文，但不适合承担长期、持续更新、跨工具共享、可版本控制的知识库职责。

如果你把 Projects 当成长期知识库，就会遇到几个问题：

第一，文档更新后，AI 不一定每次都会重新完整读取最新文件。

第二，旧对话里已经形成的摘要、判断和上下文，可能继续影响后续回答。

第三，项目指令、记忆、过往聊天、文件内容之间可能互相干扰。

第四，如果你在同一个长会话里反复追问，模型很可能优先沿用前文已经形成的判断，而不是自动回到硬盘里重新查一遍最新文件。

所以，如果你发现“我明明更新了文档，但 Codex 还是按旧内容回答”，第一反应不应该是“文件系统坏了”或者“AI 不支持更新文档”，而应该问：

它这次回答到底是基于最新文件，还是基于旧上下文、旧记忆、旧摘要、旧项目指令？

二、AI 输出旧内容，常见原因不止一个

这类问题通常不是单点故障，而是上下文链路里有多个可能的旧信息来源。

第一个可能：当前会话里已经有旧内容。

如果你之前在对话里问过旧版本文档的问题，模型已经把旧内容吸收到当前上下文里了。你后面虽然更新了文件，但没有明确要求它重新读取最新文件，它就可能继续沿用前面的理解。

这种情况很常见。

你以为你更新的是“知识源”，但模型正在使用的是“当前对话上下文”。

第二个可能：Memory 或历史聊天在干扰。

如果开启了跨会话记忆，AI 可能会从过去的聊天、保存记忆、文件或其他上下文里提取它认为相关的信息。这个功能本来是为了让 AI 更懂你的偏好，但如果里面存了旧项目设定、旧技术栈、旧文档摘要，它也可能变成污染源。

所以不是说 Memory 一定有问题，而是它不适合作为事实源。Memory 更适合保存长期偏好，比如“我喜欢中文回答”“我的项目使用 React”“我习惯先要结论再要细节”。但版本化事实，比如接口文档、需求文档、配置说明、数据库结构，最好不要依赖 Memory。

第三个可能：AGENTS.md 或项目指令里有旧规则。

Codex 很重视 AGENTS.md 这类项目指导文件。它适合放项目规则，比如如何运行测试、代码风格、目录结构、PR 要求、哪些文件优先阅读等。

但如果 AGENTS.md 里写了旧路径、旧架构、旧接口约定，Codex 就可能持续按旧规则工作。尤其是全局 AGENTS.md、项目根目录 AGENTS.md、子目录 AGENTS.md 同时存在时，很多人根本不知道 Codex 到底读了哪一个。

第四个可能：你以为更新了文档，但 Codex 所在的工作区没有更新。

这点也非常关键。

你本地更新了文档，不代表 Codex 当前运行环境里的文件就是最新的。尤其是涉及 Git、远程环境、工作树、分支、同步目录、服务器目录的时候，必须确认 Codex 看到的路径和你更新的路径是同一个。

你可以直接让 Codex 先做这几件事：

查看当前目录。

列出目标文件。

打印文件修改时间。

读取目标文件前几十行。

对比 Git diff。

不要一上来就问“根据最新文档告诉我结论”。你应该先让它证明自己确实读到了最新文件。

比如可以这样问：

“请先不要回答结论。先确认你当前工作目录、目标文档路径、文件修改时间，并读取该文档的关键段落。确认你读到的是最新版本后，再基于它回答。”

这句话非常有用。

因为它把模型从“凭上下文回答”切换成了“先验证文件，再回答”。

三、Projects、Memory、AGENTS.md、MCP 应该怎么分工？

我觉得更健康的结构应该是这样：

Projects：放短期任务上下文。

Memory：放长期偏好和常用背景。

AGENTS.md：放稳定的工作规则。

MCP：连接动态知识源和外部系统。

这四个东西不是互相替代关系，而是分工关系。

Projects 负责“我现在正在做什么”。

Memory 负责“我长期喜欢什么、常用什么”。

AGENTS.md 负责“这个项目必须遵守什么规则”。

MCP 负责“需要事实时，去哪里查最新资料”。

举个例子。

如果你正在做一个前端项目，Project 里可以放当前需求、设计稿、阶段性讨论。

Memory 可以记住你偏好 TypeScript、喜欢简洁代码、回答要中文。

AGENTS.md 可以写清楚：修改代码后必须运行 pnpm test，组件放在 src/components，接口类型放在 src/types，禁止擅自引入新的 UI 库。

MCP 则可以连接你的知识库、文档库、数据库、接口文档、Obsidian 笔记、GitHub issue、Notion、飞书文档，甚至你自己的服务器资料。

这样一来，AI 每次要查事实时，不是靠“记忆里好像有”，而是通过工具去查最新来源。

这就是区别。

Memory 是“我记得你以前说过”。

MCP 是“我现在去查最新数据”。

前者适合个性化，后者才适合知识库。

四、为什么我更推荐用 MCP 做长期知识库入口？

因为 MCP 的关键价值不是“存笔记”，而是“把笔记变成可调用工具”。

普通文档上传，本质上还是静态上下文。

而 MCP 可以把你的知识库暴露成一组工具，比如：

search_notes：搜索笔记。

read_note：读取笔记。

create_note：创建笔记。

update_note：更新笔记。

list_recent：列出最近更新。

diff_note：查看某篇笔记的版本变化。

这样 Codex、Claude、Cursor、Grok、Hermes、OpenClaw，只要支持 MCP，都可以通过同一个入口查你的资料。

这和“把文档塞进某个 AI 的项目里”完全不是一个层级。

把文档塞进 Project，通常只能服务于当前平台、当前项目、当前会话。

把知识库做成 MCP，它就变成了一个独立的数据源，任何支持 MCP 的 Agent 都能接入。

如果你的笔记更新了，下一次工具调用读到的就是更新后的内容。

如果你想在对话中修改笔记，也可以让 Agent 直接调用 update 工具完成。

如果你有服务器，还可以把 MCP 服务部署在服务器上，笔记也放服务器上，再用 Git 做版本控制。这样你的 Codex、Hermes、OpenClaw、Grok 都可以成为写笔记、查笔记、改笔记的入口。

这才是长期知识库更合理的形态。

不是把知识塞进某一个 AI，而是把知识放在你自己可控的系统里，然后让所有 AI 通过工具来访问。

五、遇到“Codex 不读新文档”，我建议这样排查

第一步，确认它读的是不是同一个文件。

让 Codex 输出当前工作目录、目标文件路径、文件修改时间、文件内容摘要。不要只问它“有没有读取最新文档”，因为它可能会回答“我读取了”，但实际上并没有真正验证。

第二步，开一个新会话或重启当前 Codex session。

如果你在一个很长的旧线程里继续问，它很可能沿用旧上下文。开新线程，并明确要求“以当前文件系统中的最新文件为准”，能减少旧上下文污染。

第三步，检查 AGENTS.md。

看全局 ~/.codex/AGENTS.md、项目根目录 AGENTS.md、子目录下的 AGENTS.md 有没有旧规则。尤其要看里面有没有旧路径、旧接口、旧命名、旧技术栈、旧启动命令。

第四步，检查 Codex Memories。

如果你开启了 Codex 的 memories，它可能会把之前的项目约定、技术栈、踩坑记录带入未来线程。这个功能很有用，但不要把它当成事实来源。如果发现它反复引用旧设定，就要清理或修正对应 memory。

第五步，检查 Git 分支和工作树。

很多时候不是 AI 没读新文档，而是你更新的是 A 分支，Codex 在 B 分支；你改的是本地目录，Codex 在远程环境；你看的文件是新版本，Codex 工作区里的文件还是旧版本。

第六步，在提示词里明确要求“先查后答”。

比如：

“涉及项目事实、接口、需求、目录结构时，不要凭记忆回答。必须先读取当前仓库中的最新文件，再给结论。”

如果你已经搭了 MCP，也可以写得更直接：

“涉及知识库内容时，必须优先调用 MCP 的 search/read 工具，读取最新笔记后再回答。”

这句话最好写进 AGENTS.md，而不是每次手动提醒。

六、一个更成熟的个人 AI 知识系统应该长什么样？

我觉得可以用这套结构：

短期任务放 Projects。

长期资料放 Git 仓库或服务器。

稳定规则写进 AGENTS.md。

动态查询交给 MCP。

重要文档做版本控制。

容易变的事实不要放 Memory。

AI 只负责调用和推理，不负责成为唯一资料库。

这种结构最大的好处是：你不会被某一个平台、某一个会话、某一个项目空间锁死。

今天你用 Codex，明天你用 Claude，后天你用 Grok，再后来你自己写 Hermes Agent，只要它们支持 MCP，就都可以接入同一个知识源。

你的知识不是跟着某个 AI 走，而是跟着你自己的系统走。

这才是 AI Agent 时代真正值得搭的基础设施。

七、给普通用户的简单建议

如果你只是临时做一个作业、写一个方案、改一个小项目，用 Projects 就够了。

如果你只是希望 AI 记住你的表达风格、常用技术栈、回答偏好，用 Memory 就够了。

如果你希望 Codex 每次在某个项目里稳定遵守规则，用 AGENTS.md。

如果你希望资料长期更新、跨工具共享、多个 Agent 都能读写，那就不要只靠 Projects，应该考虑 MCP。

一句话总结：

Projects 是临时办公室。

Memory 是私人助理的印象。

AGENTS.md 是项目规章制度。

MCP 是通向真实资料库的工具接口。

不要让临时办公室承担图书馆的职责，也不要让私人助理的印象代替最新档案。

很多 AI 使用问题，本质上不是模型不聪明，而是上下文系统没设计好。

当你把“短期上下文、长期记忆、项目规则、动态知识源”这四层分开，AI 才会真正稳定起来。

————————————