Agent 成本控制：预算不是事后统计，而是架构约束

一提到 Agent 成本，很多人第一反应是比较模型单价。但在真实系统里，成本往往由几件事一起决定：

• •模型输入输出 token
• •循环步数
• •工具调用次数
• •上下文长度
• •重试和 fallback 次数

所以成本控制的核心，不是事后看账单，而是提前设计系统边界。

换句话说，预算应该像延迟和可靠性一样，被当成架构约束，而不是财务统计。

对多数 Agent 系统来说，成本通常来自三层：

1. 模型推理成本

这是最直观的一层，也是大家最容易先想到的部分。

2. 决策链路成本

即使单次模型调用不贵，如果一个请求跑了很多轮：

• •规划
• •调工具
• •看结果
• •再规划

总成本一样会迅速上升。

3. 上下文重复成本

很多 Agent 会在每次调用里反复带上：

• •相同系统提示
• •相同工具定义
• •相同历史上下文

如果不做缓存和裁剪，这部分会非常浪费。

根据 OpenAI 2026 年 4 月 10 日公开定价页，GPT-5.4 系列标准处理价格大致为：

这张表当然值得看，但更重要的问题是：

• •哪些步骤真的需要大模型
• •哪些步骤其实只需 mini / nano
• •哪些请求根本不该进 agent loop

如果这些问题没想清楚，只看单价不会真正解决成本问题。

成本控制里最有效的动作之一，就是把不同任务送到不同成本层级的模型。

比较合理的默认分工通常是：

• •分类、提取、路由：nano
• •普通工具调用和草稿生成：mini
• •高复杂推理和关键决策：旗舰模型

这类路由不需要过度复杂，关键是把阶段拆清楚。

from langchain.chat_models import init_chat_model


cheap_model = init_chat_model("openai:gpt-5.4-nano")
fast_model = init_chat_model("openai:gpt-5.4-mini")
strong_model = init_chat_model("openai:gpt-5.4")


def select_model(stage: str):
    if stage in {"classify", "extract", "rank"}:
        return cheap_model
    if stage in {"tool_loop", "draft"}:
        return fast_model
    return strong_model

这个模式的重点不是“动态”，而是你能清楚解释为什么某一类步骤配某一档模型。

OpenAI 当前 prompt caching 文档对成本控制的意义非常大。它指出：

• •缓存会自动生效
• •对 1024 tokens 以上请求更有意义
• •最佳情况下输入成本可降低 90%
• •exact prefix match 是关键

这意味着，如果你的 Agent 请求里大量重复这些内容：

• •系统提示词
• •工具定义
• •固定 few-shot 示例
• •长期稳定的工作流说明

那你就应该有意识地把它们放在 prompt 前部，让动态内容尽量后置。

这件事既影响延迟，也直接影响账单。

很多 Agent 成本问题并不是“模型选贵了”，而是“每轮都在带一大坨历史”。

LangChain 当前 middleware 文档里的 SummarizationMiddleware 和 ContextEditingMiddleware，本质上都在解决这个问题：

• •该保留什么
• •该压缩什么
• •该删除什么

如果你不做这一步，prompt caching 命中再好，也会被不断膨胀的新上下文稀释掉收益。

所以成本控制和上下文治理其实是同一件事的两个面。

成本暴涨最常见的触发器，不是一次超贵调用，而是失控循环。

LangChain 当前 prebuilt middleware 里已经给了很实用的控制点：

• •ModelCallLimit
• •ToolCallLimit

这类限制的价值不只是省钱，还能防止异常路径下的 runaway loops。

也就是说，调用上限既是成本控制，也是可靠性控制。

OpenAI 当前定价页还提到 Batch API 可以为异步批处理任务提供 50% 的输入和输出成本折扣。

这类能力特别适合：

• •离线评估
• •大规模摘要
• •embedding / 索引预处理
• •批量内容清洗

不适合：

• •用户正在等待结果的在线交互

这条原则非常简单，但很有效：

能离线做的事，就别放到高实时主链路里烧在线模型预算。

如果只在月底看一次总花费，基本已经来不及优化了。更有用的监控方式，是把成本拆到：

• •按 workflow
• •按租户
• •按任务类型
• •按模型层级
• •按单次 trace

LangChain 当前 models 文档也提到 usage metadata callback，可以用来聚合 token 使用情况。这让你至少能回答：

• •哪条链路最费 token
• •哪类请求最容易超预算
• •哪个版本上线后成本突然升高

没有这些可观测性，成本控制通常只会停留在“感觉最近花得多”。

如果你现在要给 Agent 系统控成本，我建议先按这个顺序做：

• •把任务按阶段拆开，建立模型分层
• •把静态 prompt 前缀整理好，提升缓存命中
• •对长会话做 summarization / context editing
• •给模型和工具调用加上限
• •把离线任务挪到 batch 或后台处理
• •用 trace 和 usage metadata 持续追踪单位任务成本

这套顺序比“先把提示词砍短一点”更系统，也更容易在大流量下稳定生效。

Agent 成本控制最重要的不是单次省多少 token，而是把预算纳入系统设计：

• •用模型分层控制基础单价
• •用 prompt caching 降低重复前缀成本
• •用上下文治理防止成本随历史膨胀
• •用调用上限阻止异常循环
• •用 batch 和后台任务挪走非实时负载

只要把这些约束放进架构层，成本就不会只是一张账单，而会变成一个可管理、可优化的系统指标。

• •OpenAI API Pricing
• •OpenAI Prompt Caching
• •LangChain Models
• •LangChain Middleware Overview
• •LangChain Prebuilt Middleware