Fable 之后：scaling + 分层

今天是 2026.7.2,Fable 重新解禁了。之前已经体验过一天的全 Fable 开发，模型强度相对了解了，但此时对 Fable 的理解更像是「大号 Opus」。但前两天尝试把 Opus 的工作流迁移到 Sonnet 5（跑分看起来接近），这才算是对 Claude 的整体模型有了解。

I. 先说模型 #

T0:Anthropic 的完整成熟金字塔 #

对于 Sonnet 5 和 Fable 5，核心点如下：

1. Sonnet 5 是和 Opus 同代基础做的模型，更新到 5.0 之后 tokenizer 统一了。
2. 对比 GLM 5.2 和 Sonnet 5 的性能，GLM 能做到极其相近的性能，这至少说明相同尺寸下国模并没有任何落后。
3. 对比 Opus 4.8 和 Sonnet 5 的性能，Opus 对问题的挖掘和规划远好于 Sonnet（即使是 Opus low 对比 Sonnet max）。
4. 同第三条，Fable 对问题的挖掘和规划远好于 Opus。
5. Sonnet、Opus、Fable 三个模型在「错误深度」的情况下都会出现急剧的性能下降。

我最核心的观点依旧是第五条，那就是 Anthropic 对三个模型已有了稳定明确的预期，并且对特定的任务深度进行了对应的加强，这让 Anthropic 的模型金字塔整体往上移动了一层（也就是 Haiku 直接弃坑，完全不适用）。

对于第五条的具体解释：

• 如果你询问 Fable 今天晚上吃什么，那么 Fable 会搜索你的记忆并且尝试泛化出一个超多分支超高深度的回答，但单从问题的结果上来看，他没有帮你做出晚上吃什么的决定。
• 如果你询问 Sonnet 服务器具体配置的部署，那么 Sonnet 会进行浅深度的搜索和更烂的总结，给你一个能够落地但是头脑简单的回答，能用，但他没有帮你设计出一个好的服务器架构。

这类金字塔的分层从最早的 Opus-Sonnet-Haiku 的命名中就能看出来，但进入 agent 时代后，Anthropic 对金字塔思路的理解深度和模型完成度远超其他厂商。具体的表现如下：

• 所谓的 Flash 尺寸模型和 Pro 尺寸模型的区分是对性能的简单缩小增加，有家族性但没有分层，最终导致更多用户一味地使用 Pro 来解决大多问题。
• 更多国产模型厂甚至没有足够的模型分层，更多是掏出一个旗舰模型然后吃一辈子，用所谓的思考深度做出分层（包括 GPT 5.5，很高兴 GPT 5.6 是正确的）。
• Anthropic 对各个任务难度进行了具体的训练，从而能做到三个模型的最优区间互相耦合，一方面锁定家族化的 API 使用，另一方面对工程化极其有益（即使是自己设计工作流也是如此）。
  • 如果一个 1T 规模的开源模型有着比 Sonnet 5 好 20% 的价格，我依旧会在 Claude Code 中使用 Sonnet，因为 Sonnet 的优势区间对我来说是可预期的。这点在稳定工作流中更加重要。
  • 小尺寸模型的灵感爆发（1T 是「小尺寸模型」）对整体工作流来说是毁灭性的，反而需要更严格的 skill 和 context 来限制。

综上所述，我会坚定地支持 Claude 为当前时代的最强 AI 产品，当然 AI 平均两个月就开创一个新的时代（prompt 和 skill 都被 loop 超过了，真是让人痛苦），习以为常了。

T0.5:OpenAI 的曙光，日出之前 #

此文写于 GPT 5.6 发布前，很高兴 OpenAI 也学习了这个架构。相对 Claude 的金字塔结构，GPT 的 5.5 系列以及直接停更的 mini 尺寸看起来就极其不足，尤其是 code 作用模型和通用模型的分流，在我看来是在妥协方案上投入过多资源。

但我依旧觉得 OpenAI 是绝对稳定的 T0.5 厂商，这就是因为 Codex。对于之前所说的稳定性，Codex 的 agent 架构是非常好的，这点对比会在之后具体说明。

在 GPT 5.6 发布之前，真的无法揣测什么。当前的模型跑分对模型能力的展示并不足够,10% 的性能提升可能没啥作用，而 Opus 和 Fable 之间 2% 的差距就是明确的两个等级的模型。所以说一切都要看 GPT 5.6 到底做得如何强大，以及 GPT 5.6 对 Codex 的适应性有多好。

