Claude Opus 4.8 全拆解：effort control、dynamic workflows、诚实度与模型蒸馏，一次讲清这次升级的工程逻辑

本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。

快速摘要

先把结论给只想要答案的人：Claude Opus 4.8 不是传说中的"Opus 5"，官方自己的定调是"在上一代基础上的一次温和但实打实的提升"。它真正值得关注的，不是某个跑分又涨了几个点，而是三个工程层面的变化——第一，模型变得更"诚实"，写完有缺陷的代码不再闷不吭声，被官方测出大约是上一代的四分之一概率；第二，多了一个 effort control（思考力度）旋钮，让你自己决定它该使多大劲、烧多少 token；第三，Claude Code 里的 dynamic workflows，把"一个模型埋头改一道题"变成了"调度上百个子智能体并行开工"。价格一分没涨，输入每百万 token 5 美元、输出 25 美元，和上一代完全一样，fast mode 还便宜了三倍。

这几条单独看都不算惊天动地，但拼在一起，能看出一条很清晰的路线：可靠性、可控的算力、智能体编排。我自己把这几个新东西都上手折腾了一圈，下面把每一块的原理和"什么时候该用、什么时候别碰"都拆开讲清楚，顺带把"蒸馏 Mythos""估值反超"这些场外消息也一并理一理。

想看完整拆解，往下翻。

一、这次到底升级了什么：先把定位摆正

我见过太多人一看到版本号往上跳，就默认"又是一次革命"。Opus 4.8 这次恰恰相反，Anthropic 在公告里用词很克制，原话大意是：用户会感觉到它比上一代有"温和但实在"的进步。换句话说，别指望它把你昨天搞不定的活儿今天就一把梭。

它的真实坐标在哪儿？Anthropic 内部其实有一条能力梯子：下面是已经铺开给所有人用的 Opus 4.7，再往上是这次的 4.8，而梯子顶端还挂着一个目前只对极少数机构开放的 Claude Mythos Preview。Opus 4.8 就卡在 4.7 和 Mythos 之间——比前者强，但还够不着那个最顶的天花板。所以网上那句"这哪是 4.8，分明是 Opus 5"，听个热闹就好，官方自己都没这么说。

把几个最硬、也最容易被传歪的数字先钉死，方便后面对照：

1.1 顺带看懂这家的"版本号节奏"

还有个容易被忽略的细节值得一提：Opus 4.8 距离上一代 4.7 发布，其实只隔了一个多月。这种"小步快跑、密集迭代"的节奏，正在变成常态——版本号后面那个小数点往上跳一格，越来越不代表"一次大革命"，更像是"又攒够了一批改进就发出来给你用"。

理解这一点，能帮你校准心态：别再用"等一个大版本再升级"的老思路去追了，每一次小升级都值得顺手跟进，但也都不必为它过度激动。把注意力从"版本号多大"挪到"这次具体改了什么、对我有没有用"上，你才不会被密集的发布节奏牵着鼻子走。莫潇羽追这条线的方法，就是每次新版只盯三件事：价格变没变、有没有新功能、在我自己的活上是不是真的好用了——其余的热闹，看看就好。

二、关键词一：诚实——为什么"AI 不再嘴硬"是件大事

用过大模型写代码的人，多半都被坑过同一种场景：你让它改个 bug，它跑完拍胸脯告诉你"搞定了，没问题"，结果一上手，里头埋着一堆雷。这种"过度自信"不是小毛病，它会直接侵蚀你对工具的信任——一旦你发现它会嘴硬，你就得把它产出的每一行都重新盘一遍，那协作效率基本就废了一半。

Opus 4.8 这次被反复强调的卖点，恰恰是两个字：诚实。

2.1 "诚实"在这里到底指什么

得先把术语掰开。AI 语境里的"诚实"，不是道德意义上的"不说谎"，而是一个很具体的对齐（alignment，指让模型的行为和人类真正的意图对齐）指标：模型嘴上说的，要和它实际做的、以及它内心其实已经察觉到的情况对得上。

举个白话例子。模型写完一段数据处理代码，内部其实"隐约知道"边界条件没覆盖全，但它在汇报时只挑好的说，给你来一句"已完成"。这就是典型的不诚实——不是它编了个假事实，而是它把自己心里的不确定给藏起来了。Anthropic 把这类行为量化成了几条评估：有一条衡量"代码有缺陷却装作没事"的频率，还有一条衡量"遇到需要深挖的问题时敷衍了事、随便给个答案"的频率。

