大模型 API 的计费方式（按 token 计量、输入输出分开定价）决定了成本很容易在不知不觉中失控。下面六个是实际项目里出现频率最高的。
一、把整个知识库塞进上下文
最常见也最贵的错误。既然模型支持长上下文，索性把相关文档全塞进去——结果每次调用输入 token 数以万计。
止血：老老实实做检索，只传真正相关的 3–5 个片段。长上下文能力应该用于处理单个长文档，而不是替代检索。
二、所有任务都用最强模型
强模型和轻量模型的价格差异常常在一个数量级以上。而实际业务里，大量调用是分类、抽取、格式化这类简单任务，轻量模型完全够用。
止血：按任务复杂度分级路由。一个可操作的起点是先统计各场景的调用量，从量最大的那个场景开始试降级，用评测集确认效果不掉。
三、没有缓存
客服、FAQ 类场景里，用户问题的重复率往往高得惊人。没有缓存意味着同一个问题被反复付费回答。
- 精确缓存：完全相同的问题直接返回缓存结果
- 语义缓存：相似问题命中同一答案（需要设好阈值，避免误命中）
- 提示词缓存：固定的系统提示词部分，多数厂商提供缓存折扣
四、失败重试没有上限
一个写得不好的重试逻辑，遇到持续失败时会无限重试，每次都是真实计费的调用。更糟的是这类问题往往在夜里发生，第二天才发现。
止血：重试次数硬上限、指数退避、区分可重试错误（超时、限流）和不可重试错误（参数错误、内容违规）。
五、输出长度不设限
输出 token 通常比输入贵。不设 `max_tokens`、提示词里也不约束长度，模型可能洋洋洒洒写很长，而用户界面只展示前几行。
止血：按场景设置合理的输出上限，提示词里明确要求简洁。这一条改起来最快，收益立竿见影。
六、多智能体的调用放大
多智能体编排里，一次用户请求可能触发十几次模型调用。如果每一步都用强模型、每一步都传完整上下文，成本是单体智能体的十几倍。
止血：编排层要有全局的调用预算概念——单次任务的总 token 上限、单个子智能体的模型等级、步骤之间只传摘要而不是全文。
最重要的一件事：先能看见
上面六条都建立在一个前提上：你能按场景、按接口看到 token 消耗的分布。没有这个数据，优化就是盲猜。
所以任何认真的大模型应用，第一天就该把调用埋点做上：记录每次调用的场景标识、模型、输入输出 token 数、耗时。这份数据的价值会在第一次账单异常时体现出来。