跳到主要内容

Claude Sonnet 5:Claude Code 的新默认 Agent 模型

· 阅读需 10 分钟
Claude Dev
Claude Dev

Anthropic 在 2026-06-30 发布了 Claude Sonnet 5,将其定位为目前最 agentic 的 Sonnet 模型,并把它设为 Claude Free 和 Pro 用户的新默认模型。

官方叙事很清楚:Sonnet 5 把最近只有 Opus-class 模型才能可靠完成的许多 agentic work,带到了更便宜、更快、覆盖更广的模型层级。它可以做计划、使用浏览器和终端、处理长时间 coding task,并默认启用 adaptive thinking。

对 Claude Code 用户来说,Sonnet 5 不只是普通模型刷新。它很可能成为许多团队的默认执行层:不是 Anthropic 最强的模型,但会是开发者最常调用的模型。

但升级并非无摩擦。Sonnet 5 有新的 tokenizer,thinking 和 sampling 参数的 API 行为发生变化,默认启用实时 cyber safeguards,而且它虽然比 Opus 便宜,并不代表每个任务一定更便宜。

Anthropic 发布了什么

Anthropic 的发布稿将 Sonnet 5 描述为 Sonnet 4.6 的重大升级,重点提升 reasoning、tool use、coding 和 knowledge work。官方称它缩小了与 Opus 4.8 的差距,同时保持更低价格。

关键操作细节如下:

  • Model IDclaude-sonnet-5
  • 可用性:Free 和 Pro 默认模型;Max、Team、Enterprise、Claude Code 和 Claude Platform 可用。
  • 上下文窗口:默认和最大都是 1M tokens。
  • 最大输出:同步 Messages API 上为 128k tokens。
  • 价格:到 2026-08-31 前为 launch pricing,输入每百万 tokens 2 美元,输出每百万 tokens 10 美元;之后标准价格为 3/15 美元
  • Adaptive thinking:Claude Code 和 API 默认开启。
  • Cyber safeguards:默认启用实时 cybersecurity safeguards,这是 Sonnet-tier 模型首次默认具备这一点。

实用定位是:Sonnet 5 不是要替代 Fable 或 Mythos,而是要让 agentic work 进入日常。

正面反馈:它能完成更多工作

官方合作伙伴反馈和早期媒体测试里,最强的正面信号是一致的:Sonnet 5 更擅长完成多步骤工作,而不只是回答 prompt。

Anthropic 的 early access partners 提到,它在持续 coding、debugging、遵循项目约定、处理 brownfield code、完成并验证 pull request 方面都有提升。关键模式不是“它写的文字更漂亮”,而是“它会继续推进、更多自检,并用更少提示到达 finished result”。

TechRadar 的上手测试在非 coding 场景中也得出了类似结论。普通聊天时,Sonnet 5 和其他助手的差异并不夸张;但当任务从“回答问题”变成“完成一件事”,例如规划旅行或搭建家庭预算 tracker,Claude 更像围绕完成任务来组织输出。

这对 Claude Code 很关键。Sonnet 5 最适合的不是 one-turn snippets,而是这类工作流:

  • 调查 bug,写 reproducing test,修复并验证;
  • 按项目约定迁移一个模块;
  • 检查混乱代码库并产出分阶段计划;
  • 使用 terminal 和 browser tools 收集证据;
  • 生成 artifact、迭代修改,并保持输出一致。

这些日常开发任务,正是 Sonnet 5 应该明显超过 Sonnet 4.6 的地方。

Benchmarks:更强,但还不是 Opus

外部报道重复了两个有价值的 benchmark 信号。

TechRadar 报道 Anthropic 在 Terminal-bench 2.1 agentic coding 上给 Sonnet 5 的分数是 80.5%,而 Sonnet 4.6 是 67%。ITPro 报道 Sonnet 5 在 SWE-bench Pro 上为 63.2%,Sonnet 4.6 为 58.1%,Opus 4.8 为 69.2%

结论很清楚:

  • Sonnet 5 相比 Sonnet 4.6 是真实升级;
  • Opus 4.8 在最难 coding tasks 上仍然更强;
  • 高 effort 下,Sonnet 5 在部分任务上可以接近或匹配 Opus 4.8;
  • 核心价值是 cost-performance flexibility,而不是绝对 frontier quality。

Anthropic 自己的文档也强调,在 BrowseComp 和 OSWorld-Verified 上,Sonnet 5 在不同 effort levels 下有更好的 cost-performance 曲线。重点不是某个单独排行榜数字,而是团队现在可以在 Sonnet-class 模型上调节 effort 和成本,而不是直接跳到 Opus。

隐藏迁移成本:Token 变了

最大的实现细节是新的 tokenizer。

Anthropic 表示,同一段输入文本在 Sonnet 5 上会比 Sonnet 4.6 产生大约 30% 更多 tokens,具体增幅取决于内容。这不会改变 API shape,但会改变预算。

它会影响:

  • 日志中的 token counts;
  • prompt cache economics;
  • max output limits;
  • context-window planning;
  • 等价 prompts 的成本估算;
  • 与 Sonnet 4.6 的 eval 对比。

所以 launch pricing 不是完整成本故事。即使标准 per-token 价格仍是 3/15 美元,同一个 workload 也可能使用更多 tokens。团队在假设迁移成本中性前,应该用 Sonnet 5 重新计算 prompts。

开发者必须注意的 API 行为变化

只有当你的代码没有使用已废弃或不支持的设置时,Sonnet 5 才算 drop-in replacement。