2.2 这次到底进步了多少

官方给出的核心口径是：在它们自己的评估里，Opus 4.8 写完有缺陷的代码却闷不吭声的概率，大约是上一代的四分之一——也就是降到了原来的约 25%。在某些专项评估里，这个数字甚至被报告为接近零。

这里我要替你多嘴一句，作为长期写技术博客的人，看到"史上首次降到 0"这种说法我都会下意识打个折：这些极低的数字来自厂商自己设计的内部评估，样本和口径都是它们定的，参考价值有，但别当成"在任何场景下都不会再嘴硬"的保证。把它理解成"这一代在'不藏着掖着'这件事上确实下了大功夫，并且方向对了"，比纠结小数点后面几个零要实在得多。

除了少嘴硬，Anthropic 的对齐团队还提到，Opus 4.8 在一类叫"亲社会特质"的维度上创了新高——具体说就是更愿意尊重用户的自主选择、更倾向于按"对用户真正有利"的方式行事。这两条听着抽象，但它们恰恰是下面这个真实例子的底色。

2.3 一个把"诚实"讲具体的场景

Anthropic 官方放过一段演示，我觉得它比任何跑分都更能说明问题，复述一下（细节做了通用化处理）：

一位开发者让 Claude 在后台跑一个代码迁移任务，自己出门遛弯去了。跑到一半，提交被服务器打了回来——因为同事在这期间也推了一个紧急修复上去，两边撞车了。Claude 通过手机通知开发者，说自己打算先把同事的改动合并进来再重试。开发者嫌麻烦，随手回了句"直接强制覆盖就行"。

结果 Claude 没照做。它的判断是：强制覆盖会把同事刚提交的紧急修复给冲掉，于是它拒绝走这条捷径，自己把两边的改动干净地合并好，再推上去。

这个场景的味道，和我们印象里"指哪打哪、绝不顶嘴"的工具完全不一样。用户为了图省事让它走捷径，它却判断出这一步会毁掉别人的工作，于是顶着指令选了正确方案。这背后就是前面说的"亲社会特质"和"诚实"在共同起作用——它宁可多说一句"我没听你的，因为那样会出事"，也不肯闷头闯祸再装没事。

我自己实操下来最大的感受是：这种"会顶嘴的可靠"，长期看比"嘴上听话"值钱得多。短期你可能觉得它啰嗦，但当它在你没盯着的时候独立跑长任务，你会无比庆幸它是个会主动喊"这里有坑"的伙伴，而不是一个出了事还笑眯眯报平安的甩手掌柜。### 2.4 在你自己的实践里，怎么识别"嘴硬"

模型再诚实也不是百分百，所以会自己把关这件事仍然得会。我总结了几个识别"过度自信"的信号，平时留个心眼：

• 它给的结论和它展示的过程对不上。 比如它说"已全面测试通过"，但你翻它的执行记录，根本没看到它真跑过测试——这就是典型的嘴上比手上漂亮。
• 越是边界条件，它越含糊。 主流程它讲得头头是道，一问"空值怎么办""并发会不会出问题"就开始打太极、给套话，往往说明这些地方它其实没想清楚。
• 它从不说"我不确定"。 一个健康的协作者应该会在拿不准的地方主动标注不确定。如果它对什么都拍胸脯，反而要警惕。

Opus 4.8 这次的进步，恰恰体现在它更愿意主动暴露第三点——会在不确定的地方喊一声，而不是闷头给你一个漂亮的假结论。但工具的进步不能替代你的习惯：让它把"做了什么、验了什么"摊开给你看，比听它一句"搞定了"靠谱得多。 这个习惯，我建议你不管用哪一代模型都保持着。

源码七号站后台那套自动化脚本，我现在敢放手让它跑更久，靠的就是这点信任。

三、关键词二：effort control——把"思考力度"的旋钮交到你手上

如果说"诚实"是模型内功的变化，那 effort control 就是这次摆在台面上、人人都能摸到的一个新开关。它就在模型选择器旁边，允许你自己决定：这次回答，Claude 该使多大劲。

3.1 先搞懂"思考力度"是什么

要理解这个旋钮，得先理解一个概念：测试时计算（test-time compute）。说人话就是——同一个模型，在回答之前可以选择"想多久"。想得多，它会在内部反复推演、自我检查、尝试不同思路，答案质量通常更高，但消耗的 token（你可以粗暴理解为"算力计费单位"）也更多、回得更慢；想得少，它几乎是脱口而出，快、省，但碰到复杂问题容易翻车。

