养了三个月虾账单给我上了一课。我们做的是一个叫“人人养虾”的AI互动应用——不是养真虾是让每个人在网页里领养一只虚拟虾喂食、换水、观察状态所有互动都由大模型API实时驱动。外面看是轻松治愈的养成游戏背后每一句拟人化回复都在烧token。整套系统搭在OpenClaw上这是一个开源的多智能体编排框架负责把用户请求路由到不同Agent统一管理上下文、埋点和重试。这篇东西不聊产品设计专门复盘API用量与成本这件事钱花在哪、为什么烧、怎么省拿真实账单和数据一步步拆给各位看。1. 项目拆解一个AI养虾应用是怎么把API烧起来的1.1 “人人养虾”到底是什么先交代背景不然后面所有数字都显得没头没尾。这个应用名义上是“养成类游戏”用户领养一只虚拟虾给它取名字每天喂食、清理水箱、陪它玩虾会通过聊天窗口回应用户。为了让反馈足够生动虾的每一次回复都不是预设脚本而是实时请求大模型生成——比如用户问“我的虾怎么看起来没精神”系统要先识别意图再把当前的水温、喂食记录、活动量拼成一段结构化上下文让模型输出一段拟人化回复同时附带一张“虾状态卡片”。这个状态卡片是产品的一个亮点上面显示“活力指数”“饥饿程度”“水质评级”等指标。关键点是这些指标不是乱写的它们的数值来自数据库里的真实状态机计算而模型只负责把指标翻译成用户能看懂的话。也就是说每次互动并不是“模型自由发挥”而是“结构数据模型润色”这个定位决定了后续所有API调用方式——不可能靠纯规则脚本完成但也绝不能把整段原始数据都丢给模型。从成本视角看“人人养虾”的互动特征是频次高、单次轻、上下文依赖强。用户一天可能打开十几次每次操作都要触发一次或多次模型调用。这跟那些“每天只回答一个长问题”的助手型应用完全不同——我们面对的是大量短对话但每次都要携带虾的状态上下文所以在API用量上天然偏向输入token消耗。1.2 OpenClaw在链路里的真实定位OpenClaw在这个项目里不是一个业务系统而是一个“API调度层状态协调器”。它管四件具体的事路由、上下文管理、用量埋点、熔断与重试。路由指把用户消息分发到不同Agent。比如“喂食”请求进喂食Agent“闲聊”进闲聊Agent“虾状态异常”进诊断Agent。每个Agent有自己独立的提示词模板和模型档位配置。上下文管理则决定每次请求给模型带哪些数据——这是控制成本的核心位置因为同样一条消息带800 token上下文和带3000 token上下文成本差好几倍。用量埋点是最容易被忽略但最不能漏的功能。OpenClaw网关层会在每个请求完成后把输入token、输出token、模型档位、缓存命中状态、耗时、是否重试等信息异步写入日志。熔断与重试负责在模型供应商返回限流或超时时按预设策略退避而不是机械地重试放大风险。我定了一条铁规矩所有模型请求必须从OpenClaw网关经过业务代码不允许私自调模型API。这条纪律在项目早期看像多此一举但到了对账和优化阶段它是所有成本分析的唯一数据源。没有这条规矩你面对的就是一堆散落在各函数里的调用点月账单对不上也不知道差在哪。1.3 选型逻辑为什么用框架而不是直接调API有人会问一个小应用何必套一个框架直接在后端调用API SDK不就行了。确实行但会埋下三个隐患。第一计费逻辑散落。每个业务函数都要自己记录token消耗统计口径必然五花八门今天这个函数记了输入没记输出明天那个函数漏了重试请求最后月度账单出来你根本不知道哪部分是真实的。第二没有统一重试策略。高峰期模型供应商一旦限流每个函数各自重试相当于雪崩时还在加雪请求量会在几秒内翻倍。第三Agent之间的状态衔接麻烦。虾的“心情”“饥饿度”是跨请求保留的如果每次调用都是无状态直连就得自己在业务代码里维护大量上下文拼接逻辑。OpenClaw这类框架的价值是把“模型调用”这件事从业务逻辑里剥离出来让网关统一处理上下文窗口、重试、埋点、模型路由。前期确实要花一两天配置Agent和提示词模板但后面每一次排查线上问题、每一轮成本优化这笔投入都会成倍赚回来。我的建议很简单只要你的应用不是单轮问答而是有状态流转、多步骤决策的交互场景就不要省这个中间层。2. API用量分析账单上的钱到底是怎么烧掉的2.1 用量统计的四个关键维度做成本分析最忌讳只看账单总额。总额是结果不是原因。要拆就得按四个维度拆请求数、token数、模型档位、缓存命中率。请求数回答“业务频率”问题——用户每点一下后端发了几次模型请求。token数回答“单次成本”问题——平均一次请求消耗多少输入、多少输出。模型档位回答“资源配置”问题——是不是所有流量都用最贵的那个模型在扛。缓存命中率回答“重复调用”问题——有多少请求其实完全没必要发生。我拿到月账单后的第一步就是把这个月所有网关日志按这四个维度汇总。以某月为例总请求数是44,380次总token消耗是1,265万按行业通用的按量计价区间粗算总成本约42美元。单看这个数字不吓人但拆开后发现问题很大请求数里意图识别一个节点就占65%平均输出token只有40个却和生成复杂回复的节点用同一个高配模型。这就是典型的“杀鸡用牛刀”也是后续成本优化最大的突破点。2.2 一次典型养虾互动的token消耗拆解拿用户发一句“虾今天怎么不动了”来算笔细账。这句话本身只有7个汉字但有经验的开发者都知道真实发给模型的输入远不止这几个字。OpenClaw实际拼出的请求包含五部分系统提示词约400 token规定角色设定、回复风格、可使用的行为动作虾的状态摘要约350 token涵盖水温、pH值、最近喂食时间、互动记录、状态机输出用户消息本身约30 token最近3轮对话历史约300 token少量示例根据角色路由约100 token。合计输入约1180 token模型最终生成一个150 token的回复。按行业常见的按量计价方式粗算输入每百万token约3美元、输出每百万token约6美元这一次互动的成本大约是1180 ÷ 1,000,000 × 3 150 ÷ 1,000,000 × 6 0.0045美元换算下来一次互动大概3分多人民币。单看不贵但如果一个活跃家庭用户每天触发150次互动一个月就是几十美元的量级。真正拉开差距的不是这条“标准请求”而是那些上下文构造失控的请求——如果状态摘要从350 token膨胀到2000 token单次成本立刻翻好几倍。所以控制成本的核心不在模型输出长度而在输入token的瘦身。2.3 用量记录的落地方法成本分析的基础是数据数据的基础是埋点。我在这里强烈建议不要自己估算token直接读取模型返回的usage字段作为唯一可信来源。很多框架习惯用字符数或字节数估算和模型供应商标注的token口径不一致最后对账必错。每条埋点至少包含这些字段时间戳、用户标识、功能类型、Agent节点、模型档位、输入token、输出token、缓存是否命中、耗时毫秒数、是否重试。OpenClaw的网关天然适合打这些点我把它封装成一条异步消息队列不阻塞主流程每晚定时汇总成报表。举个例子一个典型的埋点对象长这样event { ts: 1710000000, user_id: u_10086, action: feed_shrimp, agent: chat_feed, model_tier: tier_2, input_tokens: 1180, output_tokens: 150, cache_hit: False, latency_ms: 860, retried: False, }这里有个细节缓存命中与否必须单独打标。因为缓存命中的请求虽然也消耗了网关资源但不产生模型调用费用。统计时分开展示才不会被“总请求数增加”吓一跳。2.4 隐性消耗用户不会感知但钱在走的API还有一种烧钱方式用户完全感知不到但账单一分不少。我们项目里有两类典型的隐性消耗每日水况播报、自动健康检查。“每日水况播报”是在每天早上自动生成一段关于虾缸状态的自然语言总结推送到用户消息列表。这段内容很多用户根本不打开看但生成时已经完整调用了一次模型API。“自动健康检查”更夸张系统每天晚上对每个家庭账户的每只虾跑一次诊断一个中型账户虾缸里可能有十几只虾一只虾一次诊断就是一条模型请求全家桶下来一晚上的调用量比白天用户主动互动还要多。这两类隐性消耗加在一起占了总成本的25%左右。我一开始差点把它们一刀切掉但后来发现它们对产品留存是有价值的——用户偶尔打开消息列表看到一句“你的虾昨晚状态不错进食比平时积极”会觉得产品很聪明。处理方式不是砍掉而是给每个隐性调用单独打标单独统计成本然后逐个问这个功能能不能降低频次能不能换低档模型能不能用规则引擎替代这样至少能确认每一分钱都花得有理由。3. 成本控制实战怎么把月账单从42美元压到22美元3.1 模型选型不做一刀切前面提到最早所有Agent共用一个能力最强的模型理由就是一个字懒。等到把用量按节点一拆数据立刻打了脸意图识别节点占了全部请求的65%每次输出平均只有40个token属于典型的分类任务根本用不着高配模型。于是我们做了三级模型分档档位适用场景平均输出token成本定位入门档意图识别、关键词抽取、格式化输出50以内最低经济档日常互动、闲聊、普通状态回复150到250中等能力档虾状态异常诊断、复杂行为解释400以上最高改动本身不复杂在OpenClaw每个Agent配置里指定model_tier就行。关键是要想清楚什么场景用哪个档位。我的判断标准不是“功能看起来简单还是复杂”而是看实际请求的token长度和推理难度。比如喂食互动模型只需要根据结构化状态生成一句自然反馈经济档完全胜任。但“虾为什么不吃东西”这种问题需要综合水温、pH值、历史记录做多因素分析必须走能力档。这个改动花了一个下午效果立竿见影——次月账单降到30美元左右接近三成。而且用户没有感知到任何质量下降因为大部分普通对话本来就不需要顶级模型。3.2 提示词瘦身一千token的顶配用法模型分档解决了“资源错配”提示词瘦身解决的是“每一千token的转化率”。我们原始系统提示词写了600 token里面塞了十几个示例覆盖投喂、换水、生病、闲聊等各种场景。问题是系统提示词里的每个字都会计入每次请求的输入token哪怕用户只是在聊“今天天气不错”模型也要先读完那600 token的示例。优化动作分两步。第一步是“基线瘦身”只保留角色设定、输出格式约束、安全边界压到200 token以内。第二步是“按需拼接”把典型示例从系统提示里拆出来放进按路由命中的独立模板库——当用户消息命中“喂食”意图时才临时拼上一条喂食示例命中“闲聊”时就不携带任何示例。这件事在OpenClaw里实现很顺手因为每个Agent本来就有自己的提示词模板网关在路由完成后才组装完整请求。优点有两个第一输入token大幅下降第二模型回答质量反而提升了因为提示词里不再堆着一堆和当前场景无关的干扰内容。好的提示词不是字数多就好而是“该出现的内容就一定出现不该出现的内容一个字都不留”。3.3 缓存与状态管理不要让同一只虾反复被问“你怎么样”很多API成本浪费不是模型价格高而是重复调用太多。我们早期的产品形态是用户打开虾缸页面前端就请求一次“虾状态摘要”的生成。用户停留十分钟前后可能刷新了五六次每次刷新都会把过去十条历史记录甩给模型重新生成一段摘要。同一个用户、同一只虾、同一段历史重复生成五六次全是无效成本。解决方法是做两级缓存。第一级是短时缓存同一个用户5分钟内对同一只虾的状态查询直接返回上一次生成结果不再发起模型请求。第二级是摘要缓存把“虾状态摘要”做成一个持久化的数据对象只有当真实状态数据发生变更时才触发重新生成。比如喂食之后饥饿度变了才需要刷新摘要如果用户就是单纯打开页面看一眼数据没变就直接复用旧摘要。同时对话历史的窗口也做了截断不再无脑传最近10轮完整对话而是设置最大600 token的滑动窗口超出部分用一条模型生成的“更早对话摘要”代替。这个摘要本身会过期一般设置20分钟过期后如果真需要再重新生成。这一套组合拳下来输入token平均消耗又降了18%。还有个意外收获缓存命中后的响应速度从原来的一秒多降到一百毫秒以内用户体验反而更好了。3.4 重试与限流的成本陷阱用户量一上来模型供应商的限流和超时几乎是每天都会遇到的事。最忌讳的就是见错就重试一个请求失败立刻重发再失败再重发等于把成本放大了好几倍还会把本来正常的请求也挤到限流队列里。我们约定了一套有节制的重试策略第一次失败等待200毫秒重试第二次等待800毫秒再重试第三次直接放弃当前请求转入降级流程。降级不是不回复而是返回一条预设的兜底文案比如“虾打了个哈欠好像不想说话晚点再来看看它吧”。这条兜底文案不消耗任何模型token但用户感知到的失败率大幅下降。还有两个细节必须提。第一重试请求必须带幂等键。网关会在请求头自动注入请求ID模型供应商按这个ID去重。没有幂等键的重试如果原始请求和重试请求同时到达会被当成两次独立请求计费。这算是成本失控的头号隐藏杀手平时没人提等账单出来才发现。第二流式请求要设首包超时超过3秒就切断连接走兜底逻辑。别小看这个值高峰期它能让网关的积压请求数下降一个量级。4. 常见问题与排查技巧实录4.1 请求量突然暴涨的三种原因这个月前半个月一切正常后半个月突然有一天请求量暴涨了一倍。我们排查了三个方向最后发现是三种完全不同的原因都值得记录。第一种是Agent循环死锁。某个意图节点没有设置出口条件导致同一条用户消息被反复送入处理节点一晚上多产生了8万次无效调用。这种问题在日志里很容易查按“依赖路径长度”排序异常链路会明显比别人长一大截。第二种是前端轮询过度。页面里的虾状态面板原本5秒刷新一次每次刷新都会触发状态摘要请求。日常在线用户一多这个刷新频率直接把请求量顶到了天花板。后来改成30秒刷新并且状态变更改用WebSocket主动推送请求量立刻降回来。第三种是重试风暴。模型供应商在高峰期限流所有请求超时后同时重试又撞上新一轮限流形成了恶性循环。处理方式是在网关加全局并发上限一旦超过并发阈值就把新请求排进队列而不是立刻发起调用。这个全局防抖特别重要不然一个几十人的小应用也能在几分钟内打出几万次请求。4.2 计费对不上先查这五个地方对不上账单这件事我们大概每个月都要遇到一次。经验是别急着找模型供应商先自查统计口径。我的排查顺序是这样的确认是否所有模型请求都从网关经过有没有绕过网关直连的漏网之鱼。确认缓存命中请求是否单独打标有没有被当成正常调用重复统计。确认流式输出统计的是增量token还是全量token全量统计会造成成本翻倍。确认重试请求和原始请求是否都只计费一次避免重复记账。确认日志时间和计费账单的时区是否一致跨天数据最容易出现一天漂移。大部分所谓的“计费异常”最后都落在第五点上也就是时间口径不一致。把日志时间统一成UTC再和账单比对问题基本能消失。4.3 延迟升高与成本失控的联动排查延迟升高和成本失控往往是同一个根因的两面。有一次综合延迟从800毫秒涨到5秒我一开始以为是网络问题后来把“平均输入token曲线”调出来才发现token量提前一小时就开始上涨延迟是被大请求拖慢的。追查真相比预想简单——前端某个版本把整个序列化后的数据库表塞进了提示词导致一次请求的输入token从1200变成12000。模型处理大请求当然慢慢就引发前端超时重试重试又继续放大请求量成本在用户无感的情况下发生了严重失控。后来我把负责任的检查命令加进发布流程每个新版本上线前抽样打印真实请求的输入token分布超过预设阈值就不允许发布。延迟优化不只看代码性能还要盯请求构造。4.4 一套可复用的成本告警配置成本告警和余额告警是两回事。余额告警是在钱烧完后通知你成本告警是在钱正烧得过猛时拦住你。我们项目里有一套极简但有效的告警配置逻辑非常简单每分钟请求数超过2000触发告警每分钟预估成本超过0.5美元触发告警缓存命中率低于40%触发告警失败重试占比超过5%触发告警。这些阈值是按我们的业务量定的你们可以按自己的基线调整。重点在于监测“速率”而非“总额”。总额告警只能事后来看速率告警才能真正把事故扼杀在萌芽期。有一次我们搞了一个不该有的促销推送几分钟内瞬时请求量拉升了三倍还好速率告警先响我立刻停了推送避免了整月预算被半天烧完。5. 养虾三个月后我最后想说的几句实在话数据看久了我慢慢发现最有价值的指标不是月账单总额而是“每千次互动成本”。这个数字把请求数、token消耗、缓存命中率都揉成一个可以直接对比的指标。第一个月这个值是0.13美元优化后降到了0.05美元左右。我每周固定看一次它涨得越快说明又有环节失控了。成本优化的本质不是抠门是让一次请求只携带它真正需要的信息只在它真正需要的时候发起。这个原则放在“人人养虾”里适用放在任何大模型API应用里也适用。最后提醒一句每次做模型档位调整或提示词改动前先看一眼前一周的网关日志——用数据做决策永远比你凭感觉拍脑袋靠谱。