T2：其他模型 #

相对于上述的两家，其他模型的差距在上个时代就已经被拉得过大（也就是 Opus 4.6 发布之前）。

• Claude 宪法说明了 Claude 对模型本质的科研和理解，他们将这部分理解转化为了准确的模型甜点设计。
• OpenAI 的图像集成相应特化了文字细节能力（图片多次修改后的噪点增加就是为文字精度做出的妥协），说明 OpenAI 这位巨人也开始认真思考模型的目标到底是什么（毫无意义的项目 Sora，不懂 OpenAI 为什么要去从 0 做社区）。

这两家的方法论已经过于领先，再叠加上专属 agent 的影响，我不认为你应该花时间在除了 Codex 和 Claude Code 之外的 agent 架构上，时间比 token 值钱，花一年半载时间优化一个开放框架只是表面功夫，实际上对模型的特调和适配才是永恒的重点。

这里值得说一句，DeepSeek 没有单列一档的原因是，他们尚未放出自己的 DeepSeek agent 架构，这点永远是核心，不然难以从头拼凑 agent 框架的设计。除了 DeepSeek 之外，其他的模型都严重地落后于时代，我当然希望我们能有一个强大的开源模型，甚至是开源模型系列，但现在看来绝大部分系列追求的是「每个尺寸模型达到 general 任务的 SOTA」，而不是真的做出一系列可用的模型。

多吐槽几句跑分：

正如我一直以来对科研界的厌恶，用一个 3B 尺寸的 Qwen2.5 在各种 toy benchmark 上做显著优化，本质上是另一种 overfit。现在看来 100B 到 1T 尺寸模型也普遍遇到了这个问题，通常使用 Claude Code 或者 opencode 框架，用精心设计的框架在特定跑分中获得 2% 到 1% 的领先，然后宣布自己成为了 SOTA。

这种乐此不疲的打打闹闹可以一直玩到 2077 年，但这对 AI 到底有何作用呢？投资人是相信 AI 的未来产业，而不是把 AI 公司当成一只特别花钱的足球队看待。

II. 世上从未有 "Open Harness" #

我们常说模型是需要被框架约束的，model + harness = agent，但这句话的解释相当匮乏。对于 Anthropic 和 OpenAI 这种稳定的大企业，他们能明确控制自己模型的风格和具体的特性，所以他们围绕此进行相应的 harness 构思和开发，从而做出自己对应的框架。所以说，model 和 harness 的关系并非是简单的堆叠，这两者的结合更接近于锻刀时候刀和刀柄的结合：刀有着对应的劈砍设计，而刀柄保证刀能够稳定地被用户掌控。在此处我对框架的评价正好和模型相反。

T0：稳定 Codex VS 狂野 Claude Code #

相当夸张的是，模型上有如此深入理解的 Claude，在实际使用体验上经常和更加混乱的 GPT 5.5 打成一团，根据不同的任务，用户会变得更加偏好 Codex 或 Claude Code。我们先来简单地对比一下两者的区别：

• Claude：奔放而又理智。 Claude 最高等级的模型通常在长规划能力上拥有极强的探索性和极强的管理能力，你可以看到 deep research 下 Opus 调用出 100 个 subagent 进行夸张地发散搜索，但最终汇总成简练干爽的 spec，也可以看到具体 UI 设计上 Opus 对 Sonnet 设计具体元素的掌控。Claude Code 的本质是限制好工具的调用，而不是限制 Claude 模型的发挥。 所以说我一直觉得 Claude Code 接入开源模型是很奇怪的行为，类似于撤掉一个本身走路不稳的人的拐杖，踉踉跄跄地走动。这部分稳定性的缺失在 Loop Engineering 大行其道的环境下带来了更大的性能差距。
• Codex：严肃的。 Codex 的整体设计严格地限制了模型的能力，并且极大幅度地强化了指令跟随能力，这点对于大部分实验室人员和数据分析专业，甚至是日常对电脑文件的整理，都是有大幅度优势的。但对应的，GPT 的相关自主性小了非常多，我认为小部分的影响来源于 OpenAI 对 GPT 的设计，但更大部分来源于 Codex 对框架的限制。

对于这部分实践，可以直接用我仓库中的 skill creator pipeline 来进行测试。这套 skill 本身针对 Claude 设计并且使用 Claude 进行 eval 流程，其中有很多要求模型自主判断并暂停的 loop 验证设计。在 Claude 中，这套 skill 搭配 Opus 可以快速自主地生成高质量 skill。

