做数据分析的人现在很少有不跟大模型打交道的。前阵子我把一套SQL查询总结流程封装成了Agent结果一个月下来账单吓我一跳——Token消耗比预想翻了三倍。本来以为只是多调了几次接口把明细拉出来才发现真正烧钱的是那些看不见的隐性消耗系统提示、工具返回值、历史上下文、多轮Agent协作信息……只要有一环没管住成本就会像滚雪球一样往上走。如果你也是数据分析师正在做或准备做基于大模型的Agent我觉得这个问题值得专门聊一聊。预算失控不是小事尤其在项目初期大家往往只关注效果指标忽略Token消耗等账单出来才后悔。这篇文章会把Agent的Token消耗机制拆开来讲帮你看清消耗点在哪、怎么建监控、优化策略怎么落地最后用一个销售周报Agent的实际复盘案例展示优化前后能差多少。1. 先算明白账Agent的Token到底消耗在哪1.1 你看到的计费规则只是冰山一角大模型API的计费逻辑其实非常朴素输入Token和输出Token分别计价输出通常比输入贵。很多数据分析师一开始觉得我每轮对话就问一句、答一句Token量能有多大这是一个很大的误区。在Agent场景下单次任务消耗的Token远不止你看到的那一两个句子。这里有个行业术语叫“上下文重发”。Agent是连续对话的每一轮新的请求模型并不能“记住”之前的对话它只能靠客户端把历史消息全部带上再塞给模型让它接着生成。也就是说如果你已经聊了10轮那么第11轮请求实际携带的输入是“前10轮的全部消息 第11轮的新问题”。轮数越多历史越长每一次新请求的输入Token就按近似线性关系增长。以常见的中文场景粗略估算一个汉字大约对应1.5到2个Token英文大约4个字符对应1个Token。看起来不算多但如果你每轮请求都携带几千字的历史数据、几千字的工具返回表乘以几十上百次调用数字立刻变得非常可观。1.2 数据人的Agent里藏着哪些隐性Token黑洞数据分析师做的Agent消耗结构往往跟普通聊天机器人很不一样。普通问答Agent主要消耗在“人—模型”的对话过程里而数据分析Agent多了一层“模型—工具”的交互这层交互才是真正的隐性黑洞。第一个大坑是系统提示词写得过长。很多人的系统提示里有大段的产品背景、角色设定、回答模板甚至道德约束动辄一两千字。系统提示在每轮请求中都会重新发送跑一个50次调用的任务就相当于把这篇小作文反复发送50遍。哪怕你平时不觉得它长累计起来就是一笔巨大的固定成本。第二个大坑是工具返回结果太“肥”。数据分析Agent经常要查SQL、看表结构、取样本数据。如果你让模型去调用一个查询接口而接口默认返回全部字段、所有行哪怕模型只需要平均数这几十KB的工具返回也会全部被计入Token。更有甚者某些团队把整个表的schema一次性塞进上下文遇到大宽表一次就是几千Token。第三个大坑是多Agent协作时的消息转发。很多项目会把数据分析Agent拆成“理解意图Agent”“取数Agent”“画图Agent”“复核Agent”Agent之间互相传递消息。如果消息体里携带完整的数据快照和冗长中间文本每个Agent都要把收到的内容重新作为上下文发一遍Token消耗就会成倍增加。1.3 建立Token消耗基线先别急着优化我不建议你上来就照搬各种优化技巧第一步应该先搞清楚自己的Agent“胖”在哪。具体做法是在你现有的Agent外层加一个日志层记录每一次调用API时的输入Token数、输出Token数、时间戳、使用的工具名称、携带的消息条数。连续记录100个任务你就能得到一份自己的Token消耗基线。有了基线之后再看三个核心指标单任务平均消耗Token、每轮请求的平均输入Token、工具返回占总输入的比重。这三个指标能帮你快速定位最值得优化的环节。如果工具返回占比特别高就别急着压缩系统提示如果每轮请求输入都很高重点要放在上下文剪枝上。没有数据支撑的优化基本等于闭着眼睛改代码效果全靠猜。2. 四个立竿见影的Token优化策略2.1 策略一Prompt瘦身——把每一行指令当成计费字符系统提示词是Agent的“默认背景音乐”每次调用都会响起。所以对系统提示的优化回报率极高。我见过的最极端案例系统提示里复制了整份业务文档接近8000字而Agent真正用到的核心规则不到200字。这种成本完全可以通过删减省下来。但不是让你把提示词砍得太干而是区分“静态要求”和“动态信息”。角色定位、输出格式、少量关键规则这些属于必须保留的静态要求尽量精简到100到300字。具体业务数据、用户信息、临时任务说明不应该写进系统提示而是想办法通过检索注入按需携带。比如某分析任务今天只需要看华东区数据那就把华东区相关表结构检索出来加进这轮请求而不是把所有区域的schema都常驻在系统提示里。另外一个细节是避免重复指令。有些Agent既在系统提示里写了“回答必须简洁”又在每个用户消息前面加一遍“请简洁回答”。模型每次都会把这两条重复接收处理起来不会更聪明只会更费Token。同一个意思在一条链路里只写一次就好。2.2 策略二上下文分级管理——能忘的就忘该记的才留多轮对话的上下文是Token消耗的大户。很多Agent为了保持连贯性把所有历史消息原封不动地保留下来一个卖货数据分析任务聊了20轮前15轮的废话还一字不落地出现在后续每一次请求里。这就像你去开会每次都把三个月前的会议纪要重新念一遍效率自然很低。业界比较成熟的做法是“上下文分级管理”也叫分层记忆。短期记忆只保留最近几轮原始消息比如最近3轮中期记忆用一个摘要代替每过5轮就把前面的对话自动压缩成一段几百字的总结长期记忆只存那些关键结论比如用户确认过的指标口径、异常结论、常用过滤条件。每次请求时把“短期原文 中期摘要 长期记忆”拼装起来而不是把全部历史一股脑塞进去。这里有个要点摘要本身也会消耗Token所以不能把摘要做得太长。一个小技巧是让模型在生成摘要时直接控制字数上限比如“用200字以内总结本轮对话只保留决策和结论”。实测下来这样的摘要对后续对话的支撑效果很好而Token开销几乎可以忽略。2.3 策略三工具调用做减法——让Agent少犯“手贱”数据分析Agent的另一个明显特点是工具调用频繁。模型能不能正确选择工具是一回事更关键的是它经常调用同一个工具多次或者把不需要的数据也拿回来。比如查一个订单总额模型先把整张订单表的所有字段查出来再看有哪些字段最后再聚合计算。这个过程中每一次工具调用的请求和返回都计费。解决思路分三层。第一层是“少调”通过更明确的指令告诉Agent哪些工具优先用、哪些不要用。比如已经提供了total_sales()聚合接口就不要让模型先去查明细再自己算。第二层是“少传”接口设计要站在Token角度考虑返回行数加LIMIT字段列表按需选择能返回聚合结果就不返回明细。你可以给工具加一个参数max_rows50默认值不要太大。第三层是“少等”把一些高频小查询做成预加载。比如Agent经常查表结构如果这个表结构一天才变一次完全可以把schema做成一次性获取后存在本地而不是每次调用工具去现查。工具调用的优化往往比Prompt瘦身更容易见效因为它直接砍掉的是大头输入Token。我见过一个案例只是给所有查询接口统一加了行数上限并把工具描述里的“可返回全量数据”改成“默认最多返回50行”整个Agent的输入Token直接降了四成。2.4 策略四缓存与模型分级双保险——复用和降配并行除了从请求内容上做减法还可以从系统架构上做乘法。缓存是很多数据分析师容易忽略的点。如果在Agent外面加一层语义缓存对完全相同的用户问题直接返回历史答案连API都不用调。更友好的是前缀缓存机制现在部分商用API支持提示词前缀复用只要系统提示和最近的历史消息前缀没变后续请求的服务端计费单价会显著降低。这意味着你尽量把变化的内容放在消息末尾而不是放在系统提示里反复改。模型分级也很重要。数据分析Agent内部不同子任务对模型能力的要求差别很大意图识别、字段对齐这种任务用中档轻量模型就够只有复杂推理、写总结这些环节才需要上旗舰模型。你可以做一个简单的路由规则先判断任务类型普通查询走小模型长文本总结和调试SQL走大模型。不同模型之间Token单价差距可能达到5到10倍这比任何Prompt优化都来得直接。3. 实战复盘某销售周报Agent的Token账本3.1 原始设计的“胖”在哪里为了让你更直观地理解上面的策略我把一个实际做过的模拟项目X拿出来复盘。这个Agent叫“销售周报生成器”任务很简单每个周五拉取一周销售明细计算各区域GMV、订单量、客单价并与上周对比最后生成一份800字以内的周报。看起来轻量实际跑起来成本却高得离谱。原始设计长这样系统提示2400字里面贴了完整的数据库表结构、字段说明、历史周报范例。Agent第一轮先调“获取全部表结构”工具返回约55个字段的说明。第二轮调“查询全量销售明细”接口没有行数限制一次性返回了该周的所有订单记录共十几万行幸好测试环境数据量小不然一次就给上下文撑爆。第三轮让模型自己写Python聚合但历史上下文已经塞进了前面几轮的全部内容。最后生成周报时模型又把前面所有查询结果重新读了一遍输出一个很啰嗦的版本。我统计了50个任务的平均消耗每任务输入Token约61000输出Token约5500折合单任务约66500 Token。按当时测试模型的单价折算50个任务总成本相当于烧掉了约3.3M Token非常肉疼。而且这还是小数据量测试真实生产数据量再放大成本完全不可控。3.2 改造后的Agent内部流程后来我按前面说的方法做了系统改造大概花了两个晚上。首先是系统提示大幅瘦身把表结构说明从系统提示里移出去改成一级工具get_schema(table_name)按需取用。其次增加了查询接口的行数上限明细查询必须带limit200聚合查询走专门的汇总接口不再让模型自己去读全表。上下文管理上也做了调整。周报任务本来就不需要保留全程对话原文我只保留最近两轮原始对话再让模型每周一第一次运行时生成一个“本周关注点摘要”后续轮次用摘要代替完整历史。Agent之间不再直接转发数据快照而是统一存到一个中间结果对象里需要时用工具按key读取。改造后的流程简化为四步识别周报需求并生成本周汇总口径→按区域调用聚合接口拿核心指标→对比上周数据生成差异分析→输出周报。每一步只携带必要数据。3.3 优化前后消耗对比改造后我再跑了同样的50个任务统计结果如下指标优化前优化后降幅单任务平均输入Token610008200-86.6%单任务平均输出Token55002100-61.8%单任务总Token6650010300-84.5%工具调用次数/任务4.22.5-40.5%50任务估算成本按统一测试单价基准值约15.5%-84.5%这个降幅并没有牺牲输出质量。我对比了优化前后的周报结论、数据、重点差异都在只是在文字表达上更精炼了。这也让我后来养成了一个习惯每次做完Agent优化都拿同一批测试用例同时跑优化前和优化后版本人工盲测结果质量防止优化Token却把效果搞坏了。4. 常见问题排查与避坑实录4.1 排查思路从日志到Token明细做Agent优化的过程中我踩过不少坑也积累了一套自己的排查方法。如果发现Token消耗异常别急着改代码先按下面的顺序从外到里排查先看每次API调用的出入Token明细。很多平台的返回结果里自带usage字段包含prompt_tokens和completion_tokens。把这个字段记到日志里按请求维度做汇总你很快就能发现是哪个环节消耗异常。如果日志里没有Token统计那说明你的日志层本身就不合格先去补上。接着看输入Token的构成。拿一次消耗最高的请求出来把输入消息按角色拆分系统提示占多少、历史消息占多少、工具返回占多少、用户消息占多少。通常很快能定位到那个“肥胖”的组件。我见过最夸张的一次某个请求的输入Token里工具返回占比高达78%而真正的最新用户问题只占0.5%。最后对照业务链路排查Agent是不是“绕路”了。如果任务本来一步就能完成模型却调了五六次工具很可能是工具描述写得不够清晰让模型误判了调用条件。这时优化方向应该是重写工具描述而不是继续加限制。4.2 避坑清单下面这份清单是我在实际项目中整理出来的每条都对应过一个真实教训上下文“一股脑全带”。只要不做分层记忆任何多轮Agent的Token消耗都会线性增长。记住历史不是越完整越好而是越精炼越好。接口没有默认行数上限。一次查询返回十万行不只是Token爆掉的问题还容易导致模型在长上下文里找错重点。系统提示里放“经常变化的参数”。比如把最新日期写进系统提示每次日期变化都会破坏前缀缓存。正确做法是放在用户消息里让变化的内容尽量后置。输出格式过于冗余。让模型输出JSON时字段名又长又多还没设置严格的结构约束模型经常输出额外解释文本。能用结构化输出的就用别让它自由发挥。日志本身不计入Token但日志记录的内容如果被当作上下文传给模型就会计入。日志和上下文要分开不要为了方便调试把Debug信息也加进消息里。多Agent的中间消息里带大字段。有些框架会自动把工具结果是长文本广播给所有Agent这个设计对Token极不友好。确认你用的框架到底传了什么。4.3 计费口径的几个冷知识关于Token计费有几个容易被忽略的细节。第一输出Token通常比输入Token贵所以生成冗长答案的成本比想象中高。写“一句话总结”别让模型给四段背景说明。第二部分服务对“思考过程”单独计费模型在正式回答前会先生成一大段内部推理这段推理也可能计入Token。如果你发现输出Token远大于预期去检查是不是开启了过多推理预算。第三提示词缓存不是所有平台默认开启有的需要显式配置有的需要满足“前缀完全一致”条件。在优化前先查清楚你用的服务支持什么。这些计费冷知识不会写在产品首页但直接影响你的预算模型。我在做成本预估时会额外留20%的缓冲空间给不可控的Token波动。5. 写在最后Token意识应该是数据分析师的基本功其实Agent开发本身并不复杂复杂的是让它在效果、速度和成本之间取得平衡。作为数据分析师我们天然对指标敏感这本该是我们的优势。但很多人做Agent时还是停留在“能跑就行”的思维里对Token消耗没有概念等到账单出来才觉得难以接受。我个人在实际操作中的体会是Token优化不是一个一次性动作而是一个持续跟踪的习惯。每上线一个新Agent我都会先做基线统计每周跑一批固定测试任务看Token消耗有没有随着业务数据量增长而恶化。只要数据开始出现明显上涨我会立刻检查上下文增长和工具返回情况而不是等月底账单再亡羊补牢。这一整套方法并不需要多么高深的技术核心就是把Token当作真实成本来管理先量化再优化最后固化到代码和流程里。如果你正在做数据分析Agent建议下一步就从自己的项目里抽一次完整请求把Token明细打出来看看。真正看到那串数字的时候你自然会知道该从哪里动手。