1. Token 都去哪了先给 Coding Agent 算一笔成本账1.1 一次小修小补烧掉两万 Token 的真实场景先还原一个我前两天实际经历的场面。我用 Coding Agent 改一个 Java 服务的日志配置原本预期是改动一个 properties 文件、重跑一次测试验证就可以收工的事结果整个会话硬生生烧掉了两万多个 Token上下文窗口从 70% 一路冲到 92%最后被迫清了历史记录才能继续。问题出在哪不是 Agent 理解不了需求而是它在看我的终端时太实在了。我让它跑mvn test它把进程里的输出完完整整接走了从 Maven 下载依赖的进度条、Surefire 每个测试用例的 INFO 日志到堆栈的中间帧全部作为上下文喂给了模型。这是我此前一直忽略的Coding Agent 和传统 IDE 不一样它读终端不是显示给你看而是每个字节都要进模型、都要折算成 Token、都要占用上下文容量。终端输出越啰嗦Agent 的视野就越容易被垃圾信息占满真正让它做判断的那几行关键错误提示反而被淹没在几万字符的噪音里。这个场景估计很多人见过Agent 在同一个错误上反复打转或者修完 A 忘了 B因为上下文里相关的信息早就被后续日志顶出了注意力范围。要说罪魁祸首终端输出绝对首当其冲。本文我就围绕这个点展开为什么一个98% 终端输出剪枝的思路能同时解决 Token 刺客和上下文爆仓两个问题以及这套方案我是怎么落地的。1.2 终端输出为什么是刺客重灾区先量化一下终端输出的成本。一段典型构建日志里包含的信息大致有这么几类工具横幅和版本信息比如 Maven 启动时打印的 banner依赖解析和下载过程一行一个 artifact动辄几百行测试进度输出每个用例一条 Tests run: xx, Failures: xx编译告警、弃用提示等重复性噪音真正的错误堆栈但通常十行里只有两三行是关键帧ANSI 转义序列各种颜色控制码人看不见但模型看得见。其中真正对 Agent 决策有帮助的占比往往不到 2%。换句话说如果你什么都不做就让 Agent 全盘接收终端输出98% 的上下文容量都花在了与本次任务无关的文字上。这也是把终端输出剪枝作为切入点时98% 这个数字的来源它不是标榜一套神奇算法能无损压掉 98% 的信息而是指在真实构建和测试日志里值得交给模型的语义信息天然就只占极小一部分剪枝做的只是把这部分挑出来。1.3 上下文爆仓的本质不是窗口太小而是垃圾太多现在各家 Agent 都把上下文窗口越做越大有的已经到了百万 Token 级别。有些朋友觉得窗口大了就不怕爆仓了我实测下来并不是这么回事。大上下文模型在长文本上的注意力分配是有限制的输入越长单位 Token 的关注度越稀薄关键信息容易淹没在海量输出中。而且成本也跟着输入量走把几万字符的日志全塞进去钱花在了不该花的地方。所以我把上下文爆仓拆成两层来看一是容量层窗口满了新信息进不来这是显性爆仓二是质量层窗口虽然没满但有用的信号密度太低模型找不到重点这是隐性爆仓。终端输出剪枝关键解决的是第二层同时大幅延缓第一层的到来。从这个角度说剪枝不是少给模型一点东西而是给模型更准确的上下文。它相当于一个信息筛选器挡在终端和模型中间先把噪音滤掉再把精华送给模型。2. 剪枝思路一个信息筛选器该怎么设计2.1 先给输出打分什么值得进上下文做剪枝之前我给自己定了一条原则不要试图理解所有输出而是先分类再按类别决定取舍。我把终端输出从信息密度上分了四个等级关键信号编译错误、测试失败的断言信息、异常堆栈的头部帧、端口冲突等直接说明哪里出问题的行必须完整保留状态摘要测试总数、通过/失败数量、覆盖率百分比、构建成功或失败结论保留但可以精简成一行过程噪音依赖下载列表、每个用例的执行日志、工具 banner、重复告警全部丢弃或合并成一行格式垃圾ANSI 转义码、极长的编码串、窗口控制字符直接剥离。这套分级是我所有剪枝规则的底层逻辑。之后的过滤器、截断策略、采样策略本质上都是在回答这一段输出属于哪一级、应该保留还是丢弃。2.2 三种剪枝手段的适用场景剪枝不是单一算法而是一套组合方案。按实现方式我分了三种第一是规则剪枝。利用正则、前缀匹配、长度限制等手段做静态过滤。优点是零开销、完全可控、不依赖模型缺点是只能处理已知噪音模式遇到没见过的格式就无能为力。第二是采样剪枝。限制行数和字节数比如最多保留前 50 行加最后 100 行或者按比例抽样。优点是普适、简单对任何输出都能生效缺点是会误伤中间段的关键信息比如错误堆栈里有用的调用链刚好被截掉了。第三是语义剪枝。借助轻量级的规则加关键词打分判断某几行是不是值得保留。说实话在编码 Agent 场景里我没必要为终端输出专门上一个模型来做语义判断成本太高况且大部分日志是高度格式化的规则足够处理。真正需要一点语义判断的地方是错误信息摘要后面会讲。选型的时候我的建议是优先规则剪枝它是性价比最高的再叠加采样剪枝作为兜底语义剪枝只在特定位置补充。别一上来就上大模型剪枝那等于用更大的 Token 去省小 Token账算不过来。2.3 98% 压缩率是怎么算出来的实现完第一版之后我拿一个真实的 Maven 项目做了量化测试。项目里跑一次全量测试原始终端输出 58KB不算 ANSI 控制码纯文本字符数大约 5.8 万。经过剪枝过滤掉依赖下载日志、测试进度日志、banner、重复告警保留测试汇总行、错误堆栈关键头、构建结果最终进入上下文的内容只有大约 1.1KB。5.8 万字符到 1.1KB保留比例约 1.9%压缩率约 98.1%。这个数字为什么能达到让我拆开算一下依赖下载日志占了 22KB 左右全滤掉Surefire 每个用例的 INFO 行加起来 18KB全滤掉重复的弃用警告 8KB合并成一行编译命令回显 4KB只保留关键参数ANSI 转义和空行 3KB直接剥离真正有用的测试汇总、错误断言、失败用例列表加起来不到 3KB。最后我还做了个简单校验把剪枝后的内容和 Agent 实际需求对比发现它需要的测试失败了哪个类哪个方法哪一行断言不对恰好都在这 3KB 里。剪枝不是盲目丢弃而是系统性地把决策所需信息和渲染所需信息分离了。3. 实操一套可落地的终端输出剪枝管线3.1 前置准备先录日志再写规则动手剪枝之前我强烈建议先做一步把你要处理的典型终端输出采集下来存成文件然后对着真实输出写规则。我见过太多人凭想象写剪枝规则结果上线一测发现连真实日志长什么样都对不上。具体做法是在 Coding Agent 的工具层做一个输出捕获钩子把进程的标准输出和标准错误分离开分别落盘。然后跑一遍真实的测试、构建、检查任务拿到几个典型样本。对照样本你会发现每个工具链的噪音模式都不一样Maven 和 Gradle 的噪音主要在依赖下载和测试进度TypeScript 编译的噪音主要在大量类型检查的冗长日志Rust cargo build 的噪音主要在编译单元列表和重复警告前端 dev server 的噪音主要在热更新文件列表。我的做法是对每个工具链维护一个独立的过滤规则文件在 Agent 调用时根据命令类型自动加载。这一步做完后面的剪枝就顺了。3.2 规则引擎四条通用过滤规则提炼出来的通用规则我用 Python 写了个原型核心逻辑并不复杂。先看代码import re # ANSI 转义与窗口控制字符直接剥掉 ANSI_RE re.compile(r\x1b\[[0-9;]*[a-zA-Z]|\x1b\][^\x07]*\x07) # 常见噪音日志时间戳、依赖坐标、测试进度行 NOISE_PATTERNS [ re.compile(r^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}[,\s]), re.compile(rDownloading|Downloaded|Progress \(, re.I), re.compile(r^\[INFO\] Tests run:, re.I), re.compile(r^\s*at (org\.apache\.maven|java\.base|jdk\.)), ] def prune_terminal_output(raw_text: str, max_lines: int 300, max_line_len: int 200) - str: lines [] for line in raw_text.splitlines(): line ANSI_RE.sub(, line) if not line.strip(): continue if any(p.search(line) for p in NOISE_PATTERNS): continue if len(line) max_line_len: line line[:max_line_len] lines.append(line) head lines[:50] tail lines[-100:] return \n.join(head tail)这里面有几个设计点值得说一下。ANSI_RE 一定要放到最前面处理颜色控制码在终端里不可见但在 Token 里是实打实的成本必须先剥掉。NOISE_PATTERNS 用的是正则匹配匹配到任一行就直接丢弃这里我刻意把依赖下载这类和构建功能无关的进度信息整段去掉而不是截断因为它们对诊断问题没有任何帮助。截断超长行需要注意错误堆栈里经常有一些特别长的文件路径截断时我是保留前缀的因为判断哪个模块报错主要看路径前缀后面那一长串坐标反而用处不大。头尾保留策略是最值得留意的。典型的动态输出场景比如 dev server 的日志最新状态永远在尾部所以尾部比中间重要而命令行参数回显和 banner 在头部偶尔有用。这个通用方案在真实场景里还需要根据任务类型微调头尾数量。原型只用了规则加采样两层就已经能达到 95% 左右的压缩率后面再加上错误感知才把最后几个百分点补齐。3.3 错误感知剪枝要会看痛苦表情纯规则剪枝有个致命缺陷它对错误没有感知。如果某一行不是已知的噪音格式它就会被当成正常信息保留下来。但反过来说如果整个输出里只有一行是真正的错误而其他全是噪音规则剪枝可能把那一行也当成噪音丢掉。所以我在管线里加了第二层错误信号增强。具体逻辑是设置一个状态机状态分为正常输出、发现问题、收集错误上下文一旦某一行匹配到 ERROR、FATAL、Exception、Caused by、AssertionError、退出码非零等信号词立即进入收集模式收集模式下该行的上下各 N 行全部保留直到遇到下一个状态切换或连续 5 行都没有信号词。为什么上下行要一起保留因为单看一行错误往往不够比如异常堆栈里真正的原因和顶层异常之间隔着十几行只留一行会把因果链切断。保留上下 10 行在绝大多数场景下能把因果链完整包住又不会引入太多噪音。这一层的效果是决定性的。我对比过没有错误感知的纯规则剪枝压缩率可以到 95%但偶尔会把关键错误整段丢掉加上错误感知之后压缩率略微降到 93% 到 98% 之间但关键错误的保留率能做到接近 100%。在 Coding Agent 场景里宁可少压一点也不能让模型看不见错误这个取舍毫无疑问是值得的。3.4 按任务类型切换剪枝策略剪枝规则不能一套打天下我的做法是按照任务类型维护不同的配置。用表格总结一下我的配置任务类型典型命令剪枝策略构建mvn package / cargo build保留编译错误、警告摘要过滤下载进度尾部保留构建结果测试pytest / jest / mvn test保留断言失败、测试汇总过滤单个用例日志错误堆栈前后各留 10 行静态检查eslint / clippy / spotbugs保留全部警告和错误过滤 banner 和重复建议按文件路径分组服务启动next dev / npm start保留启动关键地址和错误过滤热更新日志只留尾部最新 20 行命令回显git status / ls / grep不过滤原样保留这些命令本身输出就很少这里有一个可能反直觉的配置静态检查任务里我要保留全部的警告和错误而不是只留汇总。原因是这类任务的输出密度很高几乎每一行都对应一个需要 Agent 处理的代码问题过滤掉任何一行都可能漏掉一个 bug。相比之下构建日志里九成是纯噪音密度极低才需要大砍特砍。剪枝的本质是根据输出信息密度来动态调整保留比例而不是看到所有输出都无脑压缩。4. 剪枝之外上下文工程才是治本方案4.1 长上下文不是垃圾桶剪枝解决的是输入端问题但光有输入端还不够还要讲清楚它和长上下文的关系。最近不少 Agent 都放开到百万级 Token 上下文了很多团队的第一反应是那我可以把整个仓库丢进去再也不用管什么剪枝了。我的实测结论是长上下文可以当仓库背景知识库但不能当日志垃圾桶。做个类比一百万 Token 就像一个大房间。你把整个仓库的书都搬进去模型翻找起来照样费劲但如果房间大且整洁书都按索引排好它查起资料来就很快。终端输出剪枝做的就是保持整洁长上下文提供的是更大的存储空间。有了更大的空间就要更加讲卫生因为空间的代价是注意力质量下降不是免费午餐。实际使用中我把长上下文留给代码文件、项目结构、设计文档这些静态知识而终端输出这种动态过程信息仍然坚持先剪枝再进入。这样两者优势互补模型既知道整个项目的大背景又能精准聚焦到当前构建失败的细节。4.2 提示词工程配合告诉 Agent 输出的边界剪枝只是工具侧做的事Agent 自己也得配合。我在系统提示词和工具描述里加了一些约束效果立竿见影明确告诉它在调用终端工具时标准输出可能已被过滤请优先关注标准错误和错误摘要要求它在执行长任务时主动用--quiet、-q等参数压制冗长输出约定错误处理协议看到非零退出码先读取剪枝后的错误摘要再决定是否需要查看完整日志定义输出规范回复中展示的终端内容必须是剪枝后的关键行并标注原始日志文件路径。这些约定本质上就是提示词工程和上下文工程的配合。提示词工程决定模型怎么理解任务上下文工程决定模型看到什么信息两者结合才能让 Agent 的输出质量稳定。有一次我观察到Agent 在跑构建时用了安静模式输出量直接从 58KB 掉到 8KB这是最省 Token 的做法。剪枝管线处理这 8KB 后只剩不到 1KB整个会话成本打了个对折不止。4.3 多智能体协作场景下的上下文网关如果团队里已经用了多智能体架构剪枝的价值会进一步放大。因为多个 Agent 之间要传递上下文每传递一次Token 成本就翻倍一次。你不希望 A 把 60KB 日志传给 BB 再传给 C最后光日志传递就烧掉上百万 Token。我的建议是在所有 Agent 的交互接口处统一加一层上下文网关。网关负责三件事一是输出剪枝任何 Agent 产出的终端输出、任务结果进入共享上下文前先跑一遍过滤二是摘要入库凡是 Agent 产生的关键结果写成一个结构化摘要存到共享的 Agent 记忆里而不是把原始日志存进去三是按需归档完整日志落盘到独立的日志系统按任务 ID 关联需要时再按需拉取。这个规范落地后我们内部的 Coding Agent 协作从每个 Agent 都背着一大包原始日志变成了每个 Agent 只拿自己需要的卡片多智能体之间的 Token 开销降了一个数量级。5. 常见问题与排查实录5.1 剪枝之后关键错误信息也丢了这是我被问得最多的一个问题也是最容易踩的坑。原因大多是规则写得太激进把看起来像噪音的关键行也过滤掉了。排查思路是先把剪枝前后的输出各留一份跑一个对比脚本把所有被过滤掉的行重新找出来人工扫一遍。常见是因为时间戳正则写得太宽把错误信息里某些以日期开头的行也匹配掉了或者是忽略全部 INFO 行的规则把一部分 INFO 级别的错误上下文也滤掉了。我的经验是给过滤规则加一个例外机制凡是包含 ERROR、Exception、Failed、Caused by 等信号词的行跳过所有过滤规则强行保留。这相当于给关键信息发了一张免死金牌简单粗暴但极其有效。5.2 日志定位失效出问题找不到现场剪枝可以挡住 Agent 的上下文但挡不住排查需求。如果剪枝把过程日志都丢了当你事后想手动排查某次失败时就找不到原始现场了。解决方式是分层存储剪枝只影响进入上下文的量不允许影响落盘的量。终端输出无论多长都完整写入本地日志文件并保留任务 ID、时间戳、命令等元信息。Agent 拿到的是剪枝后的摘要摘要上标注完整日志的文件路径需要排查时开发者和 Agent 都可以按需去读那个文件。这里注意一个细节Agent 补读日志文件时读取范围要控制建议一次最多读尾部 200 行避免又把整个日志卷进上下文。5.3 Token 用量统计口径不一致还有一类问题是统计层面的。同一个会话有人看 API 后台显示消耗很多看自己客户端显示只有一小部分差距巨大。其实是因为统计口径不同有的只算输出有的算输入加输出有的把缓存命中也算进去。剪枝能让所有口径下的数字都显著下降但你要想准确核算我建议在 Agent 的工作流里加一个计数器按输入剪枝前字符数、剪枝后字符数、模型实际输入 Token、模型输出 Token分开记录。这样既能看到剪枝的压缩率也能换算成真实成本。我实际跑过一个统计接入剪枝前一个典型的三轮测试修复会话大约消耗 40 万到 60 万 Token接入剪枝后同样的任务降到了 12 万到 18 万综合成本大约节省七成以上。5.4 存量项目的兼容问题最后提示一个工程化层面的坑如果项目已经积累了大量 Agent 配置和提示词突然接入剪枝管线可能会因为原有提示词里写了请查看完整输出读取日志全文之类的内容导致 Agent 的行为异常。我的建议是渐进式灰度先只对构建、测试两类高频长输出命令开启剪枝其他命令保持原样同时在系统提示词里加入输出可能已被过滤的说明让 Agent 自己调整预期。跑一两周确认没有关键信息丢失再逐步扩大范围。遇到 Agent 反复从剪枝摘要里找不到答案的反馈时不要急着关掉剪枝先看它到底缺哪条信息然后针对性地把那条信息加进保留规则里。这个过程本质上就是持续优化剪枝规则配置一两周之后就能趋于稳定。最后再说一个我的体会。剪枝这件事听起来是省 Token、防爆仓的成本控制操作但真正跑起来以后你会发现它最大的价值是让 Coding Agent 的注意力更加集中。省下来的上下文空间都变成了它真正聚焦在问题上的能力。给工具装上筛选器等于帮模型腾出脑子这比单纯把窗口调大要划算得多。如果你也在被 Token 成本困扰我建议从今天跑的任意一次构建日志开始先量一下原始输出多少字符再人工挑出真正有用的那几行看看占比是不是也低于 2%。如果是系统性的剪枝就值得你动手了。