Claude Sonnet 5实测：隐藏的Token陷阱让「低价」成幻觉

文章正文

Anthropic近期正式推出了Sonnet系列迄今最大的一次升级——Claude Sonnet 5。官方将其定位为「最具Agentic能力的Sonnet模型」，宣称在推理、工具调用、编码和通用知识工作方面都有显著提升，性能甚至逼近旗舰的Opus 4.8。然而，一场来自B站及海外UP主的实测却揭示了另一番景象：这可能是Anthropic近期最令人失望的一次发布。

官方数据：性能确实向Opus看齐

从纸面参数看，Sonnet 5的表现相当亮眼。据实测者引用的官方基准数据，Sonnet 5在多项测试中平均得分达到63.2%。在Terminal Bench 2.1上，它取得了80.4%的成绩，已经非常接近Opus 4.8；在HLE基准上与Opus几乎并驾齐驱，计算机使用（computer use）能力得分81.2%；在GDP EVOL基准上更是达到16.19%，甚至反超了Opus。

Terminal Bench与HLE背景：Terminal Bench是专门评估AI模型在真实终端环境中自主执行命令行任务能力的基准测试，涵盖文件系统操作、进程管理、网络配置、脚本编写等场景，要求模型在无人监督下完成多步骤跨工具操作。Computer Use则是Anthropic自研的评估框架，测试模型操控图形界面的能力，包括鼠标点击、键盘输入、屏幕截图理解等，代表了AI从「文字助手」向「数字操作员」演进的关键能力维度。HLE（Humanity's Last Exam）则是由Scale AI与学术机构联合开发的超高难度综合评估基准，题目由全球顶尖学者贡献，涵盖数十个领域的专业级问题，设计初衷是找到当前最先进LLM的能力边界，是目前最能体现模型「深度知识整合」能力的评估工具之一。

这些数据说明，Sonnet 5在自主化工作流（agentic workflows）方面确实取得了实质性进步。Agentic工作流代表了大语言模型从「被动问答」向「主动执行」的范式转变，是指AI模型不再仅仅被动地回答单一问题，而是能够主动拆解复杂任务、调用外部工具（如浏览器、代码执行环境、API等），并根据中间结果动态调整行动策略，形成「感知-规划-执行」的闭环。其技术架构通常包含四个核心模块：感知层（接收环境状态与用户指令）、规划层（将复杂目标分解为可执行子任务序列）、执行层（调用工具API、浏览器、代码解释器等外部资源）和反思层（根据执行结果评估进度并动态修正策略）。

值得关注的是，Agentic AI正在从学术概念快速演进为产业基础设施。2023年以来，LangChain、AutoGPT、CrewAI等框架的兴起标志着Agent编排进入工程化阶段，而Anthropic的Claude、OpenAI的GPT-4o、Google的Gemini也相继推出原生工具调用接口，使「模型即执行引擎」成为现实。在这一产业背景下，Sonnet 5所标榜的Agentic能力提升并非孤立的技术进步，而是整个行业从「模型即产品」向「模型即基础设施」转型浪潮中的组成部分——企业不再满足于通过对话框交互，而是希望将LLM嵌入自动化业务流程，替代人工完成数据采集、报告生成、代码审查等重复性高价值任务。这也解释了为何Anthropic将Agentic能力作为此次发布的核心宣传点：这一赛道的竞争正在从「谁的回答更准确」演变为「谁的Agent更能干活」。

这一架构在学术界被称为ReAct（Reasoning + Acting）框架，由普林斯顿大学和谷歌研究院于2022年提出。ReAct的核心创新在于将「推理轨迹（Reasoning Trace）」与「行动执行（Action Execution）」交织进行——模型在每次调用工具前先输出自然语言形式的思考步骤，在获取工具返回结果后再进行下一轮推理，形成「思考→行动→观察」的迭代循环。这一设计相较于纯推理链（Chain-of-Thought，CoT）或纯行动序列有显著优势：推理轨迹使模型的中间决策过程变得可解释、可审计，便于开发者追踪错误来源；而将推理嵌入行动序列则让模型能够根据实时反馈动态修正计划，而非盲目执行预设步骤。在复杂Agent任务中，ReAct框架的容错能力尤为重要——当某个工具调用返回异常结果时，模型可以在推理层识别偏差并选择备选路径，而非直接导致任务失败。Terminal Bench和Computer Use等基准测试正是专门评估模型在此类场景下「动手能力」的标准，它们模拟真实的自动化任务，要求模型在无人监督的情况下完成跨系统操作。Agentic能力的评估难度远高于传统语言理解任务，因为它要求模型在部分可观测、存在随机性的环境中维持长时间一致的目标追踪，同时处理工具调用失败、中间状态异常等边缘情况。Sonnet 5能够规划任务、调用浏览器和终端等各类工具，并以数月前只有更大更贵模型才能达到的水平自主运行。

