Codex Token 省流实战：从上下文工程到 Prompt 约束降低 80% 消耗

1. 这篇文章真正要解决的问题

最近 Codex 在开发者圈子里热度越来越高，很多人已经不只是把它当成一个“能写代码的聊天助手”，而是真正接入了日常开发流程：让它修 bug、写测试、做代码审查、自动补全工程脚手架。但很快大家就发现了同一个痛点：Token 烧得太快了。

我见过不少开发者第一天安装 Codex，兴冲冲让它跑一个中等规模的任务，结果不到半小时，套餐里的额度就见底了。更让人心疼的是，很多 Token 其实并没有花在刀刃上——它可能被用来反复读取同一个文件、重复分析相似上下文、在错误的模型参数下做无谓的长输出。

这篇文章要解决的问题，不是“Codex 怎么安装”——那是入门话题。我要讲的是：如何在不牺牲任务完成质量的前提下，把 Codex 的 Token 消耗降低 80% 左右。

这里必须先给出一个判断：Codex 的 Token 消耗大头，往往不是“AI 写代码”本身，而是上下文工程做得不好导致的连锁放大。你用多少 Token，取决于你喂进去多少上下文、让模型在多大范围内推理、以及有没有在关键环节做结构化约束。这三件事做好了，省 Token 不是玄学，而是工程能力。

读完这篇文章，你会获得：

1. 一套可落地的 Codex Token 省流策略，从工作区设计、会话隔离到 prompt 模板。
2. 真正搞清楚 Token 在 Codex 内部是怎么被消费的，不再靠猜。
3. 一套参考配置和常用命令，直接复制就能用。
4. 常见的“Token 异常消耗”场景排查清单。

文章中所有内容，都基于 Codex 的命令行工具和本地配置文件展开，不涉及任何“破甲”“逆向”等灰色操作，所有做法都是官方公开支持的方式。

核心结论先放前面：Codex 真正能吃 Token 的地方，不是你问一句话，而是它启动时读取上下文、执行工具调用时返回大段输出、以及多轮交互中上下文不断累积这三条链路。省 Token 的所有技巧，本质上都在这三条链路上做收敛。

2. Token 到底是被 Codex 怎么“吃掉”的

2.1 先从 Token 是什么说起

Token 是 LLM 处理文本时的最小计算单元。你可以把它粗略理解为：英文里大约 4 个字符算 1 个 Token，中文通常 1 到 2 个汉字算 1 个 Token，代码里一个短标识符也可能就是 1 个 Token。

Token 消耗量，直接决定了你调用模型的花费，也决定了单次请求能否在模型上下文窗口内完成。对于 Codex 这种 Agent 型工具，Token 消耗的复杂性在于：它不是一次性请求，而是一整个循环。

一次完整的 Codex 任务，大致长这样：

1. 用户在终端提出一个需求。
2. Codex 把当前会话的指令、模型要用的 prompt、可能的工作区摘要汇总成一次请求。
3. 模型输出决策，可能包含对工具的调用。
4. Codex 执行工具调用（比如读取文件、运行测试、搜索代码）。
5. 工具调用结果被放回上下文，再次进入模型。

看到没有，第 3 到第 5 步会反复循环。每一步都会产生新的 Token 消耗，而且每一轮循环里，前面几轮的信息依然在上下文窗口内。Token 是复利式增长的。

2.2 Codex 的三种大额消费链路

我把它拆成三条链路，理解了这三条，后面的省流策略就有依据了：

链路一：上下文注入

Codex 不是直接把你的全部代码库都塞给模型。它默认会读取工作区内的配置、项目结构，也可以选择性地把代码片段加入上下文。但如果你的项目配置、AGENTS.md 文件写得又长又乱，或者会话结束时没有做清理，每一次新任务都会背上沉重的“遗产税”。

记住一个原则：Codex 的输入上下文越干净，Token 消耗越低，模型理解越准。

链路二：工具调用返回

