AI 智能体的成本算账：Haiku 何时胜过 Sonnet（何时不行）

目录

2026 年 6 月更新。

摘要： 选择 Claude Haiku 而非 Sonnet 可以把每次调用的成本削减一个数量级，但前提是任务能容忍 Haiku 更低的成功率。真正要紧的指标是每个成功结果的成本——调用成本加上重试再加上人工善后——而不是每个 token 的标价。我按任务路由，需要判断的环节留给 Sonnet，而相当一部分高频环节跑在 Haiku 上。

运营者视角： 我运行着 100 多个智能体，推理是一笔实打实的开支。但我见过一些团队把所有东西硬塞进最便宜的模型来”省钱”，然后在重试、升级和愤怒的客户身上把成本吃了回去。成本算账只有在你衡量整个漏斗时才成立。

最便宜的模型并不是每 token 单价最低的那个。而是把活儿做对所需总成本最低的那个。这是两个不同的数字，而它们之间的差距，正是大多数智能体成本决策出错的地方。

token 经济学，直说

Anthropic 按每百万 token 对 Claude 计费，输入和输出分开计费，输出的成本是输入的数倍。确切数字会随时间变动，所以请查阅 Anthropic 当前的定价——但驱动决策的是结构：

• Haiku 是廉价、快速的档位——在整个家族中每 token 成本最低，且优势明显。
• Sonnet 居中——明显比 Haiku 贵，明显比 Opus 便宜。
• Opus 是面向最难推理的高端档位。

由此引出两点。第一，在生成类任务中，输出 token 主导成本，所以一个啰嗦的模型即便单价相同也更贵。第二，Haiku 与 Sonnet 之间的每 token 价差足够大，以至于在高频环节上一定会反映到账单上。这是支持 Haiku 的理由。下面是反对的理由。

真正要紧的指标：每个成功结果的成本

每次调用的成本是个面子数字。这是我真正使用的公式：

每成功成本 = (调用成本 × 尝试次数) + 善后成本
            ÷ 成功率

其中 尝试次数 计入重试，善后成本 是由人来修复那些漏网失败的预期成本。看看这对比较起了什么作用。

假设 Haiku 每次调用的成本大约是 Sonnet 的十分之一。如果在某个任务上 Haiku 有 80% 成功、Sonnet 有 98% 成功，每次调用的节省看起来巨大。但如果 Haiku 的每次失败都触发一次重试，且每 10 次仍有 1 次需要一个花真金白银的人，善后这一项就可能吞掉 token 上的节省。在低风险、高频的任务上，算账压倒性地有利于 Haiku。在一个失败就会给错误客户发邮件的任务上，结论可能完全反转。

不衡量每个模型的成功率，你就无法做这个决定——而这正是评估框架所提供的。用同一套评估集分别跑两个模型，在同一把尺子上读出成功率。

Haiku 决定性胜出之处

当任务狭窄、结构化且可验证时，Haiku 是正确选择：

• 分类与路由——“这条进来的消息是预订、投诉还是垃圾信息？“三个桶，易于验证，持续运行。整天用 Haiku。
• 带模式的抽取——从文本中拉出一个日期、一个名字、一个金额，用 Zod 校验。如果输出能解析，几乎可以肯定是对的。
• 短改写与格式化——语气微调、对已知良好的输入做摘要、归一化数据。
• 首轮过滤——Haiku 做分诊，只有模糊的情形才升级到 Sonnet。这是杠杆率最高的模式。

共同的脉络：Haiku 出错的代价低，且错误便于发现。当验证便宜、风险低时，便宜的模型胜出。

Sonnet 值回票价之处

当任务开放式、多步骤，或出错代价高昂时，Sonnet（有时是 Opus）才值得：

• 多工具智能体循环，其中一次错误的工具调用会层层级联。更高的推理可靠性会跨步骤累积——我在多智能体编排中讲到的编排模式，正依赖于模型不丢失思路。
• 面向客户的生成，其中一次糟糕的输出损失的是信任，而不只是一次重试。
• 任何验证本身就困难的场景。 如果你无法廉价地判断输出是否正确，你就承担不起一个经常出错的模型。

这里的失败不止一次重试的代价——它的代价是退款、流失的客户，或我的时间。相比之下，每 token 的溢价只是舍入误差。

我真正上线的路由规则

我不会为每个智能体选定一个模型。我在智能体内部按任务路由，通常由一个廉价的分类器决定由哪个下游模型来处理：

function pickModel(task: Task): string {
  // 廉价、可验证、高频 → Haiku
  if (task.type === "classify" || task.type === "extract") {
    return "claude-haiku";
  }
  // 开放式或面向客户 → Sonnet
  if (task.customerFacing || task.steps > 2) {
    return "claude-sonnet";
  }
  return "claude-sonnet"; // 默认采用安全选项
}

这里编码了两条原则。默认选用安全的模型，而非便宜的——你是从一个可用的基线向下优化成本，而不是从一个破损的基线向上优化可靠性。以及升级，别赌：让 Haiku 处理容易的 80%，把困难的 20% 交给 Sonnet。这种混合方案几乎总是胜过把所有东西单独跑在任一模型上。

此外还有提示缓存可以叠加：如果你的系统提示很大且会被重复使用，缓存会在不分档位的情况下大幅削减输入成本，这有时会让 Sonnet 便宜到使 Haiku 的取舍变得无关紧要。

来自我自己技术栈的一个实例

以一个高频的进站分诊环节为例。它运行成千上万次，任务是三分类，漏判也只是让条目落入一个审核队列——便于发现、风险低。这是教科书式的 Haiku 任务，把它从 Sonnet 上挪走，在不对要紧结果造成可测量影响的前提下，明显降低了该环节的成本。

再看一个起草真正回复客户内容的环节。频率较低、开放式，而一份糟糕的草稿发出去损失的是信任。这一环节留在 Sonnet 上。同一个智能体，两个模型，按风险路由。我会盯着两者的每次运行成本和成功指标，方式如我在我如何衡量一个 AI 智能体是否真的在起作用中所述——而且只有在评估表明更便宜的模型能保住成功率之后，我才会把某个环节降一档。

常见问题

在实践中 Claude Haiku 总是比 Sonnet 便宜吗？

按 token 算，是的——而且差距很大。按每个成功结果算，则不总是。如果 Haiku 较低的成功率触发了重试和人工善后，在那些错误难以发现或修复的任务上，总成本可能超过 Sonnet。

对于某个给定任务，我该如何在 Haiku 和 Sonnet 之间抉择？

从两个维度给任务打分：输出有多可验证，以及一次错误有多昂贵。验证便宜、低风险、高频的工作交给 Haiku；开放式、面向客户或难以验证的工作交给 Sonnet。按任务路由，而非按智能体。

我应该追踪的唯一成本指标是什么？

每个成功结果的成本——调用成本乘以尝试次数加上预期善后成本，再除以成功率。单看每次调用的价格会掩盖重试和人力时间，而那正是廉价模型悄悄变贵的地方。

我能在一个智能体里同时用两个模型吗？

可以，而且通常你应该这么做。最强的模式是一次廉价的首轮处理（Haiku 做分类或过滤），只把模糊的情形升级到 Sonnet。这种混合方案通常胜过把所有东西跑在单一档位上。