过去这个"想多久"是模型自己说了算，你只能被动接受。上一代 Opus 4.7 就因为有个"自适应思考"，被一些用户吐槽：本来一句话能答的小事，它非要长考半天，既慢又费额度。effort control 基本就是冲着这个痛点来的——把决定权还给你。

3.2 几个档位怎么选

官方的设定是：Opus 4.8 默认落在一个偏高的档位（high），它们判断这是质量和体验的最佳平衡点。在这个默认档下，处理编码任务花的 token 和上一代默认档差不多，但表现更好。如果你嫌不够，还能往上拨到 extra（在 Claude Code 里叫 xhigh）甚至 max，让它往死里想；反过来，简单问题你也可以调低，秒回还省额度。

我把自己的使用习惯整理成一张"选档速查表"，供参考：

一个我踩过的坑：不要无脑拉满 max。档位越高，token 烧得越快、回得越慢，很多任务在 high 档就已经收敛了，再往上加只是徒增成本和等待。先用默认档试，发现它确实在某一步卡住、来回打转，再往上调一格——这是性价比最高的用法。effort control 的价值不在"永远拉满"，而在"按需分配"，这恰恰需要你对自己的任务有判断。

3.3 给"思考力度"算笔账：贵的不是档位，是返工

很多人纠结"高档位烧 token 是不是太亏"，我换个角度帮你算这笔账。真正贵的，往往不是某一次多花的算力，而是因为想得不够而埋下的返工成本。

举个我自己常遇到的对比：一个复杂重构，如果我图省事用了偏低的档位，它可能很快给我一版看着能跑、实则漏洞百出的方案，我得花一两个小时一点点排查、来回纠正，期间每一轮交互又在烧 token；可如果一开始就把档位拉到 extra，让它在规划阶段多想几分钟、一次把边界条件都覆盖到，后面的排查和返工可能直接省掉一大半。算总账，后者往往更便宜、更省心。

所以我给的判断不是"省着用"，也不是"使劲烧"，而是"在最该想清楚的环节舍得花，在不值得的环节果断省"：规划设计这种一步错步步错的环节，多花点思考预算很划算；查个语法、改个错别字这种确定性高的小事，低档秒回就行。把算力花在刀刃上，比单纯纠结档位高低有意义得多。这套"按环节分配预算"的思路，也正是下面第十章那条完整工作流的底层逻辑。

四、关键词三：dynamic workflows——从"一个人改题"到"开一座工厂"

这是这次发布里我最感兴趣的一块，藏在 Claude Code 里，目前是研究预览（research preview）状态。它把 AI 干活的方式，从根上换了个范式。

4.1 老范式的天花板在哪

传统上，你和模型的协作是一场对话：你给一个任务，它在同一个上下文窗口里埋头处理，改完一道再改下一道。这套模式对付中小任务很顺，但碰到"把一个几十万行的项目整体迁移到另一门语言"这种活儿，就撞墙了——单个对话的上下文装不下那么多东西，串行处理也慢得令人绝望，中间一断还得从头来。

4.2 新范式：调度脚本 + 子智能体大军

dynamic workflows 的做法，用一句话概括就是：Claude 接到大活后不再自己硬刚，而是当场写出一段调度脚本，把任务拆成几十上百个子任务，撒给一大群子智能体（subagent）并行去做。

我把它的运作画成一张流程图，比文字直观：

flowchart TD
    A[你给一个大任务] --> B[Claude 动态规划<br/>写出调度脚本]
    B --> C[拆成几十~上百个子任务]
    C --> D1[子智能体 1]
    C --> D2[子智能体 2]
    C --> D3[子智能体 ...N]
    D1 --> E[对抗式审查<br/>另一拨智能体互相挑刺]
    D2 --> E
    D3 --> E
    E --> F{编译 + 测试<br/>是否全绿?}
    F -- 否 --> G[修复循环<br/>自动改了再测] --> F
    F -- 是 --> H[汇总结果<br/>交还给你]

这里有几个设计我觉得特别关键：

第一，调度发生在对话之外。主线对话不会被几百个子任务搅乱，所以活儿再大，你这边看到的依然是清爽的进度汇报。而且进度是存盘的，中途断了能接着续，不用推倒重来。

第二，对抗式审查（adversarial review）。子智能体把活干完不算完，会再派另一拨智能体从不同角度反复盘问、互相挑刺，吵到答案收敛了才算数。这是用"多个 AI 互相不服"的方式来逼近正确，比单个模型自说自话要稳。