Codex 执行 shell 命令、读取文件时，会把命令输出作为上下文的一部分送回模型。最典型的高消耗场景，是执行了一个cat xxx.log或者git diff，然后日志文件几万行，全部进入上下文。更隐蔽的是，一些本来只需要 10 秒的任务，因为模型反复猜测、反复运行探测性命令，把大量无效输出送进了上下文。

链路三：多轮累积

一个任务如果没有在明确的分界点结束，上下文里就会一直挂着历史步骤。Codex 的“继续会话”功能虽然方便，但代价是后续每一轮都要重新处理前面所有历史。会话越长，单位任务的平均 Token 成本越高。

2.3 需要明确的边界：Codex 不是“聊天窗口”

很多人把 Codex 当成 ChatGPT 的替代品来用，输入一大段背景故事：“你好，我现在在做一个电商项目，我的后端是 Java，数据库是 MySQL，然后我遇到了一个 bug……”

这种做法非常耗 Token。因为 Codex 本身就能通过配置文件和工作区感知这些信息，你不必重复描述。它更擅长的是“给一个明确任务，然后在项目里自主执行”。

这个认知差异，是省 Token 的起点。

Codex 的定位	不是定位
在代码库内执行多步骤任务的 Agent	通用知识问答聊天机器人
通过工具调用读写文件、执行命令	一次性生成完整代码片段
通过会话隔离保持上下文干净	一个会话连续处理无关任务
依赖工作区摘要和配置高效工作	依赖人工在提示词里重复项目背景

3. 省 Token 的整体策略：降本，但不要降低质量

3.1 目标设定

我们的目标是“省 80% Token”，如果你用过 Codex，对这个量级应该有体感：从“半小时烧完额度”变成“能完整跑完几个中型任务”。

但这里有一个前提：省 Token 不能靠阉割任务需求。如果本来要重构 10 个文件，你改成只改 2 个，那不叫省 Token，那叫降低交付质量。

真正合理的省流策略，是：

• 让 Codex 在更小的上下文窗口内，做出更准确的决策。
• 减少无效工具调用和冗余输出。
• 通过配置和模板，把模型“引导”到结构化、收敛的工作路径上。

3.2 三个核心杠杆

我们用一张表说明省 Token 的三个核心杠杆，接下来每一节都会对应展开：

杠杆	操作方式	效果
工作区与配置	精简 AGENTS.md、隔离项目目录、善用 .gitignore	降低每一轮请求的固定 Token 开销
会话管理	短会话、小任务、及时分离上下文	降低多轮累积的增量 Token
Prompt 与工具约束	结构化指令、限制命令输出、禁止盲目读取	减少无效工具调用和返回内容

这三个杠杆叠加，才能达到 80% 量级的差距。只做其中一两个，可能也就省 20% 到 30%。

3.3 为什么官方文档不会直接给你答案

如果你去看 Codex 的官方文档，会发现它不会列出一张“Token 最优实践清单”。因为 Codex 是通用编程 Agent，官方更关注功能完备性，而不是针对某一个用户的具体成本模型。

这意味着，Token 优化大部分时候是使用者的工程责任，而不是开箱即得的能力。好消息是，Codex 的配置体系是开放的，你可以通过调整配置、约束模型行为、设计提示词模板，让它更“省”。

判断依据：从社区反馈和使用体感看，Codex 的 Token 消耗差异极大，同样一个任务，有人烧 50 万 Token 都完不成，有人用 10 万 Token 就跑通。差距不来自模型的随机性，而来自使用方式。

4. 环境准备与前置条件

4.1 基础环境

在实操省流技巧前，先把基础环境准备好：

• 操作系统：Windows、macOS 或主流 Linux 发行版均可。本文示例以 macOS / Linux 的终端操作为主，Windows 用户建议在 Git Bash 或 WSL 中使用，命令行操作更顺手。
• Node.js：Codex CLI 需要 Node.js 环境，建议安装 Node.js 18 及以上版本（以官方要求为准）。可以用node -v检查。
• Codex CLI：可以先通过 npm 安装，也可以使用桌面版。本文重点讲 CLI 场景，因为 CLI 最容易做精细的配置控制。

