让 Codex 自己查账：一个省 token 的小技巧

最近我发现一个挺实用的小技巧：让 Codex 自己回顾最近的运行记录，分析哪些地方在浪费 token。

这件事看起来有点绕，但实际很简单。你不用先去翻一堆日志，也不用自己算每次工具调用占了多少上下文，直接把下面这段话甩给它就行：

回顾你过去的运行记录，分析怎样才能更省 token，可以考虑用某些 skill、脚本，或者切换模型，根据分析结果去调整设置，但不能牺牲原本的性能和能力。

我自己跑了一遍，发现它真能把一些平时看不见的浪费点翻出来。

很多时候我们以为 token 是花在“写代码”上，其实不是。真正贵的地方，往往是它为了找到信息、理解上下文、处理工具返回结果、带着一堆历史继续跑子任务时，一点点烧掉的。

它会看什么

这个提示词的核心，不是让 Codex 给一堆泛泛而谈的省钱建议，而是让它基于自己的历史记录做诊断。

它通常会去看几类东西：

这些问题人当然也能查，但麻烦。让 Codex 自己查，优势是它离运行现场更近，能把“我刚才到底浪费在哪”说得比较具体。

我这边最明显的问题是：喂给它看的东西太杂、太多。

比如一个任务本来只需要看某个函数附近几十行代码，结果它可能整篇文件都读进来了。一个工具返回了几千行日志，真正有用的只有中间两段，但上下文里已经被原始日志塞满。再比如一个子 agent 只负责查一个小问题，却带着主 agent 前面所有讨论一起出门。

这些都不是“模型不聪明”，而是工作方式太粗。

对于 Agent 来说，上下文不是免费的草稿纸。每多读一点，每多塞一点，每多保留一点，都会变成后续推理的负担。

这次诊断后，Codex 给我列了几条比较实在的优化方向。

第一，读文件不要一上来整篇塞进去。先搜索定位，再分批读，只读和当前问题有关的部分。如果工具返回结果太长，先截断、筛选或者摘要，再把关键信息交给模型。

第二，截图这类素材不用默认上最高精度。能用低分辨率判断布局、颜色、结构的，就没必要动不动传原图。尤其是只做初步判断时，高精度往往只是增加成本。

第三，同一个操作失败了，不要原地重试好几遍。先看错误信息、确认失败原因，再动手。很多 token 就浪费在“没搞清楚问题但又跑了一遍”上。

第四，子 agent 接任务时，只给它完成这个任务必需的信息。不要把主 agent 一路积累的历史全部打包甩过去。子任务越小，上下文越应该干净。

第五，skill 也不是越多越好。需要哪个加载哪个，不要每次都把一堆用不上的规则放进上下文。skill 的价值是让模型更懂当前任务，不是让它背着一个工具箱跑全程。

这里有个很重要的前提：Codex 输出的分析不一定全都准确。

它能看到一部分运行痕迹，也能根据日志做推断，但这不代表每条建议都适合你的项目。比如有些任务确实需要读完整文件，有些截图确实需要高清，有些复杂重构也确实应该用更强模型。

所以更稳的做法不是“它说什么就改什么”，而是拿几个自己平时常跑的任务做对比：

省 token 的目标不是让 Codex 少干活，而是让它少做没必要的活。

我觉得这个玩法还有一个更有意思的方向：把它扩展成项目知识库蒸馏。

因为它真正依据的不是某个抽象理论，而是你过去的对话历史、任务记录、失败案例和项目上下文。这些东西本来就有价值，只是平时都散落在会话里。

如果进一步整理，就可以沉淀出几类数字资产：

换句话说，省 token 只是第一层收益。更长期的收益，是把一次次对话变成可以复用的项目经验。

如果你最近用 Codex 比较频繁，可以试试这句提示词：

回顾你过去的运行记录，分析怎样才能更省 token，可以考虑用某些 skill、脚本，或者切换模型，根据分析结果去调整设置，但不能牺牲原本的性能和能力。

跑完之后不要急着全盘照抄，先挑两三个高频任务做 A/B 对比。只要能在不牺牲结果质量的情况下减少无效读取、重复调用和过载上下文，这条规则就值得留下来。

真正省 token 的方法，从来不是让 Agent 少知道一点，而是让它更快知道该知道什么。