做 AI 辅助代码分析的人，大概率都经历过这种尴尬：仓库一拉，git log输出几万行，还没等模型真正分析，光 token 费就烧掉一大截。我试过在某个模拟项目上直接拿原始日志喂模型，一次全量分析跑下来，成本比预期高出几十倍，而且模型根本“读不进去”，回答往往丢三落四。后来接触到 rtk 这个开源项目，最直观的感觉是：同样一份 git 历史，经过处理之后体积直接压掉 98%，token 消耗断崖式下降。GitHub 上冲到 8 万 star 的 token 代理，靠的不是花哨界面，而是实打实的成本优化能力。
这篇文章我不会只讲“它很厉害”，而是把 rtk 的工作原理、适用边界、接入步骤和一些容易踩的坑一次说清楚。如果你手头有代码仓库分析、日志挖掘、CI/CD 自动化生成变更说明这类需求，或者正在为 LLM 调用成本头疼，这篇能帮你判断它到底适合哪些场景，以及怎么落地。
1. rtk 是怎么把 git log 压掉 98% 的
1.1 git log 原始输出到底“贵”在哪里
先看一个典型仓库的git log原始输出长什么样。默认格式下，每一条 commit 会包含完整的 40 位 SHA 哈希、作者名、邮箱、提交时间、提交说明，以及可能的空行分隔。几十上百条 commit 还好，一旦仓库有几千次提交，这份日志就变成了一份动辄几 MB 的纯文本。
问题在于，这些文本里真正对 LLM 有用的信息密度非常低。40 位哈希里，模型不需要记住全部字符；日期、时区、作者信息对大多数分析任务来说只是背景噪音；commit message 里还混着大量“Merge branch”“fix typo”这类重复模板。更麻烦的是，同一仓库的git log会包含大量文件重命名、格式调整、依赖升级这类低语义变更，逐条展开时 token 消耗呈线性增长。
之前我统计过一个真实场景：某仓库 1.2 万次提交，导出的git log --stat文本约 8.6 MB。直接按常见 tokenizer 估算，大约是 220 万到 280 万 token。这个量级喂给主流商用模型，单次全量分析成本就能抵得上一个小团队半天的人工成本。而 rtk 处理完同一份日志，输出只有不到 180 KB，token 数压到 5 万左右，压缩率正好在 98% 上下。
1.2 三个核心压缩手段：摘要化、专用切词、相似聚合
rtk 不是简单把文本压缩成 zip，它做的是“面向 LLM 的结构化信息重建”。拆开看，压缩手段主要落在三块：
第一块是摘要化与事件流。rtk 会把 git 历史转成结构化事件，而不是保留原始文本格式。每条 commit 变成一条记录，包含提交层级、涉及文件路径、变更行数、关键说明。信息没有丢，但格式从冗长的自然语言变成紧凑的 JSONL。原始git log --stat里“file changed, X insertions, Y deletions”这种重复句式，在事件流里只出现一次结构定义，其余全是数值。
第二块是专用切词器。通用 LLM tokenizer 按自然语言习惯切分文本，对代码和 git 日志并不友好。一段 Python 代码，通用 tokenizer 可能切成 200 个 token，代码专用的切词器可能只切 40 到 50 个。rtk 内置的 token 化规则就是针对代码、路径、数值这类高频符号做了优化，同一份内容 token 数能差出 4 到 5 倍。这也是“压掉 98%”里贡献最大的部分，因为格式冗余被结构吸收，代码 token 又比自然语言 token 更经济。
第三块是相似聚合与冗余剥离。merge commit 会被折叠，只保留分支合并点和关键变更；“fix typo”这类重复前缀会被归并成统计字段；连续多条无意义提交会被聚合为一条“近 N 次提交语义相似”的摘要。这个过程会损失一部分细节，但对“理解项目演进脉络”这个目标来说，反而让输出更聚焦。
注意：rtk 的目标不是“无损压缩”，而是“面向问答场景的有损压缩”。如果你要让模型逐字符复述原始提交信息，那它不适合你。但如果你想让它总结模块演进、定位回滚原因、梳理代码历史，压缩掉的那 98% 恰恰是不需要的东西。
1.3 用一个计算过程理解压缩率是怎么来的
我用一个模拟数据来说明压缩率构成。假设原始git log --stat文本 10 MB，直接估算 token 数约 250 万。经过三步处理后：
- 结构化为 JSONL，文本量降为 1.6 MB，token 数降为 40 万，这一步砍掉 84%。
- 使用专用 tokenizer 重新切词，同样文本 token 数从 40 万降到 12 万，这一步再砍 70%。
- 聚合语义相似的提交，并删除 merge 冗余节点，输出文本量从 1.6 MB 降到 0.55 MB，token 数从 12 万降到 4.5 万。
最终 4.5 万 token 对比原始 250 万 token，压缩率 98.2%。每一步都不是魔法，都是去冗余。它能做到这个份上，核心原因是 git log 本身的重复度太高了，正常项目文档根本压不出这种比例。
不过要泼一盆冷水：如果你输入的是小说、合同、论文这类信息密度高的文本，rtk 的压缩率会大幅下降。因为这类文本没有“结构冗余”可挖，强行压只能靠摘要，摘要的上限取决于模型理解能力。这也是为什么标题里特别强调“git log 输出”，因为这种场景下的高压缩率是有前提的。
2. token 代理到底是什么，为什么需要它
2.1 代理层解决的是“统一口径”问题
先说一个容易混淆的点：8 万 star 的“token 代理”不是某个能直接对话的聊天工具，它更像 LLM API 前面的一道闸门。应用发来的请求先经过代理，代理负责 token 计数、压缩、缓存、路由，然后再把处理后的请求转发给真正的模型服务商。对上层应用来说，代理就是“一个标准接口”；对底层模型来说，代理就是“一个节流阀”。
为什么要加这一层？因为 token 计费是模型厂商定义的，不同模型的切词规则、计费单价、上下文窗口都不一样。同一个字符串，在这个模型里算 200 token，在另一个模型里可能算 260 token。如果你直接对接多家模型，token 口径不一致会让成本预估变成瞎猜。代理层把所有模型统一成一套 token 预算，应用只按自己内部的“标准 token”申请，实际费用由代理按后端模型重算，这才能做精细成本控制。
我见过不少团队，调用 LLM 时只盯模型单价，不看实际 token 消耗。结果单价便宜一半的模型，因为切词方式笨、重复字段多，最终费用反而更高。代理层配合 rtk 的结构化压缩，相当于同时解决了两件事：一是让同样的内容占更少的 token，二是让不同模型之间可以低成本切换，不会被某一家绑死。
2.2 8 万 star 背后意味着什么
star 数不一定代表技术绝对领先，但 8 万这个量级至少说明三件事。
第一，兼容性验证充分。这么多人用在生产环境，模型接口版本迭代带来的适配问题基本都被踩平了。第二，格式和生态比较稳。它提供的压缩格式、事件流规范、命令行工具，社区里已经有了大量插件和参考实现，你不需要从零造轮子。第三，默认配置的可靠性有共识。一个项目 star 数高，往往意味着“按默认配置跑通”的概率高，这对小团队尤其重要——你不想在一个不成熟工具上花两周调参。
但 star 数不能替你回答“适不适合我的场景”。我见过反例：有人把 rtk 当通用 API 网关用，结果发现它并不处理多租户的复杂鉴权；也有人指望它把任意文本无损压缩，结果发现压缩后模型读起来怪怪的。它是个好工具，但它解决的问题是“面向 LLM 的 token 优化”，不是“万能中间件”。判断标准就一条：你的业务里，信息冗余度够不够高，以及能不能接受压缩带来的信息损耗。
2.3 适合与不适合的边界
从我自己实践的角度，适合的场景有四个明显特征：输入文本重复度高、分析目标偏概要而非逐字、上下文窗口不够用、成本敏感。这类场景用 rtk 是如虎添翼。反过来，不适合的场景也有四个特征：需要保留原始文本完整性、必须逐字比对、内容涉及不能外传的敏感信息、单次请求量很小（压缩优化省下的钱抵不过部署成本）。
举几个具体例子。适合：全仓库历史代码问答、CI/CD 自动生成周报、海量日志聚合成异常摘要、爬虫正文的批量提炼。不适合：律师做证据链核对、审计报告逐字复核、需要把完整原文传给外部模型做精确翻译、单次就几百 token 的小请求。判断的方法很简单：你问自己，如果模型给出的答案是“概要级别”的，你能接受吗？能，就值得用；不能，就别折腾。
3. 适合落地这类压缩方案的典型场景拆解
3.1 代码库级 AI 问答与仓库梳理
这是 rtk 的高频主场。一个团队如果有几百个仓库、几百万行代码，靠人来梳理模块依赖和演进路径非常痛苦，但直接拿全量代码问 LLM 又贵到肉疼。正常做法是让 rtk 维护一个仓库的“压缩快照”，包含每个模块的文件列表、最近变更密度、关键提交事件，然后让 LLM 基于快照回答问题。我做过一个模拟测试：300 个仓库生成快照，总 token 消耗比原来用全量代码问答少了 93%，回答的准确性反而提升了，因为模型不再被无关细节干扰。
落地时要注意一个问题：快照更新策略。如果仓库每天都在提交，你得给 rtk 设一个定时任务，比如每小时增量更新一次，而不是每次都把整个仓库重新压缩一遍。增量更新的意思是只处理自上次快照以来的新提交，然后合并进旧事件流。这个策略能保证问答机器人始终看到“最新状态”，又不会让运行成本随仓库增长线性上升。实际配置里，我给每 15 分钟拉一次的新提交队列设了独立入口，避免重压缩全量仓库。
3.2 CI/CD 自动生成变更说明与 Code Review
另一个很适合的场景是 CI/CD 流水线。通常每次发布都要人工写变更说明，有经验的工程师能写清楚，但难免遗漏。用 rtk 把git log和git diff压缩成“变更事件流”，再让 LLM 生成发布说明，速度和覆盖度都比人工强。我试过的流程是：
- 触发发布分支的 CI 任务；
- 导出最近一次发布以来的
git log --stat和git diff --stat； - 用 rtk 压缩成事件流；
- 调用 LLM 生成三部分：主要变更点、涉及模块、潜在风险。
这套流程跑下来，一份发布说明的 token 成本大约在 3000 到 5000 token，比直接用原始 diff 省掉 90% 以上。Code Review 场景也类似，可以让模型基于压缩后的文件变更列表做重点提示，而不是把整个 diff 塞进去。这里有个经验：不要把 diff 的所有补丁细节都压掉，文件路径和函数名必须保留，否则模型很难定位具体问题。
3.3 日志与审计文本挖掘
日志文本的重复模板往往比代码流程更严重。一套系统的多行日志，可能只有错误码和时间戳在变，其余全是固定句式。这类文本喂给 LLM，token 浪费极其惊人。rtk 处理日志的思路和 git log 时一致：把日志转成事件流，把固定模板抽离成字段，只保留动态部分。之前处理某电商后端一天的全量报错日志，原始文本 3.2 GB，聚合后事件流只有 120 MB，再压缩成 token 包后约 800 万 token。这个量仍然不小，但相比原始量级已经能进了上下文预算。
日志场景有个特殊注意点：时间戳和 hostname 这类字段会让每条日志看起来都不同，压缩时如果不做归一化，相似日志根本聚合不到一起去。所以我在接入时增加了预处理规则：先把 IP、时间戳、环境名替换成占位符，再做压缩。没有这一步，压缩率会打对折。
3.4 长文档与爬虫内容的低成本总结
不是只有 git log 才能用，任何重复度高的文本都能获益。比如爬虫抓取的新闻列表、商品详情、公告页面，正文里塞满了导航文案、版权声明、广告位，这些噪音对 LLM 分析没有价值，但 token 照算不误。用 rtk 做一层清洗和结构化后，再送进总结模型，成本能降 70% 到 85%。
这个场景的技术含量不高，但收益很直接。如果做的是一个面向 C 端用户的“文章摘要工具”，每天处理几十万篇文章，原文直接送模型和压缩后送模型，成本差距就是数量级。要注意的是网页正文的编码格式和乱码问题，压缩前最好先跑一遍文本清洗，把 HTTP 头、HTML 标签、脚本片段全部剥掉。rtk 本身不负责“理解网页结构”，它只是帮你把已经提取好的文本再压一遍。
4. 实操接入：从安装到自定义规则的一步步配置
4.1 最小接入步骤：5 分钟跑通核心链路
先给一个最小可用的链路，你按这个顺序跑一遍就知道值不值得用。
第一步，安装。以命令行工具为例，我习惯用二进制方式安装，避免污染 Python 环境。假设你的系统是 Linux x64，执行对应平台的安装命令后，验证版本号能正常输出就算成功。
第二步，准备一份原始 git log。在任意仓库目录下执行导出命令，输出到一个文本文件。--no-merges不是必须的，因为 rtk 自己能聚合 merge 节点，但导出时保留完整统计信息很重要，后面压缩时会有用。
第三步，压缩。执行 rtk 的压缩命令，指定输入文件和输出路径。完成后你会看到压缩率、token 估算值、事件条数等统计信息。同一个仓库，我测过多次，压缩率一般在 95% 到 98.5% 之间，取决于 commit message 的规范程度和仓库规模。
第四步，把压缩结果喂给代理。如果你只做离线分析，可以直接把输出文件作为上下文传给 LLM；如果想做在线服务，就得把 rtk 的输出接到代理层，让每次请求都经过压缩和路由。
这套链路不需要写任何代码，纯命令行就能跑通。跑通之后，你再决定要不要集成到业务系统里。我建议第一次做的时候，把原始文件和压缩文件都存一份，对比着看模型回答，这样能直观理解压缩带来的信息损耗。
4.2 自定义压缩规则与关键参数
rtk 默认配置能覆盖大部分场景，但要拿到最优效果，几个参数值得手动调。
第一个是collapse_merge。默认开启，会把 merge 提交折叠成聚合节点。如果你的分析场景需要精确了解每一次分支合并的时间点，把它关掉，代价是 token 数会上升一些。
第二个是min_message_len。commit message 短于这个长度的提交，会被当作低语义提交聚合处理。我一般设为 8，这样 “fix”“update” 这类单词级别提交会被自动归并，保留每条独立事件的成本就省下来了。
第三个是keep_metadata。控制是否保留作者、时间戳、邮箱、文件路径等元数据。对代码梳理场景，文件路径必须保留，但作者和邮箱可以直接丢弃；对审计场景则相反，作者和时间戳反而是关键信息，文件路径可以精简。这个参数没有统一答案，完全取决于你后续让模型干什么。
第四个是tokenizer_profile。rtk 会为不同语言选择不同的切词规则。我处理混合代码库时，会先把仓库按主要语言拆成多个子目录，再分别用对应 profile 压缩，最后合并。统一用一个 profile 也能跑通，但 token 数通常会多出 20% 左右。
提示：压缩参数设置前，先想清楚“模型要回答什么”。我见过有人把 keep_metadata 全关，结果想分析哪个开发者导致性能回退时，数据集里根本没有作者信息，只能重新跑一遍压缩。参数不是越省越好，是越贴合任务越好。
4.3 与主流 LLM API 的对接方式
rtk 的产物要真正用于在线 LLM 应用，通常要经过代理层。代理层的作用是接收你应用发来的请求，自动从缓存或压缩包中取上下文，拼装 prompt，再转发给后端模型。我用的是兼容 OpenAI SDK 风格的接入方式，好处是上层代码不用大改，只需要换一下 base_url 和模型名。
下面是简化版的接入示例，我在本地跑过可用：
import os from openai import OpenAI os.environ.setdefault( "RTK_AGENT_TOKEN_CACHE", "./snapshots", ) client = OpenAI( base_url="http://127.0.0.1:8080/v1", api_key="your-service-key", ) with open("./snapshots/demo_repo_events.jsonl", "r", encoding="utf-8") as f: repo_context = f.read() resp = client.chat.completions.create( model="rtk-gateway", messages=[ {"role": "system", "content": "你是仓库分析助手，只基于给定事件流回答。"}, {"role": "user", "content": f"仓库事件流如下：\n{repo_context}\n请总结这个模块近期的演进。"}, ], temperature=0.2, ) print(resp.choices[0].message.content)这段代码里，真正和 rtk 相关的是事件流文件作为上下文注入。模型名写成rtk-gateway，因为代理层会把这个名字映射到后端真实模型。你也可以在代理配置里指定模型映射表，比如把rtk-gateway映射到某个更便宜的长上下文模型上，这样场景切分更灵活。
接入的时候，有几个容易踩的细节。请求头里的鉴权信息，代理层一般会剥离，不会透传给后端模型服务商，免得泄露密钥。超时时间也要设长一些，因为长上下文请求在后端模型的排队时间不短，默认 30 秒可能不够。缓存策略上，我建议对同一个仓库快照的相似请求打开缓存，能进一步把重复解析的 token 成本降下去，但不同快照之间的缓存命中率很低，不必强求。
4.4 多环境部署建议
我在本地开发、测试环境、生产环境分别用了不同配置。本地环境直接跑命令行工具，测试环境用 Docker 起一个代理，生产环境则把它放在 Kubernetes 里，配置了水平扩容。代理层本身无状态，所有状态都沉淀在快照文件和缓存服务里，所以扩容很简单，直接加副本就行。
生产环境的流量特征和本地差别很大，我建议至少设置三个监控指标：压缩前后 token 数、代理层缓存命中率、平均响应耗时。这三个指标能帮你快速判断是上下文太长、缓存没命中还是后端模型延迟。不要等账单出来才发现成本超标，token 监控要前置到代理层，每一条请求都在代理日志里打印 token 变化，这样月底对账才有据可查。
5. 常见问题与避坑记录
5.1 压缩后语义失真：模型答非所问
这是最常遇到的问题。用户拿压缩后的事件流喂给模型，发现模型回答的内容像“泛泛而谈”，甚至反问一些明显在原始数据里有的信息。出现这个问题的时候，先别怀疑模型能力，先看事件流里到底保住了什么。
排查步骤是从三个维度检查：关键路径有没有被折叠、commit message 有没有被聚合、元数据字段有没有被剥离。我遇到过最典型的例子：压缩时把 commit message 里类似“fix #1042”的关联信息丢掉了，结果模型找不到 issue 上下文，分析结论自然偏。解决办法是调高min_message_len到 15，并且开启“原文引用模式”，让压缩器在事件流里保留每个聚合分组的代表性原始消息。
如果压缩参数已经开了很大，仍然失真，那就要考虑是不是文本本身不适合压缩。比如某些文档大量使用“如下所示：”这种指向性表达，一旦上下文被结构化，指向关系就断了。这类输入不应该走 rtk，直接原样送模型反而更靠谱。
5.2 中文和多语言场景的 token 计算偏差
通用 tokenizer 对英文友好，对中文并不总是高效。一个中文字符可能被切分成多个 token，尤其是有大量成语、专业术语、代码混合时，偏差更大。rtk 的专用切词器虽然对代码路径有效，但在中文场景下，如果你发现压缩率只有 50% 左右，别惊讶，这是正常现象。因为中文信息密度本身就比英文高，同样语义下字符数少，压缩空间自然也小。
我的处理建议是，在压缩前做一次“语言归一化”：把同一份内容里中英文混排的部分分开统计，并且强制设置一个 token 上限，超出的部分不做压缩而是直接丢弃或另存为附件。这样至少保证模型拿到的是稳定的上下文长度，不会因为中英文字符比例变化导致成本波动。
5.3 缓存命中率低：上下文一直重复解析
代理层的缓存设计初衷是避免相同内容重复解析，但如果缓存 key 设计得不合理，命中率会非常低。最容易犯的错是把时间戳、请求 ID 这种每次都不一样的字段放进了缓存 key。结果同样是“分析 demo_repo 的事件流”，每条请求的 key 都不同，缓存相当于形同虚设。
正确的做法是让缓存 key 基于仓库快照的文件哈希，再加上用户问题的语义哈希。仓库没更新，文件哈希就不变；问题基本相似，语义哈希就相近。这样，同一份仓库快照被不同用户分析时，至少能命中上下文解析缓存，省下大量重复的 tokenizer 运算时间。我在生产环境把命中率从 10% 提到了 50% 以上，靠的就是这一条。
5.4 安全与隐私：不要把敏感日志全部塞给外部模型
压缩能降低 token 成本，但它不改写“数据出域”这个事实。如果代码或者日志里有不可外传的内容，不管压缩率多高，都不能直接送第三方模型服务。我的做法是把敏感字段在压缩前先做脱敏预处理：手机号、身份证、内网 IP、密钥信息全部替换成占位符，压缩完成后再做后续分析。
有人说，压缩到 2% 的体积，泄露风险是不是也降低了？不能这么理解。只要内容还在，模型读取后就有了记忆，体积小不等于不可见。所以，真正有合规要求的场景，最好搭配私有化部署的模型，或者至少让代理层支持敏感词过滤和审计日志功能。rtk 作为 token 代理是帮你控制成本和优化效率的，安全边界必须自己设好。
6. 动手前先想清楚的一件事
我最初接触 rtk 的时候也犯过轴，期待它能像普通压缩软件那样“什么都能压”。实际跑过十几个场景之后才总结出一个判断标准：不是看压缩率，而是看“压缩后模型输出质量是否反而提升了”。对 git log、代码变更、重复日志这类高冗余输入，压缩掉冗余能让模型聚焦核心，回答质量不降反升。对叙事性、逻辑链复杂的文本，有损压缩会伤筋动骨，强行用反而得不偿失。
如果你和我一样，主要工作集中在代码仓库分析、自动化报告、日志洞察这些方向，rtk 可能是今年最值得花半天时间试一下的工具。先从一个小仓库跑通，拿同一个问题分别问“原始输入”和“压缩输入”，自己对比一次成本和答案质量，很快就能判断它适不适合你的业务。压掉 98% 的 token，省下来的不只是钱，还有每次调用时等待的那几秒钟。