如果还没有安装 Codex CLI，安装命令参考（具体版本以官方为准）：

npm install -g @openai/codex

安装后验证：

codex --version

如果提示找不到命令，检查 npm 全局 bin 目录是否在 PATH 中。

4.2 Codex 配置文件位置

Codex 的配置文件格式是 TOML。它在不同平台上的位置不同，但都会在用户目录下：

• macOS：~/.codex/config.toml
• Linux：~/.codex/config.toml
• Windows：%USERPROFILE%\.codex\config.toml

同时，Codex 也支持项目级配置，通常放在项目根目录的codex.toml中。项目级配置会覆盖用户级配置的对应项。这个机制对省 Token 很关键：你可以为不同项目设置不同的模型、不同的工具权限和不同的上下文策略。

4.3 基础配置示例

先看一个最简配置。文件路径：~/.codex/config.toml

model = "gpt-5.6-sol" model_reasoning_effort = "medium" approval_policy = "on-failure"

说明：

• model：指定使用的模型。这里的实际可选模型取决于你的账号和 Codex 版本，不需要死记，安装后可以运行codex --help查询本版本支持的模型。
• model_reasoning_effort：控制模型的推理强度。可选值通常有minimal、low、medium、high。这一项直接关系到 Token 消耗，后面会专门讲。
• approval_policy：控制工具调用是否需要人工批准。on-failure表示只在命令失败时暂停请求批准，能减少人工打断，也避免频繁的人工环节导致上下文分叉。

需要提醒的是：配置文件一旦写错，Codex 可能忽略它，并在启动时打印提示。热词里也出现了codex is ignoring 1 unrecognized configuration setting这样的报错，遇到时先看配置键名是否正确。

5. 实操技巧（一）：工作区设计——从源头减少 Token 负担

5.1 让 Codex 只看到它该看的

Codex 在执行任务时，会从工作区读取信息。如果你的工作区很大、文件很多、依赖很重，Codex 的每一步决策都可能把更多文件放进上下文。

先做一个基本动作：确认项目里的.gitignore内容，把无关目录都排除掉。比如：

# 项目级 .gitignore node_modules/ dist/ build/ *.log .tmp/

如果你的项目有庞大的dist或target目录，Codex 在导航文件结构时可能会读到它们，浪费 Token。把它们排除在工具能感知的范围内，是第一个低成本高收益的做法。

5.2 拆分“任务工作区”

在实际项目中，我建议开发者维护一个“最小任务工作区”的概念。不要把 Codex 指向整个企业级 Monorepo，而是针对单个服务、单模块开一个新的临时工作区。

比如你现在团队的项目叫payment-platform，里面有order-service、user-service、payment-service。你只让 Codex 去改order-service里的一个 bug，那就直接在order-service目录下启动 Codex，而不是在仓库根目录启动。

这样做的好处：

• 上下文里不会出现其他模块的文件路径和代码。
• Codex 在搜索符号、读取文件时，候选范围小，工具调用次数少。
• 任务本身更聚焦，模型的输出质量更高。

判断：分工作区不是“多此一举”。在 Monorepo 场景下，错误的工作区选择可能让 Token 消耗放大 3 到 5 倍。

5.3 精简 AGENTS.md

Codex 支持在项目里放一个AGENTS.md，用来给 Agent 提供项目约定和风格指南。这是一个非常有用的功能，但也很容易写过头。

我见过一些团队的AGENTS.md写了三千多字，从团队历史到部署流程全都有。Codex 在每一轮开始都会把它放进上下文，这就成了持续性的固定 Token 开销。

精简建议：

• 只保留“Codex 完成任务必需的规则”：代码风格、测试命令、构建命令、目录结构要点。
• 把冗长背景和团队管理规则挪到团队 Wiki，不要放在AGENTS.md。
• 按任务类型拆分成不同的指令文件，然后通过会话 prompt 指定。

一个精简示例：

