成本与性能工程

Agent 上线之后，最先炸的通常不是效果，是账单。一个回答得不错的 chatbot 每轮对话几千 token，一个能干活儿的 coding agent 一次任务动辄几十万甚至上百万 token——差距不是百分之几十，是一个到两个数量级。Gartner 2026 年 3 月的分析给出的量级是：agentic 任务每个任务消耗的 token 是普通 chatbot 的 5 到 30 倍；多步工具调用型 agent 的实测数据普遍落在 10-100 倍区间。

这一页讲清楚两件事：钱到底花在哪（token 经济学），以及怎么在不明显牺牲质量的前提下把它压下来（路由、缓存、上下文瘦身、延迟与限流工程）。它不是泛泛的"降本清单"，每一节都尽量给到可以直接抄的数字和代码。

价格时效性

文中所有单价以 2026 年 8 月核实的公开定价为准（Anthropic 官方定价页已逐一核对）。LLM 价格半年一变，引用前请以厂商官网为准。

一、Token 经济学：一次 Agent 任务的钱花在哪

为什么 Agent 是"平方级"烧钱

Chatbot 的成本模型是线性的：每轮输入 ≈ 系统提示 + 历史 + 用户消息，历史增长缓慢。Agent 的成本模型是近似平方的——这是很多人预算失控的根源。

Agent Loop（见 Agent Loop）的每一轮迭代，都要把到目前为止的完整轨迹重新发给模型：

第 1 轮输入: 系统提示 + 工具 schema + 任务
第 2 轮输入: 第 1 轮全部 + 模型输出1 + 工具结果1
第 3 轮输入: 第 2 轮全部 + 模型输出2 + 工具结果2
...
第 N 轮输入: 前面所有轮次的内容之和

如果每轮新增 Δ token（模型思考 + 工具返回），N 轮任务的总输入 token 约为 N × 初始上下文 + Δ × N(N+1)/2。轨迹累积项是 N² 级的。Augment Code 的分析用一个具体例子说明过这一点：一个 20 步的循环，实际消耗的 token 是"每步估算 × 20"这种线性算法的 10 倍以上。

一个量化的估算示例

假设一个典型的 coding agent 任务（修一个 bug）：

• 系统提示 + 工具 schema：3,000 token（工具 schema 本身就不便宜——Anthropic 官方文档披露，仅工具调用的内置系统提示就要额外增加 286-804 token，加上每个工具定义各自几百 token）
• 每轮模型输出（思考 + 工具调用）：约 500 token
• 每轮工具返回（读文件、跑测试的输出）：约 2,000 token
• 共 20 轮

总输入 token ≈ 20 × 3,000 + (500 + 2,000) × 20×21/2 = 60,000 + 525,000 = 585,000 token；总输出 ≈ 10,000 token。

按 Claude Sonnet 4.5 定价（输入 $3 / MTok，输出 $15 / MTok）：

• 输入：585k × $3/M = $1.76
• 输出：10k × $15/M = $0.15
• 单次任务合计 ≈ $1.9

作为对照：一次普通 chatbot 问答（2,000 输入 + 500 输出）约 $0.014。一个修 bug 任务贵了 130 多倍——而且它只修了"一个" bug。如果换成 Opus 4.5（$5/$25），输入部分是 $2.9，合计约 $3.2。

输出 token 才是单价杀手

输入输出价差通常是 5 倍（Sonnet 4.5：$3 vs $15）。长思考链、逐字重写整个文件而不是给 diff、啰嗦的最终总结，都是在按 5 倍单价烧钱。优化输出 token 的 ROI 经常高于优化输入。

成本结构拆解

把上面这笔账拆开，一次 Agent 任务的 token 消耗大致是四块：

