Esc
输入关键词开始搜索
News

OpenMythos：这是 Claude Mythos 的开源复原，还是一场工程化猜想？

OpenMythos：这是 Claude Mythos 的开源复原，还是一场工程化猜想？

原仓库：https://github.com/kyegomez/OpenMythos

动动侧 fork：https://github.com/DongDongBear/OpenMythos

核对说明：本文基于源码、GitHub 元数据、issues/PR、Anthropic 官方 Glasswing/Mythos 公开材料做交叉核验，不把 README 自述直接当事实。

速查卡

项目内容
一句话总结OpenMythos 不是 Anthropic Mythos 的“已证实开源复原”，而是一个踩中信息真空的工程化理论重建：代码里确实做了一个能跑的循环深度 Transformer 原型，但 README 对能力、成熟度和与真实 Mythos 的接近程度明显讲得比代码更满。
最重要的判断值得研究，不值得盲信。 它的价值在于把“looped / recurrent-depth transformer 能否解释 Mythos”这条研究线做成了可检查代码；它的问题在于工程质量、发布治理和核心 claim 验证都还没跟上热度。
价值评级A- 作为研究线索和行业情报值得跟；作为可直接复用的成熟开源底座，只能给 B- 甚至更低。
真正可验证的部分仓库存在、代码存在、确实实现了 Prelude + Recurrent Block + Coda 的循环结构，也确实写了 GQA、MLA、MoE、ACT、LTIInjection 等模块；仓库 1 周内爆到 1 万 star+。
不能直接当真的部分“Mythos 就是这种架构”“更多 loops 一定带来更强推理”“MLA 在这些配置下显著省 cache”“ACT 已实现 token 级动态省算”“这套 recipe 已被大规模训练验证”。这些都没有被 Anthropic 官方证实，且部分被社区实验直接挑战。
最值得盯的风险点文档和包元数据不一致、外部 PR 大量积压但 0 merge、无 release/tag/CI、核心 depth-extrapolation 叙事被 issue #28 的系统实验公开质疑。

为什么 OpenMythos 会突然爆

OpenMythos 的传播，不是因为它真的“破解了 Anthropic 内部架构”，而是因为它正好出现在一个极其适合爆红的窗口：

  1. Anthropic 先把 Mythos 的能力热度点燃了。 Project Glasswing 和 Claude Mythos Preview 官方公开材料已经让市场知道 Mythos 很强，尤其是在代码、agent 和网络安全方向，但几乎没有公开底层架构细节。
  2. 市场天然会追问：它到底为什么这么强？ 当官方只给能力，不给机制，社区就会自动进入“架构侦探模式”。
  3. OpenMythos 提供了一个可运行的答案。 不是一条 X 帖子，不是纸上猜想，而是一套 PyTorch 实现、训练脚本、变体配置和 README 叙事，足够让人转发、引用、二次传播。

所以它火的核心，不是“证据”，而是“解释力”。

更准确地说，OpenMythos 是一个 可执行的猜想载体。它填补的是信息真空，而不是官方披露。

先把边界钉死：Anthropic 官方到底公开了什么，没公开什么

先把官方层面的“真”和“猜”切开，否则后面所有讨论都会滑坡。

官方确实公开了的

Anthropic 官方 Glasswing 页面、Mythos Preview system card、risk report 与安全博客，可以确认以下几点：

  • Mythos Preview 真实存在，而且是 general-purpose, unreleased frontier model；
  • 它被限制在受限研究预览和防御性网络安全合作场景中，而不是普通公开产品发布；
  • 在多项代码、browser、terminal、网络安全相关 benchmark 上强于公开的 Claude Opus 4.6；
  • 它具有更强的 agentic/autonomous 使用能力；
  • 官方公开了较宽泛的训练信息，如 proprietary mix of public internet、public/private datasets、synthetic data，以及大量 post-training；
  • 官方评估重点集中在能力、安全、限制部署与风险缓解，而不是底层架构细节。

官方没有公开确认的

