一句话结论：如果说 caveman 是 Claude Code 的省钱插件，rtk 就是更狠的角色——一个用 Rust 写的独立 CLI 代理层，坐在你和 AI 模型之间专门负责压缩与优化：请求侧分析并剔除冗余上下文、缓存工具输出、摘要历史对话，返回侧做代码去重与结果缓存，官方宣称 token 消耗降低 60-90%；毫秒级处理、单二进制部署，能与所有主流 AI 编程工具搭配，Star 约 7.8 万。

Meta Description：rtk-ai 开源的 CLI 透明代理层，坐在用户与 AI 模型之间做压缩优化：请求侧分析冗余上下文、缓存工具输出、摘要历史，返回侧做代码去重与结果缓存，官方宣称 token 消耗降低 60-90%；Rust 实现毫秒级处理、单二进制部署，Star 约 7.8 万。

核心亮点速览

一、从“插件”到“代理”，一层的差别

如果说 caveman 是 Claude Code 的省钱插件，rtk 就是更狠的角色——一个独立的 CLI 代理层，坐在你和 AI 模型之间，专门负责压缩和优化。官方数据：token 消耗降低 60-90%。它的核心设计是“透明代理”：不改变你的工作方式，只是在 API 调用的路径上加了一层智能处理。你发给模型的请求，rtk 会先分析一下——哪些上下文是冗余的？哪些工具输出可以缓存？哪些历史对话可以摘要？处理完再发给模型；返回的响应也经过 rtk：如果模型的输出包含大段重复的代码，rtk 会做去重；如果工具调用结果跟之前一样，直接用缓存。

这个“双层处理”的设计让它在省 token 这件事上做得非常彻底：请求侧少发，返回侧少收，双向都在控制流量。而且由于它处于代理层，理论上它对“任何”走 API 的 AI 工具都有效——这是它区别于 caveman 这类“只服务单一工具”方案的最大差异点。

二、透明代理的技术逻辑

2.1 请求侧：把发出去的东西先瘦身

rtk 拦截你的请求后，第一件事是分析内容构成。上下文冗余是 token 浪费的头号来源：一段很长的历史对话里，真正对当前问题有用的可能只有一小部分；rtk 会识别哪些上下文是冗余的、哪些可以压缩，只把“值得发送”的部分交给模型。同时它会缓存工具输出——同一个命令跑出来的结果，如果内容没变，就没必要每次对话都重新发送一遍。历史对话过长时，它还支持智能摘要，把前文凝练成关键信息。三层动作层层削，请求侧的 token 账单肉眼可见地变薄。

2.2 返回侧：把收进来的东西也筛一遍

方向上，rtk 同样做减法。模型的输出如果包含大段与之前重复的代码，它会自动去重，不让你为重复内容买单；工具调用结果如果和上次一致，直接命中缓存，不再重复计费。这一层容易被忽略，但往往又是实打实的开销——模型“懒得改就整段复述”的输出，在返回侧被 rtk 拦下来，省下的是真金白银。请求与返回双端夹击，让 rtk 的压缩效果比“只压一端”的方案更全面。

2.3 为什么用 Rust：代理层必须是“隐形”的

7.7 万 Star 的项目用 Rust 写是有道理的。代理层必须快，不能成为瓶颈——如果每次请求因为多了一层代理就明显变慢，用户立刻会弃用。Rust 的零成本抽象和内存安全保证了 rtk 能在毫秒级完成压缩处理，对用户体验几乎没有影响；再加上单二进制部署、不依赖任何运行时，它在你本地的存在感被降到最低。一个理想的代理层就该这样：你几乎感觉不到它，只有账单告诉你它一直在工作。

三、使用与接入体验

curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/main/install.sh | sh
rtk proxy --port 8080

启动代理后，把你的 AI 工具的 API 地址指向 rtk 的代理端口就行，支持所有主流的 AI 编程工具。接入方式用一个词概括就是“无痛”：不改变你的工具、不改变你的习惯，只把 API base 改一行。这对多工具并用的用户特别友好——Cursor、Claude Code、其他 CLI 工具，只要指向 rtk 的端口，统统都能享受到统一的压缩优化。你甚至可以把它理解为“AI 工具们的集中缴费处”，一处代理，全链路省。

四、适用人群与场景