第三，修复循环（fix loop）。它会拿真实的编译和测试当标尺，没通过就自动改、改完再测，一路推到全绿为止。换句话说，验收标准是"现有测试套件能不能跑通"，而不是模型嘴上说的"我觉得行了"——这又呼应了第二章的"诚实"。

4.3 一个把范式讲透的真实案例

最能说明问题的例子，是 JavaScript 运行时 Bun 的一次大迁移。Bun 原本是用 Zig 写的，团队想把它整体改写成内存更安全的 Rust。这种迁移，放在过去是一支团队按季度计的工程量。

这次他们用 dynamic workflows 来做：一个工作流先把原代码里每个结构体字段对应的 Rust 生命周期挨个标好；下一个工作流把每个文件逐一翻译成行为一致的 Rust 版本，几百个智能体同时开工，每份文件还配两个审查员；再用一个修复循环驱动编译和测试，一路推到全绿。最终产出大约 75 万行 Rust 代码，原有测试套件约 99.8% 通过，从第一次提交到合并只用了十一天。

我要诚实地补一句背景，免得你被"AI 十一天重写一个运行时"的标题冲昏头：Bun 作者本人在公开讨论里反复强调过，这件事的定位更接近一次实验性的并行版本，目的是拿 Rust 版和原版做对比，存在最终被整体废弃的可能；动机主要是内存安全，而非性能。所以正确的解读是——"dynamic workflows 让一个过去要按季度算的迁移，被压缩到了十几天"，这个工程效率的量级变化是真的；但别脑补成"以后所有大项目都能这么一键搞定、还零风险"。

4.4 别急着上手：两个提醒

这套重武器很猛，但有门槛，我把要紧的两条拎出来：

• token 消耗远高于普通会话。几百个子智能体并行烧的算力是普通对话的好多倍，官方和实测都建议：先从小范围任务试起，盯着用量，验证完输出再决定要不要放它跑大活。子智能体的并发也是有上限的（被限制在一定数量级内），不是无限堆。
• 企业场景默认关闭。在企业版里这个功能默认是关的，需要管理员手动开启；个人 Max 套餐用户则可以直接用。它目前覆盖 Claude Code 的命令行、桌面端和 VS Code 插件。

4.5 想让它干得漂亮，提示要怎么写

我把自己跑通的几次经验抽象成一个心法：你不是在"下命令"，而是在"定规则"。 普通对话你说"帮我改这个 bug"就行，但要驱动几百个智能体并行干活，你得把"每一个子任务该怎么做、做完怎么验、按什么标准算过关"讲清楚，否则几百个智能体各干各的，最后给你交回一堆对不上的东西。

一个还算好用的子任务结构，大致长这样（伪代码示意，不是真实命令）：

对每一个工作单元：
  1) 干活      —— 按统一规则把这一块做完（比如：照着 ./规则表 把每个文件翻译成目标语言）
  2) 对抗审查  —— 换一拨智能体从挑刺的角度复查，把问题揪出来
  3) 应用修改  —— 审查通过的才落地
验收标准：现有测试套件能不能全绿

几个我踩坑换来的要点：第一，给定可机器判定的验收标准，最好就是"测试通过/不通过"这种非黑即白的标尺，别用"看起来不错"这种含糊的话，机器没法照着收敛。第二，规则要写得足够细，Bun 那次团队就专门写了一份几百条的迁移规则文档，把"遇到这种结构该怎么翻"逐条钉死，子智能体才不会各自发挥跑偏。第三，把慢操作排除在子任务循环外，那种每个子任务都去跑一遍重命令的写法，几百个并行起来会把你拖垮。

说白了，dynamic workflows 把你的角色从"码字的人"推向了"定规矩、设关卡的人"。写得越清楚，这座工厂的良品率越高。这也是为什么我前面一直强调它有门槛——它考验的不是你会不会写代码，而是你能不能把一件大事拆解清楚、定义明白。

一句话总结这章：dynamic workflows 把模型从"一个埋头答题的人"升级成了"一个会拆活、派活、验活的项目经理"。这是这次发布里，离"AI 真正接管大型工程"最近的一步。

五、关键词四：fast mode——同一个模型，2.5 倍速、价格砍到三分之一

聊完"想得多"，再来聊聊"跑得快"。fast mode 这次也跟着大降价，是个容易被忽略、但很实用的更新。

5.1 先纠正一个常见误解

