关于 Token 用量的建议，大多都在优化问题的另一端。你输入的提示词很少是开销 的大头。真正消耗 Token 的，是 Agent 代你读进去的一切：文件内容、命令输出、 测试日志，以及不断增长的历史对话记录。

下面的方法按实际节省效果排列，而不是按技巧的巧妙程度。

少读每个文件

为了改一个函数而打开 2000 行的文件，Agent 的大部分预算都花在了永远用不上的 上下文里。先搜索，再只打开需要的那一段。

这种节省会累积，因为 Agent 读过的每个文件都会留在此后的对话记录中。读一次 的文件只付一次费；但第三轮读进来的文件，到第二十轮仍在被反复携带。

在输出进入模型之前先过滤

构建日志、测试运行器和包管理器的输出，是写给盯着终端的人看的，而不是写给 按 Token 付费的模型看的。一次失败的测试很容易产生几千 Token 的调用栈，而其中 真正有用的可能只有四十个 Token。

把噪音大的命令接上过滤：

pytest -q 2>&1 | tail -30
npm run build 2>&1 | grep -E "error|warning" | head -20

这一步并不起眼，但通常是可获得的最大单项节省。

控制任务范围

长对话的单轮成本高于短对话，因为每一轮都会把整份记录重新发送一遍。两次专注的 会话比一次涵盖同样内容的冗长会话更省钱，而且效果通常更好，因为模型不必再权衡 二十轮不相关的历史。

当任务方向发生较大变化时，重开一个会话既是质量决策，也是成本决策。

不要粘贴 Agent 自己能读的内容

把文件粘贴进提示词等于重复计费：一次在你的消息里，另一次在 Agent 打开该文件 进行修改时。直接给出路径即可。

哪些做法收效甚微

压缩你自己的提示词基本是做样子。精心压缩过的指令大约能省五十个 Token；而一次 多余的文件读取要花掉两千。把指令写清楚，然后把注意力放在 Agent 读了什么上， 而不是你写了什么。

对多数用户而言，压缩系统提示词或工具定义同样收效有限，而且是拿可靠性去换 一个与嘈杂测试输出相比可以忽略不计的节省。