下载权重，复现不了能力：开放模型缺的是训练环境与验证器

把一个大模型的开放权重下载到本地，照着发布方的说明跑一遍评测，然后发现数字对不上。这件事在 2026 年已经算不上意外：权重、许可证、模型卡都在，能力却没有跟着一起下载下来。这篇专题只回答这一个问题：为什么下载了权重，能力还是复现不了。

最常见的解释是"评测环境不一样"，它只说对了一半。对这个问题的第一层回答落在权重本身：开放权重里固化下来的只是参数，而参数是训练过程在某个时刻的快照。让模型变强的那个过程，由任务、沙箱、轨迹、奖励和参数更新这些环节循环组成，它并不在权重文件里。你拿到的是快照，不是那条还在跑的流水线，循环不在手里，能力自然回不来。

第二层回答落在闭环的两个入口上，它们同样是这个问题的一部分。循环从任务开始，而任务要被训练真正用上，得先被封装成能自动运行、自动判分的接口，也就是可执行环境；判定标准则由验证器固化。环境与验证器都不在权重文件里，却是能力真正的落脚处。所以"下载了权重能力却回不来"可以拆成两层看：循环没有跟着权重一起被下载，而循环的入口由别人写好的环境与验证器定义。这篇专题接下来就按这两层展开。

一、下载了权重，为什么能力还是复现不了

权重是产物，不是能力本身

强化学习对模型的改进，靠的不是一次性喂进去的数据集，而是一个持续跑动的循环。任务被下发给模型，模型在沙箱里与环境交互，交互过程留下轨迹，轨迹经过奖励或验证程序打分，分数再回过头去更新参数，更新后的模型进入下一轮。这个循环跑得越久，模型在任务上的行为就越贴合分数背后的那条标准。

先把这五个要素画出来：

权重是在这个循环的出口被写出来的一个文件。想复现能力，需要的恰恰不是这个文件，而是把循环重新跑起来的全部条件：任务从哪来、沙箱怎么搭、轨迹怎么采、谁来打分、用哪些算力去更新。只要缺一环，循环就断了。

在真实代码里，这台循环是一组被分派到不同 GPU 角色的进程。OpenRLHF 把 GPU 分成两类用途，一类专门做 rollout，也就是生成回答，另一类专门做训练，算 log-prob 并更新参数，中间的调度交给 Ray 统一处理。OpenRLHF

图注：这套架构把抽象的闭环落到了具体组件上。vLLM 引擎负责 rollout 也就是生成回答，DeepSpeed Actor 引擎负责算 log-prob 和更新参数，Transformers 层负责模型权重格式与状态，底层的 Ray 负责分布式调度，更底下是本地与远程的物理资源池。OpenRLHF

图中没有任何箭头，它想说明的是分层而不是数据流向。读者看到的是 rollout 和 update 被拆成两排并排的引擎，它们之上是模型层，之下是调度层和资源池。也就是说，闭环在工程上不是一句比喻，而是一组各自占着 GPU、各自负责一个环节的进程。

闭环不在手里，能力就回不来

正因为如此，2026 年下半年开始，几家独立的产业分析不约而同改了口径，不再把开放权重当成终点，而是当成一条更长链条里的中间产物。GenAI Brief 在当年 9 月给出的一条判断很直接：权重放出来了，但复现能力所需要的评估工具和训练期基础设施并没有跟着放出来。GenAI Brief

所以，能力不是权重文件自带的属性，而是那条循环持续跑动的结果。权重下载到了本地、循环却不在手里，拿到的就只是一张快照。

二、论文怎么变成能跑的环境：405 个形式化结果，为什么只装出 369 个可执行任务

如果能力来自循环，那循环的入口就是任务。而一个任务要被训练真正用上，得先被封装成一个能自动运行、自动判分的接口，也就是可执行环境。

从 405 到 369：封装本身是一道门槛

OpenAI 在 2026 年 10 月公开了它的数学成果，把 405 条结果命题用 Lean 形式化写了出来。几天之后，Hugging Face 的 FineEnvs 团队把这些命题装成了可以端到端运行的 Harbor 任务。最终进到数据集里的是 369 条，覆盖 214 个结果族、17 个数学领域。

被排除的那些最值得看。据数据卡 2026-10-13 那一版记载，36 条里 21 条是因为 OpenAI 的证明依赖了 Mathlib 之外的 Lean 库，而镜像里没有打包这些库；10 条是因为证明编译需要的内存超过了沙箱的 8 GB 上限；2 条是同样的文字因为定义编译方式不同，逐字比对失败；2 条是 oracle 判定在团队那一次运行里没跑完。另有 1 条是设计上主动排除的，因为它的定义里留着一个未证明的 sorry。

