最近在使用 Codex 开发项目时，经常会看到 Token、Context Window、上下文等概念。

一开始我以为：

Prompt 写得短一点，就能节约 Token。

后来发现其实不是这么简单。

对于 Codex 这类 AI Agent 来说，真正消耗 Token 的往往不只是我们输入的那几句话，还包括：

系统 Instructions
+
AGENTS.md
+
历史对话
+
读取到的项目代码
+
Tool 返回结果
+
测试日志
+
错误信息
+
模型输出

所以真正想节约 Token，核心不是：

少写几个字。

而是：

尽量减少无关内容进入模型 Context。

下面总结几个比较实用的方法。

---

一、Prompt 要明确任务范围

比如有一个 Spring Boot 项目，现在想增加“意见反馈”模块。

如果只告诉 Codex：

帮我增加一个意见反馈功能。

Codex 不知道这个功能涉及哪里，可能会：

查看整个项目目录
↓
搜索很多 Controller
↓
搜索很多 Service
↓
读取前端页面
↓
查看数据库
↓
寻找类似功能

这样很容易读取大量无关代码。

更推荐写成：

新增“意见反馈”后端功能。

要求：
1. 只修改 backend，不修改 frontend。
2. 参考现有 notice 模块的实现方式。
3. 保持 Controller → Service → Mapper → Entity 分层。
4. 不修改其他业务模块。
5. 只读取完成当前任务真正需要的文件。

Prompt 虽然变长了一点，但是它可以让 Codex 少读取很多无关代码。

所以：

Prompt 长一点不一定更费 Token，范围明确反而可能更省 Token。

---

二、不要动不动让 Codex“分析整个项目”

例如：

先仔细分析整个项目，
然后修改用户管理页面。

如果只是修改一个页面，其实没有必要让 Codex 先把整个项目分析一遍。

更好的方式是：

修改用户管理页面。

先定位用户管理相关的前后端文件，
只分析完成当前任务需要的代码，
无需分析整个项目。

因为：

项目总代码量
≠
模型真正需要看到的代码量

一个项目可能有几十万行代码，但当前任务真正需要看的，也许只有几个文件。

---

三、给 Codex 指定“参考模块”

这个方法在实际开发中非常好用。

比如新增：

Feedback 模块

项目中已经有一个：

Notice 模块

两者结构比较类似，就可以直接告诉 Codex：

Feedback 模块参考现有 Notice 模块实现，
不要遍历其他业务模块寻找参考代码。

这样 Codex 可能只需要读取：

NoticeController.java
NoticeService.java
NoticeMapper.java
NoticeEntity.java

而不是把：

User
Order
Role
Permission
Report
Student
Course
……

全部搜索一遍。

简单来说：

我们越清楚告诉 Agent 去哪里找，它越不容易到处乱翻。

---

四、一个独立功能尽量使用一个会话

Codex 在同一个会话里继续工作时，前面的：

聊天记录
代码读取结果
Tool 调用
错误日志

都会形成历史 Context。

比如一个会话连续开发：

登录
↓
用户管理
↓
权限管理
↓
订单
↓
报表
↓
知识库

会话会越来越长。

所以比较推荐：

用户管理
→ 一个会话

意见反馈
→ 一个会话

知识库
→ 一个会话

但是也不要走另一个极端。

如果都是同一个功能：

开发意见反馈
↓
增加反馈类型
↓
增加状态筛选
↓
修复分页问题

继续在同一个会话里更合适。

否则新开会话以后，Codex 又要重新读取 Feedback 相关代码。

可以简单记成：

相关任务继续聊，无关任务新开会话。

---

五、AGENTS.md 不要写得太长

AGENTS.md 会作为项目 Instructions 提供给 Codex。

所以它不适合写成一本完整的项目需求说明书。

不建议：

AGENTS.md

项目背景       1000行
全部需求       3000行
数据库设计     2000行
接口文档       2000行
历史Bug        1000行
……

更推荐只保留真正长期有效的规则：