• 多 AI 工具并用者：Cursor、Claude Code 等多个工具想统一优化 token 消耗；
• 延迟敏感用户：需要本地代理方案、不能接受明显变慢的开发者；
• 团队成本管控：想在组织层面统一控制 AI 使用成本与用量；
• 与 caveman 叠加使用：工具层优化与代理层压缩互不冲突、效果叠加。

五、局限与注意事项

• 需维护本地代理进程：多一个常驻进程，要纳入日常运维考虑；
• 压缩策略取舍：摘要与去重可能影响个别场景的信息完整性；
• 与工具版本兼容性：AI 工具更新后可能需跟进适配；
• 省幅因人而异：具体收益和对话模式、使用习惯强相关。

六、常见问题 FAQ

Q1：rtk 和直接少发内容有什么区别？ A：rtk 是自动化的智能代理层：它自动分析哪些上下文冗余、哪些输出可缓存、哪些历史可摘要，你在无感知的情况下获得压缩收益，不需要手动去精简 prompt 或复盘对话。

Q2：真的能降 60-90% 吗？ A：这是官方宣称区间，社区与实测也有不错反馈。实际收益取决于对话模式——长会话、重复工具输出多的场景省幅更大，短对话、一次性任务收益相对有限。

Q3：它能搭配哪些工具？ A：所有走 API 的主流 AI 编程工具基本都能用，把工具的 API 地址指向 rtk 的代理端口即可；它不绑定某个具体产品，这是它作为代理层的天然优势。

Q4：用 Rust 写有什么好处？ A：代理层必须足够快才能做到“透明”。Rust 的零成本抽象和内存安全支持毫秒级处理、几乎无感知，同时单二进制部署、无需运行时，对用户体验几乎零影响。

Q5：可以和 caveman 一起用吗？ A：可以，二者不冲突。caveman 在 Claude Code 工具层面优化，rtk 在代理层面压缩，一个管工具内部、一个管传输通道，叠加使用效果更明显。

七、同类项目横向比较

一句话：rtk 把“省钱”做成了通用基础设施——不止服务一个工具，而是服务你所有的 AI 调用。 它是把资源优化下放到管道层的思路突破。

提醒一句使用时的小讲究：既然 rtk 是代理层，把它挂在哪里就决定了它能管到谁。最方便的是在常用开发机本地起一个常驻代理，把几个主力 AI 工具的 base URL 统一指过去；如果你有团队，也可以把它部署成共享的内网服务，让所有成员的工具都走同一道压缩链路，用量与成本一起看板化。理想形态是“配置一次，长期省钱”一段话概括——前期花十分钟把代理接好，之后每一次对话的 token 账本都在悄悄变薄，这是一笔非常划算的工程投资。

八、延伸思考

rtk 蕴含着一个逐渐清晰的大方向：token 正在变成智能时代的“水费电费”，而围绕“怎么省”的中间层生意会越来越繁荣。代理层、压缩层、缓存层、路由层——这些过去属于运维领域的概念，正在被复制到 AI 调用链上。当模型本身越来越同质化、价格战越来越激烈，差异化反而出现在“谁能让你的 AI 支出更可控”这件事上。rtk 用 7.7 万 Star 验证了这条路的可行性，也提醒我们：下一波 AI 基础设施的创业机会，可能不在“更强的模型”，而在“更聪明的管道”。对使用者而言，选择这类工具等于给自己的 AI 使用装上了一道自动开的省钱闸门，无论模型如何迭代，这道闸门都能继续发挥价值。

总结

rtk 在“让 AI 更省”这件事上做到了范围更广、手段更全：它是独立的、用 Rust 写的透明代理层，请求侧剔冗余、缓存输出、摘要历史，返回侧去重代码、命中缓存，双向压减 token，官方宣称降幅 60-90%；它不绑定任何单一工具，所有走 API 的 AI 编程工具指个地址就能接入，且毫秒级处理让代理层几乎隐形。要付出的代价是多一个本地进程，但换来的却是跨工具、可叠加、可持续的省钱能力。如果你同时在用好几个 AI 工具、或者需要在团队层面管住成本，rtk 是当下性价比很高的选择。

一句话回顾：所有的 AI 工具都在烧钱，而 rtk 是你和模型之间那道会自动省钱的闸门。