Anthropic 公开材料里 没有直接确认 以下说法：

  • Mythos 是 recurrent-depth transformer / looped transformer；
  • Mythos 的内部结构是 Prelude + Recurrent Block + Coda；
  • 它核心依赖 MoE；
  • 它使用 MLA 或 GQA 作为关键注意力机制；
  • 它采用 ACT halting、LTI stable injection、loop-index embedding、depth-wise LoRA 等机制；
  • “更多 loops = 更深推理 = Mythos 的核心秘密”。

所以，OpenMythos 最重要的前提必须写清楚：

它是 理论重建，不是 官方证实架构。

OpenMythos 实际实现了什么

如果只看代码，不看 README 自吹，它并不空心。相反，它确实做了一个相当完整的研究型原型。

1. 三段式循环深度结构是真的

源码里的 OpenMythos 主体，确实是：

  • Prelude：若干普通 transformer block；
  • RecurrentBlock：一个共享权重的循环块，多次运行；
  • Coda：若干普通 transformer block；
  • 最后接 norm 和 lm head。

也就是说，OpenMythos 不是打着“循环深度”旗号、代码却还是普通堆叠 transformer。它在结构层面真的做了“同一块权重重复调用”的 looped / recurrent-depth 形态。

2. 它确实写了 GQA 和 MLA 两条注意力路径

仓库里不是只提名词：

  • GQAttention 做了 grouped query attention；
  • MLAttention 做了压缩 KV latent、运行时重建的 MLA 风格实现；
  • 还做了 flash-attn 可选支持。

这说明项目作者不是只会讲故事，至少把主要机制写进了代码。

3. 它也确实写了 MoE、LTIInjection 和 ACT

循环块里有：

  • token-level top-k routed experts；
  • always-on shared experts；
  • LTIInjection 负责 A·h + B·e + trans_out 这类稳定注入；
  • ACTHalting 提供每轮 halting score；
  • 再加 loop-index embedding 和 depth-wise LoRA 这些让“每次循环不完全一样”的设计。

如果你把它看成一个“把近期 latent reasoning / looped transformer 论文线索拼成统一 PyTorch 原型”的仓库，这个完成度并不低。

但问题来了：代码能支撑多少 README 的大话？

答案是：支撑一部分，但远远支撑不了全部。

这也是 OpenMythos 最关键的分界线。

第一层问题：很多部件“有”，但不是 README 暗示的那个强度

1. ACT 更像“输出加权聚合”，不是真正 token 级省算

README 很容易让人理解成：

  • 简单 token 提前停；
  • 困难 token 多跑几轮；
  • 同一个 batch 内能动态省算。

但从实现看，当前 ACT 的关键行为是：

  • 每轮还是先完整跑 transformer block；
  • 然后再计算 halting score；
  • halted 主要影响输出累计权重；
  • 只有“整个 batch 全部 halt”时才可能提前 break。

这意味着它没有真正做到“已经 halt 的 token 不再参与后续 attention/FFN 计算”。

翻成人话：

它更像一种 ACT 风格的表示聚合机制，不是 README 那种 token 级按需省算 runtime。

所以，如果有人把 OpenMythos 当成“已经实现 continuous depth-wise batching”的工程实现，那就是读过头了。

2. MoE 有架子，但更像教学版/研究版，不是工业级可训练 MoE

MoE 的路由是存在的，但 dispatch 还是明显依赖 Python 层的双重循环与小张量切片。没有看到大型 MoE 训练里常见的：

  • 高效 grouped dispatch；
  • all-to-all 通信；
  • capacity 管理；
  • 真正完整的负载均衡闭环。

更关键的是，代码里虽然有 router_bias，文档也暗示它是动态平衡路由的一部分，但主训练脚本并没有真正把这套机制跑起来。

这就导致一种典型状态：

  • 概念上，MoE 在；
  • 模块上，MoE 在；
  • 真正训练级别的稳定与效率闭环，不在。

3. MLA 的实现存在，但 README 的 cache 优势表述站不太住

这是个很值得注意的点。

README 会让人感觉 MLA 在这些大模型变体里天然更省 cache，甚至有很显著的 cache 降低收益。但按仓库自己给的 variant 配置推算，情况没那么美：

  • 在小配置下，MLA 可能确实比 GQA 更省；
  • 但从更大的 10B+ 变体开始，按当前参数设定，MLA cache 不一定比 GQA 小，甚至在一些配置下更大。

