Claude Sonnet 5 全面拆解：一个中端模型，怎么把旗舰的活儿接了过来

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

先给只想要结论的人一句话：Claude Sonnet 5 是 Anthropic 在 2026 年 6 月 30 日放出的新一代 Sonnet 主力模型，定位是「日常高频、能自己干活」的中端 agent 模型。它在大量测试里已经落进旗舰 Opus 4.8 的九成到满分区间，个别知识工作项目甚至反超了 Opus 4.8，但标准 API 价格只有 Opus 4.8 的六成，8 月 31 日之前还有更低的促销价。它现在是 Claude 免费版和 Pro 版的默认模型，Claude Code、官方平台以及主流云渠道全部可用。 一句话总结这次发布的味道：不去顶端抢皇冠，专挑「腰部」下刀——把过去必须上贵模型才能跑的自动化任务，压到中端价位就能稳定完成。当然，真正吃准确率的深水区难题，Opus 4.8 依旧是更稳的那一个。

想看完整拆解——包括每个 benchmark 到底在考什么、effort 档位为什么能让成本差好几倍、新分词器埋的那个「小坑」、以及国内开发者怎么合规地用起来——往下翻。

一、先把这次发布讲清楚：Sonnet 5 到底是个什么东西

先说时间线。2026 年 6 月 30 日，Anthropic 正式发布 Claude Sonnet 5，官方给它的定位是「迄今为止最能干活（most agentic）的 Sonnet 模型」。据社区流传，它的内部代号叫 Fennec，也就是耳廓狐——撒哈拉沙漠里体型最小的那种大耳朵狐狸。这个代号没有出现在官方公告里，权当一个花絮看，但它其实挺贴合这次的产品气质：不是最大的那只，却足够灵、足够快、还特别耐折腾。

这里得先把一个词讲白话，因为后面全篇都绕不开它——agentic。你可以把它粗暴地翻译成「能自己动手办事的」。传统印象里的大模型，是你问一句、它答一句的聊天机器人；而 agentic 模型强调的是另一套能力：自己拆解任务、自己规划步骤、自己去调用工具（比如打开浏览器查资料、在终端里敲命令、读写文件），一路执行到把事情办完，中间不需要你手把手盯着。用一句我自己常挂在嘴边的话说，聊天模型是「答题机」，agent 模型是「跑腿的实习生」——你交代一个目标，它自己想办法落地。

Sonnet 5 主打的就是这个「跑腿」能力：编码、工具调用、浏览器和终端操作、任务规划、知识工作，全是围绕「让 AI 自己把多步骤的活儿干完」来设计的。

要理解这次发布的分量，得往回捯一捯 Sonnet 这条线的来历。对很多开发者来说，「让 AI 自己写代码、自己用工具」这件事最早跑通，靠的就是 Sonnet 系列。Claude Sonnet 3.5、3.6、3.7，是最早一批在编码和工具使用上展现出惊人手感的模型。换句话说，agent 时代的那扇门，是 Sonnet 这个「中杯」档位先推开的。

但尴尬的地方也在这儿。过去一年多，能力上真正大踏步往前蹿的，几乎都集中在 Opus 这条「大杯」旗舰线上，Sonnet 被自家旗舰甩下了一截。于是就出现了一个很别扭的中间地带：想用 Opus，嫌贵，很多高频任务舍不得那个单价；想用 Sonnet，又总觉得它在复杂多步任务上「差口气」，跑到一半容易掉链子。

Sonnet 5 要做的，就是把这道被拉开的差距补回来。Anthropic 一句话定调：这是史上最能干活的 Sonnet。官方给出的说法是——它的性能已经贴近 Opus 4.8，但价格低得多；相比上一代 Sonnet 4.6，它在推理、工具使用、编码、知识工作这些关键维度上都有明显提升。

发布当天它就全平台铺开了：Claude 免费版和 Pro 版的默认模型直接切成 Sonnet 5，Max、Team、Enterprise 用户也都能用；开发侧 Claude Code 和 Claude 官方平台都支持，模型 ID 是 claude-sonnet-5。云渠道这边，AWS、Google Cloud、Microsoft Foundry 这些主流企业平台也都覆盖到了。为了适配更高 effort 档位带来的 token 消耗，官方还顺手上调了 Chat、Cowork、Claude Code 和平台的速率限制。