# AGENTS.md ## 命令 - 测试：npm test - 构建：npm run build - 单文件测试：npm test -- <file> ## 代码风格 - 使用 TypeScript 严格模式 - 禁止 any 类型 - 新增函数必须写 JSDoc ## 约束 - 不要修改 package-lock.json - 不要删除公开 API

这个文件 200 字以内的效果，往往比 3000 字还强。

5.4 利用项目级配置控制模型和工具

在项目根目录创建codex.toml，可以针对当前项目做精细控制。例如：

# 项目根目录/codex.toml model = "gpt-5.6-sol" model_reasoning_effort = "low" approval_policy = "never"

这里把推理强度降为low。如果你的任务不是复杂的多步架构设计，而是改 bug、写单测，低推理强度能明显减少思考链路的 Token 用量。请注意：low不意味着质量一定下降，对于简单任务反而更直接，因为模型不会在无关的中间分析上绕圈。

风险提示：如果任务复杂度高、涉及跨模块影响分析，不要盲目用 low。推理强度降级后的错误可能带来反复调试，反而增加 Token。

6. 实操技巧（二）：会话管理——控制上下文累积速率

6.1 任务粒度小于会话粒度

Codex 的会话（Session）设计，本质上是为了在连续交互中保持上下文。但很多人的问题是：一个会话里塞了太多子任务。

比如“帮我看看 A 模块的 bug，改完顺便把 B 模块的接口文档写了，再给 C 模块补充测试”——这种需求丢给 Codex，它的上下文会在活跃任务之间反复切换，Token 消耗直线上升。

正确做法是：一个会话只解决一个任务单元。任务单元的定义可以是“完成一次代码修改并通过测试”或“生成一个模块的测试用例集”。

6.2 用--skip-git-repo-check要谨慎

在实际工作中，有人会在一个非 Git 目录或临时目录里启动 Codex，以绕开当前仓库的庞大上下文。Codex 通常要求在工作区内启动，并且会读取 Git 状态。如果确实需要在独立目录做实验，可以使用--skip-git-repo-check参数。

但这里要说明：这不是推荐在日常开发中滥用。跳过 Git 检查后，Codex 会少一些仓库上下文，但它也可能不理解你的分支、变更集，这对需要改动现有代码的场景是坏处。

真正有价值的用法是：当你想让 Codex“只基于一个空目录 + 你提供的 prompt”生成一段独立代码时，用这个参数可以隔绝仓库上下文，节省大量 Token。例如：

mkdir -p ~/tmp/codex-lab cd ~/tmp/codex-lab codex --skip-git-repo-check "写一个 Python 脚本，从 CSV 读取数据并生成报告"

这种用法非常适合“独立小任务”，但对“改现有项目”并不合适。

6.3 明确结束会话，避免隐形 Token 利息

Codex 支持在同一会话里继续交流。但每一次“继续”，都相当于把之前所有轮次的对话和工具结果重新处理一遍。如果你发现一个会话已经执行了 10 轮工具调用，而新任务和它没有强关系，那就直接开新会话。

判断会话该不该结束，可以用一个简单标准：

• 接下来要做的任务，是否还需要前面步骤产生的文件内容或结论？
• 如果不需要，就开新会话。
• 如果需要，但只需某个结论，可以在新会话的 prompt 里直接写出来，而不是带着全部历史。

6.4 断点与继续：codex resume

Codex 提供了继续会话的命令，比如：

codex resume

当你确实需要继续一个长任务时，这是可用功能。但请记住：只有当你确认这个会话的历史都是必要信息时，才使用 resume。否则更推荐新开会话，并手动把关键上下文写进 prompt。

经验提醒：长会话是最容易被忽视的 Token 黑洞。如果你发现自己在一个会话里从修 bug 聊到了重构方案，趁早停掉。

7. 实操技巧（三）：Prompt 模板与模型行为约束

7.1 结构化 Prompt 的作用

Codex 这类 Agent 工具，会把你的 prompt 作为任务的“规范源”。Prompt 写得模糊，模型就会用更多工具调用来“试探”，每试探一次就消耗一轮 Token。

省 Token 的 Prompt，核心不是字数少，而是决策边界清晰。看一个对比：