同时，官方还为其配备了高达100万token的上下文窗口。这一数字意味着模型可以在单次对话中处理约75万个英文单词，相当于数本长篇小说的体量——对代码库分析、长文档摘要、多轮复杂Agent任务尤为重要。然而，百万级上下文窗口背后隐藏着严峻的计算成本问题：标准Transformer架构的注意力机制（Self-Attention）计算复杂度为O(n²)，即上下文长度翻倍，计算量增加四倍。为实现百万级上下文，业界开发了稀疏注意力（Sparse Attention）、滑动窗口注意力（Sliding Window Attention）等多种近似方案，但即便经过优化，超长上下文推理的实际延迟和成本仍远高于短上下文场景。早期GPT-3的上下文窗口仅有2048个token，如今百万级窗口已代表行业前沿水准。

从定价上看，Sonnet 5也颇具吸引力。截至2026年8月31日，享有每百万输入token 2美元、每百万输出token 10美元的介绍性价格；之后将上调至输入3美元、输出15美元。表面看，这是一款「性价比拉满」的日常主力模型。

隐藏的Token陷阱：低价是幻觉吗？

然而，真正的问题就藏在那份「脚注」里。实测者指出，Sonnet 5切换到了Opus 4.7的分词器（tokenizer），这意味着同样的一段文本，现在会被切分成大约1.1倍到1.3倍于以往的token数量，具体取决于内容类型。

理解这一问题需要了解分词器的工作原理：分词器（Tokenizer）是大语言模型将原始文本转换为模型可处理的数字序列（token）的核心组件，也是整个pipeline中最容易被用户忽视、却对实际成本影响最深远的环节之一。现代LLM主流采用字节对编码（BPE，Byte Pair Encoding）算法：从单字符词表出发，通过统计语料中最高频的字符对并反复合并，逐步构建出能高效表示训练语料的词表。

词表的构建策略直接决定了分词的「激进程度」：当BPE算法在训练时被允许进行更多轮次的合并（即采用更大词表），常见词汇和短语会被压缩为单个token，分词效率更高；反之，若新分词器的合并策略更为保守，则相同文本将被切分为更细粒度的子词单元，token数量随之膨胀。词表大小（vocabulary size）直接影响分词粒度——Anthropic的Claude系列词表规模约为10万量级，当分词器从一个较为「合并激进」的配置切换到更细粒度的版本时，同一段文本的token数量会显著膨胀。这种变化在代码场景中尤为明显：编程语言中大量特殊符号、缩进、变量名等在不同分词策略下的切分差异可达30%以上。Anthropic此次将Sonnet 5切换至Opus 4.7的分词器，意味着其词表结构发生了变化，导致相同输入文本所消耗的token数量显著增加，在实际使用中直接抬高了用户的综合成本。

值得一提的是，分词器并非单纯的技术工具，它的设计哲学直接反映了模型研发团队对「效率」与「表达力」的权衡取舍。OpenAI的tiktoken从GPT-2时代的5万词表扩展至GPT-4的10万词表，显著提升了代码和多语言场景的分词效率；而Google的SentencePiece则以语言无关性见长，对中文、日文、阿拉伯文等非拉丁语系语言有较好的支持。分词器的「版本迁移」在LLM发展史上并不罕见——OpenAI在从GPT-3升级至GPT-3.5时也曾调整分词策略，导致同等内容的token消耗出现波动。Anthropic此次的操作在技术上有其合理性（更精细的分词有助于提升模型对复杂语言结构的理解），但在商业透明度上却引发了用户质疑：这一变更未在发布说明的核心位置予以显著标注，而是以脚注形式低调呈现，使得不少开发者在实际部署后才意识到成本已悄然上升。这一教训也提示开发者：在集成新版模型前，应当主动检查分词器版本变更说明，并用真实业务语料进行token消耗基准测试。

换句话说，虽然单价看起来下降了，但同样的prompt会消耗更多token，实际综合成本在某些场景下会远超预期。对于每日调用量达数百万次的企业用户而言，10%-30%的token膨胀意味着真实账单的显著增加，远比表面标价更能体现模型的实际使用成本。实测者犀利地指出，Anthropic的介绍性定价「在设计上就是为了在分词器变更后维持成本大致中性」——这是一步相当聪明的商业操作，却也让「便宜」二字打了折扣。