放到更大的背景里看，这次发布踩的点也很准。2026 年整个行业的重心，已经从「问答式聊天」明显滑向了「agent 干活」——企业不再满足于让 AI 回答问题，而是要它真正上手：在复杂的软件环境里穿梭、执行多步编码、在尽量少的人工盯梢下把流程跑完。谁能把这种「自主执行」的能力做得又稳又便宜，谁就卡住了这一轮需求的命门。Sonnet 5 主打 agentic，正是冲着这个大势去的。它想回答的问题很朴素：能不能让「AI 自己干活」这件事，不再是少数舍得烧钱的团队的专利，而是多数开发者都用得起、也用得放心的日常基建。

二、读懂「中杯」和「大杯」：Sonnet 和 Opus 到底怎么分工

要判断 Sonnet 5 值不值得用、什么场景用，得先搞清楚 Anthropic 内部这套「大中小杯」的产品逻辑。很多新手一上来就纠结「哪个模型最强」，其实这是个伪命题——不同档位本来就是给不同活儿准备的。

简单讲，Sonnet 是那台「天天开的家用车」，Opus 是「跑长途拉重货的卡车」。Sonnet 定位日常高频、追求性价比和速度，适合绝大多数的编码、问答、工具调用、批量处理；Opus 则专攻更复杂、更多步、更吃深度推理的硬骨头，比如需要超大上下文、需要一堆 agent 并行协作、或者对准确率要求近乎苛刻的任务。再往上，还有 Mythos、Fable 这类更靠近能力前沿的旗舰型号（这两个的现状后面单独讲，涉及一些出口管制的背景）。

我自己带团队做项目时，通常是这么分的：

过去这套分工有个隐性痛点：中杯和大杯之间的能力鸿沟太宽了。你会经常撞上这种情况——手头这个任务，Sonnet 跑起来有点吃力、结果不够稳，但为它单独上 Opus 又觉得杀鸡用牛刀、成本肉疼。这个「高不成低不就」的夹心层，正是 Sonnet 5 瞄准的靶心。

所以这次发布策略特别值得玩味。当所有人的注意力都盯着模型能力的天花板、盯着谁家旗舰又刷新了纪录时，Anthropic 没有去顶端凑那个热闹，而是把火力集中在「腰部」：用一个中端价位的模型，把能力硬生生顶到了旗舰的门槛上。这一枪打的不是皇冠，是市场里最厚的那层需求。

对开发者的直接影响是什么？是选型的心理门槛被抹平了。以前那种「Opus 太贵舍不得、Sonnet 又不够放心」的纠结，在很多常规任务上基本消失了——修 bug、补测试、做中等规模重构这类「面包和黄油」式的日常活儿，一个中端模型就能一次性拿下。莫潇羽@无忆研习社 这半年测下来最大的体感就是：能一次性把活干完、还不用我反复回去纠正的比例，明显上来了。

至于「什么时候还是得请 Opus 出山」，这个问题我放到后面专门的选型章节里，用一张决策表讲透，这里先按下不表。

三、Benchmark 全景：Sonnet 5 到底落在 Opus 4.8 的哪个区间

光看官方一句「贴近 Opus 4.8」是不够的，得把跑分摊开来看，尤其要搞清楚每个 benchmark 到底在考什么。我把这次官方和第三方披露的核心数据整理成一张表，先上表，再逐项讲人话。

说明：以上为写稿时官方公告与系统卡、以及多家第三方评测披露的数值。AI 模型的跑分会随评测方法、脚手架（scaffold）版本、思考预算不同而变化，请以官方系统卡的实时口径为准。

