Token 节省 99% ？细数所有省 Token方法后我才明白：导致 AI 成本爆炸的核心，就是没做好上下文管理

先说结论：省 Token，不是一门“省字学”，而是一门“上下文管理学”。
因为 Token 花销，本质上就是 AI 读了多少内容，加上它写了多少内容。

大家都知道 Claude opus 贵，但因为 Anthropic 对于国内过严的封禁策略，很多人还没体验到过或者用的中转站。前两天看到L站有人发了一个帖子：本来在电脑前木然且疲惫地打电脑的我忍不住笑出声。

日常为了测试和 AI 的连通性，大部分人打开 Claude Code 一般都是先输入个“hi”、“你好”、“你是谁”之类的话确认下 AI 正不正常。

但是开局一句 hi 花费10块人民币的门槛费，也是颇有些让人哭笑不得。

所以关于如何才能节省 Token 这件事，我决定专门写一篇文章好好讲一讲。

Token 计费是怎么组成的？

还是先做个科普，说下 Token 的组成部分。

你发给模型的话，算输入 token；模型回给你的内容，算输出 token；两部分都会计费。

比如你发一句“帮我写个请假邮件”，看起来很短，但系统实际很可能还会顺手把前面几轮聊天记录、隐藏提示词、你的附加要求一起打包发给模型。

于是表面上你只问了一句话，实际上模型“看到”的内容可能比你想象中多得多。你可以把它理解成一个很朴素的公式：总花销 = 输入的钱 + 输出的钱。所以，问题越长，越贵；AI 回得越长，越贵；聊天轮数越多，也越容易变贵，因为历史上下文常常会被反复带上重新计算。举个最简单的例子：如果这一轮你输入了 100 token，模型输出了 200 token，那就按 100 + 200 算；但如果下一轮系统又把上一轮内容一起喂进去，输入可能就变成 400 token，哪怕你新发的话并不多，费用也会明显往上窜。

当然，一般来说输入比输出便宜，命中缓存又比输入便宜，而这些都需要考虑 Token 的区间，区间越大模型算力要求越高，自然也会越贵。

很多时候，贵的肯定不是你刚打的那句话，而是系统为了回答你，偷偷把你一堆旧内容也一起读了。

真正让 Token 爆炸的，往往不是“你问了什么”，而是“你怎么管理上下文”

搞懂计费规则之后，你会发现一个更关键的事实：大多数 AI 成本问题，看起来像是 prompt 问题，实际上是上下文管理问题。
历史聊天、系统提示词、规则文件、工具说明、网页内容、终端日志、项目代码、上传文档……这些东西只要被重新读一遍，就都要重新算钱。

所以真正决定成本的，往往不是你这一轮多打了几个字，而是这套系统有没有做到三件事：

1. 别让模型反复重读没必要的旧内容

2. 别让模型读进太多低信噪比的垃圾内容

3. 别让模型输出一堆不影响结果的语言泡沫

也正因为这样，这篇文章我不再按“零散省钱技巧”来讲，而是按上下文管理来讲，两块就够：

1. 系统层的上下文管理：用外部工具替你自动省

2. 使用层的上下文管理：不装工具，也能立刻降成本

系统层的上下文管理，用“科技”替你省

如果说手动省 Token 靠的是“自觉”，那工具真正帮你做的，其实是把上下文管理机制化。
它的价值不只是省钱，更是把那些会重复、稳定、无意义烧钱的环节，直接从系统层面改掉。

但工具很多，也不建议什么也不了解乱装。最好的办法当然不是“哪个火装哪个”，而是先看：你的上下文，究竟是贵在日志、贵在规则文件、贵在仓库输入，还是贵在整条 Agent 链路。

这里我尽量列了一些当前搜罗到的还算是比较热门的工具，毕竟“科技与狠活”，主打一个开箱即用，安上就能自动省。（笑）

终端输出类：专门解决“日志太吵”

AI 对接 CLI 指令，就会有很多多余信息出现。
这是编码场景里最常见、也最容易立刻见效的一类。

1. RTK：把终端废话先砍掉，再喂给模型

RTK 可以理解成一个 CLI 输出压缩器。
它专门处理这些情况：git status、pytest、cargo test、npm build、grep、ls

这些命令表面上是“有结果”，但实际上里头 70%～90% 都是噪音：空行、提示语、重复成功日志、无意义说明、颜色字符、样板输出。

RTK 做的事非常直接：

• 过滤噪音

• 合并重复信息

• 保留失败项和关键摘要

• 必要时保留原始输出供回看

它最适合的人群：

• Claude Code 用户

• Codex 用户

• Cursor / Copilot / OpenClaw 用户

• 让 AI 高频跑命令、看测试、看 Git 结果的人

它最大的优点是：不用你改变习惯。
你还是照常跑命令，只是系统先帮你瘦身，再把结果喂给 AI。

它的局限也很清楚：

• 主要针对 shell / CLI 输出

• 不是全场景上下文优化器

• 特别底层的问题，有时还是得回头看完整原始输出

一句话：RTK 是“别让 AI 吃日志垃圾”。

2. Omni：跟 RTK 很像，但更强调“上下文质量”

Omni 和 RTK 属于同一大类：都是在命令输出到达 AI 之前先做拦截和过滤。
但 Omni 更强调一个概念：省 token 只是结果，更重要的是让上下文更干净。

因为终端输出真正的问题，不只是贵，而是乱：

• warning 太多

• 成功日志太多

• 错误被埋在中间

• 加载条、进度条、提示语太多

Omni 的思路是：Less noise, more signal。

它的一些特点包括：

• 智能过滤终端噪音

• 原始输出可归档回看

• 有 session intelligence，会结合当前会话状态处理

• 能看压缩前后差异和统计节省情况

它适合谁？

• 重度 terminal + AI 用户

• 想让 AI 看得更准，不只是想让它更便宜的人

• 编码 Agent 用户

它和 RTK 的区别可以这样理解：

• RTK：更成熟，更像通用 CLI 压缩器

• Omni：同样压终端，但更强调“语义信号纯度”

一句话：Omni 省的不只是 token，也是在给 AI 提纯上下文。

3. distill：不是固定压缩，而是“按你的问题蒸馏结果”

如果 RTK 和 Omni 更像“规则型过滤器”，那 distill 走的是另一条路：
不是先定义怎么压，而是先定义“你到底想知道什么”。

比如：

• bun test | distill "测试过没过？只返回 PASS / FAIL 和失败用例名"

• git diff | distill "改了哪些文件？每个文件一句话总结"

• terraform plan |