之前遇到过类似场景, 看看人家怎么做的. 下面是 codex GPT-5.4 high 写的.
仓库:
论文:
之前遇到过类似场景, 看看人家怎么做的. 下面是 codex GPT-5.4 high 写的.
仓库:
论文:
Written by Codex with GPT-5.4 high
这版 Codex 的 memory, 如果只看 high level, 可以理解成一句话:
它不是“边聊边顺手记一些长期记忆”, 而是“先把旧会话离线蒸馏成 memory 仓库, 再在新会话里按需检索这个仓库”.
这点和 Claude Code 那种“session memory / auto memory”观感不太一样.
Codex 这套东西, 我会拆成 4 个关键词:
读: 当前对话开始时, 把一个很短的 memory_summary.md 注入 prompt, 让模型知道该去哪里找旧经验召回: 真需要时, 先查 MEMORY.md, 再按需深入 skills/ 和 rollout_summaries/写: 后台异步跑两阶段 pipeline, 从历史 rollout 提炼 raw_memory, 再 consolidate 成正式 memory遗忘/降权: 通过 usage、diff、polluted 标记, 把不可靠或过时的记忆慢慢挤出去所以它更像一个小型知识蒸馏系统, 而不是单纯的“长期笔记本”.
读下来感觉尬吹 Hermes. 其实作者讲的 memory 的点 Claude Code 早就做到了. 作者对 CC memory 的逆向工程是去年做的, 不是基于泄露的代码.
关于 AI 产品是否需要推出记忆功能的决策点可以参考.
小功能 away recap, prompt suggestion, insights.
去年排查过一个性能问题. 一个包含很多正则替换的函数, 在处理几十万字符长度的文本时, 跑了 10 秒才完成. 最后定位到问题正则形式如下:
\s*xyz blahblah
几年前排查过 灾难性回溯 问题, 但这个正则的结构其实完全没有相关特征. 如果真的是灾难性回溯, 处理几十万字符的字符串早就卡死了, 而不是只跑 10 秒.
最后解决方案是先用
xyz blahblah
找 match, 再处理 leading spaces. 时延是毫秒内.
源于一个比喻, 模型是 horse, 人是 rider, 中间那层是 harness. 从字面来看 harness 是指为确保模型按预期行为运行而构建的约束框架与支撑体系. 至少可以从两个角度理解.
随着模型能力变化, harness 也需要改变, 如 Harness design for long-running application development.