Coding Agent终端输出剪枝：Token消耗降低80%的实战方案

1. 当终端输出变成账单上的数字一个被忽视的成本黑洞第一次意识到终端输出是个问题时我正在跑一个自动化重构任务。Agent 需要遍历一个中型项目的所有测试文件逐个分析依赖关系并生成迁移方案。任务本身不复杂但跑完之后我看了眼账单愣住了——单次任务的 Token 消耗比我预估的高出将近四倍。排查过程并不曲折。打开 Agent 的执行日志真相一目了然每一次工具调用返回的终端输出都被原封不动地塞进了上下文。npm install刷了三百多行进度条pytest输出了完整的测试收集列表和每个用例的通过信息git diff把整个文件的变更内容全部打印出来——这些内容里真正对 Agent 决策有用的可能只有最后几行。这就是所谓的Token 刺客不是模型本身贵而是你喂给模型的上下文里充斥着大量无意义的噪声。更糟糕的是这些噪声还会累积。Agent 每执行一步上下文就膨胀一圈等到第十几步的时候光是历史终端输出就占了大半窗口真正需要模型关注的代码和指令反而被挤到了边缘。这就是上下文爆仓——不是窗口不够大而是有效信息密度太低。Coding Agent 和普通对话式 AI 最大的区别在于它需要频繁与终端交互。编译、测试、安装依赖、查看文件、执行脚本每一步都会产生输出。这些输出天然是给人类看的不是给模型看的。人类可以一眼扫过进度条直接看最后一行但模型不行——它会把每一个字符都当作需要理解的输入。所以问题就变成了如何在不让 Agent 丢失关键信息的前提下把终端输出压缩到极致这篇文章要聊的就是我在实际项目中摸索出的一套终端输出剪枝方案最终做到了 98% 的剪枝率同时 Agent 的任务成功率不降反升。适合正在自建 Coding Agent、或者被 Token 账单困扰的开发者参考。2. 终端输出为什么不能直接喂给模型2.1 终端输出的信息结构90% 是冗余10% 是信号先看一个真实的例子。在一个 Node.js 项目里执行npm run build终端输出大概长这样 project1.0.0 build tsc vite build vite v5.0.12 building for production... transforming... ✓ 1247 modules transformed. rendering chunks... computing gzip size... dist/index.html 0.46 kB │ gzip: 0.30 kB dist/assets/index-a1b2c3d4.css 12.34 kB │ gzip: 3.21 kB dist/assets/index-e5f6g7h8.js 234.56 kB │ gzip: 78.90 kB ✓ built in 4.32s这段输出大概 300 个字符。对 Agent 来说真正有用的信息是什么是构建成功这个结论以及如果有错误的话错误信息是什么。至于每个 chunk 的大小、gzip 压缩比、模块数量这些对 Agent 的下一步决策毫无影响。再看一个更极端的例子。跑一次pytest如果有 200 个测试用例输出会包含每个用例的 PASSED/FAILED 状态、执行时间、以及最后的汇总。200 个用例的输出轻松超过 5000 个字符但 Agent 只需要知道哪些失败了、失败的原因是什么。我统计过几种常见命令的输出信息密度命令类型典型输出长度有效信息占比主要噪声来源包管理器安装200-800 行约 2%进度条、依赖树、下载日志测试框架100-2000 行约 5%逐用例状态、耗时统计构建工具50-500 行约 8%模块列表、资源大小Git 操作10-10000 行约 3%diff 全文、文件列表日志输出不可控约 1%重复的调试信息注意这里的有效信息是站在 Agent 决策的角度定义的不是站在人类调试的角度。对人类有用的信息对 Agent 未必有用。2.2 上下文爆仓的真实代价不只是钱Token 消耗增加只是最表面的代价。更深层的影响是上下文窗口的挤占效应。假设你的 Agent 使用一个 128K 窗口的模型。系统提示词占 2K工具定义占 3K用户任务描述占 1K当前代码文件占 10K。剩下大约 112K 可供历史对话和工具输出使用。如果每次终端输出平均 5K跑 20 步就是 100K——窗口直接满了。窗口满了之后会发生什么要么触发截断把早期的对话丢掉导致 Agent 忘记之前做了什么要么触发摘要压缩但摘要本身也会丢失细节。无论哪种情况Agent 的任务成功率都会下降。我做过一组对比实验在同一个重构任务上不剪枝平均 18 步完成Token 消耗 420K成功率 72%剪枝后平均 14 步完成Token 消耗 85K成功率 89%剪枝后步数反而减少了原因是 Agent 不再被噪声干扰决策更聚焦。成功率提升则是因为上下文窗口里始终保留着真正重要的信息不会因为爆仓而丢失关键状态。2.3 为什么简单的截断策略会失效最直觉的做法是只保留最后 N 行。我一开始也是这么干的但很快发现了问题。有些命令的关键信息不在最后。比如pytest的失败摘要通常在中间最后反而是耗时统计。再比如git log的输出最后几行是最旧的提交而 Agent 通常需要的是最新的。还有编译错误错误信息可能出现在输出的任何位置简单截断会直接丢掉。另一个问题是不同命令的输出结构完全不同。用一个统一的截断规则去处理所有命令要么剪得太狠丢失信息要么剪得太松没有效果。所以剪枝方案必须是命令感知的——知道当前执行的是什么命令才能判断哪些部分是噪声、哪些部分是信号。3. 剪枝方案的整体设计三层过滤架构3.1 第一层命令识别与分类剪枝的第一步不是剪而是认。Agent 在执行任何命令之前先对命令进行分类。我把它分成几个大类包管理类npm install、pip install、yarn add、cargo build等测试类pytest、jest、go test、cargo test等构建类tsc、vite build、webpack、make等版本控制类git diff、git log、git status等文件操作类ls、cat、find、grep等通用类不属于以上任何一类的命令分类的依据是命令的第一个 token 和关键参数。比如npm开头且包含install或ci的归为包管理类pytest开头的归为测试类。这个分类不需要非常精确因为后续的剪枝规则是按类应用的即使分类有偏差也不会造成灾难性后果。但分类的覆盖率要足够高我实测下来在一个典型的 Coding Agent 工作流中前五类命令占了总调用次数的 85% 以上。3.2 第二层结构化解析与信号提取分类完成后针对每一类命令用对应的解析器提取信号。以测试类命令为例。pytest的输出虽然看起来杂乱但其实有很强的结构每个用例的结果行以PASSED、FAILED、ERROR结尾失败详情以FAILED开头后跟文件路径和行号最后的汇总行包含通过/失败/跳过的数量。我的解析器会做这几件事扫描所有行提取失败和错误的用例信息文件、行号、断言差异提取最后的汇总统计丢弃所有 PASSED 的用例行丢弃耗时统计和进度条对于包管理类命令解析逻辑完全不同检测是否有ERR!或error关键字有则提取错误块检测是否有added X packages或Successfully installed之类的成功标志丢弃所有下载进度、依赖树、警告信息这里有个关键决策成功时极度精简失败时保留更多细节。因为成功时 Agent 只需要知道可以继续下一步失败时才需要详细信息来诊断问题。3.3 第三层动态预算与优先级排序即使经过前两层过滤有些命令的输出仍然可能很长比如一个包含大量错误的构建日志。这时候需要第三层动态预算控制。我给每次工具调用设定一个输出预算默认是 2000 个字符。如果过滤后的输出超过预算就按优先级排序保留最重要的部分。优先级的排序规则错误和异常信息最高优先级警告信息成功/失败的状态标志统计汇总其他信息最低优先级排序后从高到低取直到达到预算上限。如果最高优先级的错误信息本身就超过预算那就对错误信息内部再做一次精简比如只保留前 5 个错误后面的折叠为还有 N 个类似错误。提示预算值不是固定的。对于测试和构建类命令我给 2000 字符对于文件读取类命令我给 4000 字符因为文件内容通常需要完整保留。这个值可以根据你的模型窗口大小和任务复杂度调整。4. 各类命令的具体剪枝规则与实现4.1 包管理器输出只关心成了没和错在哪包管理器的输出是噪声重灾区。以npm install为例一个中等项目的完整输出可能包含依赖解析的进度信息每个包的下载进度条依赖树的警告peer dependency 问题安全审计报告最终的安装统计我的剪枝规则是这样的def prune_package_manager(output: str) - str: lines output.split(\n) result [] error_block [] in_error False for line in lines: # 检测错误开始 if re.search(rERR!|error|Error|ERROR, line): in_error True # 检测错误结束空行或新的非错误段落 if in_error and line.strip() : in_error False if error_block: result.append(\n.join(error_block)) error_block [] continue if in_error: error_block.append(line) continue # 提取成功标志 if re.search(radded \d packages?|Successfully installed|up to date, line): result.append(line.strip()) # 如果有未闭合的错误块 if error_block: result.append(\n.join(error_block)) return \n.join(result) if result else Command completed with no significant output.这段代码的核心逻辑是错误信息完整保留成功信息只保留一行摘要其余全部丢弃。实测下来一个原本 500 行的npm install输出剪枝后通常只剩 3-5 行。如果安装失败错误块会被完整保留通常 10-30 行足够 Agent 诊断问题。4.2 测试框架输出失败详情是唯一有价值的信号测试输出的剪枝稍微复杂一些因为不同测试框架的输出格式差异很大。我目前支持 pytest、jest、go test 和 cargo test 四种覆盖了大部分场景。以 pytest 为例剪枝逻辑分三步第一步提取失败用例的完整信息。pytest 的失败输出格式很规整每个失败以FAILED或ERROR开头后面跟着文件路径和用例名然后是详细的断言差异。我会把这些块完整保留。第二步提取汇总行。通常是最后几行格式类似5 failed, 195 passed, 2 skipped in 12.34s。这一行必须保留因为它给了 Agent 一个全局判断。第三步丢弃所有通过用例的行。这些行对 Agent 没有任何价值。def prune_pytest(output: str) - str: lines output.split(\n) failures [] summary current_failure [] in_failure False for line in lines: # 汇总行 if re.search(r\d (failed|passed|error|skipped), line) and in line: summary line.strip() continue # 失败开始 if line.startswith(FAILED) or line.startswith(ERROR): if current_failure: failures.append(\n.join(current_failure)) current_failure [line] in_failure True continue # 失败详情缩进的行 if in_failure and (line.startswith( ) or line.startswith(E ) or line.startswith(_)): current_failure.append(line) continue # 失败块结束 if in_failure and line.strip() : in_failure False if current_failure: failures.append(\n.join(current_failure)) result [] if failures: result.append(f {len(failures)} Failure(s) ) result.extend(failures[:5]) # 最多保留5个失败详情 if len(failures) 5: result.append(f... and {len(failures) - 5} more failures) if summary: result.append(summary) return \n.join(result) if result else All tests passed.这里有个细节失败详情最多保留 5 个。因为如果 20 个测试都失败了大概率是同一个根因导致的看 5 个和看 20 个对 Agent 的诊断没有区别反而会浪费上下文。4.3 构建工具输出错误优先警告折叠构建工具的输出特点是成功时输出很短失败时输出可能非常长尤其是 TypeScript 的类型错误。对于成功的情况我通常只保留最后一行比如✓ built in 4.32s或Compiled successfully。对于失败的情况处理策略是提取所有错误信息按文件分组每个文件的错误最多保留 3 条警告信息折叠为一行统计丢弃所有进度和模块信息def prune_build_output(output: str) - str: lines output.split(\n) errors [] warnings_count 0 success_line for line in lines: if re.search(rerror TS\d|ERROR|Error:, line): errors.append(line.strip()) elif re.search(rwarning|WARN, line, re.IGNORECASE): warnings_count 1 elif re.search(rbuilt in|Compiled successfully|Build completed, line): success_line line.strip() result [] if errors: result.append(f {len(errors)} Error(s) ) result.extend(errors[:10]) if len(errors) 10: result.append(f... and {len(errors) - 10} more errors) if warnings_count: result.append(f({warnings_count} warnings omitted)) if success_line and not errors: result.append(success_line) return \n.join(result) if result else Build completed.4.4 Git 与文件操作按需裁剪保留结构Git 命令的剪枝策略取决于具体子命令git status保留分支信息和变更文件列表丢弃未跟踪文件的详细路径只保留数量git diff这是最棘手的因为 diff 内容本身就是 Agent 需要的信息。我的策略是保留完整 diff但设置一个上限比如 500 行超过部分折叠git log只保留最近 10 条提交的摘要行丢弃作者、日期等元信息文件操作类命令ls、find、grep的剪枝相对简单保留结果列表但如果结果超过 50 条只保留前 50 条并标注总数。def prune_file_listing(output: str, max_items: int 50) - str: lines [l for l in output.split(\n) if l.strip()] if len(lines) max_items: return output return \n.join(lines[:max_items]) f\n... and {len(lines) - max_items} more items5. 剪枝率 98% 是怎么算出来的以及实测数据5.1 剪枝率的定义与测量方法98% 剪枝率这个数字需要明确定义否则容易产生误导。我的定义是剪枝率 (原始输出字符数 - 剪枝后字符数) / 原始输出字符数测量方法是在 Agent 的工具调用层加一个拦截器记录每次调用的原始输出长度和剪枝后长度任务结束后汇总。需要说明的是这个 98% 是一个加权平均值不是每个命令都能达到。实际上包管理器命令的剪枝率通常在 95%-99%测试命令的剪枝率在 90%-98%取决于失败数量构建命令成功时剪枝率接近 99%失败时可能只有 70%-80%Git diff 的剪枝率最低可能只有 50%-60%但因为包管理器和测试命令的调用频率最高、原始输出最长所以加权平均下来能达到 98%。5.2 一组真实的对比数据我在一个包含 47 个源文件、约 12000 行代码的 TypeScript 项目上跑了一组对比。任务是将所有回调风格的异步函数重构为 async/await。指标不剪枝剪枝后变化总 Token 消耗423,00086,000-79.7%工具调用次数5241-21.2%上下文峰值占用118K34K-71.2%任务完成时间8分12秒5分47秒-29.5%任务成功率72%89%17%工具调用次数减少的原因很有意思不剪枝时Agent 经常因为上下文里噪声太多而迷失重复执行已经做过的操作。剪枝后上下文干净了Agent 能更准确地判断当前状态。5.3 剪枝带来的意外收益Agent 决策质量提升这是我一开始没有预料到的。剪枝不仅省了钱还让 Agent 变聪明了。原因在于模型的注意力是有限的。当上下文里充斥着进度条和通过用例时模型需要花更多注意力去忽略这些噪声留给真正重要信息的注意力就少了。剪枝相当于帮模型做了注意力聚焦。一个具体的例子在剪枝前Agent 经常在测试失败后忽略失败详情直接去改代码改完再跑测试发现还是失败再改。剪枝后Agent 会先仔细读失败详情定位到具体的断言差异然后有针对性地修改。这个行为差异直接体现在了任务成功率上。6. 落地过程中的坑与调优经验6.1 剪得太狠导致 Agent 丢失关键上下文我最初版本的剪枝规则过于激进对git diff也做了大幅裁剪只保留变更的文件名和行数统计。结果 Agent 完全不知道具体改了什么重构任务直接失败。教训是对于本身就是信息载体的命令diff、cat、日志查询剪枝要保守。这些命令的输出就是 Agent 需要的内容剪掉就等于蒙住了它的眼睛。我的调整方案是给不同命令设置不同的剪枝强度高剪枝强度目标剪枝率 95%包管理、构建、测试中剪枝强度目标剪枝率 60%-80%git status、文件列表、grep 结果低剪枝强度目标剪枝率 30%git diff、cat、日志内容6.2 错误信息被误判为噪声早期版本有个 bug某些工具的错误信息格式不标准比如用[ERROR]而不是error或者错误信息混在进度条中间。我的正则没匹配到导致错误被当作噪声丢弃Agent 以为命令成功了继续往下走最后任务失败。修复方法是增加一个兜底检测如果命令的退出码非零但剪枝后的输出里没有任何错误标志就保留原始输出的最后 20 行作为兜底。这样即使正则漏了也不会完全丢失错误信息。提示退出码是比输出内容更可靠的信号。任何剪枝方案都应该把退出码作为第一判断依据输出内容分析作为补充。6.3 不同项目的输出格式差异同一个命令在不同项目里的输出可能完全不同。比如npm install在 monorepo 里的输出比单包项目复杂得多pytest在不同插件配置下的输出格式也有差异。我的应对策略是规则可配置。把每种命令的剪枝规则写成配置文件不同项目可以覆盖默认规则。比如某个项目用了自定义的测试报告插件就可以在配置里指定新的解析规则。# prune_rules.yaml package_manager: error_patterns: - ERR! - error - \\[ERROR\\] success_patterns: - added \\d packages? - Successfully installed max_error_lines: 50 test: frameworks: pytest: failure_prefix: [FAILED, ERROR] summary_pattern: \\d (failed|passed|error) jest: failure_prefix: [✕, ●] summary_pattern: Tests:.*(failed|passed)6.4 剪枝逻辑本身的性能开销剪枝是在 Agent 的执行链路里同步做的如果剪枝本身太慢会拖慢整个任务。我一开始用纯 Python 正则逐行处理对于上万行的输出处理时间能到几百毫秒。优化方向有两个一是预编译正则表达式避免每次调用都重新编译二是对于超长输出先用简单的字符串匹配做粗筛只对可能包含关键信息的行做精细解析。实测下来优化后单次剪枝的耗时通常在 5-20 毫秒相对于模型推理的时间可以忽略不计。7. 把这套方案接入你的 Agent 工作流7.1 接入位置工具调用层的拦截器剪枝逻辑应该放在工具执行和结果返回给模型之间。如果你用的是自己实现的 Agent 框架通常有一个统一的工具调用入口在那里加一个后处理钩子即可。class ToolExecutor: def execute(self, command: str) - str: raw_output self._run_command(command) exit_code self._get_exit_code() # 剪枝 pruned self.pruner.prune(command, raw_output, exit_code) # 记录统计 self.stats.record( commandcommand, raw_lenlen(raw_output), pruned_lenlen(pruned), exit_codeexit_code ) return pruned如果你用的是现成的 Agent 框架比如 LangChain 或 AutoGPT通常也提供了工具输出的后处理接口找到对应的 hook 点接入即可。7.2 渐进式启用先观察再剪枝不要一上来就全量启用剪枝。我的建议是分三步走第一步只记录不剪枝。在工具调用层记录每次的原始输出长度、命令类型、退出码跑几个任务看看你的 Agent 主要在哪些命令上消耗 Token。第二步对高消耗命令启用剪枝。通常是包管理器和测试命令。这两个类别的剪枝规则最成熟风险最低。第三步逐步扩展到其他命令。每次扩展后跑一组回归测试确认任务成功率没有下降。7.3 监控与告警剪枝率突然变化要警惕剪枝率是一个很好的健康指标。如果某天剪枝率突然从 98% 掉到 80%通常意味着有新的命令类型没有被分类规则覆盖某个工具的输出格式变了解析规则失效项目里出现了大量错误导致错误信息被完整保留无论哪种情况都值得去看一眼。我在生产环境里加了一个简单的告警如果单次任务的剪枝率低于 85%就在日志里打一个 warning。8. 一些边界情况与后续可以做的事8.1 交互式命令的处理有些命令是交互式的比如npm init会等待用户输入。这类命令在 Agent 场景下通常需要加-y或--yes参数来跳过交互。如果无法跳过剪枝逻辑需要能够识别命令正在等待输入的状态并把这个信息传递给 Agent。我的做法是设置一个超时如果命令在 N 秒内没有退出且输出没有变化就判定为交互式等待返回一个特殊标记让 Agent 决定下一步。8.2 流式输出的剪枝有些命令是流式输出的比如tail -f或长时间运行的构建。对于这类命令剪枝策略需要调整不能等命令结束再剪而是要在流式过程中实时剪枝。我目前的方案是对流式输出做滑动窗口处理只保留最近 N 行的剪枝结果同时维护一个关键事件列表记录过程中出现的错误和警告。8.3 多语言项目的规则扩展我目前的规则主要覆盖 JavaScript/TypeScript、Python、Go 和 Rust 生态。如果你用的是其他语言栈需要补充对应的命令分类和解析规则。规则本身是声明式的扩展起来不算复杂主要是要花时间研究目标命令的输出格式。一个偷懒的办法是先用通用规则跑一段时间收集原始输出样本然后针对性地写解析规则。这比凭空猜测输出格式要靠谱得多。8.4 和上下文压缩的配合终端输出剪枝解决的是单次工具调用的输出膨胀但多轮对话的历史累积是另一个问题。两者需要配合使用剪枝降低单次输出的体积上下文压缩比如对早期对话做摘要控制历史总量。我的经验是剪枝做好之后上下文压缩的压力会小很多甚至在某些短任务里可以完全不用压缩。这也从侧面说明很多上下文爆仓问题根源其实在输入端没有做好过滤。这套方案我陆陆续续打磨了大半年从最初的简单截断到现在三层过滤架构中间踩了不少坑但最终的效果是值得的。如果你也在自建 Coding Agent建议从记录工具输出长度开始先看清楚钱花在了哪里再决定怎么剪。