Claude Sonnet 4.6

在 Anthropic 当前梯队里，Sonnet 4.6 是夹在 Opus(4.7/4.8 旗舰) 与 Haiku(4.5 极速档) 之间的中坚力量，也是绝大多数生产负载默认会落到的那一档。它继承了 Claude 系列一贯的强项：指令遵循扎实、长文档不易跑偏、写代码与改代码的工程感强、幻觉相对克制、对系统提示和工具定义的服从度高。对做 Agent / RAG / 代码助手的团队来说，它通常是「智能够用、价格能接受、上下文够长」三者之间最舒服的平衡点。

Sonnet 4.6 支持文本与视觉(vision)双模态，可以读截图、UI、图表、扫描件，这在做带界面理解的 Agent、文档抽取、网页操作类任务时很实用。它的上下文窗口达到百万级(1M tokens)，与同代 Opus 同档，意味着整本手册、整个代码仓库的关键文件、超长会话历史都能一次塞进去，省去大量分块与检索拼接的工程。

简单说，它不是用来追榜单最高分的「天花板模型」，而是把「能稳定交付、可大规模铺量」放在第一位的工程化主力。如果你的系统里只允许有一个默认模型，Sonnet 4.6 往往就是那个最不容易出错的选择。

Sonnet 4.6 的价格分三档：输入、输出、以及命中缓存的输入(cached input)。具体单价以本页上方价格表实时为准(本站每日核价)，这里只讲结构怎么影响你的真实账单。规律是：输出比输入贵明显一截，而命中缓存的输入又比常规输入便宜一大截。所以同样一次调用，成本高低主要取决于你「让它写多少」以及「重复的前缀有没有走上缓存」。

对 Agent 和 RAG 场景，这个结构直接决定了优化方向。第一，把固定不变的部分(系统提示、工具定义、长篇 few-shot、大段背景知识)放在 prompt 前缀并开启提示缓存，多轮对话里这部分就按缓存价计费，长会话能省下相当可观的一笔。第二，输出最贵，所以要约束模型别长篇大论——结构化输出、限制 max_tokens、让它只回必要字段，往往比换更便宜的模型更能直接压低成本。

相对 Opus，Sonnet 4.6 的输入/输出单价都低一截，但智能在多数日常工程任务上够用；相对 Haiku，它贵一些但推理深度和长上下文稳健性明显更强。判断它值不值，不要只看单价，要看「单位任务的总 token × 该任务对质量的容忍度」——高频、中等难度、需要长上下文的活，它的综合性价比通常最优。

最适合：生产级编码助手与代码审查(读大段仓库上下文、改多文件、给 diff)、复杂 Agent 的主推理节点(工具调用稳、按 schema 输出、长链路不容易迷路)、长文档 RAG 与摘要(百万上下文可以少切块甚至不切块)、客服与运营自动化(指令遵循好、口径稳定、可大规模铺)、带截图/UI 理解的视觉任务。这些都是「要质量但更要规模与稳定」的活，正是 Sonnet 4.6 的舒适区。

不太适合或要谨慎：一是对延迟和单价极度敏感的超高频轻量任务(纯分类、改写、意图识别、简单抽取)，这类用 Haiku 4.5 更划算，把 Sonnet 留给真正需要推理的环节；二是处在能力天花板的极难任务(最硬的数学/竞赛级推理、需要极致深思的研究型问题、对一次成功率要求苛刻的高风险决策)，这类更适合升到 Opus。

一个实用心法：把 Sonnet 4.6 当成「默认档」，向下用 Haiku 处理可以批量分流的简单步骤，向上用 Opus 兜底真正难啃的少数关键步骤。这种分层路由(routing)往往比全程单一模型在成本和质量上都更优。

在 Anthropic 内部：从 Sonnet 升到 Opus，是用更高的单价换更强的深推理与更高的一次成功率——当你发现某类任务 Sonnet 反复返工、需要人工兜底、或错误代价很高时，升级是划算的。从 Sonnet 降到 Haiku，是用一点质量换大幅的速度与成本——当任务足够简单、能用规则或评测把质量守住时，降级能显著压成本。注意三者都不是非此即彼，生产系统里同时用上多档、按难度路由才是常态。

跟同梯队的竞品(各家的中端主力，如 GPT 系中端档、Gemini Flash/Pro 中端档、以及 DeepSeek、通义、Kimi、智谱等国产中坚)相比，Sonnet 4.6 的差异化主要在：指令遵循与长链路稳定性、代码工程任务的体感、以及百万级上下文。国产同档在纯单价上往往更便宜，若你的瓶颈是成本且任务不吃 Claude 的稳定性优势，值得拿真实任务做 A/B 实测。

选型不要只信榜单分数。最靠谱的做法是用你自己的真实样本(几十到上百条代表性请求)同时跑候选模型，比对一次成功率、返工率、平均输出长度和总成本，再结合本页价格表算每千次调用的实际花费——往往会发现「便宜的模型因为返工反而更贵」或「贵的模型因为一次过省了人工」。