Claude Haiku 5.5 把小模型推上 Agent 主链：便宜之后，架构该怎么变？
Claude Haiku 5.5 大幅降低高频调用成本，并强化计算机操作与子 Agent 能力。本文分析小模型如何从辅助工具变成 Agent 系统的默认执行层。
3 分钟阅读
大模型应用的成本问题，正在从“每百万 token 多少钱”变成一个架构问题：哪些任务真的需要最强模型，哪些任务只需要足够快、足够稳定、可以大规模重复执行的模型？
Anthropic 在 2026 年 10 月 7 日发布 Claude Haiku 5.5。官方把它定位为面向高吞吐、成本敏感任务的小模型，适合摘要、上下文压缩、数据库查询、分类、实时客服、浏览器操作和子 Agent。更重要的是，它不只是比上一代便宜：对于 10 万 token 以内的请求，输入和输出价格分别为每百万 token 0.10 美元和 0.50 美元，并首次在 Haiku 档位加入可调 effort。
这意味着小模型不再只是主模型旁边的“省钱选项”，而可能成为 Agent 系统的默认执行层。
真正的变化不是降价，而是模型分工
很多 Agent 产品仍采用一种简单设计：无论任务大小，都把请求交给同一个强模型。这样容易开发，却会把分类、页面读取、参数提取、状态检查等低复杂度步骤，也按高推理成本结算。
Haiku 5.5 的产品信号是，模型路由应该成为 Agent 架构的一等能力：
- 小模型处理意图识别、数据清洗、工具参数生成和结果归纳；
- 中型模型负责有明确边界的编码、文档和业务任务；
- 最强模型只在复杂决策、冲突证据或长链路失败时介入。
这和此前讨论的 Sonnet 5.5 企业任务成本是一条连续趋势：模型产品正在从单一能力排行榜，转向按任务价值和失败成本分层。
为什么它特别适合高频 Agent
Anthropic 公布的结果显示，Haiku 5.5 在 OSWorld 2.1 离线子集上达到 72.4%，Terminal-Bench 4.0 为 39.2%。这些数字来自厂商评测，不能直接等同于每个生产环境的效果，但它们说明小模型已经能承担过去必须交给更大模型的一部分工具操作。
对 Agent 来说，速度会产生复利。一项用户任务可能触发十几次模型调用；如果每一步都节省几百毫秒，最终体验会从“等待自动化完成”变成接近实时交互。同时，低单次成本使系统可以增加校验调用、重试和并行候选，而不必把所有预算押在一次回答上。
便宜模型不会自动带来便宜系统
模型报价下降，并不保证总账单下降。Agent 很容易因为低价而增加循环次数、工具调用和上下文长度。Anthropic 也明确区分了 10 万 token 上下的价格：超过这一阈值后，Haiku 5.5 的输入和输出价格会上升到每百万 token 0.50 美元和 2.50 美元。
因此，工程团队至少要记录四类指标：每次任务的模型调用次数、缓存命中率、工具失败后的重试次数，以及最终成功任务的完整成本。只看 token 单价，会忽略最昂贵的失败链路。
一个更合理的落地方式
- 先从可验证的窄任务开始，例如分类、结构化提取和摘要。
- 为每类任务建立自己的准确率、延迟和失败成本基线，不直接照搬公开 benchmark。
- 设置升级条件：置信度不足、工具连续失败或检测到高风险动作时，转交 Sonnet 或 Opus。
- 把最终业务结果纳入评测，而不是只判断模型输出是否“看起来不错”。
- 保留人工审批边界，尤其是付款、删除、权限修改和对外发送等动作。
结论
Haiku 5.5 最值得关注的地方，不是它是否在某个榜单上追平更大的模型，而是它让“多数步骤使用小模型、少数关键步骤升级”的架构更现实。下一阶段的 Agent 竞争，很可能不是谁默认调用最强模型，而是谁能把任务拆分、路由、校验和升级做得最可靠。