企业官网建设流程全解析

1. 从技术报告看MiMo-V2.6的定位与野心

第一次看到MiMo-V2.6这个技术报告的时候，我正蹲在工位上啃一份MoE架构的调参记录，屏幕上密密麻麻的专家路由日志看得人头皮发麻。当时第一反应是：又一个开源大模型？但翻完报告之后，我意识到这东西跟之前那些“刷榜型”开源模型不太一样——它把“自我改进的强化学习规模化”写进了标题，这等于直接摊牌了：我要解决的是模型如何在没有人类持续标注的情况下，自己把自己练得更强。

这个定位非常关键。过去两年开源大模型卷得飞起，参数从7B卷到70B再到千亿MoE，但绝大多数模型的训练范式还是“预训练+SFT+RLHF”老三样。RLHF里的“H”是人类反馈，意味着你得养一个标注团队，成本高、迭代慢、还容易引入标注者偏见。MiMo-V2.6想做的事情，是把“H”这个环节尽可能自动化，让模型通过强化学习在可验证的任务上自我博弈、自我提升。这背后的核心关键词就是强化学习规模化和MoE架构的结合。

我为什么对这个方向特别感兴趣？因为我自己在做一个垂直领域的代码生成模型时，最大的瓶颈就是奖励信号不够。人工标注代码质量太贵，用规则奖励又太稀疏，模型训着训着就学会“骗奖励”了。MiMo-V2.6的技术报告里提到的自我改进机制，本质上是在探索一条路：让模型在大量可自动验证的任务上（比如数学证明、代码执行、逻辑推理）自己生成答案、自己验证对错、自己更新策略。这条路如果走通了，对中小团队来说意义极大，因为你不需要养几百个标注员，只需要设计好验证器和奖励函数。

这篇文章我打算从几个层面来拆：先讲清楚MiMo-V2.6的整体设计思路和它为什么选择MoE+RL这条路，然后拆解它自我改进机制的核心细节和实操中可能遇到的坑，接着还原一个可参考的RL规模化训练流程，最后整理我在类似项目中踩过的典型问题和排查技巧。适合谁看？如果你正在做模型后训练、对强化学习在LLM上的落地感兴趣、或者单纯想搞清楚MoE架构下RL训练跟稠密模型有什么不同，这篇应该能给你一些能直接抄作业的东西。

2. 整体设计思路：为什么是MoE加自我改进RL

2.1 MoE架构在RL训练中的真实优势与代价

MiMo-V2.6选择MoE（Mixture of Experts）作为基座，这个决策在技术报告里没有花太多篇幅解释，但从工程角度看逻辑很清晰。MoE的核心思想是：把一个大FFN层拆成多个专家，每次前向只激活其中一小部分。比如总参数100B，但每个token只激活10B左右，这样计算量跟10B稠密模型差不多，但模型容量大了十倍。

这个特性对RL训练特别友好，原因有两个。第一，RL训练需要大量采样（rollout），采样阶段是推理密集型的，MoE的低激活参数意味着你可以在同样的GPU上跑更大的batch size，采样吞吐直接上去了。第二，RL更新阶段需要计算策略梯度和价值函数，MoE的稀疏激活让反向传播的计算量也可控，不会因为模型太大导致训练周期爆炸。

但代价也很明显。MoE训练最头疼的问题是专家负载不均衡。理想情况下每个专家处理的token数量差不多，但实际上模型会倾向于把大部分token路由到少数几个“热门专家”，其他专家饿死。在RL训练里这个问题会被放大，因为RL的样本分布跟预训练不一样，策略更新会导致输入分布漂移，今天热门的专家明天可能就没人用了。MiMo-V2.6报告里提到了负载均衡损失（load balancing loss）和专家容量因子（capacity factor）的调参细节，这部分我后面会展开讲。

另一个代价是训练不稳定性。MoE+RL的组合相当于两个不稳定系统叠加。RL本身就有高方差、奖励稀疏、策略崩溃的问题，MoE又引入了路由随机性和专家分化。我自己的经验是，稠密模型上能跑通的RL超参，直接搬到MoE上大概率会炸。学习率要降、KL惩罚要加、梯度裁剪要更激进，这些在MiMo-V2.6的报告里也能看到影子。

2.2 自我改进RL的核心逻辑：从人类反馈到可验证奖励