这不等于 MLA 思想错了，而是说明：

README 的性能叙事，并没有被当前这套配置稳稳支撑。

第二层问题：训练脚本更像 skeleton，不像被充分打磨过的 recipe

仓库里确实有训练脚本，比如针对 FineWeb-Edu 的示例训练文件。但如果你从“这能不能作为严肃训练方案”去看，它明显更像一个研究骨架：

  • 有 FSDP/DDP、streaming dataset、checkpoint 这些框架元素；
  • 但缺完整评估闭环；
  • 缺更成熟的大规模混精与容错处理；
  • 缺清晰的 loop 训练策略验证；
  • 缺 MoE balance 的完整实现；
  • 对 README 里很多更强的 scaling / extrapolation 说法，没有仓库级别的自证。

所以它比较准确的定位是：

一个为了验证架构想法而搭起来的研究原型，不是一个被实战锤过的大规模训练框架。

第三层问题：仓库健康度明显落后于热度

这部分反而是 OpenMythos 最危险的信号，因为它说明项目现在的问题不是“还年轻”，而是“热度已经远超维护吞吐”。

GitHub 面上的情况很夸张

从公开元数据看：

  • 仓库创建于 2026-04-18；
  • 到 2026-04-25 就冲到大约 1 万 star、2200+ forks；
  • 代码主线提交主要集中在 4 月 18 日到 4 月 22 日；
  • 没有 GitHub release；
  • 没有 tag；
  • 没看到成型的 CI 工作流。

这是一种非常典型的“叙事先爆、工程还没站稳”的状态。

更刺眼的是：社区在帮它修，主仓库却几乎不吸收

目前这个 repo 的 PR 区给出的信号很明确：

  • 外部贡献者提交了大量高质量 PR；
  • 包括修 README 错误、修 bf16 dtype、修 install、补测试、补 benchmark 实验、修 API 导出等；
  • 但已合并 PR 约等于 0；
  • 大量 PR 长时间 open 或直接 closed 而非 merge。

这说明什么？

说明这个项目不是没人帮，而是：

社区贡献速度 > 维护者吸收速度。

一旦这个状态持续，就会出现两个后果：

  1. 外界继续把 star 当成熟度；
  2. 真正认真看代码的人，会越来越把它当“高热度 prototype”。

文档和发布也有很明显的基础问题

仓库里已经暴露出的典型问题包括：

  • README 中有可复现错误；
  • mythos_7b() 这种不存在的示例曾出现在文档里；
  • __all__ 里出现 load_tokenizer / get_vocab_size 这类幽灵导出；
  • pyproject.toml、requirements.txt、training/requirements.txt 对 torch 版本要求不一致，甚至出现明显可疑的版本号；
  • PyPI 已经有多个版本，但 GitHub 上没有对应 release/tag 路径，源码与包发布之间缺少清晰映射。

这些都不是“学术争论”，而是很朴素的工程质量问题。

最致命的一刀：社区已经开始质疑它的核心卖点，而且不是嘴炮，是带实验的

如果说上面那些还是“项目还年轻可以理解”，那真正需要敲钟的是这个：

社区已经有人系统性测试它的核心 depth-extrapolation claim，并得出了与 README 不完全一致、甚至相反的结果。

最典型的是 issue #28 那条线。

其中的核心争议，不是某个代码 bug，而是：

  • README 暗示“更多 loops 可以带来更深推理”；
  • 但社区实证结果显示，默认配置下这个叙事并没有稳定复现；
  • 有些情况下表现更像 U-shape 或 plateau；
  • 只有在某些特定 ablation/训练策略下，才出现更接近宣传口径的单调收益曲线。

这类反馈的重要性非常高，因为它已经触及项目最值钱的命题：

如果“loop depth 带来额外推理红利”没有在当前实现中被稳定验证，那 OpenMythos 的核心吸引力就会从“接近 Mythos 秘密”退回到“一个有意思的研究方向样机”。

这不代表它没价值，恰恰相反：它的价值要换个角度看

如果你把 OpenMythos 当成“Claude Mythos 的开源版”，那大概率会失望。

