如何减少 AI 编码代理的 Token 用量：4 个实用工具

如果您在仅发出几次请求后就触及了 AI 编码套餐的 token 限额，您可能会纳闷这些 token 都花在了哪里。 

您让代理修复一个 Bug、重构一个功能或检查一个仓库，结果突然间，大半的配额就不见了。

这不一定是服务商或订阅的问题。 

AI 编码代理天生比普通聊天机器人更“吃” token。它们不只是回答您的提示，还可能阅读多个文件、搜索代码库、检查日志、运行测试、调用工具、生成代码、审查自身改动，并在完成任务前多次重复这一过程。

好消息是，您可以大幅减少这些不必要的 token 消耗。

有一些工具可以让编码代理减少赘述，避免对简单任务过度工程化，压缩嘈杂的终端输出，并阻止大型工具响应填满上下文窗口。

在本指南中，我们将介绍四个用于降低 AI 编码代理 token 用量的工具： Caveman、Ponytail、RTK 和 Context Mode。 

我们将看看它们各自的作用、设置方法，以及如何组合使用，以便在触及使用上限前，从 Claude Code、Codex 等订阅中完成更多编码工作。

为什么代理式工作流会消耗这么多 Token？

普通聊天机器人可能是一次提示、一次回答。代理通常会做得更多。

它可能读取文件、调用工具、检查日志、检索文档、编写代码，并在完成前多次重复这一过程。 

每一步都会向上下文添加信息，而这些上下文在后续调用中又可能被再次发送给模型。

一个简化的代理循环如下所示：

请求发给模型，模型调用工具，工具返回输出，然后该输出被折叠回上下文，进入下一步。回传这一步就是成本所在：每一轮都会带着之前的结果前进，因此一个需要 6 次工具调用的任务，会把大部分历史在 6 次里反复发送给模型。

这会产生几个常见的 token 浪费来源：

• 冗长的回复： 能用简短答案解决的问题，代理却解释过多。
• 过度工程化代码： 小任务演变成额外的文件、抽象和依赖。
• 大型工具输出： 日志、测试、Git diff 和终端命令可能返回成千上万的 token。
• 上下文过多： 检索到的文档、工具定义和先前结果会迅速填满上下文窗口。
• 会话时间过长： 代理运行越久，需要携带的历史和中间结果就越多。

因此，真正的挑战不只是代理 生成 了多少 token，而是它在工作流推进过程中 读取、携带并再次处理 了多少 token。

这正是 Caveman、Ponytail、RTK 和 Context Mode 等工具要降低的目标，它们各自瞄准不同的浪费来源。

1. Caveman：让您的代理少说点

Caveman 是让编码代理更为简洁的简单方法。 

它不再让代理叙述每一步、重复显而易见的细节或添加无用的填充，而是推动回复聚焦在真正重要的信息上。

它对长时间的编码会话尤其有用，因为冗长的回复不仅会增加输出 token。 

这些回复还会成为对话历史的一部分，并被带入后续轮次。

Caveman 的工作原理

Caveman 有两个独立组件。

其 Caveman 技能 会改变代理的写作方式。 

它移除填充、寒暄、模棱两可的措辞和不必要的叙述，同时保留代码块、命令、API 名称和精确错误信息等重要细节。 

在需要清晰度的场景（如安全警告或不可逆操作）下，它也会放松这种简短风格。 

另有一个可选的 本地代理 解决问题的另一面：代理读取了什么。 

它位于编码代理与模型提供方之间，在发送请求前压缩可压缩的上下文。 

技能与代理彼此独立工作，因此您可以先从轻量的技能入手，如需更激进的上下文压缩再添加代理。 

可以用下图来简单理解：

左侧，代理在代码前后都加了前言和解释。右侧，您只得到有用的答案与代码，没有多余内容。工作量相同，叙述上花费的 token 少得多。

开始使用 Caveman

安装技能的最简单方式是：

npx skills add JuliusBrussee/caveman

然后在您的编码代理中启用：