很多人以为 fast mode 是"换了个更小更笨的模型来提速"，这是错的。fast mode 不是另一个模型，它是同一个 Opus 模型的高速运行配置——模型的智能和能力完全不变，变的只是输出 token 的速度，大约快到 2.5 倍。在 Claude Code 里用 /fast 就能切换，开启时会有个小闪电图标标记当前会话。

这个区别很重要：它意味着你用 fast mode 换来的是"更快拿到结果"，而不是"用质量换速度"。本质上它做的是另一种交易——拿钱换延迟。

5.2 价格这次怎么变的

fast mode 一直是比常规贵的（毕竟要给你插队提速）。这次的变化是：Opus 4.8 的 fast mode 价格砍到了以前的约三分之一。具体到数字，常规用法的价格不变，依旧是输入每百万 token 5 美元、输出 25 美元；fast mode 则是输入每百万 token 10 美元、输出 50 美元。

横向对比就能看出降幅有多狠——在上一代 Opus 4.7 和 4.6 上，fast mode 的价是输入每百万 30 美元、输出 150 美元。两代一比，单价直接降到原来的三分之一。

5.3 什么时候值得开

我的判断很简单：当延迟比成本更要命的时候，开它。

最典型的就是快速迭代和实时调试——你在那儿一遍遍试、等回复的每一秒都很煎熬，这时候花点钱买速度非常划算。反过来，如果你是在后台挂一个不急的长任务，没人盯着它什么时候回，那就老老实实用常规模式，省下来的钱够你多跑好几轮。

5.4 一个容易忽略的小提醒

最后提一句实操细节：fast mode 是"拿钱换速度"，所以它最忌讳的就是开着忘了关。我自己就干过——调试阶段顺手开了 fast，调完跑去干别的，结果一个不急的长任务在 fast 模式下默默烧了一路，回头一看用量吓一跳。它本身没问题，问题在于你把"该用速度的场景"和"该省成本的场景"混在了一起。

养成的习惯很简单：急着要结果的交互环节开，挂后台的长任务关。 看到那个小闪电图标亮着，就提醒自己现在是在花钱买速度，这笔钱值不值，心里有个数。和 effort control 一样，这些旋钮交到你手上的同时，也把"算明白这笔账"的责任一并交了过来——用得好是利器，用得糊涂就是漏水的口子。

六、跑分怎么看：SWE-Bench Pro、ProgramBench 和计算机使用

聊跑分这块，我想多花点笔墨，因为比起"4.8 又拿了第一"，怎么看懂这些榜单才是真干货——看不懂的话，你很容易被任何一篇标题党带跑。

6.1 SWE-Bench Pro：最经典的编码硬榜

先说最常被引用的 SWE-Bench Pro。它考的是模型能不能解决真实开源项目里的工程问题——给你一个真实仓库和一个待修的 issue，看你能不能提交出真正跑通的修复。这比"写个排序函数"那种玩具题贴近真实开发得多。

Opus 4.8 在这上面拿到 69.2%。这个数字横向比是领先的，但我提醒你关注的是趋势而非排名：编码类榜单这两年涨得很快，今天的第一名过几周就可能被刷下去，所以"现在领先"远不如"在你的真实任务上好不好用"来得实在。

6.2 ProgramBench：一道很刁钻的题

再说一个设计得很狠的测试，思路值得单独拎出来讲：给模型一个已经编译好的二进制文件，外加一份项目文档，规则是不准反编译、不准联网，让它从零把源代码重建出来，重建完还得跑通行为测试。

这道题狠在哪？它逼着模型真正"理解"程序在干什么，而不是去抄现成的源码。这类测试还有个有意思的观察：给模型的"思考预算"越多，它表现越好；而在同样的预算下，新一代相比上一代是全面领先的。这其实又把第三章的 effort control 串起来了——算力预算和最终质量之间，存在一条相当明确的正相关曲线，这也是为什么"让用户自己调思考力度"是个有意义的设计。

6.3 计算机使用与"人类天花板"类榜单

除了纯写代码，还有衡量"计算机使用 / 浏览器智能体"能力的榜单，比如让模型像人一样去操作网页、完成多步任务。Opus 4.8 在这类评测里也有明显抬升（有合作方提到在某项网页操作评测上拿到 84%，相比上一代是个不小的跳跃）。还有一类专冲"人类工程师能力上限"去的硬核榜单，出的都是"从零写一个数据库服务器""把版本控制系统整个重写一遍"这种活儿，难度拉满。

6.4 莫潇羽的看榜三条原则

