# 人人都可以搞懂并且一键配置的Codex记忆系统！（小白理解友好）
Canonical: https://social-archive.org/yena/eRviQUrfM2
Original URL: https://x.com/gengdaJ/status/2072679139098964179
Author: 逸尘
Platform: x
## Content
Fable5王者归来，我这个Codex元老用户也没忍住去试了一下，看下它到底有没有吹的那么牛，能不能干掉Codex——让它把Codex优化到极致的记忆系统继续迭代。然后我就往Zenmux里面充了十刀，把Fable5接到Claude Code里面试了一下——省流版答案：Fable5就是Codex“超高”智能的爸爸！！！（文末附记忆系统Skill） 关于我之前的半成品记忆系统： Fable5确实贵，所以我听从了Timeline上面大佬们的建议，就让Fable5参与了给Codex记忆系统提意见、做规划的环节—— 不问不知道，一问吓一跳，第一次检测用“第一性原理”就给我找出了一大堆Bug和优化空间。。。它的技术专业度不用质疑，因为Codex自己承认了。。。但是能从报告里面看出来，Fable5给的建议还是有不严谨的地方，确实是，但是4:1，Fable5完胜。 ![image](https://pbs.twimg.com/media/HMOKi4YaYAAt0IG.jpg) ![image](https://pbs.twimg.com/media/HMOKf2ubAAA5v8R.jpg) 这才是第一步，Fable5牛逼的能力才刚刚显露，我让Codex整理了一份开发计划，我又把它发给了Fable5审核： 依旧质疑。。。然后Codex依旧同意。。。 ![image](https://pbs.twimg.com/media/HMOKc3AbIAAFZWe.jpg) 我就让Codex又按照Fable5的建议，优化了一下，我想这下总没问题了吧，发给了Fable。 ![image](https://pbs.twimg.com/media/HMOKZ30bMAA0uFS.jpg) 最后Fable竟然还能找出这么多问题，我真的服了。。。赶紧让Codex来认认它最严厉的父亲。 ![image](https://pbs.twimg.com/media/HMOKW3jagAAyGGb.jpg) 开发完成后，Fable5依旧智商在线，检查代码嘎嘎乱杀。 ![image](https://pbs.twimg.com/media/HMOKT4Xa0AA898f.jpg) 经过这个测试，不得不佩服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 定期体检，保持记忆库干净。 ![image](https://pbs.twimg.com/media/HMOKQ5MaoAAlUoy.jpg) 第一步：任务输入 入口是用户的问题。 比如你说： > 继续上次那个 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 不会自动删除正式记忆，而是把问题列出来，让你决定忽略、解决、推迟或继续保留。 这一步的作用是：长期维持记忆库健康。 ## 记忆系统的优点 那这套记忆系统的运行规则就讲完啦，它的好处是显而易见的： ![image](https://pbs.twimg.com/media/HMOKN24boAAetWp.jpg) 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尽情使用，也可以在我的基础上继续优化迭代最适合你自己的～[☺️](https://abs.twimg.com/emoji/v2/svg/263a.svg)
