将分类器迁移到 Claude Haiku 5.5：有哪些变化

Towards AI - Medium 2026-10-28T21:55:11.004109

2026 年 10 月 7 日，Anthropic 发布了 Claude Haiku 5.5。它悄悄改坏了高吞吐流水线普遍依赖的三样东西：手动思考预算（thinking budget）、assistant 消息预填充（prefill），以及分类代码长期倚重的采样参数。这些都没写进标题。标题是价格：prompt 在 100k 以内时，每百万输入 token 只要 $0.10，而 Haiku 4.5 是 $1 [1][2]。但如果你跑着一条路由或分类流水线，只把模型字符串一换，那么在你拿到省钱效果之前，先等着的是一屏 400 报错。把分类流水线从 Claude Haiku 4.5 迁到 Haiku 5.5，意味着先修好这些破坏性变更，才谈得上降价。这是一篇迁移指南，不是发布回顾。它会讲清楚：把分类或路由流水线从 Haiku 4.5 迁走时，到底哪些地方会坏、每个问题怎么修，以及迁移完成后成本和延迟算下来是什么样。

本文内容：

Haiku 5.5 对高吞吐流水线到底改了什么

Haiku 5.5 的定位正是分类和路由流水线干的活：摘要、上下文压缩（compaction）、数据库查询、大批量分类；需要时可以挂在更大的模型下面当子代理（subagent）跑 [1]。上下文窗口从 200k 涨到 1M token，最大输出从 64k 提到 128k [3]。训练数据截止到 2026 年 6 月 [4]。

对一次迁移来说，这两个数字都不是重点。重点是分词器（tokenizer）。Haiku 5.5 用的是和 Claude 4.7 及之后版本相同的新分词器，同样的文本产生的 token 数比在 Haiku 4.5 上大约多 30% [3]。这一点很关键，因为计价按 prompt 长度分层：prompt 不超过 100k 时，每百万 token 输入 $0.10、输出 $0.50；超过之后涨到 $0.50 和 $2.50 [2]。

Anthropic 自己在脚注里写明：请求在 10 万 token 以下时，Haiku 5.5 比 Haiku 4.5 便宜约 90%；超过 10 万 token 则便宜约 50%。如果把分词器膨胀算进去，混合平均下来的折扣接近 75% [1]。如果你的分类提示词都很短（一张工单、一行日志、一个路由判断），那基本不会碰到 10 万 token 这道线，能拿满折扣。我早先写过一篇按工作量选模型档次的文章，那时 Haiku 5.5 还没发布；方法论仍然成立，里面的数字已经过时了。

Haiku 4.5 与 Haiku 5.5 对照：上下文窗口、价格、最小可缓存提示词长度。

Anthropic 的基准表用客户数据而不只是合成分数来支撑这个说法：Box 报告其分类得分比 Haiku 4.5 高 11 分，延迟大约只有一半；Asana 在现有工作负载上测得任务补全延迟下降 30% [1]。这些都是厂商自报的数据，没有第三方审计，所以只能当作方向性参考，不代表你自己的数据上一定如此。

首先要修复的破坏性变更

典型的分类或路由流水线里，有四处地方在 Haiku 5.5 上会直接返回 400 错误——你什么都不用改，旧语法本身就会被拒绝 [5]。

第一，手动扩展思考。thinking: {"type": "enabled", "budget_tokens": N} 不再可用。现在要写 thinking: {"type": "adaptive"}，思考深度改由单独的 effort 参数控制，不再用 token 预算 [3][5]。

第二，采样参数。temperature、top_p、top_k 在多数取值上会被直接拒绝；如果仍然传 temperature，它必须等于 1，而且同时传 temperature 和 top_p 时，无论值是多少都会失败 [5]。对那些用 temperature: 0 让标签更稳定的分类器来说，这条才是真正需要重新想方案的变化——你已经没法靠调低温度来减小标签波动了。改为在代码里校验输出，并且把模型当成概率性的东西来对待，哪怕在边缘情况下也是如此。

第三，assistant 消息预填充（prefill）。

如果你的路由代码通过在 messages 数组末尾放一个不完整的 assistant 回合来强制响应格式（一种常见技巧，目的是让模型把标签作为第一个 token 输出），Haiku 5.5 会直接拒绝。请求必须以 user 回合结尾 [3][5]。第四点很容易被忽略：之前每个 assistant 回合的 thinking 块现在都会留在上下文中，并计入输入 token；Haiku 4.5 只保留最近一个回合的 thinking 块 [3]。在多轮路由对话中，这会以前所未有的方式叠加 token 用量。我在另一篇关于 agent 循环经济学的文章里讨论过为什么这些单次调用成本比标价更重要，而 thinking 块累积正是那篇文章警告过的那种隐藏乘数。

迁移中最常见的 400 错误：把 budget_tokens 换成自适应 thinking 加 effort。

用工具调用替代基于 prefill 的标签

如果之前是用 prefill 强制流水线输出类别标签，替代方案是定义一个带枚举值的分类工具，并用 tool_choice: {"type": "auto"} 调用，而不是强制选择 [5]。最后这个细节比看起来更重要：用 tool_choice: "any" 或指定具体工具来强制调用，会完全抑制 thinking 块。所以如果你想让模型先推理再给出标签，auto 工具选择加提示词指令是唯一能两者兼得的方式 [3]。