/caveman

您可以用以下命令切回普通回复：

/caveman off

Caveman 还为 Claude Code、Codex、Gemini CLI、Cursor 和 OpenCode 等工具提供原生安装选项。

如果您还想减少发送给模型的上下文，请安装 CLI：

npm install -g @caveman-ai/cli
caveman setup --install

然后通过它启动受支持的代理，例如：

caveman claude

这会启动 Caveman 的本地代理，并将代理路由经由其上下文压缩层。 

对大多数用户，我建议先从 技能 入手。 

它易于添加，不改变您的日常编码工作流，并直击最容易浪费 token 的来源之一：代理说得远超所需。

2. Ponytail：阻止代理过度工程化

Ponytail 针对的是另一类 token 浪费： 编码代理写了超出任务实际需要的代码。

一个简单请求，可能被扩展成新依赖、辅助类、封装组件和额外配置。 

Ponytail 通过推动代理优先选择“最小可行方案”来阻止这种情况。

Ponytail 的工作原理

在编写代码之前，Ponytail 会让代理走一遍简单的决策阶梯：

每一级台阶都给代理一个在写任何新东西之前停下来的机会。只有当标准库、原生平台特性和现有依赖都被排除后，才会走到最后一步，编写“能工作”的最小代码。

例如，Ponytail 可能不会安装日期选择器库并构建封装组件，而是判断浏览器已经有：

<input type="date">

目标并不是盲目把一切都缩短。 

Ponytail 明确将校验、安全、可访问性和防数据丢失等内容排除在“精简”之外。 

它的宗旨是 在实现上偷懒，而不是在正确性上疏忽。

在 Ponytail 自身的代理式基准测试中，跨 12 个编码任务实现了约 54% 更少的代码和 22% 更少的 token，相较未使用该技能的同一代理。 

一项独立基准测试也发现实现规模显著缩小，但指出在激进设置下，可能会在未陈述的边界条件上牺牲一定稳健性。

开始使用 Ponytail

对于 Claude Code，先添加插件市场：

/plugin marketplace add DietrichGebert/ponytail

然后安装 Ponytail：

/plugin install ponytail@ponytail

以上请分两条命令发送。

安装完成后，您可以控制 Ponytail 的精简力度：

/ponytail lite
/ponytail full
/ponytail ultra
/ponytail off

full 为默认选项，也是较佳的起点。lite 仍会构建您要求的内容，但会指出更简单的替代方案；ultra 则更激进地应用 YAGNI。 

您也可以审查现有改动是否存在不必要的复杂度：

/ponytail-review

或扫描较大的代码库：

/ponytail-audit

Ponytail 对编码代理尤其有效，因为减少不必要代码有连锁效应：代理现在写更少的 token，生成更小的 diff，并为后续自读留下更少的代码。

3. RTK：削减嘈杂的工具输出

RTK，全称 Rust Token Killer，聚焦于另一类 token 浪费：编码代理从终端接收到的一切。

像 git status、测试运行、日志、搜索和包管理器输出等命令，可能返回数百甚至上千行。 

这些信息对看终端的人类很有用，但代理往往只需要关键部分。

RTK 介于命令与代理之间，在模型看到之前压缩输出。 

RTK 的工作原理

RTK 采用针对命令的过滤、分组、截断和去重，剔除噪声，同时保留错误、失败、变更文件和摘要等有用信息。 

例如：

在普通流程中，代理运行 pytest 并读取它打印的每一行，其中大多是无需查看的通过用例。有了 RTK，中间层会将同一次运行压缩为失败信息加摘要，这样代理只需读几十行，而不是几百行。

在受支持的编码代理中，RTK 可以自动钩住 shell 调用。类似命令：

git status

可以在幕后被重写为：

rtk git status

代理将收到更小的输出，而无需每次都显式请求 RTK。 

RTK 报告称，针对常见开发命令，可将命令输出相关的 token 使用量减少 60–90%。这并不意味着您的整体 LLM 账单下降 60–90%；它只针对 RTK 压缩的终端输出部分。 

