1. 问题背景Token开销是怎么悄悄失控的先用一段真实的日常来说明问题。我平时用Claude Code和Codex这类AI编程代理写代码最初觉得“AI干活真爽”直到月底看账单时愣住——一次功能迭代烧掉几万Token一问周围同事大家全是同款状况。问题的核心往往不是对话本身而是工具输出。所谓工具输出指的是AI代理在执行任务时调用的工具返回结果。比如它读取文件、运行测试、搜索代码、查看Git状态每一个动作都会返回一大段内容回到模型上下文里。代码文件动辄几百行测试日志动辄几十条Git diff动辄上千行改动。这些结果全部进入Token计算而且往往是按输出Token计费的。模型本身生成的思考内容其实占比不大真正吃掉预算的是那些看起来不起眼、却反复进入上下文的工具返回。为什么这个问题值得专门拿出来讲因为大多数优化文章都在聊“怎么让模型少说废话”“怎么压缩Prompt”但工具输出是被严重低估的隐形消耗点。对AI编程代理来说工具体系越丰富工具输出占比越高。你让代理多用几次工具Token用量就能翻好几倍而且这类消耗具有叠加效应——每次工具输出都留在上下文里后续对话按全量上下文计费于是越到后面越贵。这篇文章面向的是所有重度使用AI编程代理的开发者。无论你用Claude Code、Codex、Cursor还是其他方案优化工具输出都是通用且立竿见影的方向。这篇文章只聊具体操作不聊空泛理论所有技巧都是我在实际项目中反复验证过的。2. Token去向拆解工具输出为什么是隐形大户2.1 Token到底被谁吃掉了想优化先得知道Token去哪了。我把自己跑过的一次真实任务拆开统计过最终发现三类消耗系统提示词和工具定义每次请求都会带上属于固定开销。一个工具定义动辄几百Token工具多的时候光这层就能吃掉几千Token。对话历史包括用户的输入和模型的历史回复。这部分是随对话增长而膨胀的无法完全避免但可以被压缩。工具输出工具返回的结果全量进入上下文。文件内容、运行结果、搜索列表这些几乎都是高密度文本单次输出轻松上万Token。在这三类里工具输出的增长曲线最陡峭。对话历史至少还有个“内容相关性”的筛选过程工具输出则经常是全量灌入。一次跑测试就可能输出几十KB日志这些日志不仅这次消耗Token还因为留在上下文里在后续每次请求中重复计费相当于同一份内容被反复收钱。2.2 工具输出的三种典型形态结合我自己的项目经验工具输出通常以三种形态出现对应的优化方式完全不同。第一种是文件读取类输出。代理读取源码文件、配置文件、锁文件等手段很常见但一次读取动辄上千行。很多代理工具在读取文件时还内置了“读取后自动执行”的逻辑比如自动执行构建命令结果输出更长。第二种是命令执行类输出。运行测试、Lint、格式化、安装依赖这些命令的输出经常又长又杂。特别是测试框架默认输出模式会把每个用例的名字、耗时、状态全部打出来几百个用例就是几百行。第三种是结构化查询类输出。代码搜索、符号引用查询、Git状态查询这类操作输出格式相对干净但返回条目数量庞大会累积出大量Token。搜索“某个函数在哪里定义”可能返回几十个匹配大部分匹配其实与当前任务无关。2.3 拿一个真实案例算一笔账有一次我给项目加一个本地缓存模块让Claude Code帮我实现。任务本身不复杂但我观察了一下全过程读取入口文件、读取缓存工具类、读取相关测试、运行测试、运行Lint、查看Git diff整个流程下来大约发生15次工具调用。最夸张的是读取一个公共工具类那个文件有900多行工具输出直接打出3万Token。接着运行全量测试输出800多行又吃掉2万Token。再看Git diff改了6个文件diff输出1万多Token。一轮任务下来光是工具输出就接近8万Token而模型真正生成的有效代码可能只有2000行。这个比例太离谱了工具输出占比高达总Token消耗的七成以上。当时用的还只是小模型的收费标准如果换成高端模型这一轮任务光工具输出的成本就够买好几杯咖啡了。所以说工具输出优化是降本增效最见效的环节。3. 工具输出优化的四大实操手段3.1 给工具加输出上限从源头控量最直接的手段是给工具输出设置硬性上限。大部分AI编程代理框架都支持对工具输出做截断比如Claude Code支持在工具配置里设置MAX_OUTPUT_TOKENSCodex命令行也有对应的输出限制参数。具体设置思路是这样的对文件读取类工具限制单次读取行数比如最多200行。对命令执行类工具限制输出字节数超出部分用省略号替代。对测试命令强制使用精简输出模式。举个例子在Claude Code的配置里可以加上{ tools: { read_file: { max_lines: 200, truncate_message: [输出已截断仅显示前200行] }, run_command: { max_output_chars: 5000, truncate_message: [命令输出超过限制已截断] } } }这样设置之后即使工具底层返回了完整内容模型侧收到的也只是截断后的前200行或前5000字符。看似简单但效果非常明显。我调整完这个参数后一个典型重构任务的工具输出直接下降了60%以上。不过这里有一个关键权衡截断会让模型丢失关键信息。如果截断位置恰好落在错误堆栈的关键报错行模型的判断就会受影响。所以我建议不要一刀切对大文件读取可以行数限制放宽一些对日志类输出则严格卡字符数。3.2 智能过滤输出内容只留关键段落截断是比较粗暴的手段另一个进阶做法是过滤工具输出只保留和任务相关的部分。这需要工具输出结构本身做配合或者通过配置系统自带的过滤规则。以测试输出为例。如果代理封装了一个专用的测试工具它可以在内部解析pytest或JUnit的输出格式只保留失败用例的完整信息对成功用例统一做折叠处理。下面是一个极简的Python实现思路import re def filter_test_output(raw_output: str) - str: # 提取失败用例与摘要 failed_section re.findall(rFAILED.*?(?\n\n|\Z), raw_output, re.DOTALL) summary raw_output.splitlines()[-5:] # 最后几行通常是汇总信息 filtered \n.join(failed_section summary) return filtered or raw_output[:1000]输出内容就变成“失败用例明细尾部统计信息”而不是几百个用例的全量日志。这种过滤模式对测试、Lint、构建这类结构化输出特别有用因为它们的核心信息天生就集中在少数几行。再比如Git diff的优化。原始diff里经常有大量纯格式变动、依赖锁文件变动、注释变动这些对AI理解代码逻辑几乎没有帮助。可以在工具层面对diff做降噪筛选掉非关键文件或者对超过阈值的文件直接折叠成“文件X有N行改动”。3.3 精简工具返回值结构从设计层面降耗如果说前两项是“事后裁减”那这一项就是“事前设计”。如果你本身在开发给AI用的工具集工具返回值的结构设计直接影响Token消耗。在设计工具返回值时有三条原则默认返回摘要详情按需提供。比如文件列表工具默认只返回文件名和文件大小需要看完整目录树时再加参数。结构化数据优于纯文本。同一个信息用JSON返回通常比用散文返回更省Token。比如“当前分支有3个未提交文件分别是src/a.py、src/b.py、test/test_a.py”写成JSON格式后信息密度更高。避免重复返回公共信息。工具输出里如果每一条都带上完整路径前缀累积起来就是大量重复Token。可以设计成“基础目录只出现一次后面用相对路径”。以文件搜索工具为例一个糟糕的设计是{ result: Found 3 files:\n/src/module/foo.py is 120 lines\n/src/module/bar.py is 80 lines\n/test/test_foo.py is 150 lines }好的设计是{ base_dir: /src/module, matches: [ {path: foo.py, lines: 120}, {path: bar.py, lines: 80} ], test_dir: /test, tests: [ {path: test_foo.py, lines: 150} ] }两种表达信息量差不多但结构化的Token数明显更少。别小看这种优化单个工具可能只省几十Token但一次任务要调用几十次工具累计起来就非常可观。3.4 跨步骤保留输出摘要减少重复处理工具输出还有一个容易被忽略的消耗点同一份信息在任务的不同阶段被反复拉取。比如AI代理一开始读了某个文件后面改代码时又读了一次跑了一次测试看结果修改代码后又跑了一次全量测试。对于这类重复行为可以在工具层做缓存或摘要复用。具体来说有两种做法会话内缓存同一个工具、同一个参数在短时间内重复调用时直接返回上次结果避免重复计算和重复输出。结果摘要提取第一次执行命令时把完整输出保存起来后续对话只把摘要传给模型。比如第一次跑测试时记录完整日志后续只传递“测试状态失败失败数2失败用例名列表”。用摘要替换完整输出需要模型能区分“完整结果”和“摘要结果”的差异。我在实践中会在摘要里附带一行说明“这是结果摘要原始日志在/path/to/log处”这样AI如果需要排查细节就会主动去读取文件跟真实开发者的操作习惯对齐。4. 模型与推理层面的省Token策略4.1 优先选支持上下文缓存的模型工具输出之所以贵是因为模型每次都要重新处理全量上下文。如果推理引擎支持上下文缓存情况就完全不同了。上下文缓存的意思是请求中未发生变化的部分可以直接复用之前的计算结果不需要重新计算。对工具输出优化来说这意味着工具输出虽然仍占用Token但不再按全价计费。拿Anthropic的Claude模型举例它的上下文缓存定价远低于标准输入价格。只要你用的是支持该能力的API代码前缀、工具定义、历史工具输出都会被自动缓存。我实测过开启上下文缓存后长会话任务的总成本节约能到50%以上。怎么判断自己的工具链是否支持看请求日志里的cache_read和cache_creation字段如果存在这两个字段说明已启用。也可以在API请求里显式声明cache_control参数让流程更可控。4.2 用小模型处理工具输出大模型专注决策一个容易被忽略的思路工具输出的筛选和预处理可以在进入大模型之前就完成。现在的AI编程代理大多采用单模型串联架构所有数据都往大模型里灌。其实完全可以把“解读工具输出、整理成摘要”这件事交给更小更便宜的模型再由大模型基于摘要做决策。举个例子代理执行测试后先让一个廉价模型对原始输出做分类输出一段结构化的结果摘要比如{ test_status: failed, failed_count: 2, failure_reasons: [断言错误: expected 5 but got 3, 超时: test_timeout_exceeded], success_count: 98 }然后大模型只消费这份JSON摘要而不是上千行的原始日志。一套完整的工具输出可能价值1万Token经过小模型处理后变成500Token的精炼摘要成本差异是数量级的。这种架构目前在一些代理框架中已经内置比如Codex的Agent模式就支持工具输出预处理。如果自己搭建代理也可以通过给Felix或LangChain添加中间节点来实现。4.3 调整采样参数减少无意义续写很多代理的配置里包含max_tokens、temperature这类采样参数这些也会影响实际Token用量。尤其是在工具调用后的下一个回复里模型经常会产生大量“过渡性文本”比如“好的我看完了这个文件现在让我分析一下”这类废话。虽然单段废话消耗不多但每轮都有就不一样了。一个可行的优化方向是把temperature调到较低值比如0到0.3让模型更直接地给结论而不是过多解释。同时在系统提示词里明确要求“确认工具输出后直接进入下一步不要复述工具内容”也能显著减少无效Token。我自己在Claude Code的配置里加过这么一句话“执行工具后不再复述工具输出内容直接基于结果判断下一步动作。”这行描述大约占50Token一次任务跑下来能省几百到上千Token收益率相当高。5. 常见问题与排查技巧实录5.1 问题一截断后模型判断力下降现象限制输出行数后AI经常忽略关键报错信息或者做出错误修改。原因截断策略是“取前N行”但错误堆栈的关键信息往往在末尾。解决办法优先用“保留头尾压缩中间”的截断方式。即提取输出的前50行和后50行合并返回中间用[中间N行已折叠]代替。对错误排查场景尾部往往比头部更重要可以在工具实现里把尾部输出放到前面。一个具体实现示例def truncate_middle(text: str, head_lines: int 50, tail_lines: int 50) - str: lines text.splitlines() if len(lines) head_lines tail_lines: return text omitted len(lines) - head_lines - tail_lines return \n.join(lines[:head_lines] [f[{omitted}行已折叠]] lines[-tail_lines:])5.2 问题二过滤太激进导致有效信息被误删现象过滤规则把本来有用的信息也删掉了比如负责判断错误类型的上下文。原因规则过于机械只认关键词不理解语义。解决办法给过滤规则留一个保底机制。当原始输出长度小于某阈值时不过滤只有超过阈值才启用压缩策略。另外可以把过滤后的内容做成“摘要原文路径”的组合关键信息丢了还能通过阅读原文找回。我习惯在过滤后的输出末尾附加一行[完整输出已保存在 .agent_cache/cmd_output_12345.log如需查看请读取该文件]这样既保证了低Token消耗也给AI留了“按需深挖”的入口。5.3 问题三缓存命中率低省了等于没省现象明明开了上下文缓存账单却没什么变化。原因工具输出中夹杂了大量动态内容比如时间戳、随机日志、绝对路径名。任何变化都会导致缓存失效命中率自然低。解决办法在工具生成输出时主动做归一化处理。把所有绝对路径替换为项目根目录的相对表示法时间戳统一格式随机数值用固定占位符替代。模式下如果同一个工具反复执行输出内容稳定不变缓存命中率就可以提上去。使用频率高的几个替换规则比如/Users/username/work/project/server/src/foo.py→src/foo.py2025-01-01 12:00:00.123→[TIMESTAMP]session_idabcdef12345→session_id[HASH]这步要放在工具真正输出前做而不是等模型层再处理。5.4 问题四省了Token但多了人工干预成本现象为了省Token把工具输出压到太短模型频繁要求读取详细文件来回多次后反而总Token用量上升。原因代理的“按需读取”机制依赖模型自己判断是否需要完整内容如果摘要信息不足模型只能频繁触发新的读文件动作。解决办法把优化重心放在“单次输出内容压缩”上而不是“频繁触发按需读取”上。测试下来单次工具调用节省70%输出比让模型在读文件与不读之间反复试探更划算。这里的关键是找到平衡点摘要里保留足够决策信息同时确保一次调用就能获取。我自己会定期查看代理的执行日志统计“每1000 Token实际产出多少有效步骤”。如果有效步骤太少说明摘要过于模糊需要重新调整保留信息的程度。5.5 家常便饭级的错误忽略工具定义本身的Token现象工具输出确实优化了但系统提示词里的工具定义太长每次请求都在白白扣钱。原因工具数量多、描述冗长、JSON Schema庞大。有些代理框架默认带十几二十个工具每个工具描述几百字光这层就是两千起步的固定开销。解决办法评估每个工具的实际使用频率从来没用过的工具直接禁用或从工具列表里移除。对工具描述做垂直精简去掉不必要的示例只保留“何时使用”和“返回什么”两个核心字段。一次任务如果触发30次LLM调用每次工具定义500Token就是15万Token的固定消耗。把它压缩到每次300Token省下的是纯利。这个细节非常容易被忽略我最初优化时完全没注意后来看请求日志才发现工具定义居然占了那么大比重。6. 不同场景的实战配置参考不同的工作场景对工具输出的敏感度完全不同下面是我最近在几个实际场景中跑出来的配置组合可以直接参考。6.1 日常开发辅助场景这个场景以代码阅读、局部修改为主AI代理需要频繁读取文件但不需要长期保留大段工具输出。建议配置文件读取上限200行尾部优先保留。命令输出上限3000字符超长折叠。缓存开关打开重用相同文件的读取结果。工具定义描述压缩非高频工具直接禁用。这样一轮典型任务识别问题、改代码、跑测试、做修正的实际Token用量大约能控制在2万到4万内比默认配置少一半以上。6.2 大规模重构场景大规模重构的问题在于AI需要同时理解大量文件结构和依赖关系工具输出中的全局信息很重要。建议配置搜索类工具不限制返回条数但要求结果按相关度排序只返回前20条。文件读取上限放宽到500行因为重构时上下文连续性很重要。测试工具使用过滤模式只返回失败用例和汇总信息。关闭“自动扫描项目结构”类工具这类工具输出的目录树又长又没用。重构场景最忌频繁切文件我会在项目指令文件里明确要求“优先读完一个文件的完整上下文再切换下一个”减少重复读取。6.3 长期驻留任务场景像Codex的--modeagent长期任务、自动化巡检脚本这类场景AI会在长时间内反复调用工具。建议配置缓存彻底打开且对工具输出做严格的归一化处理。摘要机制全面启用任何超过2000字符的输出必须附摘要。定期清空上下文按任务阶段切换全新会话。使用一个任务状态文件记录进度代替把长期状态留在上下文里。长期驻留场景的核心逻辑是“宁可多读几次文件也不要让上下文无限膨胀”因为上下文一旦超过3万Token每次请求的计费就会指数级上升。7. 定期复盘用日志反推Token消耗类型7.1 建立Token消耗台账优化做完不能只看总账还要看明细。大部分代理框架会输出请求日志里面包含了每个请求的输入Token、输出Token和缓存命中情况。把日志定期汇总按工具名分组统计就能知道哪个工具是消耗大户。一个简化的统计方式把所有日志里的tool_name和数据量字段抽取出来配合简单脚本做聚合。比如按工具输出字符数排序看哪些工具单次输出最大按调用次数排序看哪些工具被调用最频繁。我自己的统计结果里排名靠前的几乎总是文件读取、全局搜索、测试执行。这也正好对应用上文说的优化重点。7.2 用“Token/有效步骤”做度量纯看Token总量没有意义因为任务复杂度和Token天然正相关。有意义的指标是每完成一个有效操作消耗了多少Token。什么是有效操作可以理解为“模型基于工具输出做出的一个真实决策”比如修改文件、切换策略、定位到原因。这个指标我在早期尝试过统计起来比较麻烦但对判断优化方向非常有效如果有效操作的Token成本下降说明优化确实提升了效率如果下降不明显需要继续调整。简化版操作是记录每次会话的“任务完成数”和“总Token数”两者相除得出单任务Token成本。连续几周对比这个数字比看单次任务的绝对Token量健康得多。7.3 至少每月做一次全链路审查工具输出优化不是一个一次性动作因为代码库规模在变、工具集在变、代理框架也在更新。建议一个月做一次全链路审查重点看三件事新加入的工具是否缺少输出限制。配置里的缓存策略是否仍然生效。有没有出现新的“大输出”场景比如新引入的测试框架、构建工具。审查时最好从一次真实任务日志出发完整追踪每一次请求的Token来源把不需要的消耗点标记出来再决定下一步的优化清单。8. 我踩过的坑和一些碎碎念工具输出优化做了快两个月中间踩了不少坑最后留几个印象最深的点。第一不要把工具输出压得太狠。有一次我把命令输出限制卡到500字符模型因为看不到关键报错信息连续改错三次方案最后我不得不介入手动查看日志折腾一圈下来反而多花了好几万Token。优化工具输出要带着“够用”的思维来做摘要保留决策所需的最小信息集即可。第二上下文缓存的省Token效果拔群但要避免“伪命中”。缓存按前缀匹配只要内容有一点变化就整段失效。所以凡是会在一次会话中反复出现的内容比如项目结构描述、工具定义、常用配置最好放在上下文最前面且保持不变。这个顺序安排非常重要我折腾了几次才真正跑出高命中率。第三工具定义精简是最被低估的优化点。很多人只盯着运行时输出却忘记每次请求都在支付的系统提示词开销。把工具列表从20个缩到10个把每个工具的描述从100字缩到40字每轮请求能省1000Token左右。对重度用户来说这是每天都要付的“城市税”减下来是真金白银。第四善用“外部化存储”。不要把所有信息都塞进上下文很多代理支持让AI把中间结果写到文件然后通过工具按需读取。这种方式天然适合长任务因为它让上下文保持短小而不是无限膨胀。我现在做长任务时都会在项目里建一个agent_memory/目录让AI把阶段结论写进去需要时再读取效果非常好。总的来看减少AI编程代理的Token使用真正有效的思路是降低工具输出“上屏”的频率和体量哪怕每一次只省那么一点累计到几十个步骤后差距就非常明显了。希望这篇文章能帮你把账单数字降下来。
AI编程代理Token优化：工具输出隐形消耗的四大实操手段
1. 问题背景Token开销是怎么悄悄失控的先用一段真实的日常来说明问题。我平时用Claude Code和Codex这类AI编程代理写代码最初觉得“AI干活真爽”直到月底看账单时愣住——一次功能迭代烧掉几万Token一问周围同事大家全是同款状况。问题的核心往往不是对话本身而是工具输出。所谓工具输出指的是AI代理在执行任务时调用的工具返回结果。比如它读取文件、运行测试、搜索代码、查看Git状态每一个动作都会返回一大段内容回到模型上下文里。代码文件动辄几百行测试日志动辄几十条Git diff动辄上千行改动。这些结果全部进入Token计算而且往往是按输出Token计费的。模型本身生成的思考内容其实占比不大真正吃掉预算的是那些看起来不起眼、却反复进入上下文的工具返回。为什么这个问题值得专门拿出来讲因为大多数优化文章都在聊“怎么让模型少说废话”“怎么压缩Prompt”但工具输出是被严重低估的隐形消耗点。对AI编程代理来说工具体系越丰富工具输出占比越高。你让代理多用几次工具Token用量就能翻好几倍而且这类消耗具有叠加效应——每次工具输出都留在上下文里后续对话按全量上下文计费于是越到后面越贵。这篇文章面向的是所有重度使用AI编程代理的开发者。无论你用Claude Code、Codex、Cursor还是其他方案优化工具输出都是通用且立竿见影的方向。这篇文章只聊具体操作不聊空泛理论所有技巧都是我在实际项目中反复验证过的。2. Token去向拆解工具输出为什么是隐形大户2.1 Token到底被谁吃掉了想优化先得知道Token去哪了。我把自己跑过的一次真实任务拆开统计过最终发现三类消耗系统提示词和工具定义每次请求都会带上属于固定开销。一个工具定义动辄几百Token工具多的时候光这层就能吃掉几千Token。对话历史包括用户的输入和模型的历史回复。这部分是随对话增长而膨胀的无法完全避免但可以被压缩。工具输出工具返回的结果全量进入上下文。文件内容、运行结果、搜索列表这些几乎都是高密度文本单次输出轻松上万Token。在这三类里工具输出的增长曲线最陡峭。对话历史至少还有个“内容相关性”的筛选过程工具输出则经常是全量灌入。一次跑测试就可能输出几十KB日志这些日志不仅这次消耗Token还因为留在上下文里在后续每次请求中重复计费相当于同一份内容被反复收钱。2.2 工具输出的三种典型形态结合我自己的项目经验工具输出通常以三种形态出现对应的优化方式完全不同。第一种是文件读取类输出。代理读取源码文件、配置文件、锁文件等手段很常见但一次读取动辄上千行。很多代理工具在读取文件时还内置了“读取后自动执行”的逻辑比如自动执行构建命令结果输出更长。第二种是命令执行类输出。运行测试、Lint、格式化、安装依赖这些命令的输出经常又长又杂。特别是测试框架默认输出模式会把每个用例的名字、耗时、状态全部打出来几百个用例就是几百行。第三种是结构化查询类输出。代码搜索、符号引用查询、Git状态查询这类操作输出格式相对干净但返回条目数量庞大会累积出大量Token。搜索“某个函数在哪里定义”可能返回几十个匹配大部分匹配其实与当前任务无关。2.3 拿一个真实案例算一笔账有一次我给项目加一个本地缓存模块让Claude Code帮我实现。任务本身不复杂但我观察了一下全过程读取入口文件、读取缓存工具类、读取相关测试、运行测试、运行Lint、查看Git diff整个流程下来大约发生15次工具调用。最夸张的是读取一个公共工具类那个文件有900多行工具输出直接打出3万Token。接着运行全量测试输出800多行又吃掉2万Token。再看Git diff改了6个文件diff输出1万多Token。一轮任务下来光是工具输出就接近8万Token而模型真正生成的有效代码可能只有2000行。这个比例太离谱了工具输出占比高达总Token消耗的七成以上。当时用的还只是小模型的收费标准如果换成高端模型这一轮任务光工具输出的成本就够买好几杯咖啡了。所以说工具输出优化是降本增效最见效的环节。3. 工具输出优化的四大实操手段3.1 给工具加输出上限从源头控量最直接的手段是给工具输出设置硬性上限。大部分AI编程代理框架都支持对工具输出做截断比如Claude Code支持在工具配置里设置MAX_OUTPUT_TOKENSCodex命令行也有对应的输出限制参数。具体设置思路是这样的对文件读取类工具限制单次读取行数比如最多200行。对命令执行类工具限制输出字节数超出部分用省略号替代。对测试命令强制使用精简输出模式。举个例子在Claude Code的配置里可以加上{ tools: { read_file: { max_lines: 200, truncate_message: [输出已截断仅显示前200行] }, run_command: { max_output_chars: 5000, truncate_message: [命令输出超过限制已截断] } } }这样设置之后即使工具底层返回了完整内容模型侧收到的也只是截断后的前200行或前5000字符。看似简单但效果非常明显。我调整完这个参数后一个典型重构任务的工具输出直接下降了60%以上。不过这里有一个关键权衡截断会让模型丢失关键信息。如果截断位置恰好落在错误堆栈的关键报错行模型的判断就会受影响。所以我建议不要一刀切对大文件读取可以行数限制放宽一些对日志类输出则严格卡字符数。3.2 智能过滤输出内容只留关键段落截断是比较粗暴的手段另一个进阶做法是过滤工具输出只保留和任务相关的部分。这需要工具输出结构本身做配合或者通过配置系统自带的过滤规则。以测试输出为例。如果代理封装了一个专用的测试工具它可以在内部解析pytest或JUnit的输出格式只保留失败用例的完整信息对成功用例统一做折叠处理。下面是一个极简的Python实现思路import re def filter_test_output(raw_output: str) - str: # 提取失败用例与摘要 failed_section re.findall(rFAILED.*?(?\n\n|\Z), raw_output, re.DOTALL) summary raw_output.splitlines()[-5:] # 最后几行通常是汇总信息 filtered \n.join(failed_section summary) return filtered or raw_output[:1000]输出内容就变成“失败用例明细尾部统计信息”而不是几百个用例的全量日志。这种过滤模式对测试、Lint、构建这类结构化输出特别有用因为它们的核心信息天生就集中在少数几行。再比如Git diff的优化。原始diff里经常有大量纯格式变动、依赖锁文件变动、注释变动这些对AI理解代码逻辑几乎没有帮助。可以在工具层面对diff做降噪筛选掉非关键文件或者对超过阈值的文件直接折叠成“文件X有N行改动”。3.3 精简工具返回值结构从设计层面降耗如果说前两项是“事后裁减”那这一项就是“事前设计”。如果你本身在开发给AI用的工具集工具返回值的结构设计直接影响Token消耗。在设计工具返回值时有三条原则默认返回摘要详情按需提供。比如文件列表工具默认只返回文件名和文件大小需要看完整目录树时再加参数。结构化数据优于纯文本。同一个信息用JSON返回通常比用散文返回更省Token。比如“当前分支有3个未提交文件分别是src/a.py、src/b.py、test/test_a.py”写成JSON格式后信息密度更高。避免重复返回公共信息。工具输出里如果每一条都带上完整路径前缀累积起来就是大量重复Token。可以设计成“基础目录只出现一次后面用相对路径”。以文件搜索工具为例一个糟糕的设计是{ result: Found 3 files:\n/src/module/foo.py is 120 lines\n/src/module/bar.py is 80 lines\n/test/test_foo.py is 150 lines }好的设计是{ base_dir: /src/module, matches: [ {path: foo.py, lines: 120}, {path: bar.py, lines: 80} ], test_dir: /test, tests: [ {path: test_foo.py, lines: 150} ] }两种表达信息量差不多但结构化的Token数明显更少。别小看这种优化单个工具可能只省几十Token但一次任务要调用几十次工具累计起来就非常可观。3.4 跨步骤保留输出摘要减少重复处理工具输出还有一个容易被忽略的消耗点同一份信息在任务的不同阶段被反复拉取。比如AI代理一开始读了某个文件后面改代码时又读了一次跑了一次测试看结果修改代码后又跑了一次全量测试。对于这类重复行为可以在工具层做缓存或摘要复用。具体来说有两种做法会话内缓存同一个工具、同一个参数在短时间内重复调用时直接返回上次结果避免重复计算和重复输出。结果摘要提取第一次执行命令时把完整输出保存起来后续对话只把摘要传给模型。比如第一次跑测试时记录完整日志后续只传递“测试状态失败失败数2失败用例名列表”。用摘要替换完整输出需要模型能区分“完整结果”和“摘要结果”的差异。我在实践中会在摘要里附带一行说明“这是结果摘要原始日志在/path/to/log处”这样AI如果需要排查细节就会主动去读取文件跟真实开发者的操作习惯对齐。4. 模型与推理层面的省Token策略4.1 优先选支持上下文缓存的模型工具输出之所以贵是因为模型每次都要重新处理全量上下文。如果推理引擎支持上下文缓存情况就完全不同了。上下文缓存的意思是请求中未发生变化的部分可以直接复用之前的计算结果不需要重新计算。对工具输出优化来说这意味着工具输出虽然仍占用Token但不再按全价计费。拿Anthropic的Claude模型举例它的上下文缓存定价远低于标准输入价格。只要你用的是支持该能力的API代码前缀、工具定义、历史工具输出都会被自动缓存。我实测过开启上下文缓存后长会话任务的总成本节约能到50%以上。怎么判断自己的工具链是否支持看请求日志里的cache_read和cache_creation字段如果存在这两个字段说明已启用。也可以在API请求里显式声明cache_control参数让流程更可控。4.2 用小模型处理工具输出大模型专注决策一个容易被忽略的思路工具输出的筛选和预处理可以在进入大模型之前就完成。现在的AI编程代理大多采用单模型串联架构所有数据都往大模型里灌。其实完全可以把“解读工具输出、整理成摘要”这件事交给更小更便宜的模型再由大模型基于摘要做决策。举个例子代理执行测试后先让一个廉价模型对原始输出做分类输出一段结构化的结果摘要比如{ test_status: failed, failed_count: 2, failure_reasons: [断言错误: expected 5 but got 3, 超时: test_timeout_exceeded], success_count: 98 }然后大模型只消费这份JSON摘要而不是上千行的原始日志。一套完整的工具输出可能价值1万Token经过小模型处理后变成500Token的精炼摘要成本差异是数量级的。这种架构目前在一些代理框架中已经内置比如Codex的Agent模式就支持工具输出预处理。如果自己搭建代理也可以通过给Felix或LangChain添加中间节点来实现。4.3 调整采样参数减少无意义续写很多代理的配置里包含max_tokens、temperature这类采样参数这些也会影响实际Token用量。尤其是在工具调用后的下一个回复里模型经常会产生大量“过渡性文本”比如“好的我看完了这个文件现在让我分析一下”这类废话。虽然单段废话消耗不多但每轮都有就不一样了。一个可行的优化方向是把temperature调到较低值比如0到0.3让模型更直接地给结论而不是过多解释。同时在系统提示词里明确要求“确认工具输出后直接进入下一步不要复述工具内容”也能显著减少无效Token。我自己在Claude Code的配置里加过这么一句话“执行工具后不再复述工具输出内容直接基于结果判断下一步动作。”这行描述大约占50Token一次任务跑下来能省几百到上千Token收益率相当高。5. 常见问题与排查技巧实录5.1 问题一截断后模型判断力下降现象限制输出行数后AI经常忽略关键报错信息或者做出错误修改。原因截断策略是“取前N行”但错误堆栈的关键信息往往在末尾。解决办法优先用“保留头尾压缩中间”的截断方式。即提取输出的前50行和后50行合并返回中间用[中间N行已折叠]代替。对错误排查场景尾部往往比头部更重要可以在工具实现里把尾部输出放到前面。一个具体实现示例def truncate_middle(text: str, head_lines: int 50, tail_lines: int 50) - str: lines text.splitlines() if len(lines) head_lines tail_lines: return text omitted len(lines) - head_lines - tail_lines return \n.join(lines[:head_lines] [f[{omitted}行已折叠]] lines[-tail_lines:])5.2 问题二过滤太激进导致有效信息被误删现象过滤规则把本来有用的信息也删掉了比如负责判断错误类型的上下文。原因规则过于机械只认关键词不理解语义。解决办法给过滤规则留一个保底机制。当原始输出长度小于某阈值时不过滤只有超过阈值才启用压缩策略。另外可以把过滤后的内容做成“摘要原文路径”的组合关键信息丢了还能通过阅读原文找回。我习惯在过滤后的输出末尾附加一行[完整输出已保存在 .agent_cache/cmd_output_12345.log如需查看请读取该文件]这样既保证了低Token消耗也给AI留了“按需深挖”的入口。5.3 问题三缓存命中率低省了等于没省现象明明开了上下文缓存账单却没什么变化。原因工具输出中夹杂了大量动态内容比如时间戳、随机日志、绝对路径名。任何变化都会导致缓存失效命中率自然低。解决办法在工具生成输出时主动做归一化处理。把所有绝对路径替换为项目根目录的相对表示法时间戳统一格式随机数值用固定占位符替代。模式下如果同一个工具反复执行输出内容稳定不变缓存命中率就可以提上去。使用频率高的几个替换规则比如/Users/username/work/project/server/src/foo.py→src/foo.py2025-01-01 12:00:00.123→[TIMESTAMP]session_idabcdef12345→session_id[HASH]这步要放在工具真正输出前做而不是等模型层再处理。5.4 问题四省了Token但多了人工干预成本现象为了省Token把工具输出压到太短模型频繁要求读取详细文件来回多次后反而总Token用量上升。原因代理的“按需读取”机制依赖模型自己判断是否需要完整内容如果摘要信息不足模型只能频繁触发新的读文件动作。解决办法把优化重心放在“单次输出内容压缩”上而不是“频繁触发按需读取”上。测试下来单次工具调用节省70%输出比让模型在读文件与不读之间反复试探更划算。这里的关键是找到平衡点摘要里保留足够决策信息同时确保一次调用就能获取。我自己会定期查看代理的执行日志统计“每1000 Token实际产出多少有效步骤”。如果有效步骤太少说明摘要过于模糊需要重新调整保留信息的程度。5.5 家常便饭级的错误忽略工具定义本身的Token现象工具输出确实优化了但系统提示词里的工具定义太长每次请求都在白白扣钱。原因工具数量多、描述冗长、JSON Schema庞大。有些代理框架默认带十几二十个工具每个工具描述几百字光这层就是两千起步的固定开销。解决办法评估每个工具的实际使用频率从来没用过的工具直接禁用或从工具列表里移除。对工具描述做垂直精简去掉不必要的示例只保留“何时使用”和“返回什么”两个核心字段。一次任务如果触发30次LLM调用每次工具定义500Token就是15万Token的固定消耗。把它压缩到每次300Token省下的是纯利。这个细节非常容易被忽略我最初优化时完全没注意后来看请求日志才发现工具定义居然占了那么大比重。6. 不同场景的实战配置参考不同的工作场景对工具输出的敏感度完全不同下面是我最近在几个实际场景中跑出来的配置组合可以直接参考。6.1 日常开发辅助场景这个场景以代码阅读、局部修改为主AI代理需要频繁读取文件但不需要长期保留大段工具输出。建议配置文件读取上限200行尾部优先保留。命令输出上限3000字符超长折叠。缓存开关打开重用相同文件的读取结果。工具定义描述压缩非高频工具直接禁用。这样一轮典型任务识别问题、改代码、跑测试、做修正的实际Token用量大约能控制在2万到4万内比默认配置少一半以上。6.2 大规模重构场景大规模重构的问题在于AI需要同时理解大量文件结构和依赖关系工具输出中的全局信息很重要。建议配置搜索类工具不限制返回条数但要求结果按相关度排序只返回前20条。文件读取上限放宽到500行因为重构时上下文连续性很重要。测试工具使用过滤模式只返回失败用例和汇总信息。关闭“自动扫描项目结构”类工具这类工具输出的目录树又长又没用。重构场景最忌频繁切文件我会在项目指令文件里明确要求“优先读完一个文件的完整上下文再切换下一个”减少重复读取。6.3 长期驻留任务场景像Codex的--modeagent长期任务、自动化巡检脚本这类场景AI会在长时间内反复调用工具。建议配置缓存彻底打开且对工具输出做严格的归一化处理。摘要机制全面启用任何超过2000字符的输出必须附摘要。定期清空上下文按任务阶段切换全新会话。使用一个任务状态文件记录进度代替把长期状态留在上下文里。长期驻留场景的核心逻辑是“宁可多读几次文件也不要让上下文无限膨胀”因为上下文一旦超过3万Token每次请求的计费就会指数级上升。7. 定期复盘用日志反推Token消耗类型7.1 建立Token消耗台账优化做完不能只看总账还要看明细。大部分代理框架会输出请求日志里面包含了每个请求的输入Token、输出Token和缓存命中情况。把日志定期汇总按工具名分组统计就能知道哪个工具是消耗大户。一个简化的统计方式把所有日志里的tool_name和数据量字段抽取出来配合简单脚本做聚合。比如按工具输出字符数排序看哪些工具单次输出最大按调用次数排序看哪些工具被调用最频繁。我自己的统计结果里排名靠前的几乎总是文件读取、全局搜索、测试执行。这也正好对应用上文说的优化重点。7.2 用“Token/有效步骤”做度量纯看Token总量没有意义因为任务复杂度和Token天然正相关。有意义的指标是每完成一个有效操作消耗了多少Token。什么是有效操作可以理解为“模型基于工具输出做出的一个真实决策”比如修改文件、切换策略、定位到原因。这个指标我在早期尝试过统计起来比较麻烦但对判断优化方向非常有效如果有效操作的Token成本下降说明优化确实提升了效率如果下降不明显需要继续调整。简化版操作是记录每次会话的“任务完成数”和“总Token数”两者相除得出单任务Token成本。连续几周对比这个数字比看单次任务的绝对Token量健康得多。7.3 至少每月做一次全链路审查工具输出优化不是一个一次性动作因为代码库规模在变、工具集在变、代理框架也在更新。建议一个月做一次全链路审查重点看三件事新加入的工具是否缺少输出限制。配置里的缓存策略是否仍然生效。有没有出现新的“大输出”场景比如新引入的测试框架、构建工具。审查时最好从一次真实任务日志出发完整追踪每一次请求的Token来源把不需要的消耗点标记出来再决定下一步的优化清单。8. 我踩过的坑和一些碎碎念工具输出优化做了快两个月中间踩了不少坑最后留几个印象最深的点。第一不要把工具输出压得太狠。有一次我把命令输出限制卡到500字符模型因为看不到关键报错信息连续改错三次方案最后我不得不介入手动查看日志折腾一圈下来反而多花了好几万Token。优化工具输出要带着“够用”的思维来做摘要保留决策所需的最小信息集即可。第二上下文缓存的省Token效果拔群但要避免“伪命中”。缓存按前缀匹配只要内容有一点变化就整段失效。所以凡是会在一次会话中反复出现的内容比如项目结构描述、工具定义、常用配置最好放在上下文最前面且保持不变。这个顺序安排非常重要我折腾了几次才真正跑出高命中率。第三工具定义精简是最被低估的优化点。很多人只盯着运行时输出却忘记每次请求都在支付的系统提示词开销。把工具列表从20个缩到10个把每个工具的描述从100字缩到40字每轮请求能省1000Token左右。对重度用户来说这是每天都要付的“城市税”减下来是真金白银。第四善用“外部化存储”。不要把所有信息都塞进上下文很多代理支持让AI把中间结果写到文件然后通过工具按需读取。这种方式天然适合长任务因为它让上下文保持短小而不是无限膨胀。我现在做长任务时都会在项目里建一个agent_memory/目录让AI把阶段结论写进去需要时再读取效果非常好。总的来看减少AI编程代理的Token使用真正有效的思路是降低工具输出“上屏”的频率和体量哪怕每一次只省那么一点累计到几十个步骤后差距就非常明显了。希望这篇文章能帮你把账单数字降下来。