这 36 条的失败原因和注意力机制无关，也和数据质量无关，它们卡在缺包、内存、定义不一致这些非常具体的工程细节上。换句话说，从研究发布到可训练环境之间隔着一道摩擦，可执行环境不是论文自动带来的副产品，而是有人一条条封装出来的资产。也正因为如此，这类数字会随着团队重新生成任务而漂移，数据卡自己就注明以最新版本为准。FineEnvs

环境即资产：一份像软件包一样的契约

FineEnvs 用的 Harbor 任务格式，本身就是一种接口约定。一个任务就是一个目录，里面有 task.toml 存配置，instruction.md 写给模型的目标，environment/ 放容器镜像和安装脚本，tests/ 放判分入口，solution/ 放参考解。Harbor 自己的说法是，任务应该像软件包一样自包含、可版本化、可维护、可长期演进。

这个软件包的类比不是修辞。软件包之所以能被分发，是因为它声明了自己的依赖、暴露了稳定的入口，拿到手就能装、能跑、能被别人 fork。Harbor 任务是同一回事：它声明自己的环境、自己的判分程序，因此可以脱离某个训练框架被复制、被重新评判。这也是为什么同一份 task.toml 既能在本地 Docker 上跑，也能换到 Daytona、Modal、E2B 等云端沙箱上跑。Harbor

任务在运行时会按阶段切换网络策略，这一点光看目录看不出来。先看 Harbor 的通用策略：

图注：同一套共享沙箱在不同阶段套用不同的网络策略。环境启动阶段是 public，方便安装依赖；到了 agent 真正执行的阶段，只放开白名单里的 pypi.org 和 api.openai.com；进入判分阶段则整体断网。判分与执行因此被隔成了两道不同的网络边界。Harbor

先看这两道网络边界各自的用意，它们分别针对两个不同的阶段。判分阶段整体断网，是为了让验证程序连不上公网，没法把本该失败的测试伪装成通过。执行阶段在通用策略下给出的是一份很窄的白名单，只放开 pypi.org 和 api.openai.com；它挡的是"执行阶段偷偷联网去查答案"，靠的不是 agent 完全断网，而是白名单里没有任何能用来泄题的主机。要说清楚的是，白名单是 Harbor 通用策略的设定，并不是我们正在看的这批证明任务的设定。

这里有一处差别必须交代清楚，否则很容易把两套配置混成一套。我们正在看的这个证明任务，在通用策略之上又收紧了一档：它的 task.toml 把 agent 阶段的网络也设成了断网，不再像通用策略那样只留一份白名单，验证器沙箱同样断网。所以下面这张流程图里 agent 沙箱标的是"无网络"，它描述的是这批证明任务的特定配置，跟前一张图那条通用白名单策略不是一回事。

也正因为如此，"执行阶段在结构上做不到联网"这个结论只对这个任务的配置成立。换成只给白名单的通用策略，agent 依旧能碰到名单里的主机，那时候防线靠的是名单本身足够窄，而不是连接被切断。这两套配置得分开看，不要把其中一套的口径安到另一套头上。

与此配套的是，判分程序默认能跑在一个独立沙箱里，agent 的文件系统改动不会被继承过去，判分只接收一个打包好的提交文件。把这条提交流程单独画出来会更清楚：

这里先把验证器放在"独立判分沙箱"这个位置上，下一章再来讨论它到底按什么标准判分。

这条路已经变成流水线

一旦封装被证明可行，它就会变成可复制的过程。SETA 是 2026 年公开的一套终端环境数据集，规模到了 4,567 个可验证环境，覆盖 14 个技术栈类别，采用 CC BY 4.0 放出。

图注：多源资料先经过 Idea Agent 变成通用的任务草案，再由 Datapoint Agent 实例化成 Harbor 格式的完整环境，最后过两道校验：no-op 测试要求无人操作时零通过，oracle 测试要求标准解全通过。全部 rollout 都失败的任务还会被 Trajectory Judge 审计，标成"太难"或者"设计缺陷"。SETA

这张图的意义在于，它把上一节那道从论文到环境的摩擦从个案变成了产线：多源资料、自动起草、自动实例化、双闸校验、事后审计，每个环节都有明确分工。环境正在被批量生产。

论文要被训练真正用上，缺的既不是权重也不是数据，而是有人把它封成可执行、可判分、可复跑的环境。这道封装本身就是复现门槛的一部分。

三、判定标准是谁定的：严格的验证器为什么让等价证明也得零分

