这段时间，AI 新闻几乎天天有新动静。大模型在升级，AI Agent 在进企业，编程助手也不再只是补全几行代码，而是开始读项目、改文件、跑测试。很多公司也把 AI 用到客服、知识库、文档生成、数据分析和内部办公里。
功能看起来更强了，账单也跟着明显起来。
不少程序员第一次做 AI 应用，会把成本理解成“模型单价”。比如看每百万 Token 多少钱，然后选一个便宜点的模型。这个当然要看，但它只是一部分。真实项目里，钱往往花在用户看不到的地方：提示词太长、历史对话带太多、知识库一查就塞一大段、Agent 来回调用工具、接口失败后自动重试。
用户只问了一句，后台可能已经跑了好几轮。
一、一次提问，不一定只有一次调用以“帮我分析这个接口报错”为例。用户看到的只是这句话，系统可能还会把这些内容一起发给模型：系统提示词、最近几轮对话、接口日志、请求参数、返回体、调用链、知识库里的排查手册、最后还要加一句“请按固定格式输出”。
如果接的是 AI 编程工具，情况更重。它可能要读目录结构、相关文件、测试输出和报错堆栈。Agent 场景还会继续拆步骤：先判断问题，再查日志，再读文档，再调用工具，最后整理结论。
所以别按“一问一答”估成本。AI 应用真正烧 Token 的地方，常常在这一串后台动作里。
二、上下文越长，未必越好长上下文能力很有用。读合同、看代码仓库、处理长文档，都离不开它。但能塞进去，不代表应该全塞进去。
把一整天日志都丢给模型，通常不是好办法。里面有大量重复信息、正常请求和无关字段，模型读得慢，费用也上去，最后还可能抓不到重点。
更实用的做法是先筛一遍。比如排查线上问题，只给故障前后几分钟的日志；分析代码，只给相关模块和调用链；做知识库问答，只拿最相关的几段内容，不要把十几段相似材料都扔进去。
省 Token 的关键不是把话写短一点，而是少给无关材料。
三、Agent 要能干，也要有刹车现在 AI Agent 很热，因为它能做的不只是回答问题。它可以拆任务、调接口、查数据库、读文件、生成报告。对程序员来说，这确实很有吸引力。
问题是，Agent 越主动，成本越不好估。
普通聊天可能调一次模型就结束。Agent 做一个任务，可能要调五六次模型，还要调用几个外部工具。中间某一步失败，系统又重试；输出格式不对，再让模型修一次；结果不够完整，再补查一轮。
用户以为只是点了一个按钮，后台已经跑了一条小工作流。
做 Agent 时，一定要设上限：最多跑几轮，最多调用几次工具，失败后要不要重试，什么时候停下来，什么时候交给人工。没有这些限制，成本很容易慢慢涨上去，而且问题还不好查。
四、别一贵就换模型账单高了，很多人的第一反应是换便宜模型。这个方法有用，但不能只靠它。
有些任务本来就不需要最强模型。分类、改写、摘要、格式整理，可以用轻量模型。涉及复杂推理、代码理解、专业材料审查，再用能力更强的模型。这样比所有请求都走同一个大模型更划算。
还有一些简单但很有效的做法：
历史对话不要无限带，只保留当前任务需要的部分。知识库检索结果要截断，别把相似内容全塞进去。提示词定期清理，删掉重复规则和已经不用的说明。输出长度要控制，需要三条结论时，就别让模型写成长报告。高频问题可以做缓存，同样的问题不要每次重新生成。这些不是很高深的优化，但上线后会直接影响账单。
五、省钱之前，先知道钱花在哪AI 成本最怕只看总数。月底看到花了多少钱，但不知道哪个功能花的、哪个部门用的、哪类请求最贵，这样很难优化。
程序员最好从一开始就把 Token 当成系统指标来记。至少要记录调用次数、输入 Token、输出 Token、模型名称、功能模块、用户或部门、响应时间、失败次数和重试次数。
有了这些数据，很多问题会变清楚。
比如某个客服场景成本高，可能是历史会话带太长；某个文档问答很贵，可能是知识库每次返回太多；某个 Agent 任务不稳定，可能是工具调用失败后一直重试。
没有数据，降本只能靠感觉。有数据，才能知道该改提示词、改检索、加缓存，还是换模型。
六、缓存和评估要一起做缓存是很容易被忽略的降本办法。企业里有很多问题是重复的，比如制度解释、模板生成、常见故障说明、固定报表摘要。这些内容不一定每次都要重新问模型。
但缓存也不能乱用。业务规则变了、文档更新了、权限不同了，旧答案可能就不合适了。所以缓存要有过期时间，也要区分用户权限和业务版本。
另一个不能省的是评估。降本之后，回答是不是变差了？关键问题有没有答错？响应时间有没有改善？这些都要用真实样本测一下。可以先建一个小测试集，放进高频问题、边界问题和容易出错的问题，每次改模型、改提示词、改检索策略，都跑一遍。
省钱不能省到业务不可用。AI 应用要长期跑，成本和效果要一起看。
七、从运维角度看 Token 降本AI 应用上线后，本质上也是一套线上系统。它连着模型接口、知识库、数据库、日志、权限、网关和业务流程。只盯模型价格，很容易漏掉真实问题。
这个问题也可以结合 xapex 的 AI 网关来看。AI 应用接入多个模型后，最怕每个业务系统各接各的接口：调用量看不清，Token 成本不好拆，账号权限分散，后面排查问题也麻烦。AI 网关更适合放在模型和业务系统中间，统一处理模型接入、调用转发、权限校验和访问记录。
这样做的好处不是多加一层系统，而是把 AI 调用变成可管理的链路。哪个应用调用了哪个模型，输入和输出消耗了多少 Token，哪个部门用量最高，哪些接口失败率高，哪些场景效果不好，都可以放在网关侧统一观察。对企业来说，这比单纯接一个模型 API 更重要，因为 AI 应用一旦变多，成本、权限和效果都需要有人看得见、管得住。
结语AI 应用成本越来越高，并不奇怪。功能越多、用户越多、Agent 越主动，Token 消耗自然会上来。
程序员要做的不是盲目少用 AI，而是把账算清楚：少给无关上下文，给 Agent 设边界，按任务选模型，能缓存的缓存，该评估的评估。把这些基础工作做好，AI 应用才更容易从演示项目变成真正可长期使用的业务系统。