组成部分	占比（典型值）	特征	主要优化手段
系统提示 + 工具 schema	每轮固定 3-10k	完全重复发送	prompt caching（近乎免费）
轨迹累积（历史轮次）	总量的 60-85%	N² 增长	上下文瘦身、子 agent 隔离
工具返回内容	增量的主要来源	大量冗余（日志、文件全文）	工具结果裁剪、掩码
模型输出	占总费用常超 30%	单价 5 倍	限制输出长度、diff 式编辑

结论先行：Agent 成本优化的主战场是"轨迹累积"和"工具返回"，不是系统提示。很多人花大力气精简 system prompt 省了几百 token，却让一次 npm test 的完整输出（8,000 token）原封不动进了上下文，每轮重复计费。

二、模型路由与分级：别让 Opus 干 Haiku 的活

分级是 Agent 系统的默认架构

单一模型打天下是最常见的浪费。成熟的做法是按任务难度分级：

                    ┌─────────────────┐
   规划 / 复杂推理 → │  旗舰模型        │  Opus 4.5 ($5/$25)
                    │  (Planner)      │  GPT-5 级
                    └─────────────────┘
                    ┌─────────────────┐
   执行 / 工具调用 → │  中端模型        │  Sonnet 4.5 ($3/$15)
                    │  (Executor)     │  性价比甜点
                    └─────────────────┘
                    ┌─────────────────┐
   分类 / 路由判断 → │  小模型          │  Haiku 4.5 ($1/$5)
   摘要 / 抽取       │  (Classifier)   │  GPT-4.1 nano ($0.10 级)
                    └─────────────────┘

价差是真实的：旗舰与中端输入价差约 1.7 倍，中端与小模型差 3 倍，旗舰与 nano 级差 50 倍。一个多 agent 系统里（见 多 Agent 架构），规划器每任务只调用几次，执行器和分类器调用几十上百次——把高频调用压到小模型上，账单结构立刻改观。

学到的路由：RouteLLM 与 FrugalGPT

静态分级（"这类任务固定用某模型"）之外，还有学到的动态路由——用一个训练过的分类器预测"这条查询需要强模型还是弱模型就够"：

• RouteLLM（LMSYS / UC Berkeley，arXiv 2406.18665，ICLR 2025）：用 Chatbot Arena 偏好数据训练四种路由器（相似度加权、矩阵分解、BERT、causal LLM）。论文报告在 MT-Bench 上成本降低超过 85%，同时保持约 95% 的 GPT-4 级质量；数据增强后矩阵分解路由器只把 14% 的调用发给强模型。
• FrugalGPT（Stanford，2023）：LLM 级联（cascade）——先用最便宜的模型，质量校验不过再逐级升级，在其 HEADLINES 等基准上报告最高 98% 的成本削减。

对 85%-98% 这类数字保持警惕

这些头条数字是数据集特定的。2026 年多个独立复测（混合真实生产流量）的诚实结论是：路由器的现实收益约 20-35% 的成本节省、质量损失控制在 2% 以内，部分商业路由器在混合流量上甚至跑不赢基线。把 RouteLLM 的论文数字当成上限，不要当成你的预期收益。路由真正的价值在 agent 系统内部——规划和执行分离这种结构性分级，收益比"给 chatbot 流量加个分类器"扎实得多。

路由策略的质量权衡

1. 先分级，后路由：结构性分级（规划/执行/分类用不同模型）是架构决策，不需要训练，收益可预期。动态路由是优化项，需要评估数据支撑。
2. 路由判断本身要便宜：用一个 $0.10/M 的分类器去决定发 $3/M 还是 $5/M 的模型是划算的；用一个 $1/M 的模型去路由就不一定了。
3. 错误路由的代价不对称：把难任务错发给小模型，代价是任务失败、整段轨迹作废重跑——比省下的钱贵得多。路由器应当偏向升级（拿不准就用强模型）。
4. 必须有 eval 兜底：路由策略上线前，用自己的任务分布跑一次离线评估（方法见 评估体系），确认质量损失可接受，再谈节省。