低效写法：

帮我看看这个项目有什么问题，然后修复一下。

这种 prompt 会让 Codex 先浏览目录结构、读多个文件、分析潜在问题，再决定改什么。一次下来很容易上万 Token。

高效写法：

在 src/utils/date.ts 中，函数 formatDate 对 2024-02-30 这类非法日期没有做校验，会返回无效结果。 请定位到该函数，增加 isValidDate 校验逻辑，并补充对应的单元测试。 约束： - 不要改动其它文件。 - 测试文件放在 src/utils/__tests__/date.test.ts。 - 修改后运行 npm test -- src/utils 验证。

这种 prompt 把范围、文件、验收方式全部框定，Codex 不会到处乱逛，Token 消耗大幅下降。

7.2 使用-p参数实现一次性任务

在不会话交互的场景下，Codex 支持非交互模式，非常适合执行一次性任务。比如：

codex -p "在 src/math.ts 中新增 add 函数，并运行 npm test"

使用-p时，Codex 直接完成任务并退出，不会进入持续对话。这能避免“任务完成之后人还在会话里聊几句”带来的 Token 浪费。自动化脚本、CI 集成都可以用这个模式。

7.3 通过 prompt 约束工具使用

Codex 在完成任务时，会自主决定是否读取文件、执行命令。我们可以在 prompt 里给它明确约束。示例：

请修改 src/api/user.ts 中的 getUser 函数，使其在用户不存在时返回 404。 约束： 1. 只允许读取 src/api/user.ts、src/services/userService.ts。 2. 不需要运行完整测试套件，只运行 npm run test:unit -- user。 3. 如果测试失败，最多检查 2 次。

这种约束的价值在于：把 Codex 的“行动空间”缩小，行动次数变少，Token 消耗和出错概率同时下降。

7.4 固定输出格式，减少冗长输出

Agent 型的模型天生喜欢“解释一下”“总结一下”，但在 Codex 场景里，输出越长，Token 越多。我们可以在 prompt 里要求模型输出聚焦：

请直接给出修改后的 diff，不要解释背景，不要附上无关的代码片段。

当然，不是说每次都强制让它闭嘴。在调试复杂 bug 时，模型的分析输出对定位问题有帮助。这里的原则是：根据任务类型动态决定输出详细程度，而不是永远让它输出一篇小作文。

8. 实操技巧（四）：Model Reasoning Effort 与工具策略配置

8.1 理解model_reasoning_effort

OpenAI 的模型体系里有“推理强度”概念。简单理解：模型在回复前会进行多长的内部推理链路。推理链路越长，Token 消耗越大，但复杂问题的准确性往往更高。

在config.toml里，通过model_reasoning_effort控制。参考值通常有：

配置值	适用场景	Token 相对开销
minimal	简单问答、格式化代码	很低
low	常见 bug 修复、单文件调整	低
medium	跨文件重构、测试生成	中
high	复杂架构设计、多模块影响分析	高

8.2 什么时候可以放心降档

一个非常实用的策略是：默认用 low，复杂任务临时用 medium 或 high。

怎么临时覆盖？你可以通过对话 prompt 里加一句“请仔细分析之后再动手”，或者在单独任务里用一个带临时配置的会话。不过更可靠的方式仍是调整配置文件，因为有些版本的模型名称固定默认推理强度，实际表现会因版本而不同。

以“修 bug”为例：

• 如果你已经明确知道 bug 的位置和原因，直接用 low 甚至 minimal，让它改，省 Token。
• 如果你只知道现象，需要 Codex 自己定位，用 medium，避免它“快刀乱麻”改错地方，后面反复烧 Token。

8.3 工具策略：approval_policy怎么影响 Token

approval_policy看似只影响“是否弹出确认”，实际上对 Token 有间接影响。

• never：Codex 自动执行命令，流程顺畅，但风险高。
• on-failure：只在失败时请求确认，常规命令自动执行。对省 Token 友好，因为它避免了“人机对话”夹带额外上下文。
• on-request：每次工具调用都需要确认，交互频繁，上下文多，Token 消耗升高。

