yena shared this post · 4h ago
逸尘

人人都可以搞懂并且一键配置的Codex记忆系统!(小白理解友好)

Fable5王者归来,我这个Codex元老用户也没忍住去试了一下,看下它到底有没有吹的那么牛,能不能干掉Codex——让它把Codex优化到极致的记忆系统继续迭代。然后我就往Zenmux里面充了十刀,把Fable5接到Claude Code里面试了一下——省流版答案:Fable5就是Codex“超高”智能的爸爸!!!(文末附记忆系统Skill)
关于我之前的半成品记忆系统:

Fable5确实贵,所以我听从了Timeline上面大佬们的建议,就让Fable5参与了给Codex记忆系统提意见、做规划的环节——
不问不知道,一问吓一跳,第一次检测用“第一性原理”就给我找出了一大堆Bug和优化空间。。。它的技术专业度不用质疑,因为Codex自己承认了。。。但是能从报告里面看出来,Fable5给的建议还是有不严谨的地方,确实是,但是4:1,Fable5完胜。
https://pbs.twimg.com/media/HMOKi4YaYAAt0IG.jpg
https://pbs.twimg.com/media/HMOKf2ubAAA5v8R.jpg
这才是第一步,Fable5牛逼的能力才刚刚显露,我让Codex整理了一份开发计划,我又把它发给了Fable5审核:
依旧质疑。。。然后Codex依旧同意。。。
https://pbs.twimg.com/media/HMOKc3AbIAAFZWe.jpg
我就让Codex又按照Fable5的建议,优化了一下,我想这下总没问题了吧,发给了Fable。
https://pbs.twimg.com/media/HMOKZ30bMAA0uFS.jpg
最后Fable竟然还能找出这么多问题,我真的服了。。。赶紧让Codex来认认它最严厉的父亲。
https://pbs.twimg.com/media/HMOKW3jagAAyGGb.jpg
开发完成后,Fable5依旧智商在线,检查代码嘎嘎乱杀。
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 commitcloseoutgit 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 定期体检,保持记忆库干净。
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 不会自动删除正式记忆,而是把问题列出来,让你决定忽略、解决、推迟或继续保留。
    这一步的作用是:长期维持记忆库健康。

记忆系统的优点

那这套记忆系统的运行规则就讲完啦,它的好处是显而易见的:
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尽情使用,也可以在我的基础上继续优化迭代最适合你自己的~☺️
322