{
  "model": "claude-haiku-5-5",
  "max_tokens": 2000,
  "output_config": { "effort": "low" },
  "tools": [{
    "name": "classify",
    "description": "Record the category for this ticket.",
    "input_schema": {
      "type": "object",
      "properties": {
        "label": {
          "type": "string",
          "enum": ["billing", "technical", "account", "other"]
        }
      },
      "required": ["label"]
    }
  }],
  "tool_choice": { "type": "auto" }
}

这就是我在之前一篇讲如何让 API 真正遵守 schema 的文章里详细展开过的结构化输出模式，底层方法在 Haiku 5.5 上没有任何变化。变了的是：对于这个模型，无论是通过 output_config.format 还是严格工具，结构化输出在 Amazon Bedrock 上都不可用 [5]。

如果你的路由流水线跑在 Bedrock 上，那就得回到老办法：在提示词里描述 schema，用一个非严格的工具，再在代码里校验结果。如果你之前在 Bedrock 上已经统一用严格模式，这就是一次实实在在的退步。

处理拒绝响应、effort 参数，以及 Bedrock 结构化输出的缺口

Haiku 5.5 会运行安全分类器，有可能直接拒掉某个请求。和早期一些模型不同，它没有服务端兜底重试机制 [3]。对生产环境的分类流水线来说，这意味着 stop_reason: "refusal" 现在是一条必须显式处理的代码路径，而不是可以忽略的边缘情况：把被拒绝的条目转人工复核，或者给一个默认标签，别让流水线悄悄把它们丢掉。我之前写过生产级 agent 流水线在出事之前应该记录哪些日志；没有兜底的拒绝，正是那篇文章说的那种失败模式——你得在它大面积发生之前就能看见，而不是等事后才发现。

effort 参数是另一个值得主动调节、而不是放着用默认值的杠杆。它拿智能程度去换成本和延迟，这也是 Haiku 级别模型第一次开放这个旋钮 [1]。对于简单的路由判断，把 effort 调低，成本和延迟都能压下来；对于更难、准确性比速度更重要的分类调用，升到 medium 或 high 只是改一行的事，不用换模型。这里没有放之四海皆准的答案，只有一个值得拿你自己的标签准确率去实测的取舍。

Haiku 5.5 最抢眼的数字：提示词在 100K token 以内时，输入 token 的标价下调 90%。动手之前还有一点要提醒：可缓存提示词的最小长度从 4,096 token 降到了 512 [3]。对那些以前根本吃不到提示词缓存好处的短分类提示词来说，这是一个实实在在的好处，虽然算不上大。它不会改变你的架构，但这是你之前没拿到手的白捡的钱。

切换之前，先算清成本和延迟这笔账

下面是一个演算示例。不是真实客户的数据，只是把算式摆出来，方便你套自己的数字。

这样一条路由流水线，如果每月在 Haiku 4.5 上处理 5000 万输入 token 和 500 万输出 token，按每百万 token 统一 1 美元和 5 美元计算，就是 50×1 + 5×5 = 75 美元/月。同样这批文本换成 Haiku 5.5 的分词器（tokenizer），token 数大约会涨 30%，于是变成 6500 万输入 token 和 650 万输出 token。只要单次请求不超过 10 万 token 的门槛——短小的路由提示词通常都不会超——价格就是每百万 0.10 美元和 0.50 美元：65×0.10 + 6.5×0.50 = 9.75 美元/月。对这类特定形态的负载来说，成本降了 87%，比 Anthropic 自己给出的混合口径「平均便宜约 75%」还要好一些，因为这类短提示词的小规模分类任务正好落在最便宜的价格档位。

如果流水线经常发送较长的提示词、接近或超过 10 万 token，结果就会更接近那个「便宜约 50%」的数字。所以在预估节省金额之前，先按自己的提示词长度分布算一遍。延迟很难只凭厂商给的数字一概而论，但 Anthropic 公布的客户结果方向是一致的：不仅更便宜，而且全面更快。如果你的流水线对延迟敏感（比如客服队列里的实时路由），最好用自己的真实流量验证，而不是照搬基准测试表格。

对 stop_reason: "refusal" 要显式处理：把它转入人工审核，而不是让流水线直接丢掉。不过这些都不是盲目迁移的理由。如果你跑在 Bedrock 上，并且依赖严格的结构化输出，那这个差距是真实存在的，需要和降价一起权衡。如果你的流水线靠 prefill 强制指定标签，就要留出时间把这条路径正经重写，而不是绕着 400 错误打补丁。但如果只是跑在 Claude API 或 Google Cloud 上、做简单的分类或路由任务，提示词短、又不硬依赖强制采样，那迁移清单很短，省下的钱也不是纸上谈兵。

参考资料

如果你喜欢这篇文章，想表示支持，可以：

把分类器迁移到 Claude Haiku 5.5：有哪些变化最初发表在 Medium 的 Towards AI 上，读者们正在那里继续讨论、重点标注并回应这个故事。

查看原文