推荐大多数日常场景使用on-failure。只有在高危操作（删除文件、改数据库等）才临时切到on-request。

# 用户级 config.toml model = "gpt-5.6-sol" model_reasoning_effort = "low" approval_policy = "on-failure"

8.4 日志与调试输出：log_level

Codex 的log_level影响本地日志详细程度，虽然主要不是 Token，但它会帮助你理解 Codex 在每个环节做了什么。省 Token 的核心能力之一就是“看见 Token 去哪了”。

在代码里临时查看调试日志：

codex --log-level debug -p "运行 npm test"

如果你发现日志里出现大量Read file: xxx，那说明 Codex 在反复读取大文件，很浪费。这时候应考虑缩小工作区范围，或者在 prompt 里明确禁止读取某类文件。

判断：Token 优化不是一次配置就结束。真正有效的方法是，先看日志，找到消耗热点，再针对性调整。

9. 常见问题与排查方法

9.1 高频问题清单

问题现象	可能原因	排查方式	解决方案
登录时报token exchange failed: token endpoint returned status 403 forbidden: country	所在地区无法访问认证服务，或网络中间层拦截	检查当前网络出口和代理配置	使用合规的网络访问方式；必要时联系团队协助处理网络策略
报sign-in could not be completed token exchange failed: error sending request	认证服务连接失败，网络不稳定或代理异常	查看终端代理环境变量，确认认证域名可访问	清理代理设置，或暂时关闭代理后重试
your access token could not be refreshed. please log out and sign in again	登录态过期或 refresh token 失效	执行codex logout后重新登录	重新执行codex login
failed to refresh token: 400 bad request: invalid 'refresh_token': empty string	本地存储的登录态损坏	查看~/.codex下的 auth 缓存文件	删除本地 auth 缓存后重新登录
codex is ignoring 1 unrecognized configuration setting	config.toml 中存在拼写错误或当前版本不支持的配置	检查配置键名，对照官方文档	删除或修正无效配置项
任务执行中 Token 消耗异常增加	工作区过大、AGENTS.md 太长、会话过长	打开 debug 日志，观察工具调用和文件读取	按本文第 5/6 节策略收敛上下文
cc switch local proxy failed while handling codex endpoint /responses	本地代理切换失败，导致 Codex endpoint 请求异常	检查代理配置和本地网络服务	修正代理设置，或改用直连（合规前提下）

9.2 Token 突然烧得很快的排查路径

如果你发现 Token 消耗突然异常，按下面顺序排查：

1. 先看最近一次会话的上下文是否过长。打开会话列表，评估是否应该结束当前会话。
2. 查看 debug 日志，统计Read file和Run command的次数。如果工具调用次数超过任务需要，多半是 prompt 不够精确。
3. 检查AGENTS.md是否在最近被扩充了。
4. 检查工作区是否意外包含了构建产物目录。
5. 检查model_reasoning_effort是否被设成了high，对于本不该高推理的任务，这属于降不下来的浪费。

9.3 登录问题的处理顺序

登录问题更多是认证链路问题。出现token exchange failed相关报错时，按这个顺序处理：

# 1. 登出清缓存 codex logout # 2. 清本地认证缓存（不同版本位置可能不同） rm -rf ~/.codex/auth.json # 3. 重新登录 codex login

提醒：如果团队里使用了统一的代理或认证网关，先和网络管理员确认策略，而不是反复重试。

10. 最佳实践与工程建议

10.1 把 Token 优化融入团队流程

省 Token 不能只靠个人自觉，最好把规则沉淀到团队文档和配置模板里：

• 统一维护一份精简版AGENTS.md模板，团队所有项目共用。
• 每个项目根目录放codex.toml，明确模型、推理强度、批准策略。
• 在 CI 脚本里用codex -p非交互模式执行固定任务，避免人工会话干扰。

10.2 建立安全边界

Codex 是有工具执行能力的 Agent，在省 Token 的同时不能忽略安全：

