1. Codex 项目知识库落地：AGENTS.md 与 Memories 到底解决什么问题
Codex 用久了你会发现一个很尴尬的现象：同一个项目，昨天刚跟它讲清楚「这个仓库用 pnpm 不用 npm」「接口层禁止直接改 generated 目录」，今天新开一个会话，它又当无事发生，照样给你 npm install，照样往 generated 里写代码。这不是模型变笨了，而是它没有项目级的长期记忆。
Codex 的知识库体系其实分四层，各管各的事：每次必须遵守的硬规则交给 AGENTS.md；历史决策、项目偏好这类背景信息交给 Memories；可复用的流程和领域专长打包成 Skills；需要动态拉取的外部文档、工单走 MCP。这四层里，AGENTS.md 是主体，Memories 是补充，Skills 和 MCP 是扩展。搞懂这四层的分工，你就能把「AI 不懂我项目」这个高频痛点压下去大半。
这篇要做的有三件事：一是把 AGENTS.md 的三层指令链和模板讲透，让你能直接复制；二是把 Memories 的开关、存储路径、读写边界说清楚；三是把 Codex 的 endpoint 和 auth.json 改到 TaoToken 统一通道，让规范沉淀和模型调用走同一条链路。最后给一个完整验证动作：新建会话后确认规范与记忆都被正确加载。
适合谁看：已经在用 Codex 做日常编码、但每次都要重复交代项目规则的开发者；团队里想把编码规范固化进 AI 工作流的 Tech Lead；以及想把 Codex 接入统一 API 通道、避免 Key 散落各处的人。下面按「先建知识库、再改通道、最后验证」的顺序走，每一步都有可复制的配置。
2. TaoToken 前置：把 Codex 的 endpoint 与 auth.json 统一到一条通道
在动 AGENTS.md 之前，先把 Codex 的模型调用通道理顺，不然后面验证记忆加载时，请求可能因为 Key 或 endpoint 问题失败，你会分不清是知识库没生效还是通道没通。
TaoToken 在这里的角色是统一 Key/API 通道：你不需要在每台机器、每个工具里塞不同的 Key，而是把 Codex 的 base_url 指向同一个入口，Key 也统一管理。官网入口是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 地址是 https://taotoken.net/api （这个不加 UTM）。
Codex 的配置分两块：一块是 config.toml，管模型、provider、base_url 这些；另一块是 auth.json，管认证信息。很多人只改了 config.toml 里的 base_url，却忘了 auth.json 里的 Key，结果请求一直 401，排查半天。这两块必须一起改。
先说 config.toml 的位置。Codex 的全局配置在 ~/.codex/config.toml，项目级配置可以放在仓库的 .codex/config.toml。provider 段要写清楚 base_url 和 wire_api。下面是一个可复制的片段，路径和字段名保持和 Codex 原文一致：
# ~/.codex/config.toml model = "gpt-5-codex" model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" wire_api = "responses" [features] memories = true这里有几个点要注意。model_provider 的值要和下面 [model_providers.xxx] 的 xxx 对上，写错了 Codex 会找不到 provider。wire_api 用 responses 还是 chat 取决于你用的模型接口形态，Codex 系模型一般走 responses。memories = true 是这一篇的重点，默认是关的，不开的话 Memories 不会工作。
再说 auth.json。它的位置在 ~/.codex/auth.json，结构大致如下：
{ "OPENAI_API_KEY": "sk-你的TaoTokenKey" }注意这里的字段名是 OPENAI_API_KEY，不是随便起的名字，Codex 读的就是这个键。你把 TaoToken 控制台里生成的 Key 填进去就行。Key 的获取入口在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。
如果你用的是 Claude Code 那套 Anthropic 兼容通道，配置形态会不一样，走的是 ANTHROPIC_BASE_URL 和 ANTHROPIC_AUTH_TOKEN 这类环境变量，对应文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。但 Codex 这条线，认准 config.toml + auth.json 两件套就够了。
改完之后，先别急着建知识库，跑一次最简单的请求确认通道通：
codex --ask-for-approval never "Reply with the single word: pong"如果返回 pong，说明 endpoint 和 Key 都对。如果报 401，回去检查 auth.json 的字段名和 Key 有没有多余空格；如果报连接类错误，检查 base_url 是不是写成了带路径的完整地址。这一步过了，再往下做知识库，排障时就能把通道问题排除掉。
3. AGENTS.md 三层指令链与可复制模板
AGENTS.md 是 Codex 知识库里最重要的一层，因为它管的是「每次必须遵守的规则」。Memories 是概率性回忆，Skills 是按需加载，只有 AGENTS.md 是每次会话都会读的硬约束。所以团队规范、禁止事项、常用命令这些，必须写进 AGENTS.md，不能指望 Memories 记住。
Codex 读 AGENTS.md 是按三层优先级来的，越靠近当前工作目录越优先：
| 层级 | 路径 | 放什么 |
|---|---|---|
| 全局 | ~/.codex/AGENTS.md | 个人习惯偏好 |
| 仓库 | ./AGENTS.md | 团队规则 |
| 子目录 | ./xxx/AGENTS.override.md | 专项规则，存在时忽略该目录普通 AGENTS.md |
这个优先级设计很实用。比如你个人习惯用中文注释，就写全局；团队要求提交信息用英文，写仓库级；某个子目录是自动生成的代码，禁止手改，就在那个子目录放 AGENTS.override.md。
创建方式有两种。自动的是在会话里跑 /init，Codex 会扫描项目生成初稿；手写就按模板填。我建议先 /init 生成，再手动补关键项，因为自动生成的往往缺测试命令和禁止事项。
下面是一个可直接复制的 AGENTS.md 模板，覆盖项目概况、编码规范、常用命令、禁止事项四块：
# 项目概况 - 技术栈：TypeScript + Node 20 + pnpm - 目录：src/ 源码，tests/ 测试，generated/ 自动生成 - 包管理：只用 pnpm，禁止 npm/yarn # 编码规范 - 提交信息用英文，格式 feat:/fix:/chore: - 所有导出函数必须有 JSDoc - 错误处理统一用 src/lib/errors.ts 里的 AppError # 常用命令 - 安装：pnpm install - 测试：pnpm test - 类型检查：pnpm typecheck - 构建：pnpm build # 禁止事项 - 禁止修改 generated/ 下任何文件 - 禁止在 src/ 里直接 console.log，用 logger - 禁止跳过测试直接提交模板里最容易被忽略的是「禁止事项」。很多人写 AGENTS.md 只写「要做什么」，不写「不要做什么」，结果 Codex 还是会踩坑。把重复犯的错写进禁止事项，是最省事的维护方式。
三层指令链有个合并上限：默认总大小 32 KiB，超了要调 config.toml 里的 project_doc_max_bytes。如果你团队规范文件很长，可以这样调：
# ~/.codex/config.toml project_doc_max_bytes = 65536如果团队已经有现成的规范文件，不想重命名成 AGENTS.md，可以用 fallback 配置：
project_doc_fallback_filenames = ["TEAM_GUIDE.md"]这样 Codex 找不到 AGENTS.md 时，会去读 TEAM_GUIDE.md。
验证 AGENTS.md 是否生效，跑这条命令：
codex --ask-for-approval never "Summarize the current instructions."如果它能把你的禁止事项和常用命令复述出来，说明加载成功。如果只返回泛泛的「我会帮你写代码」，说明没读到，检查路径和文件名。
维护闭环也很关键。Codex 犯了重复错误时，别只在会话里纠正，要把纠正写进 AGENTS.md。在 GitHub PR 评论里 @codex add this to AGENTS.md，它就能自己更新。这样知识库是活的，越用越准。
4. Memories 开关、存储与读写边界
Memories 是 Codex 的自动记忆层，管的是「历史决策、项目偏好背景」这类不需要每次硬性遵守、但记住会更好的信息。它和 AGENTS.md 的分工要拎清：硬规则写 AGENTS.md，软背景交给 Memories。
Memories 默认是关闭的，必须在 config.toml 里显式打开：
# ~/.codex/config.toml [features] memories = true打开之后，Codex 会在任务空闲时后台生成记忆，自动脱敏，存到 ~/.codex/memories/ 目录。会话内可以用 /memories 命令查看和控制。你可以把它理解成一个「后台小助手」，趁你不忙的时候把这次会话里值得记的东西整理归档。
存储结构大致是按项目或会话分文件，每个文件里是结构化的记忆条目。你不用手动去改这些文件，但知道它在哪，排查「记忆没生效」时有用。比如你怀疑记忆没写进去，可以去 ~/.codex/memories/ 看有没有对应文件生成。
Memories 的边界必须说清楚：它是概率性回忆，不是硬保证。也就是说，它可能这次想起来、下次想不起来。所以任何「必须遵守」的规则，绝对不能只写 Memories，必须写 AGENTS.md。我见过有人把「禁止改 generated 目录」写进 Memories，结果某次会话 Codex 没回忆起来，照样改了。这种坑，硬规则一定要放 AGENTS.md。
那 Memories 适合放什么？适合放那些「记住更好、忘了也不致命」的背景。比如「这个项目之前决定用 Zustand 不用 Redux，原因是团队更熟」「上个季度把测试框架从 Jest 迁到了 Vitest」。这些信息写进 AGENTS.md 会显得啰嗦，放 Memories 刚好。
会话内控制用 /memories 命令，可以查看当前记忆、手动添加、删除某条。如果你发现某条记忆是错的，直接在里面删掉，比去翻文件快。
验证 Memories 是否工作，可以这样：先在一个会话里告诉 Codex 一个项目偏好，比如「这个项目我们统一用 dayjs 处理日期，不用 moment」，然后结束会话。等后台生成记忆后，新开一个会话问「这个项目日期库用什么」，看它能不能回忆起来。如果能，说明 Memories 生效；如果不能，检查 memories = true 有没有写对，以及后台生成需要一点时间，别刚说完就立刻问。
再强调一次分工：AGENTS.md 管硬规则，Memories 管软背景。两者配合，才能既保证规范不被违反，又让 Codex 记住那些说不清道不明的项目偏好。
5. 常见报错排查：401、local proxy failed、reading choices、OAuth
配置过程中最容易卡在几个固定报错上，这一节按真实报错对照排查。先给一个总原则：报错先分清楚是「通道问题」还是「知识库问题」。401 和连接类错误基本都是通道问题，reading choices 和 OAuth 多半是配置或认证形态问题。
401 Unauthorized 是最常见的。原因通常是 auth.json 里的 Key 不对，或者字段名写错了。检查三点：字段名必须是 OPENAI_API_KEY；Key 前后不能有空格或换行；Key 本身没过期。如果你是从控制台复制的，注意别把多余字符带进去。改完 auth.json 后要重启 Codex 会话，配置不会热加载。
local proxy failed 这类连接错误，多半是 base_url 写错了。常见错误是把 base_url 写成带具体路径的完整地址，比如多加了 /v1/chat/completions。base_url 应该只到 https://taotoken.net/api 这一层，后面的路径由 Codex 根据 wire_api 自己拼。另外检查网络能不能通到这个地址，公司网络如果有出口限制，也会报这个。
reading choices 这个报错通常出现在响应解析阶段，意思是 Codex 拿到了返回但解析不出 choices 字段。原因一般是 wire_api 和实际接口形态不匹配。如果你用的是 responses 形态的接口，wire_api 要写 responses；如果是 chat 形态，写 chat。写错了，返回结构对不上，就报 reading choices。对照你的模型接口文档改一下。
OAuth 相关报错，一般出现在你用了需要 OAuth 的认证方式，但配置里没配对。Codex 支持多种认证形态，如果你走的是 API Key 通道，就不该出现 OAuth 流程。检查 config.toml 里有没有残留的 OAuth 配置项，以及 auth.json 是不是被别的工具的凭证覆盖了。如果你同时装了 Claude Code 那套 Anthropic 通道，注意两套凭证别混在一个文件里。
还有一个隐蔽的坑：改了 config.toml 但没生效。Codex 读配置的优先级是项目级覆盖全局级，如果你在仓库里放了 .codex/config.toml，它会覆盖 ~/.codex/config.toml。排查时先确认当前生效的是哪一份。可以用 codex 的配置查看命令确认，或者临时把项目级配置移走再试。
最后给一个排查顺序，照着走能省时间：先跑一次最简请求确认通道通（排除 401 和连接问题）；再跑「Summarize the current instructions」确认 AGENTS.md 加载（排除知识库路径问题）；最后新开会话问项目偏好确认 Memories（排除 memories 开关问题）。三步都过，说明通道和知识库都正常。
6. 把规范沉淀和模型调用收进同一条链路
走到这里，你应该已经有一套能跑的 Codex 知识库了：AGENTS.md 管硬规则，Memories 管软背景，endpoint 和 auth.json 指向统一通道。这套组合的价值在于，你不再需要每次开新会话都重复交代项目规则，Codex 会自己读 AGENTS.md，也会在后台把项目偏好记进 Memories。
如果你还在犹豫要不要把通道统一，我的建议是尽早做。Key 散落在各个工具里，一旦要轮换或者排查，成本很高。统一到一条通道后，改一处就全生效。Key 管理入口在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，接入细节看 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。
如果你只是偶尔验证一下模型返回，用模型对话页就够了：https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。但如果你像这篇一样，要把 Codex 长期用在日常编码和 Agent 工作流里，那 Coding Plan 更合适：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。
最后留一个实用习惯：每次 Codex 犯了重复错误，别只在会话里骂它，花十秒把纠正写进 AGENTS.md 的禁止事项。坚持一个月，你会发现需要重复交代的东西越来越少，这才是知识库真正的复利。
