1. 一个被忽视的真相Agent 的 token 消耗远超直觉1.1 从一次账单异常说起前段时间帮一个朋友排查他的智能体项目他跟我抱怨说明明只是做了一个自动整理会议纪要的小工具每天跑几十次结果月底一看 API 账单差点没坐稳——消耗量比他预估的高出两个数量级。他一开始以为是计费系统出问题反复核对了好几遍最后发现计费没错是他的估算模型从根上就错了。这个场景我见过太多次了。很多人第一次接触 Agent 类应用时脑子里算 token 的方式还停留在单轮对话的思维输入一段话输出一段话加起来几百 token乘以调用次数完事。但 Agent 不是聊天机器人它是一个会自己思考、行动、观察、再思考的循环体。每一轮循环都在烧 token而且烧的方式和你想象的完全不一样。这篇文章我想把这件事彻底讲透Agent 到底在哪里烧 token、为什么能烧到你想的 100 倍、怎么估算、怎么优化。不管你是刚上手做智能体的开发者还是已经在跑生产环境的老手这里面的账都值得重新算一遍。1.2 为什么100 倍不是夸张修辞先给一个粗略的直觉。假设你做一个简单的问答机器人用户问一句、模型答一句单次交互的 token 消耗大概是这样的系统提示词 200 token用户问题 50 token模型回答 150 token合计 400 token 左右。你调用 1000 次就是 40 万 token。这个量级很直观也容易估算。但换成 Agent同样一个任务流程会变成系统提示词往往更长因为要写清楚工具定义、行为规范可能 800 token用户请求 50 token模型第一轮思考输出 200 token决定调用某个工具工具返回结果 500 token模型看到结果再思考 300 token再调用工具返回 800 token再思考……最后才输出答案 200 token。一轮下来光这一个任务就可能消耗 3000 到 5000 token。更关键的是每一轮循环都要把之前所有的历史上下文重新塞进去。也就是说第二轮调用时第一轮的提示词、思考、工具结果全都要再算一遍输入 token。这就是指数级增长的来源。循环 5 轮实际消耗可能是单轮估算的十几倍甚至几十倍。如果工具返回的内容很长、循环次数很多100 倍真的不是吓唬人。2. Agent 烧 token 的五个黑洞2.1 黑洞一上下文重复累积这是最大的一块也是最容易被忽略的。Agent 的每一轮决策都需要把完整的对话历史作为输入传给模型。第一轮输入是 A第二轮输入是 AB第三轮输入是 ABC……第 N 轮输入是 AB...N。假设每一轮新增内容平均 500 token循环 6 轮那么总输入 token 是轮次本轮新增累计输入 token15005002500100035001500450020005500250065003000总输入 50010001500200025003000 10500 token。而如果按单轮 500 token × 6 轮 3000来估算你就低估了 3.5 倍。循环次数越多这个差距越夸张。循环 20 轮累计输入是单轮估算的 10.5 倍。注意很多平台的计费是按输入 token 输出 token分别算的输入往往还更便宜但架不住量大。上下文累积主要吃的是输入 token。2.2 黑洞二工具返回的隐形胖子Agent 调用工具工具返回的结果会原封不动进入上下文。问题在于很多工具返回的数据又长又啰嗦。比如你让 Agent 查一个网页返回的是整页 HTML 清洗后的文本动辄几千 token你让它读一个文件返回整个文件内容你让它查数据库返回一堆用不上的字段。我见过一个案例Agent 调用搜索工具每次返回 3000 token 的搜索结果循环 8 轮光工具返回就贡献了 24000 token 的输入因为每轮都要重新带上之前所有结果。而实际上模型真正需要的信息可能只有其中 200 token。这就是典型的工具返回肥胖症。2.3 黑洞三系统提示词的固定税系统提示词在每一轮调用里都要重新计费。如果你的系统提示词写了 1500 token工具定义、few-shot 示例、行为规范全塞进去循环 10 轮光系统提示词就贡献 15000 token 的输入。这块钱你几乎无法避免但可以通过精简和缓存机制来降低。2.4 黑洞四思考链的自言自语现在很多 Agent 会输出思考过程reasoning这些思考内容也会进入上下文并且在后续每一轮里重复计费。思考越详细烧得越狠。有些框架默认让模型输出很长的推理链看着很智能账单上很肉疼。2.5 黑洞五失败重试与死循环最要命的是这个。Agent 如果陷入循环——比如工具一直返回错误、模型一直重试、或者两个工具互相调用——它会一直烧下去直到触发最大轮次限制。如果没有设置合理的终止条件一个 bug 就能让你一夜之间烧掉一个月的预算。我朋友那次账单异常很大一部分就是某个任务卡在重试循环里跑了上百轮。3. 动手算一笔账从理论到实测3.1 建立一个可复用的估算模型与其拍脑袋不如建一个简单的估算公式。对一次 Agent 任务总 token 消耗可以拆成总输入 token ≈ Σ(每轮系统提示 累计历史 本轮工具返回) 总输出 token ≈ Σ(每轮思考 每轮工具调用参数 最终答案)其中累计历史是等差数列求和。如果平均每轮新增内容为 C循环 N 轮累计历史总量约为 C × N × (N1) / 2。举个具体例子。假设系统提示词 S 1000 token每轮新增思考工具返回工具参数平均 C 800 token循环轮数 N 8最终答案 300 token那么系统提示词累计 1000 × 8 8000累计历史 800 × 8 × 9 / 2 28800输出思考参数≈ 800 × 8 6400粗略最终答案 300总计约 43500 token。而如果按单轮 10008003002100乘以 8 轮 16800来估实际是它的 2.6 倍。如果循环到 15 轮倍数会拉到 5 倍以上。3.2 实测一个真实任务的 token 拆解我拿一个自动调研并生成简报的 Agent 做了实测。任务流程是接收主题 → 搜索 → 读取前 3 个结果 → 总结 → 再搜索补充 → 生成简报。整个流程跑了 11 轮。实测数据用某平台的 token 计数器项目token 量占比系统提示词累计1100012%历史上下文累计4200046%工具返回累计2800031%输出思考参数80009%最终答案6000.7%合计89600100%可以看到历史上下文和工具返回加起来占了 77%。真正有用的最终答案只有 600 token占比不到 1%。这就是 Agent 烧 token 的真相绝大部分消耗在过程上而不是结果上。3.3 不同循环轮数下的消耗曲线为了让你有更直观的感受我模拟了不同循环轮数下的总消耗假设 S1000C800循环轮数单轮估算总量实际累计总量倍数35400102001.9x59000210002.3x814400435003.0x1221600870004.0x20360002100005.8x注意这还只是正常情况。如果工具返回特别长、或者有重试倍数轻松突破 10 倍甚至更高。所谓100 倍通常出现在工具返回巨大 循环次数多 有重试的叠加场景。4. 优化实战把 token 消耗打下来4.1 策略一上下文压缩与摘要既然历史上下文是大头就要想办法压缩它。常见做法是每几轮之后把之前的对话历史做一次摘要用摘要替换原始历史。比如前 5 轮的详细内容压缩成 300 token 的摘要后续调用只带摘要不带原文。具体操作上可以设置一个阈值当累计历史超过 X token 时触发摘要。摘要本身也要花 token但一次性成本远低于后续每轮重复携带原文的成本。提示摘要要保留关键信息——已完成的步骤、当前状态、待办事项。丢掉的是冗余的中间过程。4.2 策略二工具返回瘦身工具返回的内容在进入上下文之前先做过滤。比如搜索工具只返回标题摘要URL不返回全文文件读取只返回相关段落不返回整个文件数据库查询只返回必要字段。我一般会在工具层加一个结果裁剪函数把返回内容限制在 500 token 以内。如果确实需要长内容就分段读取按需加载而不是一次性全塞进去。4.3 策略三系统提示词精简与缓存系统提示词能砍就砍。工具定义用最简格式few-shot 示例控制在 2-3 个行为规范用短句。如果平台支持提示词缓存prompt caching一定要开启这样重复的系统提示词部分可以按更低的成本计费。4.4 策略四设置硬性终止条件这是保命的。必须设置最大循环轮数比如 15 轮、最大 token 预算比如单任务 50000 token、以及重复检测如果连续两轮工具调用和返回高度相似强制终止。没有这些一个 bug 就能让你破产。4.5 策略五模型分级使用不是每一轮都需要用最强的模型。简单的工具调用决策可以用小模型复杂的推理再用大模型。很多框架支持在 Agent 循环里动态切换模型这个能省不少钱。5. 常见问题与排查技巧实录5.1 为什么我的账单比估算高这么多先查三件事第一循环轮数是不是比预期多看日志里的实际轮次第二工具返回是不是特别长打印每轮工具返回的 token 数第三有没有重试或死循环看是否有重复的调用模式。这三个查完基本能定位 90% 的异常。5.2 常见问题速查表现象可能原因排查方法解决方向账单远超估算上下文累积统计每轮输入 token开启摘要压缩单任务消耗巨大工具返回过长打印工具返回长度结果裁剪任务卡住烧钱死循环/重试看轮次和重复模式设终止条件系统提示词占比高提示词太臃肿单独统计提示词精简缓存输出 token 异常思考链太长看 reasoning 长度限制思考长度5.3 几个我踩过的坑第一个坑以为输入 token 便宜就无所谓。实际上输入量大起来便宜也扛不住尤其是上下文累积这种指数级增长。第二个坑工具返回直接透传。早期我图省事工具返回什么就塞什么结果一个网页抓取工具每次返回上万 token直接把成本拉爆。后来加了裁剪成本降了 60%。第三个坑没设最大轮数。有一次测试一个多步任务Agent 陷入搜索-不满意-再搜索的循环跑了 40 多轮才被我手动停掉。那次教训之后我所有 Agent 都强制设了轮数上限。5.4 一个实用的监控小技巧在 Agent 的每一轮循环里打印当前累计 token 数。这样你能实时看到消耗曲线一旦发现某轮突然暴涨立刻能定位到是哪个工具或哪段内容的问题。这个习惯帮我省了很多钱。6. 把 token 账算明白Agent 才能跑得久做 Agent 这件事功能跑通只是第一步成本可控才是能长期跑下去的前提。我见过太多项目demo 阶段很惊艳一上量就被 token 成本压垮。核心原因就是没把账算明白——不知道钱花在哪就无从优化。回到标题那句话你的 Agent 烧 token比你想的狠 100 倍这不是危言耸听而是很多人的真实经历。但只要理解了消耗的结构——上下文累积、工具返回、系统提示词、思考链、重试——你就能有针对性地把它打下来。我自己的项目在做了上下文压缩和工具裁剪之后同样的任务成本降到了原来的三分之一左右效果几乎没有损失。最后分享一个我一直在用的小习惯每次上线新 Agent 之前先拿一个典型任务跑一遍把每一轮的 token 消耗打印出来画个曲线。这条曲线会告诉你这个 Agent 到底健康不健康。如果某一轮突然翘起来那多半就是有黑洞。把这个习惯坚持下来你对 token 的直觉会越来越准估算和实际的差距也会越来越小。