但如果你把它当成下面这个东西，它就非常值得跟：

一个把“looped / recurrent-depth / latent reasoning / adaptive compute / MoE breadth-depth 组合”这条研究线压缩成可执行代码的开源样机。

它真正的价值有三层：

1. 它让 Mythos 讨论从空谈变成可检查对象

以前大家聊 Mythos，很多时候只能转述官方宣传、转发论文、写长线程。OpenMythos 让人至少能开始问更具体的问题：

  • 如果用共享循环块，真的能出现更深推理吗？
  • ACT 在这里到底是省算，还是只是权重聚合？
  • MoE + loop depth 是互补，还是叙事堆叠？
  • MLA/GQA 在这种设计里到底怎么取舍？

这对行业讨论本身是有贡献的。

2. 它非常像 2026 年 AI 开源圈的一种新范式

即：

  • 官方模型不公开架构；
  • 社区围绕公开能力、论文趋势和系统行为做“可执行推测”；
  • 然后把这些推测做成代码、文章、benchmark 和 PR；
  • 最后形成一种半研究、半情报、半工程的“开源叙事层”。

OpenMythos 不是孤例，但它是这类项目里最典型、也最火的一例。

3. 它比很多“蹭热度 repo”认真得多

虽然我上面批了很多，但要说清楚：

  • 它不是纯 PPT；
  • 它不是 README-only；
  • 它确实做了结构实现；
  • 社区也确实投入了认真修复与实验；
  • 争议不代表它空，反而说明有人把它当回事，愿意去复现、打脸、补洞。

这类项目最怕的是没人认真看。OpenMythos 不是这个状态。

那么，应该怎么给 OpenMythos 定位？

我觉得最准确的定位是：

它是一个高热度、高解释力、但低验证闭环的研究原型

拆开讲就是：

  • 高热度：传播极强，踩中了 Mythos 架构猎奇与 latent reasoning 叙事；
  • 高解释力：它提供了一套足够完整的理论结构，能让很多人“感觉这解释得通”；
  • 低验证闭环：真正关键的工程、实验和发布治理还没跟上。

它不是“假的”，但也绝不是“破案了”

最需要警惕的不是它在说谎，而是外部传播很容易把它从：

  • “community-driven theoretical reconstruction”

自动脑补成：

  • “Anthropic Mythos 的秘密已经被基本还原”。

这两者差得非常远。

给 Lighthouse 的最终判断

如果从情报价值看

它很值得持续跟。

因为 OpenMythos 不只是一个仓库，它是一个观察窗口：

  • 看社区如何试图解构闭源前沿模型；
  • 看“looped transformer 能否解释更强推理”这条研究线会不会真正坐实；
  • 看高热度 AI 开源项目如何在 star/fork 狂飙后暴露治理和验证短板；
  • 看 Mythos 叙事会不会刺激更多同类“理论重建仓库”出现。

如果从工程复用看

现在不适合把它当稳定依赖。

原因很简单：

  • 基础打包/文档/API surface 还有明显问题；
  • 社区修复积压严重；
  • release/tag/CI 缺位；
  • 核心 claim 还在被社区实证挑战。

如果从研究角度看

值得 fork、值得跟、值得做二次实验。

尤其是下面几条，后续非常值得继续验证：

  1. 关闭或重写 ACT 后，loop scaling 曲线会不会更健康；
  2. MoE 路由和负载均衡如果补齐，训练稳定性会不会更像 README 的说法；
  3. MLA/GQA 的缓存与吞吐收益，在合理配置下到底谁更优；
  4. “loop depth 带来推理增益”是否需要特定数据、训练策略或任务分布才能显现；
  5. Anthropic 后续如果公开更多 Mythos 细节，哪些会打脸 OpenMythos，哪些会意外对上。

一句话结论

OpenMythos 不是 Claude Mythos 的开源实锤，而是 2026 年 AI 社区围绕“前沿闭源模型为什么突然更强”这道题交出的一份最完整、最工程化、也最容易被误读的答案。它最值得看的地方，不是它已经证明了什么，而是它把一条本来只能空谈的研究路线，变成了可以被验证、被质疑、被继续改写的对象。

信源与证据来源：

目录