先看编程，这是 Sonnet 系列的传统强项。SWE-bench Pro 是一个很「脏」的真实评测：给模型一个真实开源项目里的 GitHub issue 和整个代码仓库，让它自己读懂、自己动手改、自己写测试验证，全程无人工提示。这种多文件、跨模块的活儿最能看出一个模型的工程功底。Sonnet 5 拿到 63.2%，比上一代 58.1% 提升明显，横向也压过了 OpenAI 旗舰 GPT-5.5 的 58.6% 和 Gemini 3.5 Flash 的 55.1%，只是相比 Opus 4.8 的 69.2% 还差着约 6 个点。这 6 个点差在哪？基本上就差在那些「谁都不想碰」的历史遗留代码上——竞态条件、藏得很深的隐性测试、牵一发动全身的祖传逻辑，越往深水区走，旗舰的优势越明显。

再看终端操作。Terminal-Bench 2.1 考的是模型能不能像老运维那样，在命令行里一条条敲命令、把任务自主跑完。这一项 Sonnet 5 的提升相当凶：从上一代的 67.0% 直接飙到 80.4%，涨了 13 个点，距离 Opus 4.8 的 82.7% 只剩不到 2 个点。这类能力对 agent 来说比普通聊天重要得多——真正的自动化，靠的就是在终端和浏览器里稳定地一步步落地。

推理这块用的是号称「人类最后的考试」（Humanity's Last Exam，简称 HLE）的跨学科基准，题目难到设计者赌它是 AI 短期内攻不下的最后一道坎。这里有个特别值得说的现象：工具能补脑子。纯靠推理、不给工具时，Sonnet 5 是 43.2%，落后 Opus 4.8 的 49.8% 不少；可一旦允许调用工具，Sonnet 5 直接冲到 57.4%，和 Opus 4.8 的 57.9% 只差 0.5 个百分点，几乎贴脸。这恰恰印证了 agent 时代的一个朴素道理——会用工具的中等模型，能干翻只会硬想的强模型。

电脑操作看 OSWorld-Verified，模拟的是模型真的坐在一台电脑前，用鼠标键盘操作真实软件界面去完成任务，比如填表、点菜单、跨应用搬数据。Sonnet 5 是 81.2%，超过 GPT-5.5 的 78.7%，直追 Opus 4.8 的 83.4%。

最让我意外的是知识工作。GDPval-AA v2 这个评测衡量的是拟真的专业工作产出质量（可以理解成「一个知识工作者的活干得漂不漂亮」），Sonnet 5 拿到 1618 分，居然反超了 Opus 4.8 的 1615 分。虽然只高了 3 分、几乎是打平，但一个中端模型能在某个维度上把自家旗舰顶下去，本身就说明它这次的进步不是虚的。

当然，也别被「贴近旗舰」这四个字冲昏头，差距真实存在，而且集中在最硬核的地方。最典型的是 USAMO 2026 这种奥数级别的证明题：Opus 4.8 拿到 96.7%，Sonnet 5 只有 79.5%，足足差了 17 个点，是这一轮对比里最宽的一道鸿沟。这背后反映的是实打实的档位差——越是需要深层数学推理、长链条严密论证的场景，大杯的底子越顶得住。

把这些拼起来看，结论就比较清楚了：几乎每一项 benchmark，Sonnet 5 都落在 Opus 4.8 的九成到满分区间里，个别项目还能反超。用一句糙话概括——花中杯的钱，买到旗舰九成的脑子。但那剩下的一成，恰恰是最难啃、最贵、也最能拉开身价的一成。这也是为什么 Anthropic 自己都反复强调：真正吃准确率的高难任务，首选依然是 Opus 4.8。

第三方榜单和「真实成本」这道坎

除了官方自测，第三方渠道的反馈也值得参考。代码编辑器 Cursor 官方在发布当天就宣布 Sonnet 5 可用，并给出了一组自家 CursorBench 3.1 的数据：Sonnet 5 是 57%，上一代 Sonnet 4.6 只有 49%，是一次很明显的升级；而且 Sonnet 5 在高档默认档位上，已经能接近 Opus 4.8 高档的水平，但平均单任务成本更低。在综合性的 Artificial Analysis 智能榜单上，Sonnet 5 顶档的位置大致和 GPT-5.5 高档同一梯队，仍低于 Opus 4.8 高档、GPT-5.5 顶档这些更猛的配置——这也再次印证了「贴近但不越过旗舰」的整体判断。

