作者分析660个会话文件后，成功让AI代理少烧钱

作者对660个会话文件进行了本地脚本分析，精确分类了每一次失败的工具调用及其后续恢复轮次。45天的测量覆盖了6月到8月初，这些错误直接导致token不断消耗。整个解析过程零成本运行，没有产生任何额外token费用，这让浪费情况变得清晰可见。

660个文件让失败调用成本首次可量化

作者把过去45天的所有本地会话记录打包成660个文件，从6月初一直到8月初。他写了一个脚本，把每一条对话流式输入进去。脚本先识别出所有工具调用失败的记录，然后把紧随其后的恢复对话单独拎出来，最后按当时模型的单价把这些token换算成人民币。

整个解析过程完全跑在本地机器上，没有调用任何云端API，因此没有产生一分钱的额外费用。这一点后来被证明非常关键，因为一旦测量本身免费，开发者就敢把历史数据全部拉出来反复看，而不会担心“再测一次又要花钱”。

脚本输出的结果是一张清晰的表格：哪一天哪次会话、哪种工具失败、恢复时用了多少token、折合多少钱。660个文件加起来让作者第一次把“感觉在烧钱”变成了可以精确到每次调用的数字。以前他只知道总体账单高，现在他知道具体是哪类错误把钱一点点漏掉。这组数据成了后面所有优化动作的基准线，没有它，后续的改进就无从谈起。

通过这种本地测量方式，普通用户也能复制同样的路径。只要把聊天记录导出成文本，用几行Python代码就能跑出成本报告。关键在于把测量成本压到零，否则很多人会因为“测了也贵”而放弃量化。

恢复轮次才是主要token浪费来源

数据出来后，最刺眼的不是失败调用本身，而是失败之后系统自动生成的恢复轮次。一次工具调用失败，模型通常会再输出几百到上千token的解释、道歉、重新规划路径，然后再次尝试。这些恢复内容几乎占了总token数的六成以上。

脚本把每一次失败标记为“错误事件”，把后面连续几轮直到工具再次成功为止的对话标记为“恢复序列”。定价结果显示，恢复序列的单价往往比正常对话更高，因为模型在出错后倾向于使用更长的句子和更谨慎的语气，token消耗随之增加。

这和单纯统计失败率完全不同。失败率可能只有百分之十几，但每次失败带来的恢复成本却是正常对话的三到五倍。作者发现，把恢复轮次单独拎出来看，比只看错误次数更能解释账单为什么突然变高。

对普通用户来说，这意味着不能只盯着“成功率”指标，更要关注“失败后要花多少钱才能回到正轨”。把恢复成本量化之后，才知道哪些错误真正伤钱，哪些只是看起来吓人但实际影响有限。

提示工程减少错误恢复次数

拿到精确数字后，作者开始修改提示词。他把过去最容易失败的工具调用场景单独提取出来，在系统提示里增加具体约束、输出格式要求和常见错误回避清单。

修改后的提示让同一类工具的失败率下降了约40%。更重要的是，失败之后的恢复轮次平均长度缩短了超过一半。因为模型现在更清楚自己该做什么，不再需要用大段文字“反思”刚才哪里错了。

成本测量脚本再次跑了一遍新数据，恢复序列的token支出明显减少。作者把前后两组数字放在一起对比，发现单纯靠提示词优化就把这部分浪费砍掉了一大半，而且几乎不需要额外投入。

普通用户可以把这个方法落地：把最近30天里失败次数最多的五种工具调用场景列出来，针对每一种写一条“防呆”提示，放在系统指令的最前面。每次新对话都带上这套提示，长期下来就是实打实的省钱。

动态路由切换低价模型

不是所有任务都需要最贵的模型。作者给自己的代理加了一层路由逻辑：先判断当前任务是简单问答、代码生成还是需要调用外部工具，再决定把请求发给哪个模型。

简单对话走价格最低的模型，只有必须调用工具或者需要高推理能力的场景才切换到更贵的旗舰模型。路由规则写在本地，几行代码就能完成。

测量结果显示，70%以上的日常会话其实可以用低价模型完成，把它们从贵模型里挪出来后，总体支出下降了接近60%。因为路由发生在本地，用户几乎感觉不到延迟，却能长期享受成本红利。

对普通用户而言，这套做法非常实用。把常用任务分成三类：便宜模型够用的、需要中档模型的、必须顶级模型的，然后写一个简单的if-else判断即可。长期使用下来，账单变化非常明显。

本地缓存避免重复token支出

作者发现很多重复的问题反复出现，每次都要重新消耗token。他把历史对话里出现频率最高的问题和答案做成向量索引，存在本地。每次新问题进来，先在本地向量库里检索，如果匹配度超过阈值就直接返回缓存结果，完全不调用模型。

这个缓存机制把重复对话的token消耗几乎归零。测量脚本显示，启用缓存后，相同问题的平均成本从原来的每次几毛钱降到了接近零。

本地缓存的另一个好处是完全不产生额外费用，和最初的测量脚本一样，都是零成本运行。作者强调，正是因为测量本身免费，他才有动力把所有历史记录都用来构建缓存，否则很多人会因为“建缓存也要花钱”而放弃。

普通用户可以从最常用的10个问题开始，把问答对存成JSON，慢慢扩充。配合简单的语义相似度判断，就能挡掉大量重复调用。

混合国产模型实现进一步降本

国内用户还有更便宜的选择。作者的做法是把部分非核心任务路由到国产大模型，比如用通义千问、豆包或者Kimi处理日常对话和简单工具调用，只在需要极高准确率或者英文原生能力时才切回国际一线模型。

实际测试显示，混合调用后总体成本又下降了30%左右。国产模型在中文理解和本地工具调用上已经足够成熟，很多场景下性价比远超国外同类产品。

具体落地时，可以用一个统一的API网关，把不同模型的调用封装成同一接口，根据任务标签和预算阈值自动选择后端。用户只需要维护一张路由表，定期根据最新价格和效果更新即可。

对大多数普通用户来说，混合使用国产模型是目前最现实的降本手段。既能享受大模型能力，又能把每月账单控制在可接受范围。结合前面的提示优化、动态路由和本地缓存，整体支出可以压到原来的四分之一左右。

这些方法都不是理论推演，而是作者用660个真实会话文件一步步验证出来的。每改一个地方，就重新跑测量脚本看数字变化。正是这种“测-改-再测”的闭环，让省钱从感觉变成可执行、可复制的工程实践。

参考来源