rtk：把智能体读到的命令输出砍掉六到九成的 Rust 单二进制代理

过去一年，编码智能体的使用方式发生了一个不太显眼的变化：模型花在读取上的 token，已经远远多于它写出来的 token。每当智能体执行一条 shell 命令，不管是运行测试、查看 git 状态、列出目录，还是编译一个中等规模的工程，命令的全部输出都会原样塞进上下文窗口。一次完整的构建日志动辄几千行，其中真正影响下一步决策的可能只有寥寥几行。剩下的内容既要按 token 计费，又会稀释模型的注意力，还会让上下文更快逼近上限，迫使系统提前做摘要或截断。rtk 正是针对这个被长期忽视的浪费点而生。它是 rtk-ai 团队开源的一个命令行代理，项目口号很直白：高性能的 CLI 代理，最多可以砍掉智能体所读 bash 输出的九成。

从定位上看，rtk 并不是又一个智能体框架，也不是又一个模型网关，而是一个夹在智能体与 shell 命令之间的薄层。智能体原本直接调用命令并读取标准输出，接入 rtk 之后，同样的命令先经过代理，代理执行命令，再对输出做过滤和压缩，最后把精简后的结果交给模型。项目标题给出的数字是 60% 到 90% 的 token 削减，README 中的说法则是最多约 90%。需要说明的是，这是项目方自己的表述，具体比例取决于命令类型：重复性强、噪声多的输出，例如依赖安装日志、冗长的测试进度条，可压缩空间自然更大；而本来就简短的输出几乎没有可压缩的余量。读者不应把区间的上限当作平均值。 在工程实现上，选择 Rust 和单一二进制有很强的现实理由。智能体的循环里，命令调用的频率很高，一次任务可能触发几十甚至上百次。如果代理本身依赖解释器或庞大的运行时，每次调用的启动延迟都会累积成可感知的等待，还会带来环境依赖的麻烦。一个没有外部依赖的原生可执行文件，启动开销低，部署时只需放进路径即可，也方便在容器、持续集成机器和开发者笔记本之间保持一致。项目目前提供 Homebrew 包，采用 Apache-2.0 许可证，并设有持续集成的安全检查徽章，README 还提供了英文、法文、中文、日文、韩文、西班牙文和葡萄牙文七种语言的版本，说明维护者很重视面向全球开发者的触达。这些都是低调但有价值的工程信号。

然而，任何压缩都意味着信息取舍，这一点必须直面。对人类读者来说，漏掉一行警告往往无伤大雅；对智能体来说，漏掉一行关键报错，可能意味着它沿着错误的假设继续工作，白白消耗更多轮次，最终比不压缩时更贵。因此评估 rtk 这类工具，不能只看 token 削减了多少，而要看任务成功率有没有下降。一个合理的评估办法是：选取团队真实的任务集，分别在有无代理的条件下各跑若干次，记录完成率、总轮次和总 token，再看节省是否真的转化为更低的单任务成本。对于失败路径尤其要核查：编译错误、断言失败、堆栈信息、退出码，这些内容应当被完整保留，而不是被当作噪声丢掉。同时，团队应当保留一条绕过代理、读取原始输出的通道，以便在智能体陷入困惑时回退。

还有一个容易被忽略的维度是可观测性。当代理介入之后，团队需要知道它到底丢掉了什么，否则出了问题很难复盘。理想的做法是让每次压缩都留下可查询的痕迹，例如记录原始输出的长度、压缩后的长度，以及被折叠的片段数量，必要时能够把原始内容还原出来对照。这样一来，token 节省不再是一个黑箱数字，而是可以被审计、被持续调优的工程指标。对于需要合规留痕的企业环境，原始输出是否仍被完整保存在本地，同样是采用前必须问清楚的问题。 把视角拉远一些，rtk 反映的是上下文工程正在从提示词层下沉到工具层。前两年，行业的注意力主要放在提示压缩、缓存复用和检索筛选上；而随着智能体变成长时间运行的循环，工具返回值成为上下文的主要来源，在工具边界上做裁剪，往往比事后摘要更便宜、更可控。它与提示缓存并不冲突：缓存降低的是重复前缀的单价，而代理减少的是进入前缀的总量，两者可以叠加。它也提醒我们，成本优化不一定要靠更小的模型，有时只需要让模型少读一些没用的东西。

当然，我们也要保持克制。截至本文撰写时，rtk 的具体过滤规则、对各类命令的适配范围，以及那组 60% 到 90% 的数据是在怎样的基准下得出的，都应以仓库中的文档和你自己的实测为准。我们没有独立复现这些数字，因此不建议把它们直接写进预算。对于正在大量使用编码智能体的团队，务实的做法是：先在非关键项目里试用，统计一周的 token 账单与任务成功率，再决定是否推广。若数据支持，它是一个以很小代价换取明显成本下降的工具；若数据不支持，也至少帮助你看清了自己的智能体究竟把钱花在了哪里。