Codex Token 利用：低消耗、高质量使用手册
历史范围：本文保留来源记录中的模型系列、费率示例和界面名称，未将其核验为当前可用配置。计量方法与任务组织原则可参考；实际模型和价格请以文末官方入口及账号界面为准。
节省 Token 不是单纯缩短提示词，而是减少无效上下文、无边界搜索、超长工具输出和反复返工。
最低足够模型 × 最小必要上下文 × 最小工具集 × 明确验收标准 = 更低 Token + 更高一次成功率
一、一页结论
| 需求 | 优先选择 | 应避免 |
|---|---|---|
| 读取、修改和运行本地代码 | Codex 内置文件、Shell、Git 和测试工具 | 粘贴整个仓库或优先接入 MCP |
| 固定项目规范 | AGENTS.md | 每次重复粘贴规范 |
| 重复的标准流程 | Skill | 长期复制同一段提示词 |
| 可共享且带外部集成的流程 | Plugin | 安装所有可能用到的插件 |
| 外部实时数据或操作 | MCP | 拉取完整历史和无关字段 |
| 复杂、模糊或高风险任务 | Plan Mode + 较强模型 | 未调查就大范围修改 |
| 可独立并行的调查 | Subagents | 为小任务启动多个代理 |
推荐默认策略：
- 日常开发使用 Terra + Medium。
- 清晰、机械、可重复任务使用 Luna + Low。
- 架构、疑难调试、大迁移和安全审查使用 Sol + High。
- 一个会话尽量只处理一个目标；主题明显变化时新开会话并附简短交接摘要。
- 本地问题先使用内置工具；只有信息在仓库外或需要外部动作时才使用 MCP 或插件。
模型的详细区别参见：模型对比 & 模型选择。
二、Token 浪费在哪里
一次 Codex 任务的消耗主要来自：
- 固定上下文：系统指令、
AGENTS.md、Skill 简介和工具定义。 - 任务上下文：提示词、附件、选中代码和粘贴日志。
- 工具回传：搜索结果、命令输出、测试日志和 MCP 数据。
- 模型输出与推理：计划、解释、代码和最终总结。
- 返工与并行：重复读取、多轮纠错和子代理的独立调用。
最常见的浪费包括：
- 要求读取整个仓库，而不是从路径、符号或失败测试开始定位。
- 直接粘贴整份日志，真正相关的却只有几行。
- 所有任务都使用最强模型和最高推理等级。
- 同时启用大量插件、MCP 工具或子代理。
- 没有给出范围、约束和完成条件，导致模型反复猜测。
- 无关任务持续堆在同一个长会话中。
- 最终只需要补丁，却要求长篇背景解释。
优化优先级通常是：
text
减少返工 > 限制工具输出 > 缩小读取范围 > 选择合适模型 > 缩短最终回答三、使用任务契约代替长提示词
高质量任务至少应包含 目标、上下文、范围、约束和完成条件。
text
【目标】
要解决什么问题，最终产生什么结果。
【上下文】
相关文件、目录、错误、Issue 或已知事实。
【范围】
允许读取和修改的路径；明确排除哪些内容。
【约束】
架构、安全、兼容性、依赖和编码规范。
【工具策略】
优先使用哪些工具；哪些工具不要使用。
【执行方式】
直接实施还是先调查和计划；是否允许子代理。
【完成条件】
需要通过哪些测试、Lint、类型检查和行为验证。
【输出格式】
限定最终需要的改动、证据、风险和篇幅。示例
低质量任务：
text
帮我优化登录功能，顺便修复问题。更有效的任务：
text
【目标】
修复 Access Token 过期后登录接口偶发返回 500 的问题。
【上下文】
错误入口为 internal/auth/refresh.go，相关测试在 internal/auth/refresh_test.go。
【范围】
只修改 internal/auth/；不修改数据库结构和公共协议。
【约束】
保持 Go 1.23 兼容，不增加依赖，使用最小 diff。
【工具策略】
先用 rg 定位错误处理链，第一轮最多读取 5 个文件；不要联网或调用 MCP。
【完成条件】
过期 Token 返回 401，其他异常仍返回 500；相关测试、go test 和 lint 通过。
【输出格式】
只报告修改文件、根因、验证结果和剩余风险。四、上下文控制：先定位，再读取
本地代码任务推荐按以下顺序执行：
text
精确搜索 → 读取少量相关文件 → 最小修改
→ 针对性测试 → 完整验证 → Review 最终 Diff可以在任务中直接加入：
text
先使用文件名、符号名和 rg 定位最相关文件。
第一轮最多读取 5 个文件，不扫描 node_modules、dist、vendor、生成目录和大日志。
需要扩大范围时，先说明证据和原因。其他实用规则：
- 提供入口文件、错误堆栈中的首个业务位置或失败测试名称。
- 使用
git diff -- <path>，避免无差别读取所有变更。 - 在大型仓库中明确允许和禁止访问的目录。
- 稳定结论用简短摘要记录，避免重复读取同一批资料。
- 新主题使用新会话，只携带必要的交接结论。
五、限制工具输出
工具输出往往比提示词更容易占满上下文。
Shell 和测试
- 第一轮运行针对性测试，通过后再扩大验证范围。
- 使用
rg、git diff --stat和限定路径的 diff。 - 长日志只保留失败摘要、首个根因、相关堆栈和退出码。
- 超长输出先写入日志文件，再搜索关键模式，不要全部回传到对话。
可复制指令：
text
命令输出超过 200 行时不要完整回传；
只保留失败摘要、首个根因、必要堆栈和命令退出码。Web Search
- 纯本地仓库任务关闭搜索。
- 一般外部资料优先使用缓存或已索引结果。
- 当前版本、近期发布和实时信息才使用在线搜索。
- 已经存在于仓库文档中的内容，不要重复联网查找。
最终回答
最终输出通常只需要：
- 修改了哪些文件。
- 根因或关键设计决策。
- 执行了哪些验证及结果。
- 剩余风险和未解决事项。
六、把长期信息放在正确位置
AGENTS.md：稳定项目规则
适合保存：
- 仓库结构和关键目录。
- 构建、测试、Lint 和类型检查命令。
- 架构约束、编码规范和禁止事项。
- Code Review 标准和完成定义。
AGENTS.md 应短、准、可执行。根目录保存通用规则，子目录只补充局部差异。不要写长篇背景和模糊口号。
Skill：重复操作流程
适合封装 PR 检查、日志诊断、发布说明、数据库迁移规划等重复流程。Skill 按需加载，比把所有流程长期塞进 AGENTS.md 更节省上下文。
Plugin：团队共享的能力组合
适合分发 Skill、外部应用、MCP 和标准工作流。只安装确实需要的插件，当前任务只启用相关能力。
MCP：外部实时上下文
仅在信息不在仓库、数据经常变化或需要执行外部动作时使用。调用时限制服务器、工具、字段、日期范围和返回数量。
text
使用 GitHub MCP 读取指定仓库的 Issue #842：
- 只读取标题、正文、标签和最近 10 条评论；
- 不读取其他 Issue，不调用写工具；
- 返回结构化摘要，不返回完整历史；
- 再结合本地指定目录分析根因。七、Plan Mode 和 Subagents
什么时候使用 Plan Mode
适合：
- 需求模糊或有多个合理方案。
- 改动跨模块、跨服务。
- 需要迁移、兼容或回滚设计。
- 错误成本高。
明确的小函数修改、指定测试或机械转换可以直接执行，无需为规划额外消耗 Token。
Subagents 不是省 Token 工具
子代理能减少主会话的上下文污染，但每个代理都会独立调用模型和工具，总消耗通常更高。
只在多个任务可以独立并行时使用，例如分别分析代码、测试和日志。避免多个代理同时修改同一批文件。
text
每个子代理只负责一个明确的只读范围，不修改代码，
最多返回 8 条结论和必要证据；
主代理汇总、去重并验证后再决定是否实施。八、三套标准工作流
简单、明确任务
- Luna + Low。
- 指定文件、符号和完成条件。
- 不使用 Plan Mode、MCP 和子代理。
- 运行一个针对性验证。
- 最终只输出改动、测试和风险。
常规工程任务
- Terra + Medium。
- 先搜索定位，第一轮读取少量文件。
- 采用最小 diff。
- 针对性测试通过后再运行更广验证。
- Review 最终 Diff。
复杂、高风险任务
- Sol + High。
- 使用 Plan Mode 明确假设、方案和回滚策略。
- MCP 只接入必要的外部系统。
- 子代理只承担独立、只读调查。
- 分阶段实现，每阶段独立验证。
- 最终复核 Diff、风险和证据。
九、可复制的 Token 纪律
text
Token discipline:
- Use the smallest sufficient model and reasoning level.
- Inspect before editing; start from exact paths, symbols, or failing tests.
- Do not scan generated directories or the entire repository without evidence.
- Read at most 5 relevant files in the first pass; explain before expanding scope.
- Prefer rg, targeted tests, and focused git diff commands.
- Do not return full logs; return failing lines, root cause, exit code, and a concise summary.
- Do not use web search, plugins, MCP, or subagents unless they materially help.
- Keep the final answer concise: changed files, tests, risks, and unresolved items.十、团队落地检查表
- [ ] 根目录有短而准确的
AGENTS.md。 - [ ] 写明构建、测试、Lint 和完成标准。
- [ ] 团队已确定默认模型与升级策略。
- [ ] 重复流程已转成单一职责 Skill。
- [ ] 插件和 MCP 使用最小权限及工具白名单。
- [ ] 大日志有摘要或截断策略。
- [ ] 复杂任务使用 Plan Mode，简单任务直接执行。
- [ ] 子代理只用于收益明确的独立并行任务。
- [ ] 最终输出固定包含改动、验证、风险和未解决事项。
建议持续观察一次通过率、平均对话轮数、模型升级率、工具输出量和测试返工率。真正有效的 Token 优化，应同时降低平均消耗并提高首次验收成功率。
参考资料
继续阅读
- AI与Codex上手与对象
- AI与Codex上手与对象
- AI与Codex任务与配置Codex 插件用途与选择记录 · 历史版本