1. Codex CLI 的记忆困境不是模型笨是每次都在重灌上下文在 Codex CLI 里跑codex exec如果你把 agent-memory 的memory目录全文塞进 prompt会看到 token 消耗曲线陡得离谱。很多人以为是模型变笨了其实是每次新会话都把同一批记忆重新灌了一遍。本文从 Codex CLI 用户视角给出一个可复现的 token 对照agent-memory 的本地检索返回路径和全文注入相比到底差多少 token以及 Codex CLI 模型调用前如何用 TaoToken 拿 Key、把 Base URL 指向https://taotoken.net/api。TaoToken 的官网入口在这里https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_cli_memory_intro 。先把入口放前面后面所有配置都围绕它展开。agent-memory 这个项目解决的是 agent 的“失忆”问题。它的核心设计很清晰用普通 Markdown 文件作为唯一事实来源SQLite 只做索引缓存索引删了也能重建因为真相都在 Markdown 里。对 Codex CLI 用户来说这意味着你在 Claude Code 里积累的经验切到 Codex CLI 还能继续用任何能跑 shell 命令的 agent都能读取同一套记忆库。更重要的是它的本地检索返回的是“路径”不是“把一大段文本粘贴到 prompt 里”。agent 拿到路径后按需打开文件用到多深读多深。这一点直接决定了 Codex CLI 每次模型调用时上下文里到底要带多少 token。但这里有个很容易踩的坑很多人为了让 Codex CLI “记住更多”会在启动前把整个memory目录cat出来拼进 system prompt 或任务描述里。结果就是每轮请求都携带几万 token 的输入模型还没开始推理token 已经烧掉一大半。Codex CLI 的 token 消耗发生在每次请求的输入侧本地检索本身不花模型 token真正花 token 的是你把什么放进上下文。所以本文要做的对照实验就是量化“全文注入”和“路径检索 按需读取”之间的差距并说明谁在消耗 Token是 Codex CLI 的每一次模型调用。agent-memory 目前还很新版本 0.1.0偏开发者工具定位适合自己搭 agent 工作流的人。它的价值不在于开箱即用而在于把“长期记忆”这个底座用透明、可审计的方式做出来了。对 Codex CLI 用户来说最务实的用法不是把它当黑盒记忆层而是把它当成一个本地可检索的记忆目录检索返回路径Codex CLI 按需读取模型只处理当前任务真正需要的那部分记忆。2. 先拿 Key、再配 config.tomlCodex CLI 接入 TaoToken 的最小步骤在让 Codex CLI 调用模型之前需要先准备 TaoToken 的 API Key。注册和创建 Key 的入口在官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_cli_get_key 。拿到 Key 后不要把它写进代码仓库用环境变量管理。Codex CLI 的配置文件和 Claude Code 不一样Codex 用config.tomlClaude Code 用settings.json/ANTHROPIC_*。这一点必须分开不能把ANTHROPIC_*那套环境变量直接套到 Codex CLI 上否则会出现 provider 不识别或鉴权失败。下面是一个 Codex CLI 的config.toml示例路径通常是~/.codex/config.toml。注意 Base URL 写https://taotoken.net/api不要加多余的/v1或结尾斜杠除非 TaoToken 文档明确要求# ~/.codex/config.toml # Codex CLI 的 provider 配置示例 model gpt-5-codex # 具体模型名以 TaoToken 模型列表为准 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api responses # 按当前 Codex 版本和 TaoToken 文档选择 responses 或 chat然后在本地 shell 里导出 Key。Key 占位符用YOUR_API_KEY不要提交到 git# 本地执行不要写入仓库 export TAOTOKEN_API_KEYYOUR_API_KEY如果你使用 CC Switch 管理多套配置记住它的三件套Provider、API Key、Base URL。在 CC Switch 里为 Codex 建一套配置时Provider 选 Codex 对应的类型API Key 填YOUR_API_KEYBase URL 填https://taotoken.net/api。切到 Claude Code 时再用另一套配置不要混用。配置完成后跑一个最小验证codex exec 只回复 ok如果返回 401优先检查TAOTOKEN_API_KEY是否在当前 shell 生效以及 Key 是否复制完整。如果返回 404检查base_url是否写成了https://taotoken.net/api而不是其他路径。如果提示 provider 不支持检查wire_api和 Codex CLI 版本是否匹配。模型名也要以 TaoToken 控制台或模型列表为准不要凭记忆填。创建和管理 Key 的页面在https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_cli_agent_memory_keys 。这个链接后面还会在 CTA 部分再次出现因为它是整条链路的核心入口。Codex CLI 配好之后模型调用就走 TaoToken 的 Base URL。此时再接入 agent-memory重点就变成每次请求到底带多少记忆进上下文。下面先讲清楚 agent-memory 的检索为什么省 token。3. agent-memory 的本地检索设计为什么返回路径比全文注入省 tokenagent-memory 的设计里有一个非常关键的选择检索结果返回路径而不是直接返回全文。这个选择对 token 消耗的影响是数量级的。我们可以把两种方案拆开看。全文注入方案在 Codex CLI 发起模型调用之前把memory目录下所有 Markdown 文件读出来拼成一个大字符串塞进 system prompt 或用户消息。假设你的记忆库有 30 个 Markdown 文件每个文件平均 600 token那么全文就是 18000 token。Codex CLI 每发起一次模型请求这 18000 token 都会作为输入发送。如果一轮任务里 Codex CLI 调用了 20 次模型输入 token 就是 360000。这还不包括模型输出和工具调用的开销。谁在消耗 Token是 Codex CLI 的每一次模型请求因为全文被重复注入。路径检索方案agent-memory 在本地用 SQLite 索引和排序算法根据任务关键词检索出最相关的若干条记忆返回它们的文件路径和简短摘要。假设返回 8 条路径每条路径加摘要约 15 token路径列表总计约 120 token。Codex CLI 拿到路径后判断当前任务需要读取其中 2 个文件每个文件按需读取 600 token合计 1200 token。那么单轮模型调用输入大约 1320 token。和全文注入的 18000 token 相比单轮节省约 92%。20 轮累计下来差距会非常明显。这里要注意一个细节本地检索本身不消耗模型 token。agent-memory 的索引、排序、路径匹配都在本地完成SQLite 只是缓存Markdown 才是事实来源。真正进入 Codex CLI 上下文的只有检索结果和按需读取的文件内容。所以省 token 的关键不是“少记”而是“只把当前任务需要的那部分记忆送进模型”。记忆库可以很大但每次请求携带的上下文可以很小。另一个细节是“按需读取”的粒度。Codex CLI 读取文件时可以只读文件的前若干行或者根据文件内的小标题定位到相关段落而不是把整个文件一次性读完。agent-memory 返回路径后Codex CLI 可以用 shell 命令做二次筛选比如用sed -n读取指定行范围或者用grep -n先定位关键词所在行再读取附近内容。这样即使命中了文件也不一定要把整个文件塞进上下文。对长记忆文件来说这个二次裁剪能进一步降低 token。所以agent-memory 的本地检索返回路径本质上是在 Codex CLI 和记忆库之间加了一层“按需加载”。全文注入是“一次全给”路径检索是“先给目录再按需翻页”。哪种更省 token取决于记忆库大小和任务重复度但方向是明确的记忆库越大、会话轮次越多路径检索的优势越明显。4. 可复现对照用 tiktoken 统计路径检索与全文注入的 token 消耗下面给出一个可以在本地运行的对照脚本。它不调用任何模型 API只统计 token 数量。你需要先准备一个 agent-memory 的memory目录或者任意包含 Markdown 文件的目录。脚本使用tiktoken做 token 估算安装命令也在下面。所有命令由读者在本地执行不要在生产环境直接跑。# 本地执行安装依赖 pip install tiktoken# token_compare.py # 用法python token_compare.py /path/to/agent-memory/memory import os import sys import tiktoken enc tiktoken.get_encoding(cl100k_base) root sys.argv[1] if len(sys.argv) 1 else ./memory paths [] all_text [] for dirpath, _, filenames in os.walk(root): for fn in filenames: if fn.endswith(.md): p os.path.join(dirpath, fn) paths.append(p) with open(p, encodingutf-8) as f: all_text.append(f.read()) if not paths: print(没有找到 Markdown 文件请检查 memory 目录路径) sys.exit(1) full_tokens sum(len(enc.encode(t)) for t in all_text) path_text \n.join(paths) path_tokens len(enc.encode(path_text)) avg_file_tokens full_tokens // len(paths) print(fMarkdown 文件数: {len(paths)}) print(f全文注入 token: {full_tokens}) print(f路径列表 token: {path_tokens}) print(f平均单文件 token: {avg_file_tokens}) print(f仅路径列表相对全文节省: {(1 - path_tokens / full_tokens) * 100:.2f}%)跑完你会得到类似这样的输出Markdown 文件数: 30 全文注入 token: 18000 路径列表 token: 120 平均单文件 token: 600 仅路径列表相对全文节省: 99.33%但这还不是完整对照因为路径检索后 Codex CLI 可能还需要读取少量文件。再模拟 20 轮会话每轮检索后按需读取 2 个文件# 续接上面的变量 read_count 2 per_round_path path_tokens read_count * avg_file_tokens rounds 20 print(f路径检索 按需读 {read_count} 个文件单轮 token: {per_round_path}) print(f全文注入 {rounds} 轮累计 token: {full_tokens * rounds}) print(f路径检索 {rounds} 轮累计 token: {per_round_path * rounds}) print(f20 轮累计节省: {(1 - per_round_path / full_tokens) * 100:.2f}%)对照表格可以整理成下面这样方案单轮输入 token20 轮累计 token说明全文注入18000360000每轮都把全部记忆送进 Codex CLI路径检索 按需读 2 个文件132026400只送路径和当前需要的记忆节省比例约 92.7%约 92.7%记忆库越大差距越明显这个对照实验的结论很直接消耗 Token 的是 Codex CLI 的模型请求输入不是 agent-memory 的本地检索。agent-memory 只是把“路径”交给 Codex CLI真正决定 token 消耗的是 Codex CLI 每次请求里带了哪些文件内容。所以优化方向不是减少记忆而是减少每次请求携带的记忆量。当然实际 token 数会受文件大小、检索条数、按需读取策略、Codex CLI 的上下文管理方式影响。但只要你用同一套 memory 目录跑上面的脚本就能得到自己环境里的真实对照。这个结果可以直接用来评估是否值得把全文注入改成路径检索。5. 把 agent-memory 接进 Codex CLIAGENTS.md 规则与本地命令Codex CLI 支持通过AGENTS.md或类似的项目规则文件来约束行为。你可以把“先检索、再按需读取”的规则写进项目根目录的AGENTS.md让 Codex CLI 在任务开始前调用 agent-memory 的本地检索而不是直接读全文。下面是一个规则示例。注意命令名agent-memory只是占位实际入口以你安装后的 CLI 为准如果项目提供的是其他可执行名替换即可。# AGENTS.md ## 记忆使用规则 - 任务开始前先运行本地检索agent-memory search 任务关键词 --format paths --limit 8 - 只读取检索返回的路径不要 cat 整个 memory 目录。 - 读取文件时优先用 grep -n 定位关键词再用 sed -n 读取附近段落。 - 不要把多个记忆文件的全文拼进同一条消息。 - 会话结束时按 agent-memory 文档触发写入不要手动复制粘贴整个目录。然后在 Codex CLI 里发起任务时可以在提示中明确要求遵守AGENTS.mdcodex exec 按 AGENTS.md 规则先检索记忆再回答。任务修复登录接口的 401 问题。如果 agent-memory 的检索命令支持 JSON 输出也可以让 Codex CLI 直接解析路径列表再决定读哪个文件。例如# 本地执行先检索路径 agent-memory search 登录接口 401 --format json --limit 8 /tmp/mem_hits.json # 然后由 Codex CLI 读取这个 JSON选择要打开的文件关键点是Codex CLI 不要一次性读取所有 Markdown。路径列表只占很少 token真正的文件内容等确定相关后再读。你可以把“检索 → 选路径 → 局部读取”做成一个固定工作流写进AGENTS.md这样每次 Codex CLI 启动任务时都会遵循同一套省 token 的策略。另外agent-memory 支持会话边界自动写入和“睡眠期”整合。对 Codex CLI 用户来说这意味着你不需要在每次对话里提醒它“记得写记忆”。你只需要保证检索侧遵守按需读取规则写入侧交给 agent-memory 的本地机制。这样记忆库会逐渐积累但不会因为全文注入而拖垮每次请求的 token 预算。如果你同时用 Claude Code 和 Codex CLI两者可以共享同一个记忆库。Claude Code 里积累的经验Codex CLI 也能检索到。下面讲配置差异避免两边串台。6. Claude Code 与 Codex CLI 共享记忆库时的配置差异共享记忆库的前提是两边都能访问同一个memory目录。这件事本身不难难的是配置不要串。Claude Code 用settings.json和ANTHROPIC_*环境变量Codex CLI 用config.toml和它自己的 provider 字段。你不能把 Claude Code 的ANTHROPIC_BASE_URL、ANTHROPIC_API_KEY写到 Codex CLI 的配置里也不能把 Codex 的model_provider套到 Claude Code 上。Claude Code 侧的一个settings.json示例{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }这段配置只给 Claude Code 用。Base URL 同样是https://taotoken.net/apiKey 用你的YOUR_API_KEY。模型名以 TaoToken 模型列表为准。Codex CLI 侧则回到上一节的config.toml用model_providers.taotoken、base_url、env_key这一套。两边都指向同一个 Base URL但配置文件和环境变量名不同。如果你用 CC Switch 管理多套配置记住三件套Provider、API Key、Base URL。为 Claude Code 建一套为 Codex CLI 建一套。切换时确认当前激活的是哪一套避免把 Claude Code 的ANTHROPIC_*带进 Codex CLI 的进程环境。一个简单的检查方法是在本地 shell 里看环境变量# 本地执行检查当前环境变量 env | grep -E ANTHROPIC|TAOTOKEN|OPENAI | sortCodex CLI 启动时只应该看到TAOTOKEN_API_KEY这类它需要的变量。如果同时看到ANTHROPIC_*不一定立即报错但容易在排障时干扰判断。共享记忆库是目录层面的共享配置层面建议保持隔离Claude Code 管 Claude Code 的Codex CLI 管 Codex CLI 的。TaoToken 官网也有相关入口如果你需要重新拿 Key 或查看文档可以从这里进https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_cli_shared_memory 。Claude Code 的专门文档在文末 CTA 里给出。7. 常见报错与排查401、404、模型名、Base URL 斜杠接入过程中最容易遇到几类问题按优先级排查第一类401 鉴权失败。表现是 Codex CLI 返回401 Unauthorized或提示 API key 无效。排查顺序确认TAOTOKEN_API_KEY是否已经在当前 shell 导出确认 Key 是否复制完整有没有多余空格确认你用的 Key 对应的是 TaoToken 控制台里创建的 Key而不是其他平台的 Key。创建 Key 的页面https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_cli_agent_memory_keys 。第二类404 或路径错误。表现是请求发送后返回 404或者提示模型不存在。优先检查base_url是否写成了https://taotoken.net/api。不要凭经验加/v1、/v1/chat/completions或结尾斜杠除非 TaoToken 文档明确要求。Codex CLI 的 provider 配置里base_url应该是一个基础地址具体路径由 Codex CLI 根据wire_api拼接。第三类模型名不匹配。表现是返回模型不存在或权限不足。解决方法是去 TaoToken 控制台查看当前可用的模型名把config.toml里的model字段改成实际存在的模型。不要直接复用其他平台的模型名即使名字看起来相似。第四类provider 不识别。表现是 Codex CLI 启动时报错提示未知 provider 或wire_api不支持。检查model_provider是否和[model_providers.taotoken]的名称一致检查wire_api是否与当前 Codex CLI 版本匹配。如果不确定先按 TaoToken 文档或 Codex CLI 文档给出的示例填。第五类本地检索无结果。表现是 agent-memory 检索返回空列表Codex CLI 以为没有记忆。排查方向确认memory目录路径是否正确确认 Markdown 文件是否在目录内如果用了 SQLite 索引确认索引是否需要重建。记住 Markdown 是事实来源索引只是缓存索引坏了可以重建不要因为索引问题就放弃本地检索。第六类token 消耗仍然很高。表现是已经用了 agent-memory但 Codex CLI 的输入 token 还是很大。检查AGENTS.md规则是否真的生效检查 Codex CLI 是否在某个步骤里执行了cat memory/*.md或类似的全量读取检查按需读取时是否一次读了太多文件。可以用第 4 节的脚本定期统计当前会话实际注入的 token确认路径检索策略是否被执行。把这些排查点固定成流程可以避免大部分接入问题。配置正确之后Codex CLI 的模型调用走 TaoToken Base URL记忆检索走本地 agent-memory两者通过“路径”而不是“全文”连接。8. 把 token 花在推理上从模型对话到 Coding Plan 的落地路径agent-memory 的价值是把记忆留在本地 Markdown把检索结果以路径形式交给 Codex CLI。TaoToken 的价值是给 Codex CLI 提供稳定的模型调用入口。两者结合目标只有一个让 Codex CLI 每次请求只携带当前任务真正需要的上下文把 token 花在推理上而不是花在重复注入记忆上。如果你还没有开始建议按这个顺序走一遍先试模型对话确认模型名和基础调用没问题https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_cli_agent_memory_chat如果你要长期在 Codex CLI 里跑任务看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_cli_agent_memory_plan然后创建 API Key填入config.toml的env_key对应环境变量https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_cli_agent_memory_keys如果你同时用 Claude Code配置方式看这份文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_cli_agent_memory_claude_code最后再回到官网整体入口确认版本和文档更新https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_cli_memory_final把 agent-memory 的检索结果从“全文”改成“路径”把 Codex CLI 的 Base URL 指向https://taotoken.net/api把 Key 放进环境变量而不是代码仓库。做完这三步你就能用第 4 节的脚本量出自己环境里的 token 对照。谁消耗 Token 是 Codex CLI 的模型请求省 Token 的关键是让每次请求只带该带的记忆。