目录 · 5 个章节
最近 Anthropic 发了 Claude Haiku 5.5（模型 ID claude-haiku-5-5，2026 年 10 月 7 日发布）。我们 Node 后端里不少分类、抽取、摘要的活一直跑在小模型上，所以认真看了下官方成绩单，分享几点自己的理解。先说明：下面数字全部来自 Anthropic 发布页，不是第三方实测。
一、和上一代比，是代际级提升
- GDPval-AA v2.1（知识工作）：735 → 1620，约 2.2 倍
- AA-Briefcase v1.1：614 → 1578，约 2.6 倍
- OSWorld 2.1（电脑操作）：15.7% → 72.4%
- Terminal-Bench 4.0（Agent 编程）：0.0% → 39.2%
OSWorld 和 Terminal-Bench 都是长链条任务：理解任务、调用工具、处理反馈、出错后继续。这类提升意味着小模型不再只适合做短分类和摘要。
二、离 Sonnet 很近，但层级没有抹平
| 项目 | Haiku 5.5 | Sonnet 5.5 |
|---|---|---|
| OSWorld 2.1 | 72.4% | 83.9% |
| HLE 无工具 | 45.9% | 56.9% |
| HLE 使用工具 | 57.4% | 64.5% |
| Terminal-Bench 4.0 | 39.2% | 70.6% |
Terminal-Bench 这一项差距最值得注意。跨文件修改、长程规划、反复从错误中恢复的活，还是交给 Sonnet 更稳。另外官方表里它在同列项目上超过了 GPT-6 Luna，但这是厂商自己的对照表，别外推到没测过的任务。
三、价格：真正该算的是"单位成功任务成本"
100K tokens 以内：输入 $0.10 / MTok，输出 $0.50 / MTok，缓存读 $0.01；超过 100K 变成 $0.50 / $2.50 / $0.05。标价比 Haiku 4.5 降了 90%，但新 tokenizer 同样任务会多用一点 token，官方说平均运行成本降约 75%。
单位成功任务成本 = 完成任务的总花费 ÷ 成功完成的任务数
如果一次调用要重试两次，或者有一部分请求最后还是升级给 Sonnet，省下的钱就没价签上那么多。反过来，能自动校验、失败重试便宜的任务，Haiku 5.5 的经济优势非常明显。
四、100K 边界会影响架构
与其把整个代码库或知识库塞进一个请求，更合理的是分层：
- 先用 Haiku 做文档分类和相关性过滤
- 把原始材料压成结构化摘要
- 只把相关片段交给大模型
- 重复上下文走缓存
- 多轮对话存成可检索状态，不每次重发全量
另外 Haiku 5.5 是第一个支持可调 effort 的 Haiku。简单任务（分类、格式转换、固定字段抽取）用低 effort，长文摘要、多步浏览器操作调高。但调高 effort 也补不上 Terminal-Bench 那种规划和工具链差距。
五、一张初版路由表
- 分类 / 路由 / 打标签、字段抽取、摘要与上下文压缩、短浏览器流程 → Haiku 5.5
- 普通代码解释、小修 → Haiku 或 Sonnet，看有没有自动化测试和出错代价
- 多文件修改 → Sonnet 5.5
- 长时间 Agent 编程、最终审核与高风险判断 → Sonnet 或 Opus 5.5
我的结论：Haiku 5.5 的"强"不在于赢了谁，而在于它可以被大量使用，把以前用中型模型又嫌贵的一批活挪到更快更便宜的执行层。
完整中文原文（含官方 benchmark 的读法），在 Folkbench 上，浏览不需要注册： https://folkbench.com/blog/claude-haiku-5-5-official-scorecard?utm_source=luntan&utm_campaign=cnode
想问下大家：你们线上现在是怎么在小模型和大模型之间分流的？是按任务类型写死，还是先小模型跑、校验失败再升级？