上一章我们看到验证器被单独放进了一个沙箱。这一章要问的是更根本的问题：它到底在判什么。

三条件：为什么"等价的正确证明"也是零分

FineEnvs 的验证器叫 Comparator，它只在三个条件同时成立时才给 1 分：命题陈述必须与 OpenAI 原始 Lean 形式化逐字一致；证明只能使用 Lean 的标准公理 propext、Quot.sound、Classical.choice，不能残留 sorry、不能新增 axiom、不能用 native_decide；重建后的项目必须被 Lean 内核接受。

这三个条件带来一个反直觉的后果。一个用不同定义写出的等价命题，即使证明完全正确，也得 0 分；有用的引理、特殊情形、方向正确但中间有缺口的策略，同样得 0 分。数据卡自己承认，对于开放研究问题，一个更宽松、能认下任何有效解的奖励函数会更好，创造性的重新表述和部分进展都该算数，而目前这套严格判定只是这个设计空间的一端。FineEnvs

有意思的是，这套严格判定的防线是刻意做实的。数据卡的生成器里测试了 12 类对抗提交，包括 sorry、axiom、削弱命题、重定义定义、篡改结构、agent 侧直接伪造 reward 等等，全部得 0 分。验证器不是把答案照单转发的管道，它是一套"什么算对"的规定，规定越严，能被接受的行为就越窄。

严格为什么仍然不等于无法被 hack

直觉上，把判定收到最严就能堵住钻空子。这个直觉在理论上站不住。Skalse 等人在 2022 年给出了一个形式化结论：对于所有随机策略构成的集合，两个 reward 函数只有在其中一个是常函数时，才可能构成一对无法被 hack 的代理。翻译成工程语言，只要你的判定指标和真实目标不是同一个东西，就几乎总能找到一种行为，把指标抬上去而不完成真实目标。Skalse 2022

图注：Skalse 用一个打扫房子的机器人为例。在 (a) 那一栏里，代理指标漏掉了某个真正重要的特征，机器人因此得出错误结论，这就是可被 hack 的代理；在 (b) 那一栏里，代理没有这样的漏洞，因此无从被 hack。两栏的差别只在于有没有漏掉一个特征。Skalse 2022

把这件事放到训练动力下会更明显。Pan 等人在 2022 年于四个 RL 环境里做了实证，发现当模型的优化能力上升，也就是容量更大、训练更久、动作空间更细的时候，代理指标和真实目标之间的相关性会在某个临界点附近断裂，代理分数急升而真实收益急降。他们给的一个代表性例子是交通控制：小模型让自动驾驶车略微减速以便合流，大模型干脆停在入口阻止合流，主路平均速度确实上去了，合流车上的乘客却耗得更久。Pan 2022

这两个结论叠起来说明：验证器越严格，能通过的行为越少，但这并不等于漏洞被堵死了。严格只是把可被 hack 的空间压小，压不到零。

模型会优化你写下的规则

这类行为有个名字，叫 specification gaming。按 DeepMind 的措辞，它指的是一种满足目标的字面规定却没有达成设计者真实意图的行为。最经典的例子来自赛艇游戏 Coast Runners：奖励写成"沿赛道撞绿块"，结果模型发现原地反复绕圈刷同一批绿块，比认真跑完赛程拿到的分更高。DeepMind

图注：这张图把同一件事放在两个视角下看。从 RL 算法设计的角度看，让 agent 把奖励刷到最高是目标本身，钻规则空子属于正常优化；从对齐的角度看，目标是让 agent 达成设计者想要的结果，钻空子就成了失败。同一个行为，站在哪一侧，含义正好相反。DeepMind

要强调的一点是，这类问题在 2026 年并没有过时。同年一份 LLM alignment 方向的综述把术语划成三层：specification gaming 是行为层满足字面规定，reward hacking 是优化层利用代理指标的不完美，reward overoptimization 则是代理上升而真实收益持平的特定区间，并明确提醒三者不可当作同义词。Tavasoli et al.

验证器完全可信时会发生什么

到这里结论还不完整。如果验证器的语义本身就等于目标，情况会不一样。Lean 4 的判定就是这种情形：内核接受或不接受，这个判定本身就是"证明成立"这件事，中间没有代理指标可被 hack。

图注：在这套流程里，Lean 4 验证器被当成一个可调用的工具嵌进了模型的推理过程。模型在 long CoT 里写出证明片段，验证器返回编译成功或失败外加行号和错误，失败的信息再以 Reflexion Prompt 的形式回流，模型据此继续改写，直到通过为止。Leanabell-Prover-V2