• 生产环境变更必须在测试环境验证，且要有备份和回滚方案。
• 涉及数据库、删除操作、权限变更时，即使approval_policy设成never，也要先走人工审核。
• 合理控制 Codex 能访问的路径和环境变量，避免意外读取机密文件。
• 代码审查环节不能完全依赖 Codex 的输出，最终合入前应由开发者复核。

10.3 日志与可观测性

如果你负责团队工具建设，建议记录每个 Codex 任务的 Token 消耗和耗时。虽然本文不涉及具体平台 API，但你可以通过codex --log-level输出的事项，在本地做统计。

一个实用的做法是，在每个任务的 prompt 末尾要求 Codex “在结束后用一行说明本次改动文件和测试结果”。这样即使开了新会话，后续开发者也能快速理解上一次做了什么，不至于在旧会话里反复翻历史。

10.4 什么时候不该省 Token

我必须补充一个反直觉的建议：不是所有场景都该省 Token。

• 当你需要 Codex 做完整架构审查、安全扫描时，强制用low推理强度可能漏掉关键风险。
• 当你在处理复杂并发问题或跨模块数据流时，让它多读取文件、多分析，反而能避免更贵的“返工 Token”。
• 当你刚接触 Codex，还不熟悉它的行为边界时，优先关注正确性和安全性，不要一开始就极限压 Token。

省 Token 的正确目标，是让 Token 花在“必要的高价值推理”上，而不是不花。

11. 从“降到省”到“用得聪明”：一个完整参考流程

最后给你一个可以直接照抄的流程，把文章里所有技巧整合成一个可执行的闭环。

第一步：创建干净的隔离工作区

mkdir -p ~/projects/order-service-fix cd ~/projects/order-service-fix

第二步：在项目根目录放置配置

# 项目根目录/codex.toml model = "gpt-5.6-sol" model_reasoning_effort = "low" approval_policy = "on-failure"

第三步：写精简 AGENTS.md

只包含测试命令、代码风格、禁止修改的文件清单。

第四步：用结构化 prompt 启动任务

codex "在 src/processor.ts 的 processOrder 函数中修复库存扣减未做负数校验的问题。约束：1. 只修改 src/processor.ts；2. 新增单测到 src/__tests__/processor.test.ts；3. 修改后运行 npm test"

第五步：任务完成后检查差异，结束会话

git diff --stat

如果差异符合预期，直接关闭会话。如果不符合，再进入会话补充纠正，但不要在无关话题上继续聊。

第六步：定期用 debug 日志复盘

看到大量无效 File Read 时，下次任务就收紧 prompt 里的文件范围。

这个流程看起来简单，但执行到位的人不多。核心不是配置本身，而是你每一次任务都愿意花 30 秒设计 prompt 边界和会话边界。这才是让 Codex 真正省 80% Token 的根本方法。

12. 结语：Token 应该花在“决策”上，而不是花在“摸索”上

Codex 是一个强大的编程 Agent，但它并不是一个会自动帮你省钱的工具。它的默认行为偏向“尽力完成”，而不是“尽量少花”。所以作为使用者，你需要把“任务边界”定义清楚：让它在哪个目录工作、看哪些文件、执行哪些命令、输出多详细、推理多深入。

这套方法的底层逻辑很简单：Token 应该花在“决策”上，而不是花在“摸索”上。Codex 每一次多余的读文件、每一次超出任务的推理、每一段保留过长的历史会话，都是隐形的成本。

希望你从本文得到的不只是几个配置片段，而是一种对 Agent 工具成本结构的新理解。下次打开 Codex 时，先问自己一句：这个任务的最小上下文是什么？想清楚再动手，Token 自然就省下来了。

建议把本文收藏备用，尤其是第 5、6、7 节的操作清单，实际项目中可以反复对照。如果你想继续深入学习，下一步重点关注两个方向：一是 Codex 的本地配置项在不同版本中的差异，二是 Agent 工具调用策略和模型推理强度在不同任务类型中的最优组合。这两个方向理解透了，你不仅能省 Token，还能让 Codex 的输出质量再上一个台阶。