1. 为什么你的 Codex 每次新会话都像失忆用 Codex 推进真实项目的人大概率都经历过这个循环新开一个会话第一件事不是写代码而是重新交代一遍项目规矩。比如「复杂需求先走 OpenSpec 做系分再动手」「发布前先改版本号和 CHANGELOG」「别乱动已有的 AGENTS.md」。讲完这一轮它听懂了下次新会话一切归零。这不是模型不够聪明而是项目缺少长期记忆。模型能读代码、能改 Bug、能补测试但有一类信息它很难稳定知道这个仓库偏好什么工作流、有哪些默认约定、哪些事必须先问清楚、哪些事绝对不能做。这些信息往往散落在一次次对话里既没写进 README也不适合塞进全局规则。我试过最直接的办法——把动态内容写进全局 AGENTS.md。结果很快踩坑用户自己的 AGENTS.md 被工具偷偷接管全局规则和项目经验混在一起越来越难维护用户手动改了规则后工具到底覆盖还是保留也说不清。更麻烦的是很多人直接从 Codex 客户端打开项目根本不经过 wrapper 命令注入逻辑直接失效。所以更稳的思路是贴着 Codex 原生机制走用UserPromptSubmithook 收集输入用SessionStarthook 在会话开始时注入上下文。不默认修改用户项目文件不托管 AGENTS.override.mdCLI 和客户端走同一套注入逻辑。这篇就把这套「可复现的上下文骨架」拆成能直接复制的配置包括 AGENTS.md 骨架、SessionStart 钩子配置以及一次验证动作。2. 前置准备TaoToken 与 Codex 的接入关系在动手配 hook 之前先把模型接入这条链路理顺。Codex 本身是客户端真正干活的是背后的模型服务。我这边长期用的是 TaoToken 提供的接入能力官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 这个地址不加 UTM。你需要先拿到一个可用的 API Key入口在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。拿到之后Codex 侧一般通过环境变量或配置文件指向这个 endpoint。如果你还没配过可以先在模型对话页确认模型能正常响应 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。这一步的意义在于SessionStart 注入的上下文最终要送给模型如果模型通道本身不通后面所有 hook 调试都会变成「到底是注入没生效还是模型没响应」的糊涂账。所以顺序一定是先通模型再配 hook。注意API Key 属于敏感凭证不要写进会提交到 Git 的 AGENTS.md 或任何项目文件里。放在本地环境变量或用户级配置中。3. 可复制的 AGENTS.md 骨架AGENTS.md 是 Codex 读取项目约定的入口文件。它的价值不在于写得多长而在于把「每次都要口头交代的事」固化成结构化文本。下面这份骨架可以直接复制到项目根目录按需删改。# AGENTS.md ## 沟通约定 - 默认使用中文交流代码注释可用英文。 - 需求不明确时先提问不要直接假设后开写。 ## 工作流 - 复杂需求或重构任务先使用 OpenSpec 做系统分析再进入实现。 - 简单改动单文件、明确 bugfix可直接实现。 - 提交前运行测试测试不过不提交。 ## 架构偏好 - 新增依赖前先说明理由避免引入重量级库。 - 公共逻辑抽到 shared 层不在业务文件里复制粘贴。 ## 硬约束 - 不要修改用户已有的 AGENTS.md 内容。 - 发布前必须更新版本号与 CHANGELOG。 - 不直接操作生产数据库。 ## 常用命令 - 安装依赖npm install - 本地启动npm run dev - 跑测试npm test - 构建npm run build这份骨架的关键是分区沟通、工作流、架构、硬约束、常用命令。分区之后模型更容易判断某条规则属于哪一类也方便你后续按区维护。实测下来把「常用命令」写清楚收益特别高因为模型不用每次猜你的构建命令是什么。但 AGENTS.md 有个天然局限它是静态的。你写进去什么就是什么不会随着协作过程自动沉淀。真正反复出现的偏好还是得靠 SessionStart 动态注入来补。4. SessionStart 钩子配置让新会话自动继承上下文SessionStart 钩子的作用是在会话开始时把当前项目的动态经验注入到 Codex 上下文里。它和 AGENTS.md 是互补关系AGENTS.md 管稳定规则SessionStart 管动态沉淀。配置的核心是让 Codex 在启动时执行一个命令把经验文本输出到上下文。下面是一个可复制的 hook 配置示例写在 Codex 的 hooks 配置中{ hooks: { SessionStart: [ { command: cdxe context:preview, description: 注入当前项目的动态经验补充 } ], UserPromptSubmit: [ { command: cdxe learn:capture, description: 采集用户 prompt 用于经验提炼 } ] } }这里SessionStart负责注入UserPromptSubmit负责采集。两条命令分工明确一条管「读」一条管「写」。配置完成后进入 Codex 执行/hooks把这两条命令 trust 掉否则 hook 不会真正执行。注入的内容大概长这样你可以对照自己的项目确认格式以下内容是当前项目的动态经验补充请在本次会话中作为项目级协作参考。 如果与用户当前明确要求冲突以用户当前要求为准。 # Project - project_key: /path/to/your/project # Workflow - 复杂需求或重构任务先使用 OpenSpec 做系统分析再进入实现阶段。 # Constraints - 项目的 CLI 入口命令统一使用 cdxe文档和示例保持一致。注意最后那句「如果与用户当前明确要求冲突以用户当前要求为准」。这句很重要它保证了动态经验不会压过用户的即时指令避免记忆系统变成「自作主张」。5. 验证请求与成功结果配完不能只看配置文件得实际验证一次。验证分三步先看系统健康再看会注入什么最后看采集到了什么。第一步检查 hooks、模型、自动学习、上下文注入是否都正常cdxe doctor输出里会逐项列出 hooks 是否安装、是否 trust、学习模型是否可用、自动学习 watcher 是否运行、当前项目是否有可注入经验。任何一项异常都会明确标出来。第二步预览下一次会注入给 Codex 的上下文cdxe context:preview如果输出里能看到# Workflow、# Constraints这些分区并且内容和你项目里的约定对得上说明注入链路是通的。第三步查看最近采集到了哪些 promptcdxe prompts:list --limit 20这一步能确认UserPromptSubmit是否真的在采集。如果列表为空说明 hook 没 trust 或者没触发。一个完整的成功结果应该是doctor全绿context:preview有内容prompts:list能看到近期输入。三者都对上才说明「采集 → 提炼 → 注入」这条链路真正跑通了。6. 本篇常见错排查hook 配了但没生效。最常见的原因是没执行/hooks去 trust。Codex 对 hook 有信任机制配置写了不等于允许执行。进 Codex 后先跑/hooks确认两条命令都是 trusted 状态。context:preview 输出为空。说明当前项目还没有 active 经验。经验晋升是有门槛的单条 prompt 支撑只进 candidate至少两条 prompt 支撑才升级为 active而注入只认 active。所以新项目刚配好时预览为空是正常的多协作几轮再看。prompts:list 一直是空的。检查UserPromptSubmit的 command 路径是否正确以及cdxe是否在 PATH 里。如果用的是绝对路径确认路径没有空格或转义问题。注入内容和 AGENTS.md 冲突。记住优先级用户当前明确要求 动态经验 AGENTS.md 默认规则。如果发现动态经验压过了你的即时指令检查注入文本里有没有那句「以用户当前要求为准」的兜底说明。模型没响应误以为是注入失败。先单独确认模型通道是否正常可以在模型对话页发一条测试消息。通道不通时任何 hook 调试都没有意义。担心数据留在本地不安全。数据默认存在~/.codex-evolution。卸载前可以执行cdxe cleanup清理如果要连本地数据库和状态一起删掉用cdxe cleanup --include-home。7. 把上下文骨架用起来如果你每天都在和 Codex 推进真实项目这套骨架的价值会越来越明显。它解决的是一个很朴素的问题别让我每次都重新教你怎么和我协作。落地路径建议这样走先把 AGENTS.md 骨架复制进项目把稳定规则写清楚再配好 SessionStart 和 UserPromptSubmit 两条 hook 并 trust然后用cdxe doctor和cdxe context:preview验证链路最后在日常协作中让经验自然沉淀隔几天用cdxe context:preview看看它学到了什么。需要长期跑编码任务或 Agent 工作流的可以了解下 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。接入细节和参数说明在文档里 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。控制台在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 。最后留一个实用习惯每次大改项目约定后顺手跑一次cdxe context:preview确认注入内容和你的预期一致。上下文骨架不是配一次就完事它需要你偶尔校准才能一直「懂你」。