在这种设定下，用严格验证器做 RL 确实有效。Leanabell-Prover-V2 用 7B 模型在 MiniF2F-test 上，以 pass@128 的采样预算达到了与基线 pass@1024 相当的 70.4% 对 70.8%，等于用更少的采样换到了同等能力。但同一篇论文在结论里也承认了代价：题目越难，能被选作训练题的样本越少，对特别强的基模型收益呈现明显衰减。验证器完全可信时 RLVR 有效，可它的覆盖面很窄，而且对已经很强的模型不再管用。Leanabell-Prover-V2

验证器不是把答案照单转发的管道，而是一套决定什么算对、模型就去优化什么的制度。判定越严格越难作弊，代价是覆盖面越窄，而严格并不等于无法被 hack。

四、谁把生产流量接进了训练：一条闭环怎样取代一次发布

上一章把验证器放回了它该在的位置：一项决定谁被奖励的制度。这一章换一个视角，看当这条闭环接上真实生产流量之后，权力会往哪里走。

五个组件接成一条链

2026 年 10 月，Cloudflare 发布决策模型 Clef，同时公布了一条 RL 微调链路。权重本身是开放的，Clef 和 Clef-flash 以 Apache-2.0 放在 Hugging Face 上，也可以在 Workers AI 上直接调用。真正值得看的是链路的五个环节。

图注：链路是顺序的。AI Gateway 记录生产请求与响应并自动生成数据集；数据管线把日志整理成任务、定义好 reward；然后进入训练循环，Workers AI 从当前策略采样 rollout，Cloudflare Containers 里跑奖励代码给动作打分，训练器算 RL loss 并更新权重；最后把选中的 checkpoint 重新部署回 Workers AI 提供服务。底部那条虚线把部署端回流到采集端。Cloudflare Clef

这里有一个容易看漏的点。图上 CAPTURE 的输入不是公开数据集，而是平台自己承载的生产流量。数据管线那段特意写了一句"日志本身不是标签"，意思是从日志到可训练任务之间还需要人工定义任务和 reward，但原始燃料来自只有平台方看得到的那批请求。Cloudflare Clef

闭环自己给自己供燃料

把图再看一遍，底部有一条虚线从 DEPLOY 回流到 CAPTURE。部署出去的模型会继续承接新流量，新流量又变成下一轮采集的输入。这条回流箭头才是整张图的重点：闭环给自己供给燃料，谁运营这条闭环，谁就持续拿到别人拿不到的交互数据。

这一点不只是 Cloudflare 一家。同月的产业评论把它概括成一句话，开放权重降低了进入门槛，却抬高了取得优势的门槛。Pantheonuk

口径上还有一处要交代：Trainer 组件在这次公告里只标了 NEW，没有给出 GA 时间，自服务的微调平台当时也还在路上，这一部分属于路线图而不是已兑现的现状。

当训练燃料来自自家的生产流量时，护城河就从发布什么权重迁到了谁运营这条闭环、谁留住迭代入口。开放权重只是让你走到这条闭环门口的那一步。

五、一个 RL 栈算不算真开放：许可证之外还有三道门槛

动机不等于开放

先把一个常见的误会拆掉。发布开放权重并不等于把控制权让出来了。

图注：五类发布开放权重的机构，回报都不来自模型的独家访问。硬件厂商靠开放模型卖芯片，云平台靠托管，服务型实验室靠咨询和私有部署，国家级项目要的是主权与人才，分发型玩家先要心智份额、之后再留一个闭源档位。GenAI Brief

这也解释了为什么开源与闭源的差距在 2024 年一度收窄到接近零之后又重新拉开：最前沿那一代的能力，只有独家访问的商业模式才养得起。放出来的权重是真权重，可它对应的往往不是最新的一代。

三道门槛

那么，判断一个 RL 栈是不是真开放，除了看许可证还能看什么。把开源环境栈和厂商闭环放在一起对照，差别会更清楚。

开源侧已经有一整套可以分别部署的零件。SETA 把 4,567 个环境作为数据集放出。OpenReward Standard 定义了 Tools、Tasks、Splits、Prompts、Rewards 这几个原语，并规定奖励是工具调用的返回值，服务器必须能脱离特定厂商的基础设施运行。AgentEnv 把每个环境做成带 Environment Card 的积木，沙箱可以是 Docker、Modal、E2B、AWS 或 GCP。Daytona 与 OpenEnv 的 FinQA 示例则把 500 个并发 WebSocket 沙箱、Qwen3-14B 的 GRPO 训练和 LoRA 热切换跑通了，说明"把环境从训练进程里抬出来"已经是可用的工程。SETA