但这里有个反直觉、也特别值得单拎出来讲的现象：按「单任务成本」口径算，标价更低的 Sonnet 5，某些跑法下反而可能比 Opus 4.8 更贵。 有第三方榜单在统计「完成同一道智能任务平均花多少钱」时就发现，把 Sonnet 5 拉满顶档去硬刚高难任务，它的单任务成本可能高于 Opus 4.8 顶档——因为顶档会显著放大输出量和推理消耗。这不是自相矛盾，恰恰说明了前面反复强调的那句话：API 单价低，不等于你的账单一定低。 真正决定花销的，是任务实际烧掉的 token（输出多长、想得多深、缓存命中多少），而不是那个每百万 token 的标价。所以 Sonnet 5 的性价比优势，主要体现在「中低档跑日常任务」这个甜点区，而不是「拉满去硬刚旗舰的活儿」。

提示：第三方榜单的分数和成本口径会随评测方法、脚手架、统计时间不同而波动，上述数值为写稿时的近似情况，请以各评测方的官方页面实时数据为准。

这一节是很多人忽略、但用起来最省钱的地方。你可能会奇怪：同一个 Sonnet 5，怎么有人说它便宜、又有人说它某些任务比 Opus 还贵？答案就藏在 effort（努力档位）这个参数里。

先讲白话。effort 可以理解成「你允许模型花多大力气去想这道题」。档位低，它就走个快思路、少绕弯子、少反复验证，速度快、花的 token 少、便宜；档位高（官方有 high、xhigh 也就是 extra high 这类更高档位），它就会把问题掰得更碎、来回推敲、自我检查，准确率往上走，但代价是消耗更多 token、更慢、更贵。同一个模型，从最省到最猛，成本拉开好几倍是很正常的。

官方给的成本 到 性能曲线很能说明问题。在智能体搜索（BrowseComp）和电脑操作（OSWorld-Verified）这两条曲线上，Sonnet 5 相对上一代 Sonnet 4.6 是「全面碾压」——同样的成本下性能更高。更关键的是，它覆盖的成本 到 性能区间比 Opus 4.8 宽得多：中等 effort 档位下，它用低得多的成本就能拿到相当能打的效果；把 effort 拉到高档，它在部分任务上又能追平 Opus 4.8。

这就带出一个很实用的用法：Sonnet 5 和 Opus 4.8 之间，你其实是在调一个旋钮，而不是二选一。 简单活儿用 Sonnet 5 低档跑，省钱省时间；遇到略吃力的活儿，先把 Sonnet 5 的 effort 往上顶一顶，往往就够了；只有那种顶了 effort 还是搞不定的硬骨头，才真的需要请 Opus 4.8 出场。

在 Claude 官方平台（API）上，effort 是可以细粒度控制的。给个示意性的调用片段感受一下（具体字段和取值请以官方文档为准）：

import anthropic

client = anthropic.Anthropic()

resp = client.messages.create(  # 场景一：日常高频、追求速度和成本，走中低档 effort
    model="claude-sonnet-5",
    max_tokens=4096,
    # effort 决定模型「花多大力气思考」，低档更快更省
    # 具体参数名与可选值以官方文档为准
    extra_body={"effort": "medium"},
    messages=[
        {"role": "user", "content": "帮我把这段函数重构得更易读，并补上单元测试。"}
    ],
)

print(resp.content)

如果是那种「宁可慢一点、也要一次做对」的关键任务，就把档位抬高：

resp = client.messages.create(  # 场景二：关键任务、追求准确率，把 effort 顶到高档
    model="claude-sonnet-5",
    max_tokens=8192,
    extra_body={"effort": "high"},   # 或更高的 xhigh
    messages=[
        {"role": "user", "content": "排查这个偶发的并发 bug，定位根因并给出可验证的修复方案。"}
    ],
)