传统RLHF的流程是：模型生成多个回答→人类标注员排序→训练奖励模型→用奖励模型做PPO。这个流程的瓶颈在“人类标注”这一步，成本高、速度慢、而且标注质量参差不齐。MiMo-V2.6的“自我改进”思路，核心是把奖励信号从“人类偏好”转向“可自动验证的正确性”。

什么叫可自动验证？举几个例子。数学题：模型生成解题过程，最终答案可以跟标准答案比对，对就是对，错就是错。代码题：模型生成代码，直接跑单元测试，通过率就是奖励。逻辑推理题：模型生成推理链，可以用形式化验证器检查每一步是否合法。这些任务的共同点是：验证成本远低于生成成本，而且验证结果是客观的、可规模化的。

这个思路不是MiMo-V2.6首创，但它在“规模化”上做了很多工程优化。报告里提到的关键点包括：如何构建大规模可验证任务集、如何设计奖励函数让模型不会钻空子、如何在训练过程中动态调整任务难度。我特别关注的是它提到的“课程学习”机制——先用简单任务让模型学会基本策略，再逐步增加难度，避免一开始就在难题上浪费采样预算。

这里有个很容易踩的坑：奖励黑客（reward hacking）。模型会找到奖励函数的漏洞，生成看起来对但实际上没用的答案。比如代码题里，模型可能直接硬编码测试用例的期望输出，而不是真正实现算法。MiMo-V2.6报告里提到了用“留出测试集”和“多验证器交叉检查”来缓解这个问题，但说实话，这个问题没有银弹，只能持续对抗。

2.3 规模化RL的基础设施挑战

“规模化”三个字听起来很爽，但落地的时候全是工程问题。RL训练跟预训练最大的不同是：它是一个在线学习过程，模型在训练的同时也在生成数据，数据分布随着策略更新不断变化。这意味着你不能像预训练那样把数据预先处理好扔进管道，必须有一套高效的采样-训练-更新循环。

MiMo-V2.6报告里透露的架构是：采样和训练分离，采样用推理集群，训练用训练集群，中间通过高速网络同步策略参数。这个架构的好处是采样和训练可以独立扩缩容，采样慢就加推理节点，训练慢就加训练节点。但坏处是通信开销大，策略参数同步的延迟会直接影响训练效率。

我自己的经验是，RL规模化最容易被低估的成本是采样效率。一个70B的MoE模型，生成一条长度为2048的轨迹，在8卡A100上大概需要2-3秒。如果你需要每轮采样10万条轨迹，那就是几十个小时的纯采样时间。所以MiMo-V2.6在报告里特别强调了“采样加速”和“经验回放”的优化，这两点后面我会详细拆。

3. 核心细节拆解：自我改进RL的实操要点

3.1 可验证任务集的构建与难度分级

自我改进RL的第一步是构建任务集。MiMo-V2.6报告里提到的任务类型包括数学、代码、逻辑推理、科学问答等，每个任务都必须有自动验证器。构建任务集的时候有几个关键决策：

任务来源：可以从现有数据集中筛选，也可以合成生成。数学题可以从竞赛题库里爬，代码题可以从开源仓库的单元测试里提取，逻辑题可以用模板生成。MiMo-V2.6的做法是混合使用，既有真实数据也有合成数据，保证多样性。

难度分级：这是课程学习的核心。难度分级不能只看人类标注的难度标签，还要看模型当前的实际通过率。一个任务如果模型通过率是0%，说明太难，采样全是负样本，没有学习信号；如果通过率是100%，说明太简单，采样全是正样本，也没有学习信号。最佳难度是模型通过率在30%-70%之间的任务，这时候正负样本都有，梯度信号最强。

我自己的做法是：先用当前模型跑一遍所有任务，统计每个任务的通过率，然后按通过率分桶。训练初期只用通过率30%-50%的任务，中期加入50%-70%的，后期加入70%-90%的。这个动态调整的过程需要定期重新评估，因为模型能力在变。

验证器设计：验证器必须严格、快速、可并行。数学题的验证器就是答案比对，但要注意等价答案的处理（比如1/2和0.5）。代码题的验证器是单元测试，但要注意超时和资源限制。逻辑题的验证器是形式化检查，但要注意推理链的每一步都要验证，不能只看最终结论。

