1. Codex 越用越慢的真实场景从 MEMORY.md 膨胀说起Codex 用久了变慢很多人第一反应是模型波动或者网络问题。我一开始也这么想直到发现一个更隐蔽的原因本地记忆文件在悄悄膨胀。Codex 这类 Coding Agent 会把长期偏好、工作区规则、历史任务摘要写进MEMORY.md和memory_summary.md每次新会话默认加载。文件越大默认塞进上下文的内容越多模型判断越容易跑偏。具体表现很难用单个 Bug 解释任务还没开始先重复一大段旧规则已完成的项目被当成当前背景仓库已经升级回答里还引用旧提交号简单要求需要多次确认长任务越来越容易跑偏。这些现象叠加在一起体感就是越用越慢、越用越啰嗦。我实测下来当时MEMORY.md已经到 1,875 行、201,111 字节包含 40 组历史任务整个记忆目录约 2.0 MB。清理后主文件剩 150 行、8,698 字节按字节减少 95.7%摘要从 99 行降到 60 行目录降到 976 KB对话和 62 份任务回放摘要全部保留。这篇复盘聚焦一件事怎么把每轮默认加载的知识和需要时再查的历史证据分开。排查顺序是先做只读盘点再识别膨胀来源然后建立分层目录、备份重写、逐项确认清理对象、同步摘要、用 Git 验收最后用真实任务测量效果。适合长期使用 Codex 或类似 Coding Agent、感觉响应变慢的开发者跟做。2. TaoToken 前置准备把 settings 改到 TaoToken 的完整配置在动手清理记忆之前先把模型接入层固定下来否则你无法判断变慢是记忆膨胀还是接入配置问题。我用的方案是把 Codex 的 settings 指向 TaoTokenBase URL、Key、Model ID 三件套一次配齐后续排查才有稳定基线。TaoToken 官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。你需要先去控制台生成 API Key地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite Key 管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 遇到字段不确定时对照文档最稳。Codex 的配置通常落在~/.codex/config.toml或项目级 settings 里。下面是一份可复制的 TOML 片段路径和字段按你本地实际文件调整# ~/.codex/config.toml model claude-sonnet-4-5 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat对应的环境变量在 shell 里导出不要写进仓库export TAOTOKEN_API_KEYsk-你的Key如果你用的是 Claude Code 或 Cline 这类工具配置思路一致Base URL 填https://taotoken.net/apiKey 填控制台生成的密钥Model ID 填你实际要用的模型名。三件套缺一不可只填 Base URL 不填 Model ID 是最常见的半配置状态表现为请求能发出但返回异常。配好之后先别急着清理记忆跑一个最小请求确认接入层是通的。这一步的意义是把变量隔离如果接入层本身有问题后面所有变慢的观察都不可信。3. 可复制配置与排查脚本只读盘点加分层目录接入层固定后进入记忆排查。第一步是只读盘点不要拿到目录就递归删除。先确认主文件、摘要、日志、更新单和回放分别占多少空间set -euo pipefail MEM_DIR$HOME/.codex/memories wc -l -c $MEM_DIR/MEMORY.md $MEM_DIR/memory_summary.md du -sh $MEM_DIR find $MEM_DIR -maxdepth 3 -type f -print | sort如果目录由 Git 管理再补两条git -C $MEM_DIR status --short git -C $MEM_DIR log -5 --oneline这一步要回答三个问题哪些文件会默认进入新会话哪些只是按需证据目录里是否已有未提交修改。第三点很重要你自己的改动不能被清理脚本覆盖。识别膨胀来源时重点看四类内容重复规则同一约束同时写在摘要、主记忆和工作区说明中、陈旧动态事实提交号、版本号、当前部署、临时地址、任务流水账某天做了什么、跑了哪些命令、冲突结论旧技术栈与新技术栈都被写成当前命令。模型不是 SQL 数据库不会按时间戳只选最新一行相互矛盾的自然语言同时出现时它只能猜猜错就表现为答非所问。我采用三层目录边界。活跃索引层MEMORY.md和memory_summary.md只保留长期有效信息稳定偏好和验收口径、架构与安全边界、工作区定位、冲突时的决策原则。按日日志层放当天进展和临时笔记例如memory/2026-08-25.md可追溯但不要求每个新任务读取。证据归档层放完整排障记录、发布回读、旧版本快照和任务回放进入memory/archive/仍可搜索但不再充当当前指令。凭据、私钥、签名材料和客户私有文件内容不能靠分层解决它们根本不应进入记忆目录。备份和重写主文件set -euo pipefail MEM_DIR$HOME/.codex/memories STAMP$(date %Y%m%d-%H%M%S) BACKUP_DIR$MEM_DIR/archive/pre-slim-$STAMP mkdir -p $BACKUP_DIR cp -p $MEM_DIR/MEMORY.md $BACKUP_DIR/ cp -p $MEM_DIR/memory_summary.md $BACKUP_DIR/旧主文件出现几十个任务章节时建议新建精简版本而不是逐段删除。新文件先写稳定偏好、硬边界和工作区索引再逐条对照旧文件补漏。我给活跃层设了两个上限MEMORY.md不超过 150 行或 15 KiBmemory_summary.md不超过 60 行或 4 KiB。上限不是通用标准关键是默认层必须有预算。清理对象逐项确认本次盘点结果如下对象体积或数量处理旧 MEMORY.md201,111 B备份后用精简索引替换raw_memories.md289,360 B确认是阶段性聚合后清理已处理更新单39 份 / 79,721 B确认已合并后移除重复归档201,111 B校验内容重复后清理.DS_Store3 个 / 24,588 B清理rollout summary62 份 / 334,646 B保留不要只看扩展名判断。名为 archive 的文件也可能是唯一证据名为 raw 的文件也可能尚未消费。删除前至少比较内容、修改时间和引用关系。4. 验证请求与成功结果Git 验收加真实任务测量只瘦身MEMORY.md很容易出现删了但仍然记得的错觉。如果新会话先加载memory_summary.md而摘要仍包含旧项目和旧版本问题并没有消失。顺序应当是确定新的主记忆从新主记忆提炼摘要清点已消费更新单新建干净任务验证。旧线程已经读过旧内容磁盘修改不会让现有上下文倒带验收一定要包含新任务。用 Git 做可回读验收。我的自动脚本曾经中途失败macOS awk 对路径正则的处理与预期不同同时 Markdown 还有两处尾部空白文件虽然改了但提交并未完成。因此至少执行git status --short git diff --cached --stat git diff --cached --check这三条命令分别回答改了什么、改了多少、格式是否可提交。它们比脚本最后打印的 done 可靠得多。最终提交包含 41 个文件变化新增 208 行、删除 6,447 行仓库压缩后只有一个约 402 KiB 的 pack工作区干净。测量是否真的有效不要只比较目录大小也不要只靠主观体感。准备 3 到 5 个真实任务固定模型、仓库状态和提示词记录第一次有效工具调用耗时、输入与输出 Token、引用过期事实的次数、重复确认次数、最终验收是否一次通过。清理前后的冷缓存、热缓存也要区分新任务用于观察记忆层旧长线程还会受当前对话长度和 compaction 影响。验证接入层是否正常可以用模型对话页发一个最小请求 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 。如果这里返回正常说明 Base URL、Key、Model ID 三件套没问题变慢的锅就不在接入层。5. 本篇常见错排查401、local proxy failed 与 reading choices排查过程中最容易撞上的几类报错逐个对照。401 Unauthorized 通常有三种原因Key 没导出到当前 shell、Key 复制时带了空格或换行、环境变量名和配置里的env_key不一致。检查方式是echo $TAOTOKEN_API_KEY | head -c 8确认前缀正确且无多余字符。如果配置里写的是env_key TAOTOKEN_API_KEY环境变量就必须叫这个名字大小写敏感。local proxy failed 多出现在你本地还挂着其他转发工具时。先确认没有残留进程占用端口再确认base_url没有被本地代理改写。配置里base_url应直接是https://taotoken.net/api不要指向127.0.0.1之类的本地地址。reading choices 报错一般是响应结构不符合预期常见于wire_api字段和实际接口不匹配。如果你用的是 chat 类接口wire_api chat如果工具走的是另一套协议对照接入文档调整。这个错误和记忆膨胀无关但会伪装成变慢因为请求在重试。OAuth 相关报错出现在用 Claude Code 或类似工具时通常是登录态和 API Key 混用。用 Key 接入就不要再走 OAuth 流程两者选其一。Claude Code 的接入配置参考 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentClaudeCodeAnthropicutm_campaignrewrite 里面有完整的 Base URL、Key、Model ID 填写位置。还有一个隐蔽的坑清理脚本跑完显示 done但 Git 提交没成功。表现是下次新会话仍然加载旧记忆。回到第 4 节的git status --short确认工作区状态别信脚本的输出。如果排查完接入层和记忆层还是慢再考虑是不是当前线程太长。长线程受对话长度和 compaction 影响和记忆层是两回事。开一个新任务对比能快速区分。6. 长期编码与 Agent 场景的稳定接入把 settings 改到 TaoToken 之后长期编码和 Agent 场景的稳定性主要取决于两件事接入层固定记忆层有预算。接入层固定意味着 Base URL、Key、Model ID 三件套不随意变动排查时变量可控。记忆层有预算意味着默认加载的内容有上限历史证据移出默认层但保持可检索。如果你经常跑长任务或 Agent 工作流可以考虑用 Coding Plan 把额度和管理集中起来 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。配合前面说的分层目录活跃索引保持精简按日日志和证据归档按需检索Codex 的响应会稳定很多。这次清理确认了两件事活跃主记忆可以从 201KB 降到 8.7KB同时保留核心规则历史也不必删除只要移出默认加载层并保持可检索。它没有证明所有 Codex 任务都会固定提速多少这个结论要靠同一套任务长期对比。如果你的 Coding Agent 也开始慢、啰嗦、爱引用旧结论排查顺序可以是先看默认上下文再看规则冲突然后核验磁盘现场最后才讨论模型是否变化。