最近看到一组数据：单个 token 的价格，从 2024 年初到现在跌了差不多 98%。按直觉，推理成本应该跟着一路往下走才对，可现实是不少公司的 AI 账单反而越来越高。这中间的落差，挺值得琢磨。
Agent 不是聊天机器人
聊天机器人是一问一答，你发一句它回一句，token 消耗基本是线性的，也好预估。
Agent 完全是另一回事。为了把一个任务做完，它会反复推理、调工具、读返回、再推理、再调，中间还夹着自我纠错和重试。同一件事，Agent 烧掉的 token 大概是普通对话的 5 到 30 倍。
所以单价跌了 98%，单任务的消耗却涨了一个数量级，账单就这么被吃回去了。降价省下来的那点钱，根本扛不住消耗量的暴涨。
Uber 的 CTO 提过一个例子很说明问题：公司一整年的 AI 预算，到四月中旬就花光了，人均每月 API 成本在 500 到 2000 美元之间。这不是谁在乱花钱，而是 demo 阶段跑几次完全看不出问题，真上线后每天跑几千上万次，成本曲线就是另一副样子了。试点时算的那笔账，跟生产环境的账，根本不是一回事。
钱到底花在哪
把成本拆开看大致是四块。最显眼的那块，反而常常不是花得最多的。
一、推理，和被反复发送的上下文
这一块里最容易漏掉的，是重复上下文。
Agent 走多步循环，每走一步，往往要把系统提示、工具定义、历史状态整个再发一遍给模型。你以为只发了一次的东西，一个任务下来其实发了几十遍。有研究估算，光这部分重复传输就占到 Agent 推理账单的 62%。换句话说，账单里超过一半的钱，是花在反复运送那些根本没变过的内容上。
二、上下文管理与 Context Rot
很多人第一反应是把上下文窗口开大点不就行了。问题是开大不但解决不了，还更贵更糟。
测下来主流模型几乎都有同一个毛病：输入越长，准确率越掉。对话到二三十轮往后，夹在上下文中段的信息，准确率能掉三成以上。这跟窗口多大没关系，200K 的窗口塞到 50K 就已经明显退化了。这现象一般叫 Context Rot，上下文腐烂。
所以往上下文里硬塞东西是两头亏，钱多花了，质量还往下走。该做的是主动管上下文：
- 接近上限就做压缩，把历史摘要成短一点的版本；
- 工具按职责分层调用，别一次性把所有工具定义全塞进去；
- 内容按需检索，用到再拉，别一股脑全堆着；
- 拆成各管一摊的子 Agent，每个只带自己那点上下文。
经验上，把实际工作的上下文压到 8K token 以内会舒服很多。
三、RAG 那一整套
如果上了 RAG，得清楚它不是「调一次向量检索」那么简单，是一整套持续花钱的东西。embedding 调用要钱，向量库的托管和查询要钱，最容易被低估的是数据清洗和预处理，这部分能占到一个 RAG 项目总成本的三到五成。更别说数据一更新，重新 embedding、重新建索引又是一笔。它不是一次性投入，是会一直放血的基础设施。
四、编排、监控、合规，还有失控的循环
这一层最阴。推理本身可能只占总成本的两成，剩下八成都在别处。
持续验证 Agent 输出对不对，要花算力，有时还得再请一个模型来打分；审计日志、人工介入、策略校验这些治理和合规的活，也都是钱。最危险的是失控循环，重试一旦没有熔断，成本是指数级往上窜的。
几个翻车的例子就够吓人了。有人 30 天烧掉 130 万美元。某家医疗公司因为一个检索 bug，把超大文档整个拉了进来，月成本六周内从 1.2 万涨到 6.8 万。这些都不是单价的锅，是缺陷和循环被规模狠狠放大的结果。
真正能省钱的几件事
问题说完，说点能落地的，大致按性价比排。
排第一的肯定是 prompt caching。把会被反复发送的固定前缀（系统提示、工具定义这些）缓存起来，命中之后的读取价大约只有标准价的一成，便宜九成。在缓存有效期内（比如一小时的 TTL），复用个两三次就回本了，有案例靠这一招把月成本砍掉八成多。
但有个坑得记死：缓存前缀里千万别放动态内容。时间戳、session ID、随机生成的东西，只要一变，缓存就废了。见过一个团队，就因为系统提示里带了「当前日期」，本该省九成，最后只省了 1%。
KV Cache 的底层机制我之前单独写过：KV Cache 如何显著降低大模型推理成本。
接下来是控制上下文长度，就是上面第二块讲的那套：压缩、分层、按需检索、子 Agent 隔离。省钱的同时还能对抗 Context Rot 保住质量，一举两得。
再就是给重试和循环加熔断。单笔账单暴涨，十有八九是循环失控，设个上限、加个熔断，别让一个 bug 把预算烧穿。
最后是观念上的转变：别拿「烧了多少 token」当成绩。该看的是每一千 token 到底解决了几个工单、动了多少营收。有调研说，只有三成出头的组织能把 AI 花费对应到实打实的业务结果上；还有人预测，到 2027 年会有四成的 Agent 项目因为成本失控被砍掉。活下来的那些，基本都是上线前就把成本模型算清楚、上线时就把用量看板配好的。
说到底，Agent 的成本是个工程问题，不是一笔躺平就能交的订阅费。它得被测量、被设计、被卡上限。真要省，优先级其实挺清楚：先把 caching 用对，再把上下文管住，再给循环上熔断，这几样比「换个便宜点的模型」实在多了。
我自己最在意的是最后那条。盯着 token 消耗，只会越优化越焦虑；盯着它到底干成了几件事，才知道这钱花得值不值。token 从来就不是价值的单位。
关于
关注我获取更多资讯