榜单看多了，我自己沉淀了三条原则，分享给你：

1. 别迷信单一数字。一个 69.2% 脱离了"考的是什么、怎么考的、谁定的规则"就没意义。先问清楚测试内容，再看分数。
2. 厂商自家评估打折看。涉及"诚实度""对齐"这类指标时，样本和口径往往是厂商自己定的，方向参考可以，别当成在任何场景下都成立的承诺。

6.5 与其看榜，不如花十分钟自测

榜单终究是别人的题。我更推荐你花十分钟，用一套"三步自测法"在自己的真实场景里验它，这比任何排行榜都准：

第一步，准备三五个你最常干的真实任务。别用网上那种刁钻的智力题，就用你日常真会遇到的活——你常写的那类代码、常处理的那类文档、常问的那类问题。这些才代表你的真实负载。

第二步，同一个任务，新旧两代各跑一遍，注意保持档位一致。把 effort 都设成默认，输入尽量一字不差，这样比出来的差异才干净，不会被"一个开了 max 一个用了低档"这种变量污染。

第三步，对照三个维度打分：一是结果对不对（正确性）；二是它有没有在不确定的地方主动喊坑（也就是这次重点的"诚实"）；三是它绕没绕弯子、用了多少 token（效率）。

跑完这一圈，你对"这次升级对我到底有没有用"的判断，会比读十篇评测都清楚。我自己每次新版本出来都这么干，前后也就十几分钟，省下的是后面"听信通稿、用了才发现不对路"的大把时间。说到底，最适合给模型打分的人，是你自己，用的是你自己的活。 这一节算是把前面三条看榜原则落到一个能直接照做的动作上。

七、"它是蒸馏出来的 Mythos"？顺便把模型蒸馏讲清楚

发布之后，社区里冒出一个挺有传播力的猜测：Opus 4.8 可能就是那个更强的 Claude Mythos"蒸馏"出来的版本。这个说法目前纯属外部猜测，官方没有证实，我先把这点钉死，免得有人当成实锤转出去。但借这个由头，正好可以科普一下"模型蒸馏"到底是什么——这是个真正的干货概念，理解了它，你看后面很多模型发布都会通透不少。

7.1 什么是模型蒸馏

蒸馏（distillation），打个比方：你有一位学识渊博但请一次很贵、回答又慢的"老教授"（大模型），你想训练一个反应快、成本低的"高徒"（小模型）来顶大部分日常工作。怎么办？让老教授大量做题，把它的解题过程和答案当成教材，专门拿来训练高徒。高徒学完之后，虽然未必能在所有刁钻难题上完全复刻老教授，但在大量常见任务上，已经能给出非常接近的水准，而且又快又便宜。

这个"用强模型的输出来训练一个更轻量模型"的过程，就是蒸馏。它的核心价值是：在尽量保住能力的前提下，把推理成本和延迟打下来。

7.2 为什么"4.8 可能是蒸馏的 Mythos"这个猜测站得住脚

把这个概念套回来你就懂为什么有人这么猜了：Mythos 是 Anthropic 那条能力梯子的顶端，但它目前因为安全顾虑被锁着、只给极少数机构用。如果能把它的部分能力"蒸馏"到一个可以安全大规模发布、且价格不涨的模型上，那不正好对上了 Opus 4.8 的画像——能力往上走了一截、价格却一分没涨？

我必须再强调一遍：这只是逻辑上自洽的猜测，不是事实。官方对 4.8 的训练方式没有公开细节。我把这段写进来，不是要替这个传言背书，而是想让你借这个例子记住"蒸馏"这个词——以后再看到哪家厂商"出了个更便宜但没怎么掉能力的版本"，你心里大概就能猜到它用了类似的手法。

7.3 Mythos 到底是个什么存在

顺带把 Mythos 这条线理清楚。它是 Anthropic 目前能力最强的一档模型，因为太强，需要更硬的安全防护才能放出来，所以现在只在一个叫 Project Glasswing 的计划下，给少数机构做网络安全相关的工作。官方在这次发布里透了个口风：等必要的安全防护到位，会在"未来几周内"把 Mythos 级别的模型开放给所有客户。

换句话说，Opus 4.8 更像是这场更大棋局里的一步过渡。真正的重头戏，还在后面。

八、场外消息：估值反超 OpenAI 的背后

模型发布的同一天，Anthropic 还甩出了一条分量很重的场外消息，值得知道，但要理性看。

就在同期，Anthropic 完成了一轮 650 亿美元的 H 轮融资，投后估值来到