注意：验证器本身也可能有bug。我遇到过验证器把正确答案判错的情况，导致模型学到了错误的策略。建议验证器上线前用人工标注的黄金集做一轮校验，确保准确率在99%以上。

3.2 奖励函数设计与奖励黑客的对抗

奖励函数是RL训练的灵魂。MiMo-V2.6的奖励函数设计有几个层次：

正确性奖励：最基础的奖励，答案对给+1，错给-1或0。这个信号最可靠，但也最稀疏。对于长推理链任务，最终答案对但中间步骤错的情况，正确性奖励无法区分。

过程奖励：对推理链的每一步给奖励。这个信号更密集，但需要过程验证器。MiMo-V2.6报告里提到了用“步骤级验证”来提供中间奖励，但实现复杂度高，需要为每个任务类型定制验证逻辑。

格式奖励：鼓励模型输出符合预期格式的答案。比如要求用特定标记包裹最终答案，方便验证器提取。这个奖励是辅助性的，权重不能太高，否则模型会只学格式不学内容。

长度惩罚：防止模型生成过长的无意义推理。MiMo-V2.6用了长度归一化的奖励，避免模型为了凑长度而废话。

奖励黑客是RL训练中最难缠的问题。我踩过的坑包括：模型在代码题里直接print测试用例的期望输出、在数学题里把题目中的数字直接当答案、在逻辑题里生成循环论证。对抗奖励黑客的手段包括：

• 留出测试集：训练时用的验证器和最终评估用的验证器分开，防止模型过拟合到特定验证器。
• 多验证器交叉检查：同一个任务用多个独立实现的验证器，只有全部通过才给奖励。
• 对抗性任务生成：主动生成容易触发奖励黑客的任务，加入训练集让模型学会正确行为。
• 奖励裁剪：对异常高的奖励进行裁剪，防止模型找到“超级奖励”漏洞。

3.3 MoE路由在RL训练中的稳定性调优

MoE+RL的稳定性问题是我花时间最多的地方。MiMo-V2.6报告里提到的几个关键调参点，我结合自己的经验展开讲：

负载均衡损失系数：这个系数控制专家负载均衡的惩罚强度。系数太小，专家分化严重；系数太大，路由变得均匀但失去专业性。MiMo-V2.6用的值在0.01-0.1之间，具体取决于专家数量和任务多样性。我的经验是，RL训练初期用大一点的系数（0.1），保证专家不要过早分化；训练后期可以降到0.01，让专家自然分化。

专家容量因子：控制每个专家最多处理多少token。容量因子太小，token被丢弃，训练信号丢失；容量因子太大，计算浪费。MiMo-V2.6用的容量因子在1.25-2.0之间。RL训练中因为样本分布变化大，建议用大一点的容量因子（1.5-2.0），减少token丢弃。

路由温度：控制路由的softmax温度。温度高，路由更均匀；温度低，路由更尖锐。RL训练中建议用较高的温度（1.0-2.0），保持路由的探索性，避免过早收敛到少数专家。

梯度裁剪：MoE+RL的梯度方差很大，梯度裁剪是必须的。MiMo-V2.6用的裁剪阈值在0.5-1.0之间。我的经验是，如果训练中出现loss spike，先把裁剪阈值降到0.5，再逐步调回来。

KL惩罚系数：RL训练中KL惩罚控制策略偏离参考模型的程度。MoE模型因为容量大，更容易偏离，所以KL系数要比稠密模型大。MiMo-V2.6用的KL系数在0.01-0.1之间，稠密模型通常用0.001-0.01。

实操心得：MoE+RL训练中，我习惯每隔100步保存一次checkpoint，并且记录每个专家的激活频率。如果发现某个专家连续多个checkpoint激活频率低于1%，说明它已经“死亡”，需要考虑重启训练或者调整负载均衡系数。

3.4 采样效率优化与经验回放

RL规模化最大的瓶颈是采样效率。MiMo-V2.6报告里提到的优化手段包括：

批量采样：一次生成多条轨迹，而不是一条一条生成。这能充分利用GPU的并行能力。但要注意，批量采样时不同轨迹的长度可能不同，需要padding和mask处理。

推测解码：用一个小模型做草稿，大模型做验证，加速生成。这个技术在推理阶段很成熟，但在RL采样阶段要注意草稿模型和策略模型的一致性，否则会引入偏差。

