一个 API 代理负责在请求到达大模型之前用 AST 剪枝把代码里的冗余 token 删掉再转发。这是我最近研究 LLM 费用优化时重点关注的一类方案代码文件里有大量注释、未使用的 import、重复空白和死代码这些内容每次都会被完整计费但模型真正需要的信息可能只占一小部分。AST 剪枝的思路就是先把代码解析成语法树按结构判断哪些内容可以安全删除、哪些必须保留再重新生成一份紧凑的请求发给模型。这篇文章适合两类人。一类是开发 LLM 应用被 token 成本和上下文限制反复折腾的另一类是团队接入了大模型做代码生成、代码审查、Bug 定位想把 API 费用压下来。最值得先搞清楚的不是它能省多少——这个必须实测——而是它到底在剪什么、为什么用 AST、哪些边界不能碰。把这三件事弄明白再决定要不要把它放进自己的链路。1. 先理解它剪的是什么不是文本压缩是结构裁剪1.1 一条代码请求里的 token 到底消耗在哪很多人看到“剪 token”第一反应是压缩字符串比如把代码里多余的空格换行去掉。这个理解方向没有错但太浅了。真正调用模型处理代码时请求体里通常包含三部分系统指令、历史消息、当前要分析的代码文件。系统指令一般不长历史消息是重复出现的而代码文件往往是最吃 token 的部分。一份真实业务代码里浪费点非常集中注释块。尤其是一段函数上方那几十行解释说明模型回答这个函数是干嘛的的时候其实用不上那些重复的话。未使用的 import。很多文件里导入了一堆包实际只用了一两个但 token 是按行完整计费的。长 docstring。有的项目把文档写得很细对找 Bug或者重构这类任务反而是噪声。重复的空白和样板代码。空行、缩进、换行风格不会影响语义但会占 token。显而易见的死代码。注释掉的代码块、永远不会执行的分支模型看完也不会用到。这些内容加起来往往能占总代码 token 的 20% 到 40%。具体比例取决于项目风格注解非常全、样板非常多的项目收益更大本身已经写得很紧凑的工具库可能只有几个百分点。所以不要问别人能省多少要拿自己的代码跑一遍对比。1.2 为什么选 AST 而不是正则或截断有人会问直接用正则删掉以#开头的行不就行了不行。正则的问题在于它不理解代码结构它只是按字符模式匹配。先说注释。正则删除#开头的内容会误伤字符串里的内容。比如url https://example.com/#section或者一个字典里存了key: #important。这些是字符串不是注释但正则根本分不清。AST 解析器知道哪些 token 属于注释节点哪些属于字符串节点这是结构上的区别不是靠猜。再说未使用的 import。要判断import foo到底有没有被用到需要追踪这个导入在后面的代码里是否出现了引用。正则顶多能数一下出现次数但分不清出现了和被调用了的区别。AST 可以做绑定分析找到 import 语句创建的绑定关系然后看这个绑定在哪些地方被读取。截断就更危险了。直接给代码砍掉后半段会让函数不完整、括号不匹配、定义缺失。模型拿到残缺代码轻则输出质量下降重则直接开始瞎猜补全完全偏离你的意图。AST 剪枝的基本流程是固定的原始代码 → 解析成语法树 → 标记冗余节点 → 重新生成紧凑代码 → 统计前后 token 变化 → 转发给模型这个流程的核心价值在于删除操作发生在语法树层面每一种删除都能说得清我为什么删它。这是正则做不到的。1.3 剪与不剪的边界哪些内容绝对不能动AST 剪枝的第一个原则是可以少给信息但不能给错信息。所以下面这些内容在默认情况下不能剪被导出的函数和类。一个模块的公开接口即使当前文件里没人调用也可能是给外部引用的。动态调用可能触达的符号。Python 里的getattr、globals()JavaScript 里的eval都可能引用到静态分析看来没被使用的变量。类型注解和装饰器。去掉它们确实省 token但有些任务明确依赖类型信息比如接口对齐、类型错误排查。字符串和模板内容。AST 不会剪字符串这是优点也是局限。优点是不会误伤局限是字符串里的冗余它管不了。注释也分情况。如果任务是解释这段代码为什么这么写注释反而是最核心的信息来源这时候不该剪。如果任务是找出这个函数里所有潜在的异常注释基本没用可以剪。所以一个成熟的 AST 剪枝代理不应该只有一把刀而是要有剪枝等级和任务感知。这部分的判断标准会在后面展开。2. 部署前先看运行条件代理层方案对环境的要求2.1 代理的接入方式和基础架构先理解这类工具在系统里的位置。它不是一个库不是让你在代码里调用的函数而是一个独立的代理服务。客户端把请求发到代理代理剪完 token 再转发给上游 LLM API拿到响应后原样返回。典型的接入方式项目里把 OpenAI 客户端的base_url指到代理地址。代理内部配置真实的上游 API 地址和密钥。代理兼容主流的大模型 API 请求格式不改变消息结构只改消息里的代码内容。这样做的好处是业务代码不用改只需要改一个配置项。团队里有人用 Cursor、Continue 这类支持自定义接口地址的工具也可以走同一个代理。代理本身一般包含四个部分HTTP 请求入口、语言检测和解析模块、AST 剪枝引擎、上游转发模块。请求入口负责接收消息解析模块判断里面哪一段是代码、是哪一种语言、值不值得剪剪枝引擎做实际删除最后再转发。2.2 环境准备清单部署前先核对这几项避免装完发现跑不起来。第一运行时版本。这类工具通常用 Python 或 Node.js 实现。如果项目使用的是 Python建议 3.10 以上主要为了语法树处理和异步请求的便利性Node.js 则建议 18 以上。原始材料没有给出明确版本落地时先确认实现方的依赖要求。第二语言解析器。如果只需要处理 Python标准库自带的ast模块就够了零额外依赖。如果要支持 JavaScript、TypeScript、Go、Java 等多种语言一般需要引入类似 tree-sitter 的通用解析方案。解析器决定了你能覆盖多少语言也决定了剪枝的准确率。第三上游 API 配置。代理必须知道真实接口地址、密钥、默认模型名。密钥建议通过环境变量注入不要写死在配置里。第四网络和超时。代理和上游 API 之间要有网络连通。代理本身要设请求超时避免模型接口卡住时拖垮所有请求。第五日志和统计目录。我建议从一开始就开日志记录每次请求原始 token、剪后 token、剪枝等级、语言类型。没有这些数据后面根本没法判断收益和问题。2.3 什么场景适合接入什么场景先别上适合接入的场景很明确代码密集型的 LLM 应用。比如代码审查工具、自动补全、Bug 定位、单测生成、代码重构。这些任务的输入基本都是代码文件冗余多剪枝收益大。不太适合的场景也有几类。短文本问答比如帮我起个变量名代码量少剪枝没有意义。需要完整文件上下文的场景比如把这个文件整体重构一遍你剪掉任何一段重构结果都可能不完整。还有一种需要警惕的情况当前链路极其脆弱代理本身不稳定就会导致业务中断所以生产环境接入前必须把失败回退做好。我见过不少人一上来就想把所有请求都走代理结果在对话类场景里剪掉了一段看似没用的备注模型突然回答不出调用关系了。先挑代码审查和单测生成这类明显有冗余的任务跑比什么都走代理要稳得多。3. 从一条请求跑通最小验证流程3.1 先配置上游和启动条件不要上来就接批量任务。第一次验证我建议按这个顺序走先启动代理再发一条请求确认能通再观察剪枝效果。环境变量可以先这样配置实际参数以你的实现为准UPSTREAM_BASE_URLhttps://api.example.com/v1 UPSTREAM_API_KEYyour_key_here PROXY_PORT8080 PRUNE_LEVEL1这里有个顺序问题为什么先配上游再测剪枝因为剪枝效果只能在代理能正常转发的基础上评估。如果代理连模型都调不通后面统计出来的 token 差异没有任何意义。启动之后先用健康检查或者一个最简单的不含代码的请求确认代理活着。这个动作很快但能排除掉一半的配置问题端口没监听、地址配错、密钥没加载。3.2 准备一段样例代码直接看剪枝前后差异准备一段有代表性的 Python 示例包括多余的 import、一大段注释、空行、一个定义但没用到的工具函数。比如类似这样的结构import os import json import hashlib # 下面这个函数是用来计算文件内容的 hash 值 # 当前版本已经不需要了保留作为参考 # v2 改用外部服务处理 def old_checksum(file_path): with open(file_path, rb) as f: data f.read() return hashlib.md5(data).hexdigest() def load_config(path): 加载配置文件返回 dict。 if not os.path.exists(path): return {} with open(path, r, encodingutf-8) as f: return json.load(f)这段代码里import hashlib、old_checksum函数、上方的注释块都是典型冗余。AST 剪枝之后os和json会保留因为load_config在用hashlib会删掉因为只有old_checksum用它而它本身又被判为死代码注释块会整体删除空行和 docstring 是否删除取决于剪枝等级。一个值得强调的细节剪枝前后一定要分别打印 token 数和字符数。字符数下降不代表 token 数下降因为模型 tokenizer 对代码的切分不是按字符算的有些短符号反而占独立的 token。所以判断收益的标准是模型自己的 token 统计而不是纯文本长度。3.3 对比验证同一题跑两次剪枝完不能只看 token 数下降就开心还要确认模型回答质量没变差。最简单的办法是同一个 prompt 跑两组A 组直接调用上游 API不经过代理。B 组经过代理代码被剪枝后调用。然后对比两边输出。对比的维度要具体回答是否完整、引用的函数名是否准确、给出的修改是否和原代码结构一致、有没有出现因为剪枝导致的错误结论。我一般建议拿 3 到 5 个不同任务测试覆盖解释代码找 Bug生成单测重构这四类。第一次只跑单条是为了快速定位问题。能跑通之后再开始记录统计数字评估收益。4. 核心参数与判断标准剪枝强度、语言覆盖、失败回退4.1 剪枝强度要分等级不能一刀切剪枝强度是这类工具最重要的参数。我建议按四个等级设计等级剪什么适合场景省 token 期望0不剪纯转发对比实验、确定性要求极高的场景01只规整空白和多余换行大多数通用任务最安全5% - 10%2加上删除注释、未使用 import、明显死代码代码审查、Bug 定位、单测生成15% - 30%3激进模式压缩 docstring、合并重复上下文需要大面积上下文的项目30% 以上风险上升等级 1 是默认推荐。它只处理格式化层面的冗余不改变代码语义几乎不可能引入错误。等级 2 开始有效果但必须依赖准确的语言解析和绑定分析。等级 3 不要轻易开除非你确认自己的代码没有动态调用、没有跨文件引用问题。判断剪枝等级是否合适的标准不是省得多不多而是模型输出是否正确。如果某个任务在剪枝后频繁出现幻觉或漏答先降一级再分析原因。4.2 语言识别和失败回退代理需要判断消息里哪一段是代码是哪一种语言。常见做法是在消息内容里找代码块标记比如 Markdown 代码块的python或者根据文件后缀和内容特征启发式判断。这里最容易踩的坑是解析失败。任何解析器都不是万能的特别是面对模板语法、内嵌 DSL、版本过新或过旧的语法时解析器可能直接报错。这时候的回退策略非常关键解析失败时应该原样透传不要返回错误也不要半剪。宁可少剪不能错剪。日志里标记这条请求是解析失败透传方便后面统计失败率。判断标准解析失败率如果超过 5%说明语言覆盖或者代码块检测有问题需要先修这里而不是继续优化剪枝规则。4.3 日志、统计和缓存没有统计就没有优化。代理至少要记录这几个字段请求时间、模型名、语言、剪枝等级、原始 token 数、剪后 token 数、节省比例、是否解析失败、响应延迟。有了这些数据你可以回答几个实际问题哪个语言的剪枝收益最大哪个项目的请求体最冗余剪枝之后响应延迟下降了多少有没有某些 prompt 一直在触发解析失败缓存也值得做。同一个文件的同一段代码短时间内被重复请求的概率很高比如开发者在编辑器里反复触发补全。把 AST 解析和剪枝结果按代码内容哈希缓存起来能省掉大量重复计算。缓存命中率是另一个可以统计的指标一般能达到 20% 以上就算有效。5. 批量化和生产化时要处理的坑5.1 代理本身要 fail-open不能成为单点故障这是最容易被忽视的一点。代理一旦挂了如果它选择 fail-closed拒绝转发那所有下游请求全部失败业务直接中断。正确的做法是 fail-open代理自身出现异常时直接把原始请求透传给上游 API保证业务不受影响。判断标准很简单把代理进程杀掉所有客户端应该还能正常调模型只是少了剪枝而已。做到这一点才敢把它放进生产链路。5.2 行号映射问题这是 AST 剪枝特有的坑。代码被剪掉若干行之后行号会变化。模型如果返回第 15 行有内存泄漏这个 15 对应的是剪枝后的代码而不是原始文件的行号。开发者拿着这个行号回到 IDE 里定位会指错位置。解决办法有两种。一种是在剪枝时保留原行号信息比如把原始行号作为注释标记嵌入到紧凑代码里代价是会多占一点 token。另一种是代理在返回响应的同时附上行号映射表由客户端转换。第一种实现简单第二种节省 token 但需要客户端配合。如果只是做单测生成或者代码解释行号问题影响不大。但做代码审查和 Bug 定位这个必须提前处理。5.3 单文件剪枝在多文件项目里的局限最常见的误判场景单文件里看到某个变量没被使用判定为冗余但它可能是模块导出的接口或者被配置中心按名字动态调用。单文件 AST 分析无法跨文件判断引用关系。保守策略是只剪单文件层面能确定安全的冗余比如注释、空白、从未被引用的局部变量、当前文件内没有使用的私有 import。需要跨文件分析才能判断的比如一个export function即使当前文件里没人用也不要剪。激进策略需要额外引入项目级的符号分析复杂度高很多不是常规代理的第一版该做的事。5.4 输出一致性要用样例回归来验证批量上线前一定要建一组固定样例。样例集要覆盖不同的语言、不同的任务类型、不同的代码风格。每次修改剪枝规则之后跑一遍样例集对比输出与上一次的差异。我建议的验证方式准备 20 到 50 个样例任务。每条任务记录剪枝前后的 token 数和模型输出。重点关注输出里有没有新增的错误、遗漏、幻觉。任何一次改动至少跑完整样例集再上生产。这样做不是为了证明效果多好而是为了及时发现剪枝规则调整引发的回归问题。样例集的价值是在你改激进策略时拉住你避免上线后才发现一堆任务结果变差。6. 常见问题和排查顺序6.1 剪枝之后模型输出明显变差先看什么先看代理日志里剪枝前后的 diff确认到底剪掉了什么。很多时候不是剪枝逻辑整体有问题而是某条规则对当前任务不适用。比如把 docstring 全剪了但任务恰恰要求模型理解接口的文档语义。排查顺序打开这条请求的剪枝日志看剪掉了哪些节点。把原始请求和剪枝后请求并排对比确认差异范围。降低剪枝等级重跑一次。如果降级后结果正常说明是剪枝规则过激需要针对这类任务做豁免。不要一上来就改代码逻辑先确认是不是规则配置问题。6.2 某些语言完全没有剪枝效果如果你发现 TypeScript 文件处理得很好但 Java 文件每次都原样透传先看语言识别和解析状态。可能原因代码块里没标注语言、解析器不支持该语言的新语法、剪枝规则没有覆盖该语言的节点类型。排查顺序看日志中语言检测结果确认代理认为这段代码是什么语言。确认解析器对该语言的支持范围。用最小语法样例单独测试定位是解析失败还是剪枝规则没覆盖。6.3 代理接入后请求超时或直接报错如果之前直接调用上游 API 正常走代理后开始超时先不要怀疑是剪枝的问题。按照这个顺序查代理端口是否正常监听客户端有没有把地址指对。代理能否连通上游 API网络和密钥是否还有效。请求超时时间设置是否足够模型接口慢的时候代理可能提前断开。代理日志里有没有异常堆栈有没有解析器崩溃。最后再看剪枝逻辑因为剪枝本身很快通常不会成为超时主因。这个排查链路我能反复用先排除环境再看依赖再看配置最后才怀疑核心逻辑。很多所谓剪枝导致的问题最后查出来是端口冲突或者密钥过期。6.4 关于省钱有一个容易误算的地方token 减少不等于费用等比例减少。大模型 API 的计费通常分输入和输出输入 token 便宜输出 token 贵。剪枝只减少输入 token如果某个任务模型本来就只输出几十个 token总费用下降幅度会远小于 token 减少比例。另外很多 API 提供上下文缓存重复的前缀 token 可以命中缓存价格更低。过度剪枝反而可能破坏缓存命中导致某些重复请求的计费反而变贵。这块需要实际对比账单不能只看 token 数。一个更稳妥的做法先跑一周日志统计不同任务类型的输入 token 变化、输出 token 变化和实际调用费用再决定要不要在更多场景开启高等级剪枝。AST 剪枝这类 API 代理最适合的场景是代码密集、请求体庞大、重复性高的任务。它的收益来自结构化的冗余裁剪风险也来自结构化判断的边界。最终能不能落地不看它省了多少而看你在剪枝等级、失败回退和统计验证上有没有做到位。先单条跑通再批量接入再逐步调等级这条路径最稳。