1. Codex 的一次性记忆困局每次都要重新自我介绍的痛先说一个我自己的真实感受。Codex 这个工具单次对话内的表现确实能打——给它一个清晰的任务描述它能理解上下文能照着项目里已有的代码风格往下写甚至能一个文件接一个文件地改。但只要你把终端窗口一关或者新开一个会话它立刻就变回那个什么都不懂的“新人”。你昨天刚告诉过它的技术栈、目录结构、命名规范、已经踩过的坑全部清零。这个痛点用过的朋友应该都能秒懂。你把一个老项目的背景交代清楚可能得花十多分钟写一大段 system prompt 级别的背景说明而真正让它干活的时间可能还没交代背景花的时间多。遇到稍微复杂一点的需求还得中途停下来说“不对我之前说过这个模块用的是 xx 方案别用 yy”。Codex 本身没有跨会话记忆这是它的架构特点不是 bug但确实成了实际使用中最大的效率瓶颈。OpenViking 就是冲着这个痛点来的。它的核心定位一句话就能说清楚给 Codex 加上一套长期记忆系统让 Agent 在新会话里也能记得住项目上下文、历史决策和个人偏好。项目的名字也起得挺有意思——Viking 有“探索者”的味道Open 则是开源和开放的意思大致上就是想做一个开放、通用的记忆层而不是绑定某个特定模型或特定工具。这篇文章我会从四个方面展开Codex 的失忆机制到底是怎么回事OpenViking 的记忆分层和工作流程是怎么设计的我实际部署和用它跑项目的完整过程以及在集成过程中踩到的一堆坑和对应的排查思路。同时最后会聊一聊 Agent 记忆体系中短期、中期、长期、永久记忆到底该怎么分工——这个问题我觉得比单个工具本身更有价值。文章适合正在用 Codex、被重复交代背景折磨得不行的朋友也适合那些想在业务里给 AI 编程工具加记忆能力的团队参考。2. 失忆的根源会话机制、上下文窗口与“假的长期记忆”2.1 为什么 Codex 不同会话之间“什么也不记得”要理解 OpenViking 在解决什么问题得先搞明白 Codex 为什么失忆。核心原因其实有三个而且这三个原因是叠加的。第一Codex 的会话默认是隔离的。以我常用的 Codex CLI 为例每一次对话开始它都会创建一份独立的会话上下文。所谓“独立上下文”的意思是模型只能看到当前会话里的消息历史、读取过的文件、工具返回的结果其他会话的内容它根本接触不到。这就像是两个互不相通的聊天窗你在 A 窗口里灌了多少背景信息B 窗口是一点都感知不到的。第二上下文窗口有物理上限。即使你通过某种方式能把历史都塞进同一个会话token 总额也是有限的。模型不可能无限地记住所有对话内容和文件内容。一旦超过窗口容量早期的信息要么被截断要么被系统压缩而压缩本身就是一种损耗——信息还在但细节没了。这就决定了一个很尴尬的处境你想让它“记住”的东西越多它反而越容易丢失对当前任务真正重要的细节。第三也是很多人容易忽略的一点大多数人给 Codex 配的所谓“长期记忆”其实只是把项目说明写进了AGENTS.md之类的文件里。这种方式确实有点用但它本质上是一种静态记忆——你写什么它就记什么项目运行过程中产生的新决策、新约定、新结构它不会自动沉淀进去。你改了一版接口设计但如果忘了更新AGENTS.md那这个文件记录的就是过期的信息。静态记忆没法随着项目的演化自动更新这是它最大的局限。2.2 真正缺的不是模型能力而是记忆层我在实际使用中有一个很强烈的体会当 Codex 失去上下文时它的表现会断崖式下降但这并不代表模型变笨了而是因为信息不足。拿我维护的一个中型项目来说项目里十几个模块每个模块有自己的约定和依赖关系。我如果花十五分钟把背景写清楚Codex 的代码质量是可以接受的但如果省掉这一步直接扔任务给它它就会凭着通用知识去猜测架构猜错的概率非常高生成出来的代码往往要推翻重写。换句话说模型的能力是够用的缺的是“它能记住的东西”。OpenViking 做的事情是把这个缺失的记忆层补上——把历史会话里的关键信息抽取、压缩、结构化、持久化然后在下次会话需要时再按需召回。听起来不复杂但落地上有几个麻烦要解决什么东西值得存存下来之后怎么在需要的时候找回来怎么防止记忆库越滚越大、最终淹没真正有用的信息这些问题我会在下一节详细展开。2.3 一个真实的成本测算反复交代背景有多亏这里我算一笔账大家感受一下这个问题的实际成本。我做过一次小实验用一个老项目做同一个需求分两种情况。第一种情况新开会话不提供任何背景直接让它完成任务第二种情况会话开始前使用 OpenViking 自动注入了项目记忆和历史决策记录。结果很直观——第一种方式下Codex 产生的“修复性问答”特别多它会反复问一些已经在项目文档里写过的基础问题给出的方案有三处明显偏离项目既有架构而第二种方式下它第一次给出的方案方向基本正确后续修改量小很多。如果你每天要开十几个会话每个会话都节约五到十分钟的“背景同步时间”一天下来节省的时间是相当可观的。这个数字在实践中其实就是效率差距的本质。3. OpenViking 的记忆分层会话、项目、跨项目三层存储3.1 为什么记忆必须分层而不是一个大筐OpenViking 在我实际使用中印象最深的是它的分层设计。它没有把所有的历史消息一锅端地塞进同一个存储而是分成了三层会话级记忆、项目级记忆、跨项目级记忆。为什么要这样分举个生活中类比人的记忆也不是录音机不是把所有经历原封不动地回放而是分成了“今天中午吃了什么”这种短期记忆、“我家住哪条街”这种中期记忆和“我一直不喜欢香菜”这种长期偏好。不同层级的记忆更新频率不同、需要长期保留的程度也不同如果混在一起检索会非常混乱。3.2 三层记忆的存储对象与生命周期会话级记忆对应的是单次会话内的上下文。它记录的是“这个任务做到哪一步了、改了哪个文件、下一步打算做什么”。这一层的信息变化最快通常任务结束就可以丢弃只留下有价值的摘要沉淀到上层。项目级记忆是核心。它记录的是某个项目专属的知识技术栈选型、目录结构、模块职责、编码规范、历史决策和踩坑记录。比如“这个项目的 API 请求统一走client.ts不要直接 fetch”“支付模块上周重构过现在入口在modules/payment/index.ts”——这类信息就是项目级记忆。OpenViking 写入项目记忆时并不只是把对话原文原样存档而是经过抽取和压缩以结构化条目存储这样后续检索才高效。跨项目级记忆可以用来存跟具体项目无关、但跟你的工作习惯相关的东西。比如你写 Python 时偏好类型注解和 dataclass写前端时习惯用 CSS 变量而不是随机颜色值提交信息偏好 conventional commits 格式……这些偏好会作用于你所有项目。这一层的记忆OpenViking 默认是全局生效的在你使用它处理任何项目时都会参与召回。我在使用中观察到分层带来的最大好处是检索精度明显提高当我在 A 项目里工作时召回的主要是 A 项目的记忆不会被 B 项目的无关内容干扰。这一点在后面讲多项目并行实测时还会再展开。3.3 存储格式结构化条目比原文存档可靠关于存储格式OpneViking 的做法值得单独说一下。它没有把对话历史当成纯文本日志存而是把每一次需要沉淀的信息转换成了结构化条目。每个条目至少包含这几个字段内容摘要、涉及的代码路径、关联的决策上下文、录入时间、过期时间有些条目有、来源会话 ID。这样的好处有两点。第一召回时可以快速做相关性过滤不需要整篇扫描第二条目可以独立更新和删除——如果某个决策后来被推翻了可以单独标记这个条目失效而不是去一篇文章里找段落来改。我在另一个工具里体验过“整个会话存档”的方式时间一长检索效率下降得非常快因为里面大量信息是重复的、过期的、无关的。结构化条目的方式实际上是在存储之前就做了信息降噪。3.4 Auto-Save、Compaction 与 Retrieve三段式工作流OpenViking 的核心工作流可以拆成三个阶段理解了这个流程你就理解了它整套系统的运转方式。第一个阶段是 Auto-Save自动写入。在会话进行过程中OpenViking 会持续监控对话内容和代码变更结果当它判断出一些信息值得沉淀时——比如用户明确说了一个约定、模型给出了一个关键决策、某个文件结构发生了重要变化——就会自动生成记忆条目并写入对应层级的存储。这个过程不需要用户手动触发这也是叫 Auto-Save 的原因。第二个阶段是 Compaction压缩与合并。记忆条目太多之后OpenViking 会定期执行压缩把多个重复主题的条目合并成一条精炼的总结把长期没被命中的内容降级或过期。这个过程我用下来最直观的感受是记忆库不会无限膨胀过几个星期去查看条目数量依然维持在可控范围内检索响应速度也一直稳定。第三个阶段是 Retrieve按需召回。当你开启一个新会话时OpenViking 会根据当前项目路径、会话目标、最近的交互记录从记忆库中召回最相关的一批条目注入到 Codex 的上下文中。召回并不是越多越好——它更像是帮你“提词”把那几条最关键的约定放到模型眼前。我观察过它注入的内容通常控制在几十行以内不影响 Codex 的注意力分配。4. 把 OpenViking 接到 Codex CLI从零到能用的完整配置4.1 安装与环境准备我先说明一个原则OpenViking 本身是独立运行的服务/CLI它需要通过配置接入 Codex而不是作为一个 Codex 内置插件直接被启用。以我使用的版本为例安装分三步拉取仓库、安装依赖、初始化配置。git clone https://github.com/your-user/openviking.git cd openviking npm install npm run build ./bin/openviking init这里openviking init会在你的用户目录下生成一个配置文件我这里是~/.openviking/config.json里面主要是一些基础设置记忆库的存放位置、监听端口、以及和 OpenAI 平台对接用的认证信息。有一点要特别提醒如果你本机同时使用了 CC Switch 这类本地代理工具用于统一管理和切换不同的 API 端点配置务必先想清楚 OpenViking 和代理工具的启动顺序。因为 OpenViking 在 Agent 的背后充当了一个中间层如果它先启动并把 Codex 的端点接管了而后启动的 CC Switch 又想把 Codex 流量导到它配置的代理地址上两者就会冲突。这个我在后面第五节的报错排查里会详细讲这里先记住结论优先让 OpenViking 作为离 Codex 最近的本地服务代理工具的端点和模型路由放在 OpenViking 之下。4.2 在 Codex 配置中启用记忆提供方Codex CLI 的配置一般通过~/.codex/config.toml来管理。OpenViking 接入的关键就是在这个配置文件里告诉 Codex有一个记忆提供方存在并且它的本地地址是什么。# ~/.codex/config.toml model gpt-5-codex [memory] provider openviking endpoint http://127.0.0.1:9519 enabled true auto_save true max_inject_tokens 2048解释一下这几个参数的含义provider指定使用的记忆提供方这里填 OpenVikingendpoint是 OpenViking 本地服务的监听地址。端口号不一定非得是 9519以你init时看到的信息为准auto_save开启后会话中的关键信息会自动写入记忆库不需要手动调用命令max_inject_tokens控制每次新会话时最多注入多少 token 的记忆内容。这个值我建议不要设得太大否则会挤占 Codex 处理当前任务的有效上下文。我实际使用下来的经验是 1500 到 3000 之间比较合适。配置完成后启动 OpenViking 的服务进程然后正常启动 Codex CLI就能在启动日志里看到类似memory provider connected之类的内容。4.3 验证记忆是否真的写入并生效工具接好之后最怕的就是“看起来能用实际没用”。所以我有几个固定的验证步骤分享给大家。第一步在任意一个项目目录下和 Codex 进行一段包含明确约定的对话。比如直接说“以后这个项目的所有日期处理统一用 dayjs不要用 moment”。让模型正常回应然后结束会话。第二步查看记忆库里是否已经出现对应的条目。OpenViking 一般会提供一个查看命令./bin/openviking memory list --project .如果实现正常你应该能看到刚才那句约定的结构化摘要——注意不是原文而是一条类似“日期处理统一使用 dayjs避免使用 moment”的记录并标注了来源会话。第三步重新开启一个 Codex 会话然后在对话里问模型一句“我们这个项目里日期处理用什么”。如果配置正常Codex 应该能直接答出来而不是说“我不确定让我看看”更不会说“你可以用 moment”。如果它能直接说对答案就说明记忆注入链路真的通了。4.4 与 CC Switch 等代理配置工具的叠加现在很多人在本机同时使用 CC Switch 来管理多个 API 端点配置实现不同工具之间的端点切换。这时 OpenViking 和 CC Switch 的关系要理清楚CC Switch 管的是“流量从哪里进来、路由到哪个 API 端点”OpenViking 管的是“上下文里有没有历史记忆”。两者不冲突但在实际配置时有一个很容易翻车的地方。如果你用的是 CC Switch 提供的本地代理地址来跑 Codex那么 Codex 的config.toml里除了[memory]之外通常还会设置类似[provider] base_url http://127.0.0.1:9877这个端口是 CC Switch 的本地代理端口。它和 OpenViking 的9519端口是两码事。OpenViking 处理的是记忆注入CC Switch 处理的是请求转发。我在一次配置时因为把两个端口搞混导致 500 报错后来查了 20 分钟才发现是端点写错了。借这个例子提醒大家在文件里标注好每个端口的用途会省很多事。4.5 多会话的持久化进程管理还有一个细节容易被忽略OpenViking 服务是需要常驻的。如果每次用 Codex 都手动启动它、用完再手动关掉那记忆写入链路必须等它启动之后才会生效而且如果服务提前挂了Codex 会退化回没有记忆的普通模式不过一般不会连累 Codex 主体功能这点设计得比较安全。为了省心我建议把它注册成本机的后台服务开机自启或者通过进程守护工具让它始终存活。但要注意如果它常驻在后台当你需要重新加载配置时记得重启它否则新改的配置不会生效。5. 实测对比有记忆和没记忆的 Codex工作方式完全不一样5.1 跨会话维护老项目不用再重复交代背景了我实际用 OpenViking 跑了差不多一个月感受最深的是维护老项目时“重新交代背景”的频率大幅下降。举一个具体的例子我手上的这个项目结构比较乱历史包袱重很多模块之间有一种“约定俗成”的调用关系光靠代码注释根本看不出来。以前每开一个新会话我都要在第一个消息里手写一大段背景说明甚至要把几个关键文件路径贴进去。接入 OpenViking 之后这个情况明显变了。因为前几个会话里我已经通过对话让 Codex 了解了项目里各个模块的职责和依赖而这些内容被自动写进了项目级记忆。现在新开会话直接说需求它自己就清楚模块之间的边界在哪不会再出现“把属于 A 模块的逻辑写进 B 模块”这类基础错误。不过这里也要说实话它并不是万能的。项目记忆的准确度取决于你之前交代内容的清晰程度。如果你第一次跟它描述项目背景时自己都很含糊那沉淀下来的条目质量也不会高。所以我的经验是第一次使用 OpenViking 时有意识地用比较清晰的语言描述项目背景等于是在“教”记忆库怎么为这个项目建档。5.2 多项目并行上下文隔离比想象中重要OpenViking 的分层记忆在多个项目之间切换时优势特别突出。我日常会同时推进两三个项目一个偏后端的 Python 项目一个偏前端的 TypeScript 项目。在以前如果我在两个项目里各开一个 Codex 会话偶尔会串味——因为它把当前目录当作上下文的一部分有时候我切到另一个项目时Codex 还会下意识沿用上一会话里的一些习惯性表达或者命名风格。有了 OpenViking 之后项目级记忆是按项目目录自动隔离的。在 A 项目目录下启动的 Codex只会召回 A 项目的记忆在 B 项目目录下启动的就只召回 B 项目的。这个设计非常关键——如果所有项目的记忆混在一个库里那检索时就要额外判断“这条信息属于哪个项目”多一层逻辑就多一分混乱。OpenViking 直接在存储层做了物理隔离用起来几乎不用操心串味的事。5.3 记忆库的积累速度与检索质量的演变使用时间拉长之后我又发现一个新的问题记忆库是会成长的。第一周项目记忆里可能只有几十个条目每个都是精华到第三周条目数量会明显变多里面有一些其实不太常用的边缘信息。好在 Compaction 机制会定期合并和清理整体检索质量还算稳定。我自己的体会是如果你的项目本身持续在演进可以每隔一两周手动清理一次明显过期的条目比如标记为废弃的接口、已删除的模块等。OpenViking 提供了手动管理命令查一下文档就能用。5.4 对 Codex 响应速度的影响还有一个很多人关心的问题加了记忆层之后Codex 的响应速度会不会变慢我实测下来的结论是有可感知的轻微延迟但完全在可接受范围内。每次新会话开始时OpenViking 需要做一次召回、注入大概会比原来的第一次响应多个一两秒。后续对话基本没有额外影响。这个代价换来的收益——不用重复交代背景、不用纠正基础错误——我认为完全值得。6. 集成踩坑实录四个高频报错与完整排查链路6.1 报错一cc switch local proxy failed while handling codex endpoint /responses这个报错从字面上看是 CC Switch 的本地代理在转发 codex endpoint 的/responses请求时抛了异常。第一次遇到时我以为是 OpenViking 的问题后来排查了一圈才发现问题出在端点路由的叠加顺序上。具体现象是启动 OpenViking 后Codex 会话正常建立但发送第一条消息时直接报这个错。排查过程我按这个顺序走第一步确认 OpenViking 自己是否正常工作。单独访问它的本地端点看它能不能正常返回健康状态。平时正常的话问题大概率不出在这里。第二步确认 Codex 实际上是在和谁通信。Codex 的请求要先经过 OpenViking 的记忆中间层然后才转发到 API 端点。但如果你在 CC Switch 里也配置了 Codex 的代理并且 CC Switch 的代理端口和 OpenViking 注入后的转发地址混在一起就会出现这个转发失败的错。第三步也是最终解决的关键明确流量路径。我的最终配置是Codex 的base_url指向 CC Switch 的本地代理端口而 CC Switch 负责把流量进一步转发到上游 API。OpenViking 不该截胡这层代理关系它只负责记忆注入。如果你把 OpenViking 的地址写成了 Codex 的base_url就会导致请求先到 OpenViking但 OpenViking 又不做端点转发最终抛错。检查config.toml里的[provider] base_url到底填了谁就能定位问题。6.2 报错二codex auth token is unavailable这个报错出现的场景也不少尤其在刚配置完 OpenViking、第一次启动 Codex 时。它的含义很简单Codex 在启动时找不到可用的认证 token。为什么接 OpenViking 会遇到它因为我这边为了让 Codex 能正常使用认证信息并没有直接写在环境变量里而是由 CC Switch 之类的工具统一管理。而 OpenViking 作为中间层启动时如果它尝试去读取认证 token 却没有拿到就会把这个状态传递给 Codex。排查链路也很清晰。首先确认你的认证信息是不是放在 CC Switch 等工具里、并且该工具是否已经启动。如果工具没启动Codex 自然拿不到 token。其次如果你用的是 API key 方式检查环境变量是否在当前终端会话生效。注意终端改环境变量后需要重新打开终端或者source一下否则新起的进程依旧读不到。最后如果以上都正常再看 OpenViking 的配置里有没有设置独立的认证字段——在有些版本里OpenViking 允许你显式配置 token让 Codex 通过它来认证。把这里的 token 配好报错会消失。6.3 报错三the gpt-5.6-sol model is not supported when using codex with a chatgpt account这个报错我见到很多人在论坛里问。翻译过来就是当你用 ChatGPT 账号登录 Codex 时选用的gpt-5.6-sol模型在当前账号类型下不被支持。很多人的第一反应是去搜“怎么绕过支持限制”但我必须强调不要去碰任何绕过账号限制的操作正路是回到模型本身。检查你的config.toml里model字段的值换成当前账号可用的模型。比如官方支持的 Codex 模型或者你通过第三方 API 接入、且已在端点那边配置好的模型。我遇到过的情况是之前用某个 API 端点的模型名称切了端点之后忘了同步更新模型名于是报错。把模型名改为当前端点实际提供的名称问题就解决了。6.4 报错四codex is ignoring 1 unrecognized configuration setting最后这个不是致命错误但很烦——Codex 会提示“你的配置里有一个没被识别的字段我已经忽略了”。出现这个提示通常有两类原因。第一类是拼写错误。比如把max_inject_tokens拼成了max_inject_token。这一类比较容易发现对照文档逐字核对即可。第二类是配置字段在当前版本里还不存在。OpenViking 和 Codex 都在快速迭代某些新配置字段如果 Codex 侧还没来得及适配就会被当作未知字段忽略。处理方式分两种如果这个字段对你不重要直接删除它如果很重要则更新 Codex 和 OpenViking 到最新版本再看是否支持。我的习惯是更新后重启相关服务再确认提示是否消失。把我踩过的这些坑总结成一句话集成第三方工具时报错信息只是信号关键要看请求在各层之间的实际走向。搞明白谁在跟谁通信、认证信息在哪一层被消费、模型名属于哪个端点排错就不难。7. 从 OpenViking 反推 Agent 记忆体系的工程化设计7.1 短期、中期、长期、永久四层记忆的分工原则写到这里我想把话题从 OpenViking 本身稍微拉远一点聊聊 Agent 记忆体系的通用设计。这阵子“记忆”是 AI 编程工具领域非常热的话题各家常说的短期、中期、长期、永久记忆本质上对应的是不同的信息生命周期。OpeViking 的三层结构对应的是会话级、项目级、跨项目级再加一个永久级的话就更好理解了。可以这样对应短期记忆就是当前会话里正在讨论的内容随会话结束而终结中期记忆对应单个项目生命周期等于项目的存续期长期记忆对应你个人的偏好和规范跨项目长期有效永久记忆则是一些几乎不变的基础事实比如你的名字、你所在的时区、你一贯使用的提交格式等。这些内容不能频繁变迁而且任何项目里都应该稳定生效。之所以要分这么细是因为每层记忆的处理策略完全不同。短期记忆需要高保真、低延迟中期记忆需要定期压缩和去重长期记忆需要严格防止污染永久记忆则需要极高的准确性和极低的更新频率。如果只有一个大而全的存储这些不同需求就会被搅在一起哪一层都做不好。7.2 记忆写入的关键不是全存而是摘要 索引我在看 OpenViking 的处理方式时收获最大的一个思路是写入记忆不等于保存原始对话。相反它做的是“摘要 索引”的工作。具体来说它会从对话中识别出“值得记住”的信息片段将其提炼成简洁的条目同时记录这些条目的来源、关联代码路径和上下文标记。这种做法背后是一个很朴素的道理模型用的上下文窗口是有限的记忆系统如果往里塞整段原文那不是在帮它记忆而是在给它制造新的噪音。就像你写工作笔记不会把会上每个人的每句话都记下来而是记决议、记待办、记关键结论。OpenViking 的自动摘要实际上就是在扮演“好秘书”的角色。7.3 记忆召回的关键场景命中 上下文压缩召回侧也有讲究。我在使用中观察到OpenViking 并不是把每一条记忆都一股脑传给 Codex而是先做一个相关性筛选再按重要程度排序最后把命中内容压缩成一个精炼的记忆提示块。这个提示块会被注入到系统提示词和用户消息之间让模型在阅读项目文件前就已经具备了项目历史背景。为什么要压缩因为模型不会因为“记忆条数多”就理解得更深反而可能因为信息杂乱而抓不住重点。更好的做法是让它在合适的节点获得最相关的少量信息其余信息在需要时再通过检索补充。这个“按需取用”的设计思路实际上是所有 Agent 记忆系统都应该遵循的底线。7.4 记忆的过期与遗忘不是所有东西都该永远保留最后聊一个很多人不重视、但实际很重要的点记忆的遗忘机制。我一开始用 OpenViking 时以为记忆越多越好后来发现并不是。项目里有些决策是临时的比如“这周先临时把缓存关了排障”有些约定很快就过时了比如“当前这个接口还没定稿先按草案对接”。这些信息如果一直留在记忆库里会因为失去时效性而误导模型。好的记忆系统必须配备过期策略。OpenViking 的 Compaction 机制会自动合并同类条目也会把长期没被命中的内容降级或清除。如果你的项目使用频率很高、变化很快某种记忆可能在几周内就不再适用需要及时清理。手动清理也是健康的习惯——我会隔段时间主动去翻一次记忆库删掉那些明显已经失效的记录。别舍不得删遗忘本来就是记忆的一部分。8. 最后分享一点我的使用建议按惯例不做总结只分享几个我这几周用下来觉得最值得记下来的实操建议。第一第一次接入 OpenViking 时别急着让它“记住”一切先带它过一遍项目的核心架构。你可以在前两三个会话里有意识地描述清楚技术栈、目录约定、关键决策这些内容会成为项目记忆库的地基。地基打得越稳后续召回的条目质量越高。第二定期查看记忆库做个“编辑”而不是单纯依赖 Auto-Save。自动写入虽然方便但它只能记录“发生过的事”无法判断“这事应不应该被记住”。手动编辑的价值在于删掉过期内容、修正有歧义的表述我大概每隔一到两周顺手做一次。第三如果你和我一样同时用多套 API 端点配置动手改配置之前先画一下请求链路Codex 请求先到哪、再经哪、最终往哪转发。这几个地址分别写在哪些配置文件的哪个字段里。想清楚再改能省掉大量排错时间——这也是我在第六节课里踩了半天坑之后最重要的心得。OpenViking 不算是一个大而全的平台它更像是一个把“记忆”这个问题认真拆解并落地的小工具。如果你也和我一样被 Codex 的失忆问题困扰了很久不妨给它一次机会。配置好之后那种“新会话第一节就懂全项目背景”的体验确实值得一试。