RTK 在 Google Antigravity 中的集成：基于 Rules 文件的 Token 优化代理配置
【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk
本文以 RTK 仓库中 hooks/antigravity/rules.md 规则文件为核心，完整讲解 RTK 与 Google Antigravity 集成的工作原理：如何通过 Prompt 级指令让 Antigravity 自动为 shell 命令加上rtk前缀，覆盖安装方式、规则内容、元命令用法，以及该集成在源码层面（src/hooks/init.rs）的写入逻辑与测试保障。读完后你能理解 RTK 三种 Agent 集成层级中「Rules 文件」这一档的完整落地链路，并能在 Antigravity 项目中复制部署。
一、RTK 是什么，以及 Antigravity 集成处在什么位置
RTK（Rust Token Killer）是一个 token 优化 CLI 代理：它拦截常见开发命令，在命令输出到达 LLM 上下文之前进行过滤与压缩，据 hooks/antigravity/rules.md 的说明，在常见操作上最多可削减 90% 的 bash 输出字节。它是单二进制 Rust 程序，零依赖。
RTK 对各类 AI 编码 Agent 提供三个集成层级（见 hooks/README.md 与 docs/guide/getting-started/supported-agents.md）：
| 层级 | 机制 | 命令改写方式 | 维护成本 |
|---|---|---|---|
| Full hook | Shell 脚本或 Rust 二进制，通过 Agent 的 hook API 拦截命令 | 透明改写——Agent 完全看不到原始命令 | 高，需跟踪 Agent API 变更 |
| Plugin | TypeScript/JS/Python 插件，置于 Agent 插件系统 | 原地 mutation（Agent 允许时） | 中 |
| Rules file | Agent 读取的 Prompt 级指令文件 | 仅引导——告诉 Agent 优先使用rtk <cmd> | 低，没有会坏掉的代码 |
Google Antigravity 属于第三层Rules file（prompt-level guidance）。hooks/antigravity/README.md 明确了其特殊性：
- 仅 Prompt 级引导，没有程序化 hook——依赖 Antigravity 读取自定义指令文件这一机制；
rules.md包含「为所有 shell 命令加rtk前缀」的指令、使用示例与元命令说明；- 由
rtk init --agent antigravity安装到.agents/rules/antigravity-rtk-rules.md（项目本地作用域）。
与 Claude Code、Cursor 等 Full hook 集成相比，Rules 文件集成没有保证改写的机制（Agent 是否遵循指令取决于模型对 Prompt 的服从度），但它也无需适配任何 hook API，是维护成本最低的接入方式。
二、安装：一条命令写入项目规则文件
Antigravity 从项目根目录的.agents/rules/读取自定义指令（workspace 作用域）。RTK 的安装入口是：
rtk init --agent antigravity该命令在当前项目目录创建.agents/rules/antigravity-rtk-rules.md，内容为仓库中 hooks/antigravity/rules.md 的完整副本。安装行为由 src/hooks/init.rs 中run_antigravity_mode/run_antigravity_mode_at函数实现（约 L1786-L1841），源码中有三处关键事实：
- 规则文件被编译进二进制。
init.rs第 1788 行通过include_str!("../../hooks/antigravity/rules.md")在编译期把规则文件内嵌为常量ANTIGRAVITY_RULES，因此安装不依赖仓库文件位置，只需rtk二进制在 PATH 中即可安装； - Antigravity 仅支持项目级安装。src/main.rs（约 L2099-L2105）中，若传入
--global会直接报错：Antigravity is project-scoped. Use: rtk init --agent antigravity——这与 Antigravity 从当前项目根目录读取.agents/rules/的机制一致； - 幂等写入，不覆盖已有内容。安装逻辑先读取目标文件，若其中已含
RTK/rtk字样则提示 "already present" 并跳过；若文件已有其他内容，则将 RTK 规则追加到现有内容之后（空文件则直接写入）。这一点由两个单元测试固化：test_antigravity_mode_creates_rules_file（断言文件创建且包含 "RTK"）与test_antigravity_mode_is_idempotent（断言第二次安装后文件内容逐字节不变），位于 src/hooks/init.rs 的测试模块中。
三、规则文件内容逐段解析
以下完整继承 hooks/antigravity/rules.md 的规则内容，并结合仓库实现逐段说明其含义。
3.1 核心指令（Rule）
Always prefix shell commands with
rtkto minimize token consumption.
这是整份规则文件的核心一行：要求 Antigravity 在执行 shell 命令前，始终加上rtk前缀。文档给出的示例命令集：
rtk git status rtk cargo test rtk ls src/ rtk grep "pattern" src/ rtk find "*.rs" . rtk docker ps rtk gh pr list这些示例覆盖了 git、构建测试（cargo）、文件操作（ls/grep/find）、基础设施（docker）与 GitHub CLI（gh）等 RTK 支持的主要类别。
3.2 元命令（Meta Commands）
规则文件同时教给 Agent 一组不执行具体任务、而是管理 RTK 自身的元命令：
rtk gain # 查看 token 节省量 rtk gain --history # 带节省量的命令历史 rtk discover # 发现被遗漏的 RTK 优化机会 rtk proxy <cmd> # 原样执行（不过滤，用于调试）rtk gain系列由 src/analytics/gain.rs 实现，基于 RTK 对每条命令的原始输出与过滤后输出的记录计算实际节省；rtk discover对应 src/discover/ 模块，通过正则规则库分析历史命令、找出本可以加rtk前缀的机会；rtk proxy <cmd>是调试逃生通道：跳过所有过滤直接透传，方便在过滤结果不符合预期时对比原始输出。
3.3 为什么这么做（Why）
RTK filters and compresses command output before it reaches the LLM context, cutting up to 90% of the bash output on common operations.
RTK 的价值链条是：命令输出 → RTK 过滤器压缩 → 更少的字节进入 LLM 上下文 → 更低的 token 消耗与更干净的上下文。各命令类别的压缩比例区间在 hooks/README.md 中有汇总，例如测试运行器（vitest、pytest、cargo test、go test、playwright）约 90-99%，VCS 类（git status/log/diff/show）约 70-80%，文件操作（ls、find、grep、cat、head、tail）约 60-75%。
四、底层支撑：rtk 前缀之后发生了什么
Agent 按规则执行rtk <cmd>后，RTK 内部会做两类工作，这里简要给出源码依据：
1. 命令改写注册表（Rewrite Registry）
src/discover/registry.rs 是命令分类的核心。classify_command函数（L107 起）按顺序执行：空命令判断 → 忽略列表（精确匹配与前缀匹配）→ 剥离环境前缀（sudo、env VAR=val、VAR=val）→ 绝对路径归一化（如/usr/bin/grep→grep）→ git 全局选项剥离（git -C /tmp status→git status）→ 正则规则匹配，最终产出Supported（含 RTK 等价命令、类别与预估节省比例）、Unsupported或Ignored三种分类。
对复合命令（&&、||、;、|），注册表的处理策略是：管道两侧独立改写（cargo fmt --all && cargo test变为rtk cargo fmt --all && rtk cargo test），而管道场景下生产端保持原样、仅改写 pipeline-safe 的末端阶段。
2. 过滤执行
分类完成后，RTK 执行对应类别的过滤器压缩输出；过滤失败时回退到原始命令输出，保证命令永远不会因 RTK 而丢失结果。
3. 已有前缀的直通
rtk git status再次被改写时不会变成rtk rtk git status——注册表对已带rtk前缀的命令原样放行（hooks/README.md 的 "Override Controls" 一节），这对 Rules 文件集成尤其重要，因为 Antigravity 可能在模型已自行加上前缀的情况下再收到指令。
五、覆盖与逃生通道
当某条命令不希望走 RTK 时，有两种官方手段（见 docs/guide/getting-started/supported-agents.md 的 Override 一节）：
# 单条命令临时禁用 RTK_DISABLED=1 git status # 原样执行 git status，不重写# 永久排除命令（~/.config/rtk/config.toml） [hooks] exclude_commands = ["git rebase", "git cherry-pick"]exclude_commands按剥离环境前缀后的完整命令匹配，支持子命令模式（"git push"排除git push origin main），以^开头的条目按正则处理。
六、Rules 文件集成 vs Full hook：能力边界
| 维度 | Antigravity（Rules file） | Claude Code 等（Full hook） |
|---|---|---|
| 改写时机 | 模型生成命令时遵循指令 | 命令执行前被 hook 强制拦截改写 |
| 保证程度 | 依赖模型服从 Prompt | 透明改写，Agent 看不到原始命令 |
| 失效风险 | 模型偶发不遵守指令 | Agent hook API 变更需跟进 |
| 安装产物 | 项目内.agents/rules/antigravity-rtk-rules.md | shell hook 脚本 + settings.json 补丁 |
从 hooks/README.md 的 "Gaps" 与 "Graceful Degradation" 章节可看出 RTK 的整体设计底线：hook 永不阻塞命令执行——RTK 二进制缺失、JSON 非法、版本过旧等所有错误路径都以退出码 0 结束，命令按原样运行。Rules 文件集成天然满足这条底线：它只写了纯文本指令，没有任何会失败的运行时组件。
七、部署与验证清单
- 在 Antigravity 项目根目录执行
rtk init --agent antigravity，确认输出Rules: .agents/rules/antigravity-rtk-rules.md (installed)； - 打开该文件核对内容与 hooks/antigravity/rules.md 一致（Rule / Meta Commands / Why 三部分）；
- 在 Antigravity 会话中让其执行
git status，观察其是否使用rtk git status； - 用
rtk gain --history核对实际节省量；若怀疑过滤异常，用rtk proxy <cmd>对比原始输出； - 重复执行安装命令验证幂等性（第二次应输出 "already present"），该行为由 src/hooks/init.rs 的
test_antigravity_mode_is_idempotent测试保障。
适用前提与限制：Antigravity 集成仅支持项目级（--global会报错）；压缩比例数字来自 hooks/README.md 的分类估算表，实际节省取决于具体命令输出规模；「最多削减 90%」是仓库文档给出的常见操作上限，而非对每条命令的承诺。
【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