而如果在 Codex 中使用这套 skill，会出现极为严重的 token 浪费现象，因为 GPT 的 gate 要求他严格遵守 skill 中的指导性 loop，大概率你会看到 GPT 紧贴着我规定的默认设置来进行机械的循环，从而导致生成的 skill 中同时出现功能开发不完整和功能开发过度拟合。

这里可以提供一个简单的直觉性判断，帮助选购 Codex 和 Claude 的 200 刀价位套餐：

• 如果你知道自己要做什么，希望 Agent 和一个工具一样稳定可靠：请购买 Codex,Claude 会把项目导向自己希望的方向。
• 如果你知道自己的模糊想法，希望 Agent 和一个助理一样帮你完成概念的完整构建：请使用 Claude,Codex 会实现一个粗糙难用的 MVP。

这两家杰出的点在于，他们明确地给了模型团队和 harness 团队两个目标，并且这两个团队做出了相应的设计和执行。抛开手机远程操控和 computer use 等附加功能不谈，单纯地讨论代码框架的话，这两家依旧是断层的 T0，而本次我对框架的评价依旧没有 T1。

基于现在 GPT 5.6 已经变成三层分层架构的逻辑，我认为 Codex 当前的框架无法适配自家的三个模型。到最后的执行会导致底层模型做过于激进的「强制修复」（也就是无视 spec 进行无规范的修改），然后最高参数模型被框架强行拉回 prompt 要求。具体实践还是得看 Codex 怎么设计。

T2：开源框架和无头框架 #

这里所说的无头框架，就是泛指企业所构建出的、鼓励切换多种开源模型的框架。这部分框架被迫地需要去设计兜底的设定和情况，从整体设计上就需要考虑模型差异所带来的执行噪声。这导致框架的大头在抑制噪音上，而且这个算法还是一个粗暴的被动降噪算法。

• 对比 Codex：因为没有对应的模型，无法确定模型有奔放风格或是保守风格，必须指定相对中性的指令跟随，从而导致能力落后。
• 对比 Claude Code：相对添加了更多控制，但无法验证每个等级的模型对应能力如何，无法稳定地用 subagent 进行开发和降级，同时也缺少一个真正的旗舰模型来彻底控制大局。

其中最为无语的依旧是腾讯的 WorkBuddy，这个产品的 UI 设计在我看来依旧是年度最烂之一。不明意义的多次 UI 修改（内测时期我也尝试使用过，当时的设计更加诡异，还以为是美团为了 LongCat 这个名字特意设计的猫咪），整体上缺乏中心的设计，反用户的额度积分制度，但最终依靠和小程序的联动，以及和企业微信的暴力接入，已经成为了霸主之一。这多少说明当前依旧是一个以渠道为主的市场，国内用户在模型限制下对框架性能需求过低，才会闹出这种笑话。

T1*：豆包、GPT、Gemini、Claude 的多模态可能性 #

尤其值得点出的是这三个半家（Claude Design 算半个画图吧）所设计的框架，都带有了对模型厂商图片和视频能力的集成，从而导致他无法和传统的以 coding 或者 analysis 为基准的工程框架混为一谈。但我没有这方面的设计经验，更多就是 Claude 和 GPT 生成，不过插个眼，相信多模态能力集成进 agent 会带来新的机会。

III. 对 Loop Engineering 的一些杂项 #

• 对于 Loop Engineering，我认为多次循环和 spec 无法解决智力问题，如果一个模型的能力在 B 等级，那么不管如何循环他依旧只能进行 B 等级的任务，突然涌现出更高等级的理解是不稳定的，需要大量 token 来试错，反而是更高等级的模型能够在单轮的情况下一次解决问题（使用 subagent 进行上下文的拓展，保证不是 1M 都塞下项目代码）。
• 更多次的 loop 对 spec 和模型的能力需求巨大，即便使用 subagent 来做足够好的 context 隔离，并且使用实时更新的机制来进行 spec 的更新，这些改进都无法解决最基础的模型能力问题。
• 循环环节中，最后做反馈的 Attacker 很重要，一定要确保 context 隔离（其他部分的构建为了性能终究是要留下足够 context 利用上上下文能力）。当然，从始至终最重要的依旧是开始的 spec，然后是 attacker（检查 loop 是否完成），然后 engineer（具体构建），router 反而是保证好自动化地管理 temp 文件即可。

IV. 和 Fable 的对话 #