一个最小可用的 Python 路由示例（2026 年现行 API）：

from anthropic import Anthropic

client = Anthropic()

# 分级模型表：按角色而不是按心情选模型
MODELS = {
    "planner":    "claude-opus-4-5",      # 规划：旗舰
    "executor":   "claude-sonnet-4-5",    # 执行：甜点模型
    "classifier": "claude-haiku-4-5",     # 分类/摘要：小模型
}

def call(role: str, messages: list, **kwargs):
    return client.messages.create(
        model=MODELS[role],
        max_tokens=kwargs.pop("max_tokens", 4096),
        messages=messages,
        **kwargs,
    )

# 例：用小模型判断任务难度，难任务才升级到旗舰
def route_task(task: str) -> str:
    resp = call("classifier", [{
        "role": "user",
        "content": f"判断任务难度，只回答 simple 或 hard：{task}"
    }], max_tokens=10)
    return "planner" if resp.content[0].text.strip() == "hard" else "executor"

三、缓存：Agent 系统的免费午餐（至少是第一份）

Prompt caching：机制与真实定价

Prompt caching 是 Agent 场景 ROI 最高的优化，没有之一。它的原理是把已处理过的 prompt 前缀的注意力状态缓存起来，下次请求前缀命中时按折扣价计费——而 Agent Loop 每轮重发的"系统提示 + 历史轨迹"恰好天然是前缀结构。

2026 年 8 月核实的主要厂商机制：

厂商	启用方式	TTL	缓存写入	缓存读取
Anthropic	显式 cache_control 断点（或顶层自动缓存）	5 分钟 / 1 小时	1.25x（5 分钟）/ 2x（1 小时）基础输入价	0.1x（打 1 折）
OpenAI	自动，前缀 ≥ 1024 token	约 5-10 分钟	无写入费	0.5x（5 折）
Google Gemini	显式 context caching API	1 分钟 - 24 小时可配	按存储时长计费	约 0.25x
DeepSeek 等	通常自动	各异	—	通常 0.1-0.2x

Anthropic 的账很好算：5 分钟缓存写入 1.25x、读取 0.1x——命中一次就回本；1 小时缓存写入 2x，命中两次回本。Agent Loop 每轮都在上一轮基础上追加，前缀几乎必然命中，所以 caching 对 agent 不是"优化"，是"必须开"。

回到第一节的估算：585k 输入 token 中，假设首轮写入后 80% 的后续输入以 0.1x 命中：

• 无缓存输入费：$1.76
• 有缓存：写入 ≈ 585k×20%×$3×1.25/M ≈ $0.44，读取 ≈ 585k×80%×$0.3/M ≈ $0.14，合计 ≈ $0.58，省 67%

代码上只需在稳定前缀的末尾打一个断点：

resp = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=4096,
    system=[
        {
            "type": "text",
            "text": LONG_SYSTEM_PROMPT,      # 系统提示放最前，最稳定
            "cache_control": {"type": "ephemeral"},  # 缓存断点
        }
    ],
    tools=TOOLS,       # 工具 schema 也在前缀里，随系统提示一起被缓存
    messages=history,  # 轨迹逐轮追加，前缀结构天然命中
)

工程上的关键约束：

• 前缀顺序决定命中率：系统提示、工具定义、稳定文档必须放在最前且逐字节不变；时间戳、随机 ID 这类每轮都变的东西绝不能出现在前缀里。
• TTL 与心跳：Anthropic 5 分钟缓存在 Agent 长任务中途停顿（比如等用户确认）时会过期，1 小时缓存（写入 2x）适合这种人机交互场景，命中两次即回本。
• 缓存指标要监控：响应里的 cache_read_input_tokens / cache_creation_input_tokens 字段直接告诉你命中率，掉命中率通常意味着有人往系统提示里塞了动态内容。

KV cache 与语义缓存

