系列AI Agent 工程实践上一篇第 28 篇《可观测性Observability》下一篇第 30 篇《Agent 如何做测试》一、开场一张吓人的账单一个团队没做成本控制每次请求都把完整历史对话 长 system prompt 全量重发。一个月账单出来发现 60% 的费用花在反复发送同一段不变的 system prompt上。加了 Prompt Cache 后这部分直接降了七成。上篇28讲了怎么看见成本这篇讲怎么管住成本——成本控制。二、问题背景不控制 vs 系统控制不控制版# 每次都重发完整上下文 resp llm(messagesfull_history system_prompt) # 重复 token 全算钱系统控制版# 不变的部分走缓存变的部分才计费 resp llm(messagesrecent_turns, systemsystem_prompt, use_cacheTrue)差别成本从随调用次数线性爆炸变成可控。三、错误尝试三种成本翻车错误 1每次全量重发上下文如上。历史对话和 system prompt 不变却反复计费token 浪费严重。错误 2大小模型不分所有任务都用最大模型。其实 80% 的查询分类、抽取、改写小模型就够了大材大用直接翻倍成本。错误 3无 Batch / 无路由离线任务批量摘要实时调用没用 Batch API通常有折扣多供应商不按性价比路由。四、关键观察成本有 6 个可调杠杆Prompt Cache / Context Cache / KV Cache不变前缀只算一次复用命中。Model Routing按任务难度选模型简单任务走低成本的。Small Model First默认小模型复杂才升级大模型路由的具体策略。Batch离线批量走 Batch API享折扣。压缩上下文只发必要历史长上下文截断/摘要。限制输出设max_tokens防模型啰嗦烧钱。成本不是选便宜模型一句话是上面 6 个杠杆的组合。哪一个没拉钱就从那漏。五、最终方案成本控制策略表杠杆怎么做省在哪Prompt Cachesystem/历史前缀标记缓存重复 token 不计费Model Routing任务分类 → 选模型简单任务不花大钱Small Model First默认小模型失败升级大部分调用低成本Batch离线任务走 Batch API官方折扣上下文压缩只发必要轮次输入 token 下降max_tokens限制输出长度输出 token 下降控制流Mermaid六、代码对比每次重发 vs 缓存路由每次重发问题resp llm(messagessystem_prompt full_history) # 全量计费缓存路由生产provider get_provider(small) if is_simple(task) else get_provider(default) resp provider.generate( systemsystem_prompt, # 标记缓存前缀 messagesrecent_turns, # 只发近期 use_prompt_cacheTrue, max_tokens512, )关键差异system_prompt走缓存不变前缀只算一次recent_turns只发必要的max_tokens封顶输出。七、设计权衡成本 vs 质量决策建议理由核心质量路径不牺牲质量换成本省错地方丢用户简单任务坚决用小模型质量够、成本低长上下文缓存 压缩重复计费是大头离线批量必走 Batch白拿折扣反过度工程不要为省 10% 成本把核心体验搞砸。先把重复计费和大小不分两个大头吃掉小优化随缘。八、总结✅ 不控制成本 60% 费用花在重复发 system prompt。✅ 三种翻车全量重发、大小模型不分、无 Batch/路由。✅ 成本 6 杠杆Cache / Routing / Small-First / Batch / 压缩 / max_tokens。✅ 先把重复计费和大小不分两个大头吃掉性价比最高。✅ 反过度工程核心质量路径不为省钱牺牲体验。下一篇用测试守住改了不崩——Agent 如何做测试。30参考资料带用途说明本系列28可观测性Observability本文成本曲线来自28Metrics 层。本系列23Provider 抽象层设计本文get_provider路由直接复用23的抽象。本系列18Agent 如何做 BenchmarkBenchmark 是测试的质量维度本文是工程测试维度。各模型厂商 Pricing 文档platform.deepseek.com 等Prompt Cache / Batch 折扣的政策来源。本文是 AI Agent 工程实践系列的第 29 篇第四阶段第九篇。系列导航上一篇第 28 篇《可观测性Observability》下一篇第 30 篇《Agent 如何做测试》