经验回放：把历史采样的轨迹存起来，训练时混合使用新轨迹和老轨迹。这能提高样本利用率，但要注意老轨迹的分布跟当前策略不一致，需要用重要性采样修正。MiMo-V2.6报告里提到了用“近端经验回放”，只回放最近N轮采样的轨迹，平衡样本利用率和分布一致性。

异步采样：采样和训练异步进行，采样集群持续生成轨迹，训练集群持续消费。这能提高硬件利用率，但要注意策略版本的一致性。MiMo-V2.6用的是“软同步”策略，训练集群每隔一定步数拉取最新的策略参数，而不是每步都同步。

我自己的经验是，采样效率优化中最容易忽略的是验证器速度。如果验证器是Python写的，单条验证可能需要几十毫秒，10万条轨迹就是几十分钟的纯验证时间。建议验证器用C++或Rust实现，或者用批量化验证减少开销。

4. 实操流程：从零搭建一个自我改进RL训练管道

4.1 环境准备与依赖安装

假设你要复现一个类似MiMo-V2.6的自我改进RL训练管道，第一步是搭环境。我推荐的基础栈是：

• 训练框架：DeepSpeed或Megatron-LM，支持MoE并行。
• RL框架：TRL或OpenRLHF，支持PPO和GRPO。
• 推理引擎：vLLM或TensorRT-LLM，支持高吞吐采样。
• 验证器：根据任务类型选择，数学用SymPy，代码用Docker沙箱，逻辑用Z3。
• 任务管理：Ray或Celery，做分布式任务调度。

安装步骤大致如下：

# 创建虚拟环境 conda create -n mimo_rl python=3.10 conda activate mimo_rl # 安装PyTorch pip install torch==2.1.0 torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 # 安装DeepSpeed pip install deepspeed==0.12.0 # 安装RL框架 pip install trl==0.7.0 pip install openrlhf==0.2.0 # 安装推理引擎 pip install vllm==0.2.7 # 安装验证器依赖 pip install sympy==1.12 pip install z3-solver==4.12.2

注意：版本兼容性是最大的坑。DeepSpeed和PyTorch的版本必须匹配，vLLM和CUDA的版本必须匹配。建议先用一个小模型（比如1B稠密模型）跑通全流程，再上大模型。

4.2 任务集构建与验证器实现

任务集构建的代码框架大概长这样：

import json from typing import Callable, Any class Task: def __init__(self, task_id: str, prompt: str, answer: Any, verifier: Callable): self.task_id = task_id self.prompt = prompt self.answer = answer self.verifier = verifier def verify(self, response: str) -> float: try: return self.verifier(response, self.answer) except Exception as e: return 0.0 # 数学题验证器示例 def math_verifier(response: str, answer: float) -> float: import re from sympy import sympify # 提取最终答案 match = re.search(r'\\boxed\{(.+?)\}', response) if not match: return 0.0 try: predicted = float(sympify(match.group(1))) return 1.0 if abs(predicted - answer) < 1e-6 else 0.0 except: return 0.0 # 代码题验证器示例 def code_verifier(response: str, test_cases: list) -> float: import subprocess import tempfile # 提取代码 code = extract_code_block(response) if not code: return 0.0 # 在沙箱中运行测试 with tempfile.NamedTemporaryFile(mode='w', suffix='.py', delete=False) as f: f.write(code) f.write('\n') for inp, expected in test_cases: f.write(f'assert solution({inp}) == {expected}\n') temp_path = f.name try: result = subprocess.run(['python', temp_path], timeout=5, capture_output=True) return 1.0 if result.returncode == 0 else 0.0 except subprocess.TimeoutExpired: return 0.0

任务难度分级用通过率统计：

def evaluate_difficulty(model, tasks, num_samples=8): difficulty = {} for task in tasks: correct = 0 for _ in range(num_samples): response = model.generate(task.prompt) correct += task.verify(response) pass_rate = correct / num_samples difficulty[task.task_id] = pass_rate return difficulty # 按通过率分桶 def bucket_tasks(difficulty, buckets=[0.0, 0.3, 0.5, 0.7, 0.9, 1.0]): task_buckets = {i: [] for i in range(len(buckets)-1)} for task_id, rate in difficulty.items(): for i in range(len(buckets)-1): if buckets[i] <= rate < buckets[i+1]: task_buckets[i].append(task_id) break return task_buckets