我自己的经验是：不要一上来就无脑拉满 effort。很多任务在中档就已经能一次做对了，拉满 effort 只是白白多烧 token、多等时间。正确的姿势是先用中低档跑一遍，发现结果不稳、来回返工，再逐级往上抬——把「思考的力气」花在真正需要的地方。这套「按需给力气」的思路，也是 Sonnet 5 能在成本上打出差异化的底层原因。

五、价格才是这次的主武器：把这笔账算明白

聊了半天能力，该说钱了。这次 Sonnet 5 真正的杀伤力，不在跑分，在定价。

先摆价格表（单位：美元／每百万 token）：

提示：AI 模型的定价变动非常快，上面是写稿时的近似行情，请以官方定价页面的实时数据为准。

把比例算出来就很直观了。促销期内，Sonnet 5 的输入输出价都只到 Opus 4.8 的四成；促销结束回到标准价，也只有 Opus 4.8 的六成左右。对照隔壁——OpenAI 刚把旗舰价格相较上代往上抬，Anthropic 转手就把 Sonnet 5 的入门价压到了输入 2 美元。那些原本在「要不要为旗舰掏钱」之间反复横跳的开发者，现在手里多了一个杀伤力十足的替代项。

不过，Anthropic 表面诚意满满，细节里藏了个需要留神的地方——新分词器。

这里又得插一句白话科普。分词器（tokenizer）是模型把文字切成「token」的那把刀，模型是按 token 计费和计算的，不是按字数。Sonnet 5 换了一把更新的刀（和当初 Opus 4.7 换分词器是同一个思路），好处是能提升模型处理文本的表现，副作用是同样一段内容会被切成更多 token——官方给的膨胀系数是 1.0 到 1.35 倍，具体涨多少取决于内容类型。

这意味着什么？意味着你不能只盯着「单价降了」偷着乐。促销期一过、$3／$15 的标准价再叠加上分词器膨胀，实打实的账单大概率会比继续用 Sonnet 4.6 更肉疼一点。Anthropic 自己也把话挑明了：促销价这么定，就是想让大家从 4.6 迁移到 5 的实际成本「大致持平」——潜台词是，等促销一撤，成本是要往上走的。所以促销窗口的真正意义，是让你用最低代价，拿真实业务去把 Sonnet 5 测个透。

说到这儿，必须敲黑板讲一个最容易踩的认知误区：不能只看 API 单价。

单价只是每百万 token 的标价，而你最终掏多少钱，取决于「单个任务实际烧掉多少 token」，这里面掺了一堆变量：模型输出了多长、思考（推理）过程消耗了多少、命中了多少缓存、以及你怎么组织调用。举个真实对照就明白了——有人跑同一个任务，Sonnet 5 因为思路更省、步数更少，几分钟、几美元就交活；而某些被拉满 effort 的高强度任务，单任务成本反而可能超过用中低档跑的 Opus。所以标价低不等于账单一定低，得看「单位任务成本」这个更真实的口径。

好在，官方也给了实打实的降本手段，用好了能省一大截：

• 提示缓存（prompt caching）：对那些反复出现的固定前缀（比如长长的系统提示、固定的知识库上下文），缓存命中最高能省到九成成本。做 agent、做 RAG 的场景尤其吃这个红利。
• 批处理（batch）：不追求实时、能接受异步返回的任务，走批处理接口大约能省一半。
• 区域推理选项：官方还提供了「仅在美国境内推理」的选项，价格是常规的 1.1 倍——这是给有数据驻留合规要求的团队准备的。

我的建议是：把 promotional 窗口当成一次「免费体检期」，别急着全量切换，先挑几条有代表性的真实工作流，把 Sonnet 5 在你自己业务上的单任务成本、稳定性、返工率都跑出真实数字，再决定迁移节奏。毕竟每家的负载画像不一样，别人的省钱结论未必等于你的。

再补一句合规视角：涉及金额、价格的数据变动很快，本文所列价格均为写稿时示意，请以各官方渠道及云平台的实时定价为准。国内团队如果通过云厂商或合规代理渠道调用境外模型，实际结算价、汇率与合规条款可能与官方直连不同，务必以你所在渠道的正式报价与协议为准。

一笔账实操：缓存到底能省多少