• KV cache：推理引擎层面（vLLM、SGLang 等自托管场景）对前缀的注意力 KV 做复用。用 API 时你碰不到它，但自托管开源模型时，prefix caching / RadixAttention 能把多 agent 共享系统提示的首 token 延迟和算力砍掉大半——这是自托管方案里最重要的吞吐优化。
• 语义缓存：query 级别缓存——把历史查询做 embedding，新查询与历史相似度超过阈值就直接返回缓存答案。对 FAQ 型 agent 效果显著；对 coding/research 型 agent 几乎没用（查询几乎不重复），别乱用。注意语义缓存有"答非所问"的精度风险，阈值要靠 eval 调。

四、上下文瘦身即省钱

上下文工程（见 上下文工程）的每一条技巧同时都是成本优化——token 就是钱。按 ROI 排序：

1. 工具结果裁剪：最大的单一节省来源。grep 返回 200 行只取命中上下文 ±5 行；测试输出只保留失败摘要；文件读取按行号窗口而不是全文。一个原则：工具返回给模型的应该是"结论"，不是"原始数据"。
2. 轨迹压缩（compaction）：接近 context window 上限时，把早期轨迹用小模型压成结构化摘要（保留文件路径、错误历史、已做决策、待办），丢弃原文。Claude Code 等产品的 auto-compact 就是这个机制（见 Claude Code 解剖）。
3. 观察掩码（observation masking）：保留工具调用记录但把旧的工具返回替换成占位符（[输出已省略]），模型知道"这里查过什么"但不再为旧输出付 token。
4. 子 agent 隔离：搜索、探索类的脏活派给子 agent，主 agent 只接收最终结论。子 agent 的几十轮轨迹不进主上下文——这是多 agent 架构最容易被低估的成本收益。
5. diff 式文件编辑：让模型输出编辑块而不是重写全文，既省输出 token（5 倍单价）又省下一轮重新读文件的输入 token。

瘦身是有质量代价的，要测量

裁剪和压缩都会丢信息，丢错了就是任务失败。正确姿势：把上下文策略当成超参数，纳入你的 eval 集回归测试（见 评估落地）。"省 40% token、成功率降 8 个点"通常是不划算的交易；"省 40% token、成功率不变"才是。

五、延迟工程：用户等的不只是钱

成本之外，Agent 的第二个工程瓶颈是延迟——20 轮串行的 LLM 调用，每轮 5-15 秒，用户要等好几分钟。手段按实施难度排序：

TTFT 与流式输出

• **TTFT（time to first token）**是用户感知延迟的决定性指标。缩短 TTFT 的手段：缩短输入前缀（又是上下文瘦身）、开 prompt caching（命中缓存的前缀跳过 prefill，Anthropic 官方称可降低长提示的 TTFT 最多 85%）、用更小的模型。
• **流式输出（streaming）**几乎不花工程成本，却是体感提升最大的一招：把模型的思考过程和中间结论实时推给用户，30 秒的任务体感变成 5 秒。所有主流 SDK 的 streaming 都是一行参数的事，没有理由不开。

并行工具调用

Agent Loop 默认是串行的：思考 → 调用一个工具 → 等结果 → 再思考。但很多工具调用之间没有依赖（读三个文件、搜两个关键词），可以一轮内并行发出。主流模型都支持一次响应返回多个 tool_use 块，客户端并行执行后一起回填：

import concurrent.futures

# 模型一轮返回多个 tool_use 块时，并行执行而不是 for 循环串行
def execute_tool_calls(tool_uses: list) -> list:
    with concurrent.futures.ThreadPoolExecutor(max_workers=8) as pool:
        futures = {pool.submit(run_tool, tu.name, tu.input): tu for tu in tool_uses}
        results = []
        for future in concurrent.futures.as_completed(futures):
            tu = futures[future]
            results.append({
                "type": "tool_result",
                "tool_use_id": tu.id,
                "content": future.result(),
            })
    return results