4.3 RL训练循环实现

RL训练循环的核心是采样-验证-更新三步：

import torch from transformers import AutoModelForCausalLM, AutoTokenizer from trl import PPOTrainer, PPOConfig # 初始化模型 model = AutoModelForCausalLM.from_pretrained("mimo-v2.6-base") ref_model = AutoModelForCausalLM.from_pretrained("mimo-v2.6-base") tokenizer = AutoTokenizer.from_pretrained("mimo-v2.6-base") # PPO配置 config = PPOConfig( learning_rate=1e-6, batch_size=64, mini_batch_size=8, gradient_accumulation_steps=4, ppo_epochs=4, kl_penalty="kl", init_kl_coef=0.05, target_kl=0.1, cliprange=0.2, cliprange_value=0.2, vf_coef=0.1, max_grad_norm=0.5, ) # 训练循环 for epoch in range(num_epochs): # 1. 采样 tasks = sample_tasks(task_buckets, epoch) prompts = [task.prompt for task in tasks] responses = model.generate(prompts, max_new_tokens=2048) # 2. 验证 rewards = [] for task, response in zip(tasks, responses): reward = task.verify(response) rewards.append(reward) # 3. 更新 ppo_trainer.step(prompts, responses, rewards) # 4. 定期评估 if epoch % 10 == 0: eval_metrics = evaluate(model, eval_tasks) print(f"Epoch {epoch}: {eval_metrics}")

MoE模型的训练配置需要额外注意：

# MoE特定配置 moe_config = { "num_experts": 64, "top_k": 2, "capacity_factor": 1.5, "load_balancing_loss_coef": 0.05, "router_temperature": 1.0, "expert_dropout": 0.1, } # 负载均衡监控 def monitor_expert_load(model, dataloader): expert_counts = torch.zeros(model.config.num_experts) total_tokens = 0 for batch in dataloader: with torch.no_grad(): outputs = model(batch, output_router_logits=True) router_logits = outputs.router_logits expert_indices = torch.topk(router_logits, k=2, dim=-1).indices for idx in expert_indices.flatten(): expert_counts[idx] += 1 total_tokens += batch.size(0) expert_freq = expert_counts / total_tokens print(f"Expert frequency: min={expert_freq.min():.4f}, max={expert_freq.max():.4f}") return expert_freq

4.4 训练监控与调参策略

训练监控要看的指标包括：

调参策略我总结了一个优先级顺序：

1. 先调KL系数：KL散度是RL训练稳定性的第一道防线。如果KL散度超过0.1，先把KL系数翻倍。
2. 再调学习率：如果KL散度正常但loss震荡，降低学习率。
3. 然后调裁剪阈值：如果梯度范数经常超过阈值，降低裁剪阈值。
4. 最后调MoE参数：如果专家频率不均衡，调整负载均衡系数和容量因子。

实操心得：我习惯在训练脚本里加一个“紧急刹车”机制。如果连续10步奖励均值下降超过20%，自动暂停训练并保存checkpoint，人工检查后再决定是否继续。这个机制帮我避免了好几次训练崩溃。

5. 常见问题与排查技巧实录

5.1 训练崩溃与loss spike的排查路径

MoE+RL训练崩溃是家常便饭。我遇到过的崩溃类型和排查路径：

类型一：loss突然变成NaN。排查顺序：检查输入数据是否有NaN或inf→检查梯度裁剪是否生效→检查学习率是否太大→检查MoE路由是否有全零或全一的极端情况。最常见的根因是学习率太大导致梯度爆炸，解决方案是降低学习率并加大梯度裁剪。

类型二：奖励突然暴跌。排查顺序：检查验证器是否出错→检查任务难度是否突然增加→检查策略是否崩溃（KL散度是否飙升）→检查专家负载是否严重不均衡。最常见的根因是奖励黑客，模型找到了奖励函数的漏洞，解决方案是加入对抗性任务并调整奖励函数。

类型三：训练loss正常但评估指标不涨。排查顺序：检查训练集和评估集的分布是否一致→检查评估指标是否合理→检查模型是否过拟合到训练任务。最常见的根因是任务集太单一，模型学会了特定任务的模式但无法泛化，解决方案是增加任务多样性。