在真实世界的基准中，问题进一步暴露。CursorBench由AI编程工具Cursor团队开发，代表了新一代「以真实工程任务为中心」的模型评估范式，是对传统基准（如HumanEval、MBPP）的重要补充与升级。传统编程基准通常采用孤立函数填空的形式，题目规模小、上下文单一，难以反映真实软件工程的复杂性。CursorBench则着重评估模型在跨文件依赖的代码补全、存量代码库的Bug定位与修复、接口设计与重构以及多步骤调试循环等场景的表现，这些任务更贴近工程师日常工作流，因此其排名往往与孤立基准存在显著差异。

值得注意的是，CursorBench的评分机制也更接近工程实践：它不仅考察代码是否通过单元测试，还会评估代码是否符合已有代码库的风格约定、变量命名是否与上下文一致、修改是否引入了新的依赖冲突等维度——这些正是LLM在真实代码协作场景中最容易暴露短板的地方。Sonnet 5在该榜单上仅排在第13位，对于Sonnet系列一贯主打「代码强手」的定位而言，构成了显著的期望落差。要知道，Sonnet系列一直以来的核心卖点，就是在保持性能的同时比Opus更快、更便宜。但如今Sonnet 5的成本优势被大幅压缩——它相较Opus 4.8 Max仅便宜约72%。

实测者由此提出了一个尖锐的疑问：既然只需多付出边际成本就能获得Opus 4.8显著更强的性能，那么继续使用Sonnet 5用于日常工作还有什么意义？「Sonnet 5可能是有史以来token效率最低的模型，尤其是在max effort模式下——它烧token的速度几乎和Opus一样快，却给出了更弱的结果。」

实测环节：喜忧参半的表现

为了验证模型的真实能力，实测者使用自建的提示词库和World of AI基准工具，对Sonnet 5进行了多维度测试。

macOS克隆：意外的亮点

在macOS界面克隆任务中，Sonnet 5的表现出乎意料地好。它生成了带有登录页、通知系统、可切换明暗主题、更换壁纸的完整桌面环境。顶部菜单栏基本可用（虽有小瑕疵），底部Dock栏做工精良，各应用图标均以SVG绘制，观感不俗。

更难得的是，Launchpad、Safari、Messenger、邮件、照片、日历、备忘录、地图、音乐等应用大多可正常运行，甚至还生成了一款可玩的FPS射击小游戏、终端、计算器和文本编辑器。不过代价是——整个过程在workbench中耗时约40分钟，并在max模式下消耗了大量token，效率极低。这一现象与百万级上下文窗口的计算特性密切相关：随着对话历史积累，每一轮生成都需要对全量上下文进行注意力计算，受Transformer注意力机制O(n²)复杂度影响，成本随任务进行呈非线性增长——这也提示开发者，在设计Agentic工作流时，上下文压缩和记忆管理策略与模型选择同等重要。

Minecraft与前端：中规中矩

在Minecraft克隆测试中，Sonnet 5采用了独特的材质包风格，水体动态可运行，还生成了村民、苦力怕等不同生物。但问题也不少：方块破坏没有动画、缺少物品栏系统、没有无限地形生成。实测者给出6.5分的评价——原创材质值得肯定，但整体功能有限。

前端方面同样令人失望。在生成SaaS落地页的任务中，虽然滚动触发等组件模仿了Anthropic的设计风格，但页面并不功能完整，左上角组件甚至未能正确渲染。实测者直言，开源模型GLM 5.2都能做出更好的前端。

SVG生成：最明显的短板

如果说前面的测试还算喜忧参半，那么SVG生成环节则是彻底翻车。SVG（可缩放矢量图形）生成是对大语言模型空间推理能力的极端考验，其难度根源在于它要求模型具备一种人类设计师依赖视觉反馈才能完成的能力——在纯文本空间中构建精确的视觉心智模型。SVG文件以XML格式描述几何图形，核心元素包括路径指令（M移动、L直线、C三次贝塞尔曲线、A弧线等）、变换矩阵（translate、rotate、scale）和视口坐标系。

生成一辆汽车侧视图需要模型同时处理：车身轮廓的贝塞尔曲线参数计算、车轮圆形的圆心坐标与半径比例、玻璃反光的渐变填充，以及各部件的层叠顺序。这一挑战的本质是一个**「无反馈的视觉规划问题」**：人类设计师在绘制SVG时可以即时预览效果并反复调整，而LLM必须在不执行代码的前提下完整预测最终渲染结果，这要求模型将数字坐标、曲线控制点与抽象视觉形态之间的映射关系内化为参数知识。目前主流LLM在复杂SVG生成任务上普遍表现欠佳，核心原因有三：其一，训练语料中高质量的SVG代码样本相对稀少（相比HTML、Python代码少几个数量级）；其二，SVG路径指令的语义与视觉效果之间存在高度非线性映射，微小的参数误差可能导致图形完全变形；其三，现有的代码预训练目标（预测下一个token）并不直接优化视觉准确性。这也是SVG生成常被用作区分模型「真实创意能力」与「表面流畅性」试金石的核心原因。