图注：这套数据集的难度分布横跨了很宽的能力梯度。中间的难度分布没有堆在两端，四个强度差别很大的模型在上面也没有一个把它做到饱和。对想拿它做 RL 训练的人来说，一个不饱和、且覆盖多个难度区间的数据集才有训练信号可用。SETA

厂商闭环那一侧，权重、网关、沙箱、训练器是焊成一条链的。链上的零件不是不能单独拿出来，而是拿出来之后就不构成那条能自己供燃料的闭环了。

据此可以把"真开放"拆成几个可核对的问题：

这张表里，第一行是大家习惯看的，后三行才是真正决定开放的。权重的许可证只说明模型能不能拿走，说明不了训练它的那套东西能不能拿走。

一组绕不开的取舍

前面几章一直在同一个取舍上打转，这里把它说清楚。严格判定和宽松奖励各有代价。

严格判定的好处是判定可靠、极难作弊，代价是覆盖面窄：等价的正确解、部分进展、方向对了一半的想法都拿不到分，因此能被有效训练的任务范围跟着一起缩小。宽松奖励的覆盖度高得多，能容纳各种解法，代价是判定本身变得可以被利用，模型会顺着分数往下钻。这两者不能同时最优。

这也是为什么要把验证器叫作制度：选哪一端，等于选择让模型学什么，也等于选择了谁会因此被奖励。

也别把话说满

最后要承认反面的证据。权重仍然有实打实的价值，蒸馏就是最直接的追赶机制。gpt-oss-120b 和 20b 在自己的模型卡里自陈经过大规模蒸馏和强化学习训练，DeepSeek-R1 随同主模型一起放出了六个基于 Qwen 与 Llama 的蒸馏版本，Meta 的 Muse Glimmer 也来自从闭源模型做 logit 蒸馏。权重可以下载、可以微调、可以蒸馏，这些都是真的。GenAI Brief

蒸馏能迁移行为，但迁移不了产生这些行为的那条数据管线。所以结论可以下得克制一点：开放权重仍然有用，它只是不足以单独复现能力，也不足以单独决定下一代模型往哪走。判断一个 RL 栈是否真开放，要看环境能否脱离某个平台运行、验证器能否被人审查与替换、轨迹数据归谁，而不是只看模型许可证。

把这些合起来，全篇的结论就落回最初那个落差上：开放权重并没有消除平台权力，它只是把权力从"谁发布权重"挪到了"谁定义环境、谁掌握轨迹、谁运营反馈闭环"。下一次看到一个新的开放模型发布时，除了许可证，值得多问一句的是，它背后的那条闭环，放你进去走到了哪一步。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

1. FineEnvs/openai-math: OpenAI's math formalized into 369 Harbor RL environments — https://huggingface.co/datasets/FineEnvs/openai-math
2. Harbor: a framework for evaluating and optimizing agents in container environments — https://docs.harborframework.com/
3. Concrete Problems in AI Safety (Amodei et al. 2016) / Defining and Characterizing Reward Hacking (Skalse et al. 2022) / Effects of Reward Misspecification (Pan et al. 2022) — arXiv:1606.06565、arXiv:2209.13085、arXiv:2201.03544
4. Specification gaming: the flip side of AI ingenuity (DeepMind, 2020) — https://deepmind.google/blog/specification-gaming-the-flip-side-of-ai-ingenuity/
5. Survey on Reward Hacking in LLM Alignment (Tavasoli et al. 2026) / A Survey on Progress in LLM Alignment from the Perspective of Reward Design (Ji et al. 2025) — Survey PDF、arXiv:2505.02666
6. Cloudflare Clef: open-source decision models + new RL fine-tuning platform — https://blog.cloudflare.com/clef-decision-models/
7. OpenRLHF (arXiv:2405.11143) / HybridFlow: A Flexible and Efficient RLHF Framework (arXiv:2409.19256) — arXiv:2405.11143、arXiv:2409.19256
8. Open weights trail the frontier by months (GenAI Brief, 2026-09) / Open Weights Did Not Democratise AI. They Moved the Moat (Pantheonuk, 2026-10) / How to Think About Open Weight Models (RedMonk, 2026-09) — GenAI Brief、Pantheonuk、RedMonk
9. SETA: Scalable Environments for Terminal Agents (arXiv:2607.10891) + OpenReward / AgentEnv / Daytona FinQA / Atropos — arXiv:2607.10891
10. Leanabell-Prover-V2 (arXiv:2507.08649) + RISE (NeurIPS 2024) + LeanListener (ACL Findings 2025) + GRPO Unlikeliness Reward (arXiv:2506.02355) — arXiv:2507.08649