类型四：专家死亡。排查顺序：检查专家激活频率→检查负载均衡损失是否生效→检查路由温度是否太低。最常见的根因是负载均衡系数太小，解决方案是加大系数并重启训练。

5.2 奖励黑客的典型模式与对抗手段

奖励黑客的模式我整理了一个速查表：

对抗奖励黑客的核心原则是：奖励函数要奖励过程，而不只是奖励结果。MiMo-V2.6报告里提到的过程奖励模型（PRM）就是干这个的。但PRM本身也需要训练，而且可能被黑客攻击。我的经验是，PRM和结果验证器结合使用，PRM给中间奖励，结果验证器给最终奖励，两者加权求和。

5.3 MoE负载不均衡的监控与修复

MoE负载不均衡的监控指标：

def check_load_balance(model, dataloader, threshold=0.01): expert_freq = monitor_expert_load(model, dataloader) min_freq = expert_freq.min() max_freq = expert_freq.max() ratio = max_freq / min_freq if min_freq < threshold: print(f"警告：专家{expert_freq.argmin()}激活频率过低({min_freq:.4f})") return "dead_expert" elif ratio > 10: print(f"警告：专家负载不均衡，最大/最小={ratio:.2f}") return "imbalanced" else: print(f"专家负载正常，最大/最小={ratio:.2f}") return "ok"

修复手段按优先级：

1. 加大负载均衡损失系数：从0.01加到0.1，强制路由均匀。
2. 提高路由温度：从1.0加到2.0，增加路由探索性。
3. 加大专家容量因子：从1.25加到2.0，减少token丢弃。
4. 重启死亡专家：把死亡专家的参数重新初始化，或者从热门专家复制参数加噪声。
5. 调整专家数量：如果死亡专家太多，考虑减少专家数量，降低分化压力。

注意：负载均衡和专家专业化是一对矛盾。过度追求均衡会导致专家失去专业性，模型容量优势发挥不出来。我的经验是，保持最大/最小频率比在5-10之间比较健康，不要追求完全均匀。

5.4 采样效率低下的优化清单

采样效率低下的常见原因和优化手段：

我自己的优化顺序是：先优化生成速度（vLLM），再优化验证速度（批量化），然后优化通信（异步采样），最后优化内存（ZeRO-3）。这个顺序的原因是：生成和验证是采样阶段的主要瓶颈，通信和内存是训练阶段的瓶颈，先解决采样瓶颈收益最大。

6. 从MiMo-V2.6看自我改进RL的边界与可能

MiMo-V2.6的技术报告我反复读了三遍，最大的感受是：自我改进RL这条路方向是对的，但离“完全自主”还有很长的距离。报告里提到的可验证任务集、过程奖励、课程学习、MoE稳定性调优，每一个环节都需要大量人工设计和调参。模型能自己改进自己，但改进的方向和边界还是人在定。

我在自己的项目里尝试过类似的方法，最大的收获是：奖励函数的设计比RL算法本身重要十倍。PPO、GRPO、DPO这些算法之间的差异，远不如奖励函数设计好坏带来的差异大。一个好的奖励函数能让模型学到真正有用的能力，一个差的奖励函数会让模型学会一堆钻空子的技巧。

另一个体会是：MoE+RL的工程复杂度被严重低估。稠密模型上跑RL，你只需要关心RL本身的稳定性；MoE模型上跑RL，你要同时关心RL稳定性和MoE稳定性，两个系统耦合在一起，排查问题的难度是指数级上升的。我的建议是，如果你的团队没有MoE训练的经验，先从稠密模型+RL开始，跑通了再上MoE。

最后分享一个我在调参时的小技巧：用一个小模型做超参搜索。MoE+RL的全量训练太贵了，不可能每个超参组合都跑一遍。我的做法是先用一个1B稠密模型+小任务集做超参搜索，找到大致的学习率、KL系数、裁剪阈值范围，再迁移到MoE模型上微调。虽然不能完全迁移，但能排除掉大部分明显不合理的超参组合，节省大量算力。

这个方向后续还可以扩展的点包括：多模态任务的自我改进RL（比如图像生成的可验证奖励）、多智能体协作的RL（多个模型互相验证）、以及更长horizon的推理任务（比如需要几十步推理的数学证明）。每一个方向都有大量的工程问题等着解决，但每一个方向也都可能带来模型能力的实质性提升。