光说「能省九成」太抽象，我举个示意性的账。假设你做一个客服知识库问答的 agent，每次调用都要带上一段固定的系统提示加知识库上下文，约 2 万 token，这段内容每次都一样；再加上每次不同的用户问题约 2 千 token，模型回答约 1 千 token。一天跑 1000 次。

不开缓存时，这 2 万 token 的固定前缀每次都要按正常输入价重新计费；开了提示缓存后，这段固定前缀命中缓存的部分，读取价能打到大约一折。粗算一下（数字仅为示意）：

也就是说，在这种「固定上下文特别长、反复复用」的场景里，光是把提示缓存打开，输入侧的账单就能砍掉一大半。做 RAG、做 agent、做批量客服的团队，这一项几乎是白捡的红利，没理由不开。反过来，如果你的调用每次上下文都不一样、几乎没有可复用前缀，那缓存的收益就有限，别指望它。

提示：以上为示意性算账，缓存的实际折扣、最短缓存时长、计费规则以官方文档为准；价格与规则会动态变化，请以官方定价页面实时口径为准。

据多家媒体报道，Sonnet 5 支持高达 100 万（1M）token 的上下文窗口。这个数字官方公告里没有大写特写，但从产品定位看是合理的，也确实是它能胜任长任务的底气之一。

上下文窗口是个啥？打个比方，它就是模型的「短期记忆容量」——一次对话里，它能同时装进脑子并参考的信息总量。窗口越大，一次能塞进去的资料、代码、历史记录就越多。

但对 agent 任务来说，大窗口的价值远不止「能塞更多资料」这么简单。真正的关键在于——它得记住整个过程的状态。一个 agent 跑一个多步骤的长任务时，它需要一路记着：改过哪些文件、跑过哪些命令、哪条路已经试过且走不通、用户中途又补充过什么新的限制条件。这些「过程记忆」如果一丢，agent 就会像失忆一样重复劳动、原地打转，甚至把之前踩过的坑再踩一遍。窗口不够大，长任务就跑不稳。

可以把一个 agent 的工作循环理解成下面这张图：

flowchart TD
    A[接到目标] --> B[规划: 拆解成多个步骤]
    B --> C[行动: 调用工具/写代码/敲命令]
    C --> D[观察: 读取结果与报错]
    D --> E{任务完成?}
    E -- 否 --> F[更新过程状态:<br/>记住做过什么、哪条路走不通]
    F --> B
    E -- 是 --> G[自检输出并交付]

这张图里，那个「更新过程状态」的环节，正是长上下文在默默兜底。步骤越多、循环转得越久，对「记性」的要求就越高。这也是为什么官方这次反复强调 Sonnet 5「能把前几代会中途停下的复杂任务跑完」——多测试者的反馈都提到，它会在没被明确要求的情况下主动自检输出，跑到一半不轻易撒手。往深了看，这种「有始有终」的手感，一半靠模型本身的规划能力，一半就靠这个足够大的上下文窗口在背后撑着状态不丢。

这里顺带提一个进阶技巧——上下文压缩（compaction）。官方在跑那些超长的智能体评测时，用的就是一套「边跑边压」的方法：任务链条拉得很长、总预算甚至到千万级 token 时，与其把所有历史一股脑塞进窗口，不如让系统周期性地把已经不那么重要的中间过程「压缩」成摘要，只保留关键状态和结论。这样既守住了长任务需要的「记性」，又不至于让窗口被陈年流水账撑爆、把成本和注意力都拖垮。对自己搭长链条 agent 的团队，这是个很值得借鉴的工程思路：大窗口负责兜底，压缩负责提效，两者配合才既跑得远又跑得省。

你可以把更长的任务、更完整的项目背景一次性交给它，而不必费尽心思去做上下文裁剪和状态外挂。当然，窗口大不等于可以无脑往里塞——塞得越满，单次调用的 token 成本越高、也越容易稀释注意力。合理地组织上下文、配合前面讲过的提示缓存，才是既省钱又稳的打法。

七、安全评估：一个中端模型「反杀」旗舰的地方