对 I/O 型工具（HTTP、数据库、文件），线程池就够；I/O 等待期间的并行度收益通常是 3-5 倍。

推测执行（speculative execution）

两个层面：

• 推理层：speculative decoding（小模型起草、大模型验证）是自托管推理引擎的加速技术，API 用户用不到，但选推理服务商时可以问一句。
• Agent 层：更实用的思路是推测性预取——模型大概率下一步要读某个文件？在等模型响应的同时就把文件读好。以及投机性分支：对耗时操作提前并行尝试最可能的两个分支，模型选定后丢弃另一个。烧少量 token 换延迟，在交互式场景里经常是划算交易。

延迟和成本经常是同一件事

减少轮数、缩小上下文、并行化工具——这些手段同时降成本和降延迟。唯一真正冲突的是路由到小模型（省钱但可能更慢更容易失败）和长思考链（更贵更慢但更准）。工程上要明确你这个产品优化的是哪个目标函数。

六、并发与限流：Rate Limit 下的吞吐设计

生产环境的 API 不是无限水管。Anthropic 按用量层级（Build/Scale 等）限制 RPM（requests per minute）和 TPM（tokens per minute），OpenAI 类似。Agent 系统又特别能吃限流——一个任务 20 轮，100 个并发任务就是短时间 2000 个请求、上亿 token。设计要点：

1. 客户端令牌桶 + 队列：不要裸发请求让 API 端拒绝你。在网关层实现 token bucket（按 TPM 而不是 RPM 计量——Agent 请求的大小差异太大，按请求数限流会失控），超出的任务排队。队列里要带上任务的优先级：交互式用户请求优先，批处理任务让路。
2. 指数退避 + 抖动：429 和 529（过载）是常态，必须重试。标准做法：指数退避（1s、2s、4s……上限 60s）加随机抖动，重试 5-8 次后放弃并把任务标记为可恢复。Agent 的重试比 chatbot 安全——只要工具调用是幂等的，从断点继续就行。
3. 断点恢复：Agent 任务中途被限流打断不等于失败。把轨迹持久化（checkpoint），恢复后从最后一轮继续，而不是整个任务重跑——重跑意味着前面 50 万 token 白烧。这也是 可靠性设计 里反复强调的一点。
4. 批处理走 Batch API：非实时任务（评测、数据标注、夜间批处理）用 Anthropic / OpenAI 的 Batch API，统一 5 折，且不占用实时限流配额。这是最容易被忽视的半价渠道。
5. 多 provider 兜底：主 provider 限流时降级到备用 provider 或更小模型。路由层（第二节）天然适合挂这个逻辑。

七、成本观测与预算告警

不能测量的成本不能优化。最低要求是把每次 LLM 调用的 token 与成本归到 trace 级别（一次任务 = 一个 trace，每轮调用 = 一个 span），然后按任务类型、用户、模型维度聚合。这部分与 可观测性 共用同一套埋点，只是聚合维度换成钱。

落地选项（2026 年现状）：

• Langfuse（开源、可自托管）：每次调用自动记录 token 用量并按模型价目表折算成本，支持按 trace/user/session 聚合；Monitors 功能（2026 年中仍处于 beta）支持成本、延迟、评分的阈值告警，可路由到 Slack/webhook。
• LangSmith：LangChain 生态内 tracing + 成本追踪，托管省心。
• LiteLLM Proxy：作为统一网关时自动记录每次调用的成本，并支持按 API key 设预算上限（max budget）——这是最直接的"硬闸门"。
• 自建：响应里的 usage 字段（input/output/cache_read/cache_creation token 数）乘以你的价目表入库即可，几十行代码的事。

预算告警的最小实践：