从更宏观的视角看，SVG生成能力的短板也折射出当前LLM训练范式的一个根本性局限：现有的自回归预训练框架天然擅长处理具有线性结构的序列化知识（如文本、代码逻辑），但对于需要整体性空间感知的任务（如图形设计、建筑布局、物理仿真）则存在系统性弱点。这一局限并非某个特定模型的缺陷，而是整个技术路线的共同挑战——无论是GPT-4o、Gemini Ultra还是Claude Opus，在生成复杂SVG时都会出现比例失调、路径错乱等问题，差异仅在于程度。部分研究者认为，解决这一问题的根本路径在于引入「执行反馈」机制：让模型在生成SVG代码后能够调用渲染引擎获取视觉结果，并基于此进行自我修正——这正是Agentic工作流框架在创意生成领域的潜在应用方向。Sonnet 5在Agentic能力上的提升，理论上应当有助于改善此类任务，但此次实测结果表明，当前版本离这一目标仍有相当距离。

实测者要求生成一辆BMW M4 CS的侧视图，即便在X-High设置下，Sonnet 5的输出也惨不忍睹——比例失调、姿态怪异，完全没有体现出宝马应有的品牌辨识度。相比之下，Opus至少能勾勒出主体结构和车型特征。

实测者对此表示强烈失望，认为在创意任务上，Sonnet 5的设计品味甚至不及GLM，应当排在GLM 5.2之下。

结论：Sonnet 5值得切换吗？

综合来看，实测者给出的评价相当直接：Claude Sonnet 5「彻底令人失望」。除了官方宣传的自主化工作流改进外，它并没有带来许多人期待的那种飞跃。所谓的低价，因为新分词器的存在而大打折扣——你消耗了更多token，却得不到匹配的结果，这使得在几乎所有任务上都很难找到不用Opus 4.8的理由。

当然，需要理性看待的是，这只是单一测评者基于自建基准工具的主观评价，Sonnet 5在自主Agent场景下的官方数据依然亮眼，实际价值仍需更多独立评测交叉验证。但这次实测至少提醒我们一个重要原则：不要只看单价，要看真实的综合成本。 分词器的变更是一个容易被忽视却影响深远的细节——它悄无声息地改变了每一次API调用背后的实际账单，而这种变化往往不会出现在任何宣传标题中。

对于每日调用量达数百万次的企业用户而言，选择AI模型时，分词效率应当与模型性能同等纳入考量维度。在此推荐采用TCO（总拥有成本）框架进行决策评估——TCO源自Gartner于1980年代提出的IT采购方法论，在AI模型选型场景中，它不仅包含直接的API调用费用，还应涵盖：分词效率差异导致的隐性成本、延迟增加对业务SLA的影响、上下文窗口利用率、模型迁移的工程人力成本，以及因模型输出质量下降导致的人工复核成本。具体而言，企业技术团队在评估模型迁移成本时，应当使用自身业务的真实prompt样本（而非官方示例）对候选模型进行分词统计，计算实际token消耗变化比例，再结合单价计算综合成本，才能得出真正有参考价值的TCO对比结论。

值得关注的是，TCO分析在大语言模型场景下呈现出传统软件采购中从未遇到过的新型成本维度。在传统SaaS采购中，TCO的核心变量相对固定（许可费、实施成本、运维人力等）；而在LLM API场景下，成本结构具有高度动态性：同一个prompt在不同模型版本下的token消耗可能差异显著（如本次事件所示），模型输出的随机性导致相同任务的token消耗存在统计分布而非固定值，以及不同业务场景（对话式交互 vs. 批量文档处理 vs. 长上下文分析）下的成本结构截然不同。这促使业界催生了专门的「AI FinOps」实践：部分头部企业已建立专职的LLM成本工程团队，通过prompt压缩、上下文缓存（Context Caching，Anthropic和Google均已推出此功能）、模型路由（根据任务复杂度动态选择轻量或重量级模型）等手段，将LLM API支出压缩30%-60%。对于中小型开发团队而言，在集成新模型前建立基础的token消耗监控体系（如使用LangSmith、Helicone等可观测性工具），是控制隐性成本的最低成本路径。

实测者的最终建议是：对于绝大多数任务，继续使用Opus 4.8，才能获得你真正期待的效果。而对于Anthropic而言，Sonnet 5这次略显仓促的发布，或许也让外界更加期待其即将到来的下一代模型。

核心要点

核心要点