文档列出了三个行为变化:

  1. Adaptive thinking 默认开启:Sonnet 4.6 上没有 thinking 字段的请求,在 Sonnet 5 上会使用 adaptive thinking。如果要关闭,传 thinking: {type: "disabled"}
  2. Manual extended thinking 已移除thinking: {type: "enabled", budget_tokens: N} 会返回 400 error。改用 adaptive thinking 和 effort 参数。
  3. Sampling parameters 不再接受:非默认 temperaturetop_ptop_k 会返回 400 error。用 system prompt instructions 来引导行为。

对 Claude Code 用户来说,这意味着在切换 model ID 前,应先审计旧 wrappers 和自定义 agent harnesses。如果 client 还发送旧参数,模型升级会变成生产 bug。

Safety 反馈:比 Sonnet 4.6 好,但不如 Opus

Anthropic 表示,Sonnet 5 的 hallucination 和 sycophancy 率低于 Sonnet 4.6,并且在 agentic safety 上更强。它也更可能拒绝 malicious requests,并更能抵抗 prompt-injection-style hijacking。

但官方也表示,在 automated behavioral audit 上,Sonnet 5 的 misaligned behavior 率仍高于 Opus 4.8 和 Claude Mythos Preview。

Cybersecurity 方面也很具体。Sonnet 5 并未专门针对 cybersecurity work 训练。它可以做 routine、non-harmful cyber tasks,但在 dangerous cyber evaluations 上远弱于 Opus 4.8 和 Mythos 5。尽管如此,因为它比 Sonnet 4.6 更强,Anthropic 仍然默认启用了实时 cyber safeguards。

对安全团队来说,实用解读是:

  • 用 Sonnet 5 处理普通工程和 routine defensive work;
  • 对 prohibited 或 high-risk cyber prompts 预期会出现 refusals;
  • 需要 reduced guardrails 的 cybersecurity work,使用具备合适 access 的 Opus 4.8;
  • 记录 stop_reason: "refusal",因为 refusals 可能以 HTTP 200 成功响应返回。

早期外部反应:默认模型才是重点

Axios 将 Sonnet 5 解读为一次把 agentic AI 带入 everyday work 的动作,同时让风险画像低于 Opus、Fable 和 Mythos。这个判断是对的。

Sonnet 5 重要,是因为它改变默认值。如果 Free/Pro 用户、Claude Code 用户和平台开发者都拿到一个更 agentic 的 Sonnet 模型,那么 agent workflows 不再是 premium edge case,而会成为正常 Claude 体验。

风险在于用户可能高估 autonomy。TechRadar 的上手评测整体正面,但仍指出在决策、检查、预订、上传和最终执行上仍需要人类监督。Sonnet 5 更接近 finished work,但不是 review 的替代品。

对本站来说,最有用的 framing 很简单:

Sonnet 5 是日常 Claude Code automation 应该首先尝试的模型,但不是可以盲目信任的模型。

Claude Code 采用清单

1. 更新 model ID

把测试工作流从:

claude-sonnet-4-6

切到:

claude-sonnet-5

先在 branch 或 staging environment 中做。不要在没有 replay evals 的情况下直接切 production default。

2. 移除旧 API 参数

在代码库中搜索:

  • temperature
  • top_p
  • top_k
  • thinking: {type: "enabled"}
  • budget_tokens

删除非默认 sampling parameters,并把 manual thinking controls 迁移到 adaptive thinking + effort

3. 重新计算 tokens

不要复用 Sonnet 4.6 的 token budgets。用 Sonnet 5 重新计算最大 prompts、cached prefixes 和典型 Claude Code sessions。

特别注意:

  • 大型 repo summaries;
  • 生成的 plans;
  • 粘进 prompt 的 logs;
  • 长 tool results;
  • 接近期望输出长度的 max output settings。

4. 显式设置 effort

最稳妥的策略是让 effort 成为 task-level decision:

  • medium 用于 routine edits 和 explanations;
  • high 用于正确性重要的普通 Claude Code tasks;
  • xhigh 用于困难 debugging、migrations 和长 agent runs。

不要把 high effort 当作免费的质量提升。它会改变 latency 和 token use。

5. 让 Opus 保持在 routing mix 中

Sonnet 5 应该成为许多 workflow 的默认模型,但不是所有。

继续保留 Opus 4.8,用于:

  • high-risk refactors;
  • security-sensitive reviews;
  • ambiguous architecture decisions;
  • missed edge case 成本很高的任务;
  • 大型 Sonnet-generated changes 的 final review。

实用模式是:Sonnet 负责执行,Opus 负责升级处理。

结论

Claude Sonnet 5 比表面看起来更重要,因为它把更强的 agentic behavior 推进到大多数团队日常真正会用的模型层级。

它不是新的顶级 Claude 模型,而是新的默认 workhorse。

对 Claude Code 用户来说,正确做法是有意识地采用:

  • 用真实任务对比 Sonnet 4.6 benchmark;
  • 针对新 tokenizer 重新调整 token budgets;
  • 移除不支持的 API 参数;
  • 测量不同 effort levels 的成本;
  • 保留 Opus 4.8 处理升级场景;
  • 在日志中监控 cyber-safeguard refusals。

如果 Sonnet 4.6 是此前的实用基线,Opus 4.8 是 power tool,那么 Sonnet 5 就是把更多 power 带回日常工作流的尝试。这正是它需要谨慎迁移,而不是盲目切默认的原因。

参考来源