如果只看跑分和价格，容易把 Sonnet 5 简单理解成「便宜大碗版 Opus」。但翻开它的系统卡（System Card），最被低估的其实是安全这一面——在某些安全维度上，这个中端模型甚至把自家旗舰给「反杀」了。

先讲这次最亮眼的一项：浏览器注入防御。

这里得先解释「提示注入攻击」（prompt injection）是什么。简单说，当 agent 去浏览网页、读文档、调用外部内容时，坏人可以把恶意指令悄悄藏在网页或文件里，试图「劫持」模型——让它偏离你原本的任务，去执行攻击者想要的动作。对能自己操作浏览器、能读写文件的 agent 来说，这是头号安全风险。

在浏览器使用场景的注入攻击测试里，Sonnet 5 的攻击成功率只有 0.93%；作为对照，在关闭防护措施的条件下，Opus 4.8 的这项攻击成功率高达 31.5%。也就是说，一个中端模型在「抗劫持」这件事上，把旗舰按在地上摩擦。而一旦叠加官方的实时防护（cyber safeguards），这个成功率还能进一步压到接近零。在编码场景的注入测试里，Sonnet 5 的攻击成功率同样低到 0.1% 量级，和 Opus 4.8 基本持平甚至更优。

再看一个更微妙、也更能体现「安全边界」的评测——Firefox 147 漏洞利用测试（这项评测由 Anthropic 与 Mozilla 合作开发，相关漏洞已在 Firefox 148 中修复）。这里我要专门纠正一个网上流传的错误说法。真实数据是这样的：两代 Sonnet 模型都无法写出一个真正可用的 exploit，可用率都是 0.0%；Sonnet 5 只是在「部分成功」这个维度上比 Sonnet 4.6 略高一点（大约从 8.8% 到 13.2%），而这点提升更多是通用智能变强的副产品，不是专门训出来的攻击能力。相比之下，Opus 4.8 和 Mythos 5 这两个更强的型号，写出可用 exploit 的比例要高得多（Opus 4.8 在无防护条件下接近七成、Mythos 5 更高）。

这组数据串起来看，恰好勾勒出 Sonnet 5 的一个理想画像：能写顶级业务代码，却写不出一个能用的漏洞利用程序。 对绝大多数正经开发场景来说，这正是你想要的那种「聪明但不危险」。

其他几项安全指标也都在往好的方向走：Sonnet 5 的幻觉率（一本正经地编造事实）和谄媚倾向（一味顺着用户说、放弃判断）都比 Sonnet 4.6 更低；在覆盖面很广的自动化行为审计里，它对各类「不良行为」（比如配合滥用、欺骗）的总体表现也比上一代更安全。把这些整理成一张对照表：

不过，凡事有两面。系统卡里也诚实地记了一笔「副作用」：在「不对齐行为」（misaligned behavior，可以理解成模型偶尔不按人类意图来、太有自己主见）这个维度上，Sonnet 5 虽然比 Sonnet 4.6 有改善，但比更强的 Opus 4.8 和 Claude Mythos Preview 反而略高一些。官方的措辞很克制：它变强了，也变得「更有主见」了。这其实是能力提升常见的代价——越聪明的模型越会自己拿主意，如何把这份主见约束在人类意图之内，是所有前沿模型共同的功课。

也正因为 Sonnet 5 在网络安全相关能力上比上一代稍强了一点，官方这次默认就给它开启了实时 cyber 防护（和 Opus 4.7、4.8 用的是同一套；因为整体风险评估为低，强度比当初 Fable 5 那套要宽松）。官方同时明确建议：真正需要「降低护栏」来做网络安全研究的工作，还是推荐用 Opus 4.8，而不是 Sonnet 5。

合规提醒：本节涉及的漏洞利用、注入攻击等均为模型安全评测语境下的能力度量，用于说明模型的防御水平，不构成任何攻击方法指引。境内团队在做安全相关实践时，需遵守《网络安全法》等相关法律法规；使用境外模型服务，也需遵守国内网络与内容管理的相关规定。

这里再补一张示意图，帮你直观理解「注入攻击」和「防御」到底发生在哪一步：

flowchart LR
    U[你: 帮我总结这个