开始使用 RTK

在 macOS 或 Linux 上，您可以通过 Homebrew 安装：

brew install rtk-ai/tap/rtk

或使用安装脚本：

curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/master/install.sh | sh

然后确认您安装的是正确的 RTK：

rtk --versionrtk gain

rtk gain 命令会显示 token 节省面板。此检查很有用，因为另一个不相关的项目也使用了 rtk 这个名称。 

对于 Claude Code，全局初始化 RTK：

rtk init -g

对于 Codex：

rtk init -g --codex

对于 Gemini CLI：

rtk init -g --gemini

RTK 还支持 Cursor、OpenCode、Copilot、Cline、Windsurf 以及其他多种编码代理。 

配置完成后，您可以照常使用终端命令。 

RTK 在后台处理压缩，这对大量 运行测试、搜索代码、检查 Git 改动和读取日志 的代理尤其有用。

4. Context Mode：让大型工具输出留在上下文之外

Context Mode 聚焦于代理 开始使用工具之后 的情况。

浏览器快照、GitHub 议题列表、文件搜索或大型命令输出，可能会将海量信息直接倾倒进 上下文窗口。 

更糟的是，这些信息随后还会被带入后续轮次。

Context Mode 通过将臃肿的原始数据保留在活动 LLM 上下文之外，并仅带回代理真正需要的部分，来避免这种情况。

Context Mode 的工作原理

Context Mode 作为一个 MCP 服务器 运行，并为通常会产生大量输出的操作提供沙盒化工具。

原始信息可本地存入基于 FTS5 的搜索索引，这样代理之后可以再次搜索，而无需将整份结果倒回对话中。 

项目的一个示例中，315 KB 的原始工具输出被缩减为 5.4 KB 的上下文，据称为 98% 的缩减。 

需要注意，这是来自项目自身工作负载的示例，并非对每次工具调用的保证。 

开始使用 Context Mode

对于 Claude Code，最简单的设置方式是通过插件市场：

/plugin marketplace add mksglu/context-mode
/plugin install context-mode@context-mode

重启 Claude Code，然后用以下命令验证设置：

/context-mode:ctx-doctor

该诊断会检查插件、钩子、运行时和本地搜索组件是否正常工作。 

您也可以全局安装 Context Mode：

npm install -g context-mode

并在 Cursor、Gemini CLI、GitHub Copilot CLI、JetBrains 等受支持的客户端中将其注册为 MCP 服务器。 

运行后，您可以使用其统计工具查看节省了多少上下文。

Context Mode 对于 长时间运行、重度依赖工具的代理 最为有用，否则浏览器结果、日志、文件读取、MCP 响应及其他中间数据会不断填满上下文窗口。

四种节省 Token 工具对比

这四个工具瞄准编码代理工作流的不同环节，从代理写什么到它在上下文中携带多少工具输出。

最容易区分它们的方法是： 

• Caveman 减少代理说的话
• Ponytail 减少它要构建的东西
• RTK 减少终端回传的内容
• Context Mode 减少留在上下文中的工具结果。

这些工具可以一起用吗？

可以，但我不建议一开始就把所有东西堆上去。

更好的方式是 先从 Ponytail 开始。 

它很容易添加，对许多工作流而言，仅减少不必要的代码就已足够。我将它与 Zcode、Claude Code、Codex 等工具配合使用，并对带来的降耗很满意。

如果想进一步降低，可尝试 Ponytail + Caveman。Ponytail 减少不必要的代码，Caveman 减少不必要的解释，二者相得益彰。

如果您的工作流仍然会因测试、日志、Git 或终端命令产生大量 token 密集的输出，请尝试 Ponytail + Caveman + RTK。

若 RTK 不适合您的工作流，尤其是在大量使用 MCP 工具、浏览器工具、API 或其他大型工具输出时，可改用 Ponytail + Caveman + Context Mode。

不存在适用于所有人的完美组合。 

