从一次并行任务复盘 Codex 的 token 消耗

AI

开发只花 3 分多钟，验证却耗尽 5 小时额度

这次经历始于一次并行开发。我给一个 iOS 客户端接入新功能，改动涉及 iOS 和 API 两端，还要参考 Obsidian 里的 TaskSpec。为了看看多个子 Agent 并行能不能提速，我把任务拆开交给它们。3 分多钟后，代码已经写完，任务进入验证阶段。

问题出在验证。任务多次申请 Docker、Xcode 等工具权限，我逐一批准。验证还没结束，5 小时限额已经耗尽，我又额外花了 2 刀的 credit。最后只产出了几个文件，额度消耗却像做了一次大型任务。

这让我开始重新想并行带来的成本。代码没多少，token 到底花在哪儿？

最近 Codex 更新后，我也明显感觉 token 消耗变快。Plus 用户的 5 小时额度有时只够半小时左右的实际工作，之后就只能等下一个窗口。

想省 token，得先弄清楚它们花在了哪里。

先还原消耗路径：token 花在了代码之外

我后来用 ChatGPT 回看这次任务。整个过程包括理解需求、定位项目、分发子任务、实现、验证，以及根据结果排查问题。每一步都有用，累加起来，成本也跟着上升。

任务开始时，Agent 先读指令、项目规则、Skill 和 TaskSpec，弄清 iOS、API 和文档之间的关系。子 Agent 并行后，每个 Agent 还会分别加载相关上下文、浏览目录、搜索文件，再推理实现路径。并行缩短了开发时间，也让多个 Agent 重复加载相似信息。

成本最容易在验证阶段继续增加。构建指定 Scheme、启动 Docker、运行测试、读日志、失败后重试，每一步都会带来新的上下文和工具输出。验证目标没有提前收窄时，Agent 可能从确认改动能否工作，扩展到排查环境里的所有不确定性。代码写完了，token 还在继续消耗。

多 Agent 和验证都有价值。任务不同阶段需要不同的上下文和预算。子任务重叠时，并行会造成重复；到了该收敛的时候，也要及时停下来。

解决问题：把上下文和预算用在需要的环节

让规则按作用域出现

AGENTS.md 不必写成一个包罗万象的大文件。按我现在的项目结构，可以分成几层：Workspace 层说明工作流和项目路由，Project 层记录项目级约束，Repo 层写架构、验证要求和具体的 Skill 路由。

目前我的项目分层如下：

1
2
3
4
5
6
7
8
9
10
Workspace/
├── AGENTS.md
└── Development/
    ├── AGENTS.md
    ├── ios/
    │   └── AGENTS.md
    ├── backend/
    │   └── AGENTS.md
    └── web/
        └── AGENTS.md

重点是把边界划清楚。规则只在需要的范围内生效，同一条内容不必在多个层级重复。AGENTS.md 说明边界、路由和强制约束；Skill 写具体做法。同类规则保留一个来源，可以少占上下文，也不容易互相冲突。

Skill 不必每次都自动加载。高频且与当前开发类型直接相关的能力，可以由 AGENTS.md 路由；低频能力则在 Prompt 明确提出需要时再加载。做 iOS 功能时，swift-architecture、swift-concurrency、swiftui-navigation 可以作为高频 Skill，其他能力按需引入。需要时照样能用，没必要每次都放进上下文。

给 Agent 划定探索范围

Agent 的探索成本和搜索范围有关。面对一个 Workspace，它不必每次重新摸清整个开发目录；处理文档时，也不必默认扫描整个 Vault。

Prompt 里最好写明 Target Project、Target Feature、Target Files、Allowed Changes 和 Do Not Touch。文档任务也一样，先限定项目目录，再指定文档和要处理的 Section。这次任务如果提前指出相关的 TaskSpec、iOS 模块和 API 模块，每个 Agent 就不必从整个 Workspace 或 Vault 开始找入口。

把边界写清楚，能少掉无谓的查找和猜测。

给推理和验证设定预算

高推理预算留给需要权衡的环节。架构设计可以用 High，复杂调试用 Medium 或 High；普通 UI 修改和常规实现用 Low 或 Medium 通常足够。验证阶段适合用较低预算，因为目标是按明确标准确认结果，不必重新做一轮架构思考。

验证范围也要跟改动对应。一个可用的默认组合是构建指定 Scheme，再运行本次新增或直接相关的 Unit Test。UI 的视觉效果交给人确认，UI Test 不必默认运行。机器适合做稳定、成本低的检查；为了形式完整而收集大量日志、引入环境噪声并反复重试，只会让验证更贵。

验证还需要明确的停止条件。如果 Docker 或 Xcode 的问题与本次改动无关，就记录为环境阻塞，不要反复重试。要扩大验证范围时，先说明原因和预期收益。批准工具权限不代表可以无限排查，工具权限和排查范围需要分别管理。

用 Spec 和 Plan 减少后期返工

很多返工可以在 Codex 大量读取代码之前避免。Spec 写清目标、非目标、修改边界和验收标准；Plan 列出需要修改的模块、顺序、风险和验证方法。也可以为它们准备模板，固定输出格式。

这套流程能提前把需求说清楚。需求和验收标准越明确，Agent 越少需要一边探索、一边实现、一边猜用户的意图。前面多花一点时间收敛，后面就能少读代码、少改方案，也少跑一轮验证。

可以先落地的三条原则

  1. 让 AGENTS.md 和 Skill 只带入当前任务需要的内容。工程规则和能力不必全部默认加载：AGENTS.md 留下当前层级的边界、路由和强制约束，Skill 用到时再加载。这样能减少固定 token 成本，也能降低规则重复和冲突的概率。

  2. 按问题复杂度选择 Reasoning。架构取舍和复杂 Debug 可以提高推理预算；常规 UI 修改、简单实现和有明确标准的验证通常用较低预算就够。把高成本推理留给真正存在不确定性的环节。

  3. 根据变更范围验证。修改哪个模块，就构建对应的 Scheme 并运行直接相关的测试。小范围改动通常不需要默认跑全量测试、多个 Scheme 或排查无关环境。验证要为当前改动提供足够证据，不需要证明整个工程没有其他问题。

子 Agent 也适用这些原则。任务能独立交付、几乎不需要共享上下文时，并行更有意义。如果几个 Agent 都要读同一份 TaskSpec、扫描同一仓库，还等着同一轮验证，开发会更快，token 消耗也可能成倍增加。

从四个环节优化 token 消耗

复盘下来，我会从四个环节控制 Codex 的 token 消耗：Context Engineering、Agent Routing、Reasoning Budget 和 Verification Budget。它们分别对应四个问题：哪些信息进入上下文，能力何时加载，哪些决策需要高强度推理，以及哪些检查值得投入成本。

日常使用时，可以先减少无效 Context、重复探索、高成本推理、不必要验证和返工，提高一次完成任务的机会。让 Agent 在恰当的时候拿到完成任务所需的信息，有了足够证据就停下来。这样既能减少 token 消耗，也能让 Agent 的行为更稳定、工作流更清楚。

以上只是我基于一次实际任务和日常使用的个人思考。若有理解不准确或遗漏之处，欢迎指正。