# 项目开发要求

- 优先最小范围修改。
- 只修改用户明确要求的功能。
- 不主动重构无关代码。
- 未明确要求前端时，不读取和修改 frontend。
- 优先参考当前功能附近已有模块。
- 修改完成后运行必要测试。

详细文档：

- UI规范：docs/ui.md
- 权限说明：docs/permissions.md
- 数据库说明：docs/database.md

也就是：

AGENTS.md 放核心规则和“地图”，详细资料需要的时候再读取。

---

六、控制 Shell、测试和日志输出

这一点特别容易被忽略。

例如 Codex 执行：

mvn test

可能返回几千行日志。

实际上真正有用的可能只有：

ERROR
Exception
Caused by
FAILURE

这些内容。

如果几千行日志全部进入 Context，会消耗很多 Token。

所以可以使用：

tail
head
grep
rg

提前过滤。

例如：

mvn test 2>&1 | tail -n 200

或者：

mvn test 2>&1 | grep -E "ERROR|Exception|Caused by|FAILURE"

Docker 日志也一样。

不要直接：

docker logs xxx

可以使用：

docker logs --tail 200 xxx

或者：

docker logs --since 10m xxx

核心思想就是：

不要把几千行垃圾日志交给模型，让模型自己找那几行错误。

---

七、可以使用 RTK 一类的 Token 压缩工具

除了手工使用 grep、tail 等命令，现在也有一些专门针对 AI Coding Agent 的 Token 优化工具。

例如：

RTK

这类工具主要解决的是：

Shell 命令返回内容太多的问题。

原来可能是：

Codex
↓
执行 mvn test
↓
返回 5000 行
↓
5000 行进入 Context

加入输出压缩以后：

Codex
↓
执行命令
↓
输出过滤 / 压缩
↓
只保留关键内容
↓
再提供给模型

比如：

原始输出：5000 行

        ↓

过滤、压缩

        ↓

实际给模型：300 行

RTK 只是其中一种实现方式。

本质上都是：

在 Tool Result 进入模型 Context 之前，先把噪音去掉。

---

Codex 需要知道自己有哪些 Tool 可以调用。

如果同时配置很多：

GitHub MCP
数据库 MCP
浏览器 MCP
Jira MCP
Slack MCP
PostgreSQL MCP
……

即使当前任务根本用不到，部分工具定义仍然可能占用上下文。

所以：

真正长期不用的 MCP，没有必要全部开启。

需要什么能力，再给 Agent 什么能力。

这和项目代码一样：

不是越多越好
而是刚好够用最好

---

九、不要为了省 Token 而省掉必要测试

节约 Token 不是：

不测试
不看日志
不分析代码

而应该是：

先小范围验证
↓
发现错误只看关键日志
↓
功能基本完成
↓
最后再做完整构建或测试

比如：

修改 Feedback 模块
↓
先运行相关测试
↓
修复问题
↓
最后 mvn test / npm run build

这样既能控制 Token，也不会影响开发质量。

---

十、最后总结

使用 Codex 节约 Token，可以重点记住下面几条：

1. Prompt 明确“改哪里、不改哪里”

2. 不要动不动分析整个项目

3. 给 Codex 指定可以参考的模块

4. 相关任务继续原会话，无关任务新开会话

5. AGENTS.md 保持精简

6. 使用 grep、tail、RTK 等减少 Tool 输出

7. 不需要的 MCP / Tool 不要全部开启

8. 先小范围测试，最后再完整验证

其实真正的核心只有一句话：

节约 Token 的关键，不是让 Prompt 尽可能短，而是让 Codex 每一轮只看到完成当前任务真正需要的信息。

可以把它简单总结成：

少读无关代码
+
少带无关历史
+
少返回无关日志
+
少加载无关工具
=
更少的 Token 消耗

从 Harness 的角度来说，这其实就是：

Context Management / Context Engineering。

好的 AI Agent 不是把所有资料都塞给模型，而是在正确的时候，把正确的信息交给模型。