Fable5王者归来，我这个Codex元老用户也没忍住去试了一下，看下它到底有没有吹的那么牛，能不能干掉Codex——让它把Codex优化到极致的记忆系统继续迭代。然后我就往Zenmux里面充了十刀，把Fable5接到Claude Code里面试了一下——省流版答案：Fable5就是Codex“超高”智能的爸爸！！！（文末附记忆系统Skill）
关于我之前的半成品记忆系统：
https://x.com/gengdaJ/status/2067985719675773192
https://x.com/evermind/status/2063262473357336824
https://x.com/gengdaJ/status/2068555151733043504
Fable5确实贵，所以我听从了Timeline上面大佬们的建议，就让Fable5参与了给Codex记忆系统提意见、做规划的环节——
不问不知道，一问吓一跳，第一次检测用“第一性原理”就给我找出了一大堆Bug和优化空间。。。它的技术专业度不用质疑，因为Codex自己承认了。。。但是能从报告里面看出来，Fable5给的建议还是有不严谨的地方，确实是，但是4:1，Fable5完胜。
这才是第一步，Fable5牛逼的能力才刚刚显露，我让Codex整理了一份开发计划，我又把它发给了Fable5审核：
依旧质疑。。。然后Codex依旧同意。。。
我就让Codex又按照Fable5的建议，优化了一下，我想这下总没问题了吧，发给了Fable。
最后Fable竟然还能找出这么多问题，我真的服了。。。赶紧让Codex来认认它最严厉的父亲。
开发完成后，Fable5依旧智商在线，检查代码嘎嘎乱杀。
经过这个测试，不得不佩服Fable5在决策和判断这一块真的很夯，就算我是Codex忠实用户，也不得不夸奖一下，我以后做一些复杂系统（接下来可能还要优化Agent搜索系统），我还用Fable5，虽然它贵，但是只要好钢用在刀刃上，也是值得的。
如果大家也想尝试Fable5这恐怖如斯的规划能力，也可以像我一样调用Zenmux的API（这家是我觉得质量最好的Claude源头）：https://zenmux.ai/invite/GYMUHL，今天我调的时候发现：free订阅用户可以免费体验网页版，按量付费用户（账户credits>0），可以直接免费调用API，充值赠送20%额度，算是一个小福利了～
接下来，就讲讲这套Fable5重构出来的记忆系统架构，它有多牛逼，看下我接下来的通俗拆解就懂了：
我现在的这套Codex记忆系统是存放在本地、可审查、可搜索、可维护的 Agent Obsidian记忆库。它能够把非常丝滑地把你和 Codex 一起做过的项目、踩过的坑、你的偏好、重要决策、复用流程都沉淀成 Obsidian 里的 Markdown文档，再用 SQLite、全文搜索、语义检索、Git、hook 和 closeout 脚本，实现记忆系统的自运转和自迭代。
基础概念
在进入 这套记忆系统功能的正式讲解之前，还需要先了解八个基础的英文概念：
- Obsidian Markdown：原始记忆档案
它本质上就是一堆普通的 \.md\ 文本文件。 为什么不用数据库当核心？因为Obsidian对于非程序员真的更友好——人能直接读、直接改，也能被 Git 记录变化。它就是这套记忆系统的“事实原件”。
举个例子：
你有一个项目叫“小红书电商”。它的项目路径、启动命令、部署状态、之前踩过什么坑，都会写在类似这样的文件里：
Codex记忆/项目/小红书电商.md
以后你问 Codex：“继续上次小红书电商那个项目”，Codex 不需要靠模糊回忆，而是先去读这个 Markdown 文件，答案自然会更加精准。
所以 Markdown 文档承担的是：保存正式事实。
- INDEX.md：目录和导航台
\INDEX.md\ 本质上不是记忆本身，而是“入口地图”。 如果 Markdown 是一整座图书馆，\INDEX.md\ 就是前台目录：告诉 Agent 哪些文件重要、什么问题应该去哪里找。
举个例子：
你问：“之前那个 EverOS 记忆系统在哪？”
Codex 会先看 \INDEX.md\，发现里面有：
项目/EverOS.md 项目/Codex记忆模板仓库.md 工作流/Codex记忆本地脚本.md 决策/2026-07-02-Codex记忆系统审计优化优先级.md
它就知道应该优先读这些，而不是把整个 Obsidian 翻一遍。
所以 \INDEX.md\ 承担的是：节省 token，帮 Agent 快速选对入口。
- SQLite / FTS：快速检索卡片
SQLite 是一个本地小数据库，FTS 是它的全文搜索能力。 它的本质不是“事实源”，而是“搜索索引”，就像图书馆会给每本书做索引卡片：标题、关键词、摘要、路径、更新时间。
举个例子：
你问：“上次那个 scoped commit 是怎么回事？”
如果只靠目录，Codex 可能不知道在哪个文件，但 SQLite/FTS 可以快速搜索所有 Markdown 的文字，找到包含 \scoped commit\、\closeout\、\git status\ 的文件。
它可能返回：
决策/2026-07-02-Codex记忆系统审计优化优先级.md 工作流/Codex记忆本地脚本.md
然后 Codex 再去读 Markdown 原文确认。
所以 SQLite/FTS 承担的是：用关键词快速找到相关记忆。
- Zvec：语义搜索
Zvec 本质上是向量检索，也就是“按意思找东西”。 普通搜索要求搜索词对得上，比如你搜“scoped commit”，文件里也得有这个词。 但语义搜索不一样。你可以问：
“之前那个只提交本轮记忆文件，不要把整个 Obsidian 提交的规则是什么？”
你这句话里可能没有 \scoped commit\ 这个词，但意思是一样的。Zvec 就能找出相关记忆。
尽管关键词不完全一样，但是只要语义接近，Zvec 能帮忙召回。
所以 Zvec 承担的是：当你记不清原词时，按意思找回记忆。
- Git：修改记录和回滚保险
Git 本质上是版本记录系统。 它不是用来搜索的，而是用来回答几个问题：
- 这个记忆是谁什么时候改的？
- 改了哪几行？
- 如果写错了，能不能回滚？
- 本轮 Codex 到底动了哪些记忆文件？
举个例子： 当Codex 今天更新了这两个文件：
工作流/Codex记忆本地脚本.md 决策/2026-07-02-Codex记忆系统审计优化优先级.md
Git 可以记录这次修改。
如果第二天发现 Codex 写错了，不需要靠回忆，可以直接看 diff，甚至恢复旧版本。
所以 Git 承担的是：让记忆系统变得可审计、可追溯、可回滚。
- closeout 脚本：任务结束后的自动整理员
closeout 本质上是“收尾流程自动化”。 以前的问题是：Codex 做完一件事后，要不要更新记忆、刷新索引、检查敏感信息、提交 Git，全靠它记不记得。 closeout 把这些步骤合成一条命令。
举个例子：
Codex 刚帮你优化了记忆系统。结束前运行 closeout，它会自动做：
- 看看本轮哪些记忆文件被改了。
- 检查有没有疑似密钥。
- 检查文件有没有太长。
- 判断有没有和旧记忆重复。
- 刷新 SQLite 索引。
- 刷新 Zvec 索引。
- 写 closeout 日志。
- 只提交这次处理过的记忆文件。
所以 closeout 承担的是：把“记忆维护”从靠Codex主观自觉判断变成标准优化流程。
- audit 脚本：定期体检医生
audit 本质上是“系统体检”。因为记忆库会越来越大，迟早会出现：
- 有些记忆过时了。
- 有些 open-loop 太久没处理。
- 有些文件内容重复。
- 有些状态已经不准确。
- 有些条目需要人工确认是否继续保留。
举个例子： audit 可能发现：
agent/open-loops.md 里有一个事项 45 天没更新 项目/某产品调研.md 的 verified_at 已经过期 两个文件标题很像，可能重复
它不会自动删除或修改正式记忆，而是列出来让你做出最终的裁决：忽略、解决、推迟、以后再看。
所以 audit 承担的是：防止记忆库越来越脏，定期清理噪声。
- AGENTS.md：系统宪法
\AGENTS.md\ 本质上是 Agent 的行为规则文件。 它告诉 Codex：
- 什么时候必须读记忆。
- 先读哪些文件。
- 什么值得写入。
- 什么绝对不能写入。
- 写入前怎么对账。
- 什么时候必须问用户。
- 收尾时必须怎么 closeout。
举个例子： 里面会规定：
涉及微信、删除文件、账号凭证、敏感隐私、费用支出时，必须 ASK_USER。
所以当 Codex 想写一条记忆，内容涉及“删除文件”时，它不能自己决定，而是必须停下来问你。
所以 AGENTS.md 承担的是：给 Agent 立规矩，保证它不会乱读、乱写、乱自动化。
记忆系统的运转流程
理解了这八个基础概念之后，我们再来看看这套记忆系统整体的一个运转流程：
任务进来后，Codex 先读规则，再看目录；需要时用关键词搜索和语义搜索找相关记忆；找到后回读 Markdown 原文；完成任务后判断是否值得沉淀；写入前先对账，避免重复和冲突；写入后通过 closeout 检查、刷新索引、写日志、Git 留痕；长期再用 audit 定期体检，保持记忆库干净。
第一步：任务输入
入口是用户的问题。
比如你说：
继续上次那个 EverOS 记忆系统分析。
这句话本身信息不完整，因为“上次”“EverOS”“记忆系统分析”都依赖历史上下文。
所以 Codex 会判断：这不是一次性问题，需要去查长期记忆。
这一步的作用是：识别当前任务是否需要调取记忆。
第二步：先读 AGENTS.md
Codex 会先读 \AGENTS.md\。
它不是普通笔记，而是整套记忆系统的规则文件。
它告诉 Codex：
- 什么时候该读记忆。
- 先读哪些入口。
- 哪些信息能写入。
- 哪些信息不能写入。
- 遇到删除、微信、凭证、隐私时必须问你。
- 任务结束前怎么做 closeout。
这一步的作用是：先确定操作的规则边界。
第三步：再读 INDEX.md
然后 Codex 读 \INDEX.md\。
\INDEX.md\ 是导航目录。它会告诉 Codex：
这个记忆库里有哪些重要文件，每类问题应该去哪找。
比如任务和 EverOS 有关，\INDEX.md\ 里会指向：
- \
项目/EverOS.md\ - \
项目/Codex记忆模板仓库.md\ - \
工作流/Codex记忆本地脚本.md\ - \
决策/2026-07-02-Codex记忆系统审计优化优先级.md\
这样 Codex 不用把整个 Obsidian 都读一遍，只需要挑最相关的 1-3 个文件。
这一步的作用是：用很低的 token 成本找到正确入口。
第四步：必要时进入统一检索
如果光看 \INDEX.md\ 不够，Codex 会用统一搜索。
统一搜索背后有几层：
\SQLite/FTS\
适合找明确关键词。比如文件里有 \scoped commit\，你也问了这个词，它就能很快搜到。
\Zvec\
适合按意思找。比如你没有说 \scoped commit\，而是说“只提交本轮记忆，不要提交整个 Obsidian”，Zvec 也能找到相关内容。
\rg\
只作为兜底。比如索引没更新、数据库异常、或者明确要全文扫文件时才用。
但是无论 SQLite 还是 Zvec 命中什么，Codex 都不能直接把搜索结果当事实。
它必须回到 Markdown 原文里确认。
这一步的作用是：先快速召回，再回读原文核验。
第五步：读取 Markdown 原始记忆
真正的事实源是 Obsidian Markdown。
比如 Codex 找到了：
/Users/yichen/obsidian/Codex记忆/项目/EverOS.md
它会读取里面的当前有效摘要、路径、状态、历史结论、下次优先看什么。
Markdown 文件承担的是“正式档案”的作用。
也就是说，搜索工具只是帮忙找到文件，真正可信的是文件本身。
这一步的作用是：让 Codex 基于可读、可审计的原文做判断。
第六步：执行当前任务
读完相关记忆后，Codex 才开始真正干活。
比如：
- 继续分析一个项目。
- 修改一个脚本。
- 写一份报告。
- 对比一个方案。
- 排查一个问题。
- 总结一套流程。
这时它不是从零开始，而是带着你的长期上下文工作。
它知道：
- 这个项目在哪里。
- 之前做到哪一步。
- 哪些结论已经验证过。
- 哪些东西过时了。
- 你的硬边界是什么。
- 什么事情必须问你。
这一步的作用是：让 Agent 变成“连续工作”，而不是每次失忆重来。
第七步：判断是否需要写入新记忆
任务做完后，Codex 不会把所有过程都写进记忆库。
它会判断：这次有没有长期价值？
值得写的包括：
- 新的稳定路径。
- 新的关键命令。
- 已验证的故障原因。
- 重要决策和原因。
- 以后会复用的流程。
- 你的长期偏好或明确边界。
- 未闭环事项。
不值得写的包括：
- 临时过程。
- 一次性聊天。
- 没验证的猜测。
- 大段原文复制。
- 情绪流水账。
- 凭证、Token、Cookie、密码。
这一步的作用是：防止记忆库变成垃圾堆。
第八步：写入前 reconcile
如果确实有东西值得写，Codex 要先做reconcile。
reconcile的意思是：
写之前先查旧记忆，看看是不是已经有类似内容。
然后只能做 6 种动作：
1.ADD
没有旧记录，新建一条。
2.UPDATE
已有合适文件，更新旧文件。
3.NOOP
没必要写，不写。
4.MARK_OUTDATED
旧信息过时了，标记为过时。
5.MERGE_REQUIRED
新旧内容重复或冲突，需要合并。
6.ASK_USER
涉及高风险内容，问用户是否允许执行。
比如 Codex 想写一条“记忆系统 closeout 规则”，它应该先找有没有已有的 \工作流/Codex记忆本地脚本.md\。如果有，就更新这个文件，而不是新建一个重复文件。
这一步的作用是：避免重复、冲突、乱写。
第九步：写入 Markdown 正式记忆
reconcile之后，信息才会进入正式目录。
不同信息进不同地方：
- 你的长期偏好进 \
用户记忆/\ - 项目状态进 \
项目/\ - 可复用流程进 \
工作流/\ - 重要取舍进 \
决策/\ - Agent 做事经验进 \
agent/\ - 未闭环事项进 \
agent/open-loops.md\
这一步的作用是：把经验沉淀到正确位置。
第十步：任务结束运行 closeout
写完记忆后，不算结束。
还要跑 closeout。
closeout 是统一收尾脚本，它会自动检查这次记忆改动有没有问题。
它会做：
- 找出本轮改过哪些记忆文件。
- 检查有没有疑似敏感信息。
- 检查文件是不是太长。
- 做写入后的重复检测。
- 刷新 SQLite 索引。
- 刷新 Zvec 语义索引。
- 写 closeout 日志。
- scoped commit，只提交本轮处理过的记忆文件。
这一步的作用是：把“写完记忆”变成一个完整、可检查、可追溯的闭环。
第十一步：Git 留痕
closeout 成功后，Git 会记录这次改动。
Git 的作用不是记忆本身，而是审计和保险。
它可以回答：
- 这次改了哪些记忆？
- 哪些内容是新增的？
- 哪些内容被改掉了？
- 如果写错了，能不能回滚？
- 本轮记忆是否已经清账？
这一步的作用是：让记忆系统不是黑盒，而是有修改历史。
第十二步：定期 audit 体检
除了每次任务后的 closeout，还有定期 audit——7天一次的Closeout触发和macOS兜底触发。
audit 负责看整个记忆库有没有慢慢变脏。
它会发现：
- 哪些记忆太久没验证。
- 哪些 open-loop 放太久。
- 哪些文件可能重复。
- 哪些状态已经 outdated。
- 哪些问题需要你裁决。
audit 不会自动删除正式记忆，而是把问题列出来，让你决定忽略、解决、推迟或继续保留。
这一步的作用是：长期维持记忆库健康。
记忆系统的优点
那这套记忆系统的运行规则就讲完啦，它的好处是显而易见的：
1.事实源可控
所有正式记忆都存在 Obsidian Markdown 里。
人能直接读、直接改、直接迁移，不被某个 AI 平台或向量数据库锁死。
2.检索能力完整
\INDEX.md\ 负责导航，SQLite/FTS 负责关键词搜索，Zvec 负责语义搜索。
你可以记得原词，也可以只记得大概意思，系统都能帮 Agent 找到相关记忆。
3.写入记忆前reconcile
新记忆不是随便写进去。
写入前会先检查旧记忆里有没有类似内容，再决定是新增、更新、跳过、标记过时、要求合并，还是问用户。
4.任务结束有Closeout收尾
closeout 会自动检查本轮变更、刷新索引、写日志、做查重兜底，并且只处理 \Codex记忆/\ 相关文件。
这让记忆沉淀从“靠模型自觉”变成“有固定流程”。
5.有Git版本记录和回滚能力
记忆库在 Git 管理下。
每次重要改动都可以看到 diff，写错了也能追溯和回滚。
6.有Audit自动体检机制
三层触发，定时清理需要被遗忘的无关记忆：
- closeout 时如果超过 7 天没体检，会顺手跑一次。
- macOS 每周一 10:30 自动兜底跑一次。
- Stop hook 发现太久没体检时会提醒。
体检结果会写入固定报告，不会直接改正式记忆。
7.自动化克制，不越权
系统会自动搜索、检查、提醒、生成报告，但不会自动删除文件、不会自动修改敏感事实、不会自动操作高风险内容。涉及微信、删除、账号凭证、隐私、费用等，必须人工确认。
8.能让 Agent 自我进化
不是所有经验都直接变成 skill。系统会先沉淀为 case candidate，经过验证后再进入正式 case，最后才可能变成候选 skill。这让 Agent 的能力增长是有门槛、有审计的。
最后，我把这套记忆系统封装成了一个Skill：https://github.com/mcncarl/codex-memory
大家可以接入Codex尽情使用，也可以在我的基础上继续优化迭代最适合你自己的～☺️