目标是通过试验，找到在 不损害编码代理性能 的前提下，带来更低 token 用量的设置。对一些人而言，仅 Ponytail 就足够；对另一些人而言，组合使用两三种工具更有效。

减少 Token 用量与成本的其他方法

并非总是需要再加一个工具。 

Claude Code 已内置多项特性，可帮助您缩小上下文并减少不必要的开销。

不需要时禁用记忆

Claude Code 可自动存储并重载先前会话的记忆。对于短小或独立的任务，这可能会增加不必要的上下文。

运行：

/memory

在此，您可以 禁用自动记忆 或移除已无用的信息。

压缩长会话

随着会话增长，Claude 会携带对话历史、文件内容和工具输出。Claude Code 会自动压缩，但您也可更早触发：

/compact

您还可以告知它保留什么：

/compact keep the implementation plan and latest test results

当您完成任务的一部分但想在同一会话中继续时，这尤其有用。 

任务变化时从头开始

有时压缩并不值得。如果您要转向完全不同的任务，请运行：

/clear

这会从空的对话上下文开始，而不是带着无关工作前行。Anthropic 也指出，开启新会话有时比反复压缩长会话更好。

禁用未使用的 MCP 服务器

MCP 工具同样会消耗上下文。Claude Code 现已默认延迟加载完整 MCP 工具模式，但未使用的服务器仍可能带来开销。

使用：/mcp 查看已连接的服务器，并禁用当前不需要的。 

您也可运行 /context 查看会话各部分占用的空间。

保持 CLAUDE.md 精简

CLAUDE.md 会被加载进 Claude 的上下文，因此请避免将其写成庞大的项目手册。 

仅保留跨任务必需的指令，如重要约定、命令和项目规则。

使用 /context 查看记忆与指令文件占用的空间。对于仅与特定文件夹相关的指令，Claude Code 支持更有针对性的规则，而无需都放进主 CLAUDE.md。 

简单任务用更便宜的模型

并非每次编辑都需要最昂贵的模型。 

Claude Code 文档建议，大多数编码任务使用 Sonnet，将 Opus 保留给更困难的架构或重推理工作。

您可以通过以下命令切换：

/model

对于简单的子代理任务，您也可以配置它们使用 Haiku。 

尾声

这些工具的一大优点是，一旦设置完成，几乎无需额外精力。 

根据工具不同，您甚至不必记住斜杠命令，或为每个任务手动启用。 

Ponytail 可引导代理采用更简洁的实现，Caveman 可保持回复简明，RTK 可压缩终端输出，Context Mode 可防止大型工具结果淹没活动上下文。 

配置之后，这些优化多半自然融入您的日常编码工作流。

您常能在代理的运行摘要、生成代码、终端输出或上下文统计中看到效果。 

代理做的是同一件事，但围绕它的无用代码、更少叙述、更小的工具响应或更少的跨步信息传递。

更妙的是，您还可以组合这些工具。 

不过，将四者全部堆叠并不意味着一定能获得最低 token 用量。它们各自针对代理式编码工作流的不同环节，收益高度依赖您的编码代理、模型、仓库与任务类型。

我建议在您自己的编码环境中试验：先从一个工具开始，量化差异；若仍有明显浪费，再添加另一个。 

您可能会发现单一工具已足够，而另一种场景则更适合两三种工具协同。

就我个人而言，我在大多数编码工作流中使用 Ponytail，因为它设置简单，编码代理也能很快与之配合。 

我主要将它用于 Z.ai 的 Zcode，它能让实现更聚焦，而无需我改变平时对代理的提示方式。

归根结底，减少 token 用量并不是让代理少做有用的工作，而是去除围绕这些工作产生的浪费。 

分别或组合试用 Caveman、Ponytail、RTK 与 Context Mode，衡量它们对您工作流的影响，保留能在 token 用量、代码质量与代理性能之间实现最佳平衡的方案。

想进一步了解 AI 代理的工作方式，推荐查看 AI Agent Fundamentals 技能路线。