1. 三道闸门：每小时成本突增告警（比如超过过去 7 天同时段均值 3 倍）、每日预算软上限（告警）、每月硬上限（网关层直接拒绝或降级到小模型）。
2. 按任务类型归因：发现"80% 的成本来自 5% 的任务类型"是常态——通常是某个重试循环失控或某个工具返回了巨型输出。没有 trace 级归因你根本找不到它。
3. 单次任务成本设上限：在 Agent Loop 里内置 max_cost_per_task，累计成本超限时强制走 compaction + 小模型收尾，或者干脆终止并返回部分结果。失控循环烧掉几百美元的故事在社区里每月都有。

八、案例：一次真实任务的成本优化前后

场景：一个代码审查 agent，对一次 PR 做全量审查。以下数字是估算，假设如下（引用前请按你的实际分布重测）：

• 任务规模：平均 25 轮 Agent Loop，每轮模型输出 600 token，工具平均返回 3,000 token（diff、文件片段、lint 输出）
• 模型：优化前全程 Claude Opus 4.5（$5/$25）；无缓存；工具结果不裁剪
• 优化后：规划用 Opus 4.5、执行用 Sonnet 4.5（$3/$15）、摘要分类用 Haiku 4.5（$1/$5）；开 prompt caching；工具输出裁剪 60%；Batch 处理夜间批量审查

优化前：

• 输入 ≈ 25×5,000（系统+schema）+ 3,600×25×26/2 ≈ 125k + 1,170k ≈ 1.3M token，全按 Opus 输入价：$6.5
• 输出 ≈ 15k × $25/M = $0.38
• 单任务 ≈ $6.9，一天 200 个 PR = $1,380/天

优化后（逐条对应前面各节）：

措施	效果	节省
工具结果裁剪 60%（第四节）	轨迹增量从 3,600 → 1,440/轮，总输入降到约 550k	-58% 输入量
prompt caching（第三节）	剩余输入约 75% 以 0.1x 命中	输入费再降约 65%
模型分级（第二节）	仅 3 轮规划用 Opus，22 轮执行用 Sonnet，摘要 2 次用 Haiku	混合输入单价降约 35%
50% 夜间任务走 Batch（第六节）	这部分再 5 折	总量再降 25%

粗算：优化后单任务 ≈ $0.6-0.8，总成本降到原来的约 10%，延迟还降了一半（并行工具 + 缓存命中减 TTFT）。质量代价：内部 eval 上审查问题召回率从 91% 降到 88%，团队判定可接受——这个权衡是测量出来的，不是拍脑袋。

这个案例没有用到任何黑科技，就是前面七节的组合拳。Agent 成本工程的现状就是这样：手段都是已知的，差距全在执行——裁剪做了没有、缓存命中率监控了没有、路由有没有 eval 兜底。

参考资料

• Anthropic 官方定价页（docs.anthropic.com） —— 本文全部 Claude 单价、缓存倍率（写入 1.25x/2x、读取 0.1x）、Batch 5 折、工具 token 开销的一手来源，2026-08 核实。
• RouteLLM: Learning to Route LLMs with Preference Data（arXiv 2406.18665） —— LMSYS/Berkeley 的路由论文，ICLR 2025 接收，85% 成本削减声明的原始出处。
• The honest guide to LLM routing —— 对各路由方案头条数字的独立复核，指出混合流量下现实收益约 20-25%。
• Prompt caching complete guide 2026 —— Anthropic/OpenAI/Gemini 缓存机制与 TTL 对比。
• The Bill Arrives: How to Manage Agentic AI Costs at Scale（Cockroach Labs） —— 引用 Gartner 2026-03 分析：agentic 任务 token 消耗为 chatbot 的 5-30 倍。
• Why AI Agents Can Cost 50x More Than Expected（Larridin） —— 轨迹累积导致 token 平方级增长的分析，含 Augment Code 的 20 步循环案例。
• Langfuse Token & Cost Tracking 文档 —— trace 级成本追踪与告警的实现参考。