大模型升级被指仅为外层流程优化

背景

近期，大型语言模型（LLM）的版本迭代频繁，尤其是 Claude 和 GPT 系列模型，几乎以月甚至周为单位进行更新。然而，每次更新后，社区用户普遍反馈新模型对 5 小时用量（5H）的消耗显著增加，且输出质量提升并不与消耗增长成正比。这一现象引发了关于模型升级本质的讨论：版本更新究竟是对基座模型本身的改进，还是另有蹊跷？一位来自 LINUX DO 论坛的长期 AI 实践者，基于自身自研的 5 条研发 harness（元问题、设计、研发、测试、模拟部署）的使用经验，提出了一种个人猜测——模型升级可能主要是在优化基座模型外层的 harness 层，而非模型架构或核心算法本身。

核心内容

原作者认为，真正的模型升级应当像 DeepSeek 那样，至少在以下三条路线之一发生实质变革：

• 模型架构升级（如 Transformer 变体）
• 核心算法升级（如训练策略、推理机制）
• 内在业务流程升级（如数据流、模型内部决策链）

若通过以上方式升级，对于相同的任务，消耗应基本持平或仅小幅增加，同时展现出更智能的结果。

然而，近半年来 Claude 和 GPT 的版本更新（如 Opus 4.6 → 4.7 → 4.8、Sonnet 4.6 → Sonnet 5 等）呈现出与上述规律相悖的现象：每次更新后，5H 用量消耗剧增。原作者由此提出猜测：这些模型的底层基座（如 Opus 4 基模、GPT-5 基模）可能并未大幅变动，而是模型外面包裹了一层额外的 harness（类似工作流管线）。每一次“模型升级”，实际上是在优化这层 harness 的内部环节，例如增加检查点、多复核逻辑，或引入强化学习循环（Ralph loop）以提升输出质量。这本质上等同于传统 Web/App 的功能迭代，因此能做到每 1-2 个月甚至每周升级一次。

该猜测还解释了另一个事实：Sonnet 4.6 直接跳到 Sonnet 5，而没有中间的 Sonnet 4.7/4.8。原作者推测可能是 Sonnet 的 harness 团队被抽调到了 Opus 项目，以集中资源争夺大模型头把交椅。

此外，该猜测也能逻辑自洽地解释消耗剧增的原因：环节增加必然导致计算和 token 消耗上升。以前用户输入 prompt，模型直接输出低质量结果，然后轮到用户再改进；现在模型自带的 harness 内部加入了类似 Ralph loop 的自动化循环，相当于将手动的反复调试转换为自动化过程，代价是消耗 token 更多。

原作者进一步指出，如果该猜测成立，便能更好理解为什么 DeepSeek 成为“大模型斩杀线”——DeepSeek 是纯模型，没有外部 harness，用户需要自己构建 harness。原作者体验表明，DeepSeek pro 配合自研 harness（high 级别），效果远超 Sonnet。同时，注意到 DeepSeek 团队也在持续招聘 harness 相关人才，并正在开发 DeepSeek Code，暗示未来 DeepSeek 也可能走向“基模 + harness”模式，以实现模型工程化的快速迭代。

关键要点

• 作者质疑：Claude 和 GPT 的频繁版本升级可能不是模型架构或算法本身的升级，而是基座模型外层的 harness（工作流/检查管线）迭代。
• 证据一：每次升级后 5H 用量消耗剧增，这与“同等任务消耗略增但智能显著提升”的预期不符。
• 证据二：升级节奏快（1-2 个月甚至周更），符合功能迭代而非模型本质变革的节奏。
• 证据三：Sonnet 跳过 4.7/4.8 直接到 5，疑似 harness 团队资源调配所致。
• 作者提出：harness 层面的升级包括增加检查点、多复核、Ralph loop（强化学习循环）等，将手动调优自动化，导致消耗上升。
• 对比 DeepSeek：DeepSeek 是纯模型，没有 harness；用户需自建 harness，且效果可以超越带 harness 的闭源模型。
• DeepSeek 团队正在招聘 harness 人才并开发 DeepSeek Code，暗示未来可能采用“基模 + harness”模式。

意义与影响

这一猜测若成立，将重塑行业对 LLM 版本更新的认知：用户支付的“升级”可能并非模型智能的飞跃，而是工程化管线（harness）的迭代。对于开发者和提示词工程师而言，这意味着：

• 不同模型（如 Claude、GPT）的“版本号”需区分对待，不能简单视为模型能力提升；在选择模型时，应考虑其是否内置了 harness 以及 harness 的复杂度。
• 开源或国产模型（如 DeepSeek）作为纯模型，虽原生能力可能不如带 harness 的闭源模型，但通过自行设计 harness 可以实现超越，这为技术能力强的团队提供了定制化优势。
• 行业趋势上，闭源厂商可能进一步将“模型 + harness”作为产品护城河，而开源社区或将发展出标准化的 harness 框架，降低使用门槛。
• 对模型评估标准提出挑战：传统的基准测试（如 MMLU、HumanEval）可能无法区分基座模型与 harness 的贡献，需要设计专门的评估方案来剥离二者影响。