从预训练到智能体：思考型大模型训练教程

一、这篇教程要解决什么问题

近两年开源社区出现了一个清晰的技术趋势：一批开源“思考型（Thinking）模型”把训练重点从“更大的参数、更多的语料”转向了“更高效的预训练优化 + 更真实的智能体化后训练 + 推理期的测试时扩展（Test-Time Scaling）”。某开源思考型模型在公开高难度综合知识评测上达到了约 45% 量级的成绩，并且可以稳定执行 200～300 步连续的工具调用，展现出接近商业闭源模型的长程规划与自适应推理能力。

本文的目标，是把这类模型“是怎么炼成的”转写成一份可执行的工程教程：你将完成一条从预训练优化到智能体强化学习、再到推理期扩展的完整链路搭建，并能用明确指标验证每一阶段是否真的生效。

适合阅读的人：

• 做大模型预训练/继续预训练的算法工程师，关注 token 效率与训练稳定性；
• 做后训练（SFT/RL）的算法工程师，关注智能体化数据流水线；
• 做 Agent 平台、推理服务的工程与架构人员，关注长程工具调用的工程实现；
• 技术负责人，需要在“榜单效果”和“真实业务可用性”之间做取舍。

二、适用场景

本教程的方法论适用于以下典型场景：

1. 需要从零或从开源底座继续预训练一个领域模型，且算力预算有限，希望同等 loss 下少烧 token；
2. 需要让模型学会“调用工具完成任务”，而不是只会“回答问题”，例如代码执行、数据库查询、检索增强、工单流转、数据分析；
3. 需要让模型在开放式生成任务（创意写作、报告撰写、方案策划）上产出可控、可评、可迭代的高质量文本；
4. 需要在业务侧评估一个思考型模型是否“真的在思考”，而不是“在堆砌 token”。

三、前置准备

3.1 训练与推理基础设施

• 算力：预训练阶段需要大规模 GPU/NPU 集群；后训练 RL 阶段算力需求低于预训练，但对调度灵活性要求更高（rollout 与训练需要交替占用）。
• 存储：需要对象存储承载语料与检查点，需要高吞吐并行文件系统承载随机读训练。
• 分布式训练框架：业界通用的做法是“数据并行 + 张量并行 + 流水并行 + 序列并行”组合，并配合 ZeRO 类显存分片。
• 推理引擎：用于 RL 阶段的轨迹采样，要求支持高并发、连续批处理与 KV 缓存复用。
• 可观测性：训练侧的 loss/梯度范数/学习率曲线，推理侧的工具调用成功率与延迟分布，两者必须打通。若使用公有云资源，可依托通用的容器平台、日志服务、监控告警与对象存储产品完成这套基础设施，不必自建全套运维体系。

3.2 数据准备

• 预训练语料：通用网页文本、代码、数学、多语言语料，需要完成去重、质量打分、有害内容过滤；
• 任务型语料：可执行的题目、带明确答案的题目、带明确验收标准的开放式题目（写作、分析、设计）；
• 工具与环境：一套可沙箱化运行的工具集（代码执行、检索、数据库、文件系统、外部接口模拟器），必须支持失败重试与状态回滚。

3.3 评测基线

在动手之前，必须先建立三个基线，否则后续所有优化都无法判断收益：

基线类型	作用	建议指标
通用能力基线	防止后训练把通用能力训崩	MMLU 类、代码类、数学类基准分数
智能体能力基线	衡量工具使用与长程任务完成率	任务成功率、平均工具步数、无效调用率
开放式生成基线	衡量创意与写作类任务质量	人工/模型评分细则打分的一致性

四、阶段一：预训练如何提升 token 效率

4.1 为什么要盯着 token 效率

在固定算力预算下，token 效率决定你能“读多少数据”。同样训练 15T token，如果优化器效率更高，等价于你多读了几万亿 token 的高质量语料。评估方式很直接：绘制“loss vs 已训练 token 数”曲线，与基线优化器对比同一水平 loss 所需的 token 数，或同一 token 数下的 loss 差距。

4.2 优化器选择：正交化动量更新 + 数值稳定性裁剪

业界通用的一阶优化器（如 Adam/AdamW）对每个参数元素做二阶矩归一化，其更新步长与参数规模、矩阵结构无关。近年来出现的一类“正交化动量更新”优化器思路是：把权重矩阵的动量矩阵做符号化正交化（近似谱范数意义下的最优更新方向），让更新在整个矩阵上能量分布更均匀，从而在 Transformer 的矩阵参数上获得更高的 token 效率。

工程落地时必须注意两个坑：

• 数值稳定性：正交化过程会产生较大的更新幅度，激活值与 logits 容易出现爆炸。公开方案中给出的做法是在正交化之后、参数更新之前加入一路“数值稳定性护栏”，对更新幅度做裁剪（业界称为 MuonClip 类改进），本质是给更新范数设一个上限，避免出现 loss 尖峰（spike）与不可逆发散。
• 参数分组：嵌入层、输出头、门控、LayerNorm 相关参数通常不适合正交化更新，仍交给通用一阶优化器处理。

伪代码示意（参数分组与护栏裁剪）：

# 通用示意，非特定框架专有接口
matrix_params, scalar_params = split_by_shape(model.parameters())
opt_matrix = OrthogonalMomentumOptimizer(lr=lr_m, weight_decay=wd, clip=update_clip)
opt_scalar = AdamW(scalar_params, lr=lr_s, betas=(0.9, 0.95), weight_decay=wd)
for step, batch in enumerate(loader):
    loss = model(batch).loss
    loss.backward()
    # 护栏：先限制全局梯度范数，再限制单步更新范数
    gnorm = clip_grad_norm_(matrix_params + scalar_params, max_norm=grad_clip)
    update = opt_matrix.compute_update(matrix_params)      # 动量 + 符号化正交化
    update = clamp_rms(update, max_rms=update_clip)        # 防止激活/logits 爆炸
    opt_matrix.apply_(matrix_params, update)
    opt_scalar.step()
    if gnorm > SPIKE_THRESHOLD: skip_or_halve_lr(step)     # 尖峰保护

4.3 训练稳定性护栏清单

除优化器外，大模型预训练的稳定还依赖一组通用工程约定：

1. QK-Norm：对 Query/Key 做归一化，抑制注意力 logits 增长，是长上下文训练的必要条件；
2. 不使用 bias 项与固定位置编码偏置，降低训练早期不稳定；
3. 大 batch + 渐进式学习率调度（warmup 后按余弦或 WSD 衰减），后期用更少的高质量数据做退火（decay 阶段）；
4. 低精度训练（如 FP8/BF16 混合）时，敏感算子保持高精度累加，并对 loss scale 做动态调整；
5. 检查点保存频率与自动回滚：一旦连续 N 步 loss 偏离滑动均值超过阈值，回滚到最近健康检查点并降低学习率重启。

4.4 数据改写策略：创意写作方向的关键

原始语料天然存在“难度分布不均、风格单一、指令与内容不匹配”的问题。改写（rewrite）的目的不是造更多数据，而是提升单位 token 的信息密度与任务多样性。推荐的处理流水线：

1. 抽取与打标：从原始语料中抽取候选样本，标注主题、体裁、语言、长度、难度等级；
2. 受控改写：用较强的基础模型按预设模板改写，模板需明确约束“保留事实骨架、改变表达方式、提升难度或视角多样性”；
3. 去重与污染检查：改写前后都要做 MinHash/SimHash 级别近重复去除，并与评测集做 n-gram 重叠检查，防止测试污染；
4. 质量过滤：用规则（长度、重复率、乱码率）+ 模型打分双重过滤，剔除“看似流畅但信息量为零”的样本；
5. 配比控制：改写数据只作为整体配比的一部分，通常不宜超过总的高质量语料比例，否则模型会出现风格同质化；
6. 回流迭代：把线上/离线评估中模型表现差的子类，反馈给改写模板做定向增强，形成闭环。

对创意写作任务，尤其要避免“模板化改写导致创意坍缩”。可行的做法是引入多样性约束（同一主题要求不同叙事视角、不同结构、不同语气），并在筛选阶段保留一定比例的“低分但新颖”样本，避免评分器把探索性内容全部过滤掉。

五、阶段二：后训练如何让模型学会用工具

5.1 三阶段范式

通用的后训练路径是：监督微调冷启动（让模型认识工具与输出格式）→ 大规模轨迹采样与筛选（自蒸馏）→ 通用强化学习（让模型学会在失败中恢复）。

其中“冷启动”只解决格式与基本可用性，真正的能力提升来自后两步。

5.2 核心：用真实环境模拟运行获取轨迹

这是本教程中最重要的一步，也是最容易被做错的一步。常见的错误路线是：先人工构造大量“问题—工具调用—答案”的合成样本，再用模型筛选。这种方式构造出来的轨迹往往“看起来很对”，但与环境真实行为不符（工具返回、报错信息、状态变化都是编造的），模型学到的是表面模式，泛化很差。

正确路线是把环境真正跑起来：

for task in task_pool:
    env = sandbox.reset(task)                  # 真实初始化：代码库、数据库、文件系统
    for step in range(max_steps):
        action = policy.act(env.observation)   # 模型输出工具调用
        result = env.execute(action)           # 真实执行，可能失败/超时/报错
        if result.error: env.feed_error(result) # 把真实报错喂回上下文
        trajectory.append((env.observation, action, result))
        if verifier.check(env): break          # 真实校验任务是否完成
    pool.save(trajectory, env.final_state)

要点：

• 环境必须能真实报错。报错信息是模型学会自我纠错的主要信号来源；
• 环境必须可判定。任务要有可执行的验收脚本（单元测试、SQL 结果比对、文件哈希、断言），否则无法给奖励；
• 环境必须可并发、可隔离、可重置，否则采样吞吐会成为瓶颈；
• 允许“部分轨迹”落盘：长任务在预算耗尽时也要保留中间状态，供后续续采与训练使用。

5.3 用 LLM 做轨迹筛选

真实运行产生的轨迹质量参差，筛选是必需的。推荐三层过滤：

1. 规则过滤：丢弃格式非法、步数超限、工具参数明显越界、答案与环境状态不一致的轨迹；
2. 模型筛选（LLM as judge）：让较强的模型判断“这条轨迹是否真的完成了任务”“是否存在绕路/冗余调用”“推理链是否与动作一致”，输出通过/拒绝与理由；
3. 难度与多样性均衡：按任务类型、步数分布、成功/失败比例做采样配比。保留一定比例的“失败但推理正确”的轨迹，对 RL 阶段的探索很有价值，全部只留成功轨迹会让模型过度保守。

5.4 评分细则（Rubric）驱动的奖励设计

当任务是开放式的（写方案、做分析、写代码库级别的改动），没有唯一正确答案，无法用精确匹配给奖励。此时用“评分细则”把主观目标拆成可打分的维度，是当前比较成熟且有效的做法。

一个可用的细则模板：

task_id: report_generation_014
weight_dimensions:
  - name: 事实正确性        # 是否与输入材料一致，有无编造
    weight: 0.35
    check: 可对照原始材料逐条核验
  - name: 结构完整性        # 是否覆盖要求的章节
    weight: 0.20
    check: 章节清单匹配
  - name: 可执行性          # 建议是否具体到可落地动作
    weight: 0.25
    check: 每条建议是否有责任主体与验收标准
  - name: 表达质量          # 简洁性、无冗余、术语一致
    weight: 0.10
  - name: 约束遵守          # 字数、格式、禁用内容
    weight: 0.10
    check: 规则可程序化校验
scoring: 每维度 0-4 分，加权归一化到 [0,1]

奖励来源建议混合三种，避免单一来源被“刷分”：

• 可验证奖励（Verifiable Reward）：来自环境真实校验，最可靠，权重最高；
• 细则奖励（Rubric Reward）：由外部评判模型按细则打分，覆盖主观维度；
• 自评细则奖励（Self-critique）：让模型先产出答案，再按细则自我批判、指出缺陷并改进，用“批判后的改进幅度”和“自评与外部评分的一致性”作为奖励信号。这一条的价值在于显著降低了训练与推理阶段对外部评判模型的依赖，同时也把“自我反思”能力内化进模型。

工程注意点：所有评判模型的打分都必须做校准（同一批样本多人/多模型标注，计算一致性），否则奖励噪声会直接转化为策略噪声。

5.5 RL 基础设施的两个关键改造

长程智能体训练的瓶颈不在算力，而在“采样吞吐”和“训练/推理一致性”：

1. 部分轨迹回放（Partial Rollout）：把超预算的轨迹状态存下来，下一轮继续采样，避免长任务被直接丢弃浪费算力；配合异步调度，让训练与采样流水线并行；
2. 数值一致性：采样用的推理引擎与训练框架的算子实现必须对齐（尤其注意力与归一化实现），否则重要性采样比会漂移，RL 训练出现难以解释的崩溃。上线前应做逐层 logits 对齐检查，把 KL 控制在预期量级。

5.6 阶段验证

• 工具调用成功率（任务级）与步均工具调用数：步数下降且成功率上升，说明模型学会了更高效的规划；
• 无效调用率（参数错误、重复调用、调用不存在的工具）应显著下降；
• 通用能力基线不退化：这是判断“是否训崩”的硬指标；
• 长任务完成率：把最大步数预算从 20 提到 100，观察成功率是否随预算增长而提升。若提升饱和，说明是模型规划能力瓶颈；若持续线性提升，说明还能靠测试时扩展继续榨取收益。

六、阶段三：Test-Time Scaling 与长程工具调用

6.1 三个可扩展的轴

推理期扩展不是只有“想更久”一种做法，实际有三条正交的轴：

扩展轴	做法	代价	收益特点
并行采样	同一问题采样 N 条轨迹，再聚合	算力线性增长	对可验证类问题收益最明显
串行思考	生成更长思维链，允许反复自检	延迟线性增长	对推理深度要求高的问题有效
工具预算	提高最大工具调用步数（如 200～300 步）	延迟与环境成本高	对长程智能体任务收益最大

经验结论：想要效果，牺牲一定时间与算力通常是值得的；但收益不是无条件的，需要针对任务类型选轴。

6.2 长程调用的上下文与状态管理

200～300 步的工具调用会产生巨量上下文。不做管理，模型会在第 50 步左右“忘记”早期约束。通用做法：

1. 结构化状态区：把“任务目标、已完成子目标、关键中间结论、失败教训、待验证假设”维护成一块固定格式的摘要区，每 K 步强制重写一次；
2. 观察裁剪：工具返回结果先做规则裁剪与摘要（保留错误信息、关键字段、退出码），丢弃无关大段输出；
3. 外部记忆：把完整轨迹写入外部存储，模型需要时按需检索回看，而不是全部塞在上下文里；
4. 分层规划：外层维护高层计划（少步、稳定），内层执行具体动作（多步、可丢弃），避免计划被中间细节冲散。

6.3 预算与终止控制

def run_agent(task, cfg):
    state = EnvState.init(task)
    plan = planner.make_plan(task)          # 高层计划，尽量短且稳定
    for step in range(cfg.max_steps):
        if budget_exhausted(step, cfg):     # token/时间/调用费用三重预算
            return summarize_partial(state)
        action = policy.act(state.render()) # 含状态摘要区 + 裁剪后的观察
        result = env.execute(action)
        state.record(action, result)
        if verifier.check(env):
            return state.answer()
        if state.stalled(k=cfg.stall_window):   # 连续无进展则重规划
            plan = planner.replan(state)
        state.maybe_compress(every=cfg.compress_every)
    return summarize_partial(state)

关键参数的含义与取值逻辑：

• max_steps：任务难度决定，可从 30 起步，对长程任务逐步放宽到 100～300；过大只会放大“绕路”问题；
• compress_every：压缩频率过高会丢失关键细节，过低会导致上下文膨胀，建议以“上下文占用率”而非固定步数触发；
• stall_window：检测无效循环的窗口，超过窗口无新进展就强制重规划，这是抑制“反复重试同一失败动作”的主要手段；
• 三重预算：token 预算、时间预算、环境调用成本预算，任一耗尽即优雅终止并输出部分结果，避免任务悬挂。

6.4 多轨迹聚合

并行采样后的聚合策略要与任务类型匹配：

• 有唯一可验证答案（代码、SQL、数学）：优先用“执行结果正确性”投票，而不是让模型自评；
• 开放式生成：用评分细则让评判模型逐条打分，取加权最高者，或做“取各自最优段落再合成”；
• 高一致性优先：多条轨迹结论一致时可直接输出；分歧大时应触发一次额外的“对照分析”步骤，而不是简单多数投票。

6.5 抑制过度生成与工具滥用

测试时扩展会带来两个副作用，必须在产品层做约束：

1. 过度生成：模型倾向于用更长输出换取评分提升。对策是显式惩罚长度（在奖励与评分细则中加入冗余扣分），并设定输出上限；
2. 工具滥用：模型倾向于“先调工具再说”，包括重复查询、调用不必要的高成本工具。对策是给工具调用计费化（在奖励中扣除调用成本），并对高频重复调用做熔断。

七、常见问题与排查

现象	可能原因	排查与解决思路
预训练 loss 出现尖峰后发散	正交化更新幅度过大、学习率过高、数据中存在异常样本	收紧更新裁剪阈值；定位尖峰对应的数据批次并剔除；回滚检查点降学习率重启
token 效率提升但下游能力下降	改写数据占比过高导致风格同质化	降低改写数据配比，恢复原始语料多样性，做配比消融
RL 阶段奖励上升但真实成功率不升	奖励被刷分（长度、格式、迎合评判模型）	加入长度惩罚与可验证奖励权重；用独立测试集做人工抽检校准评判模型
RL 训练突然崩溃	采样与训练实现不一致导致重要性比漂移	做逐层 logits 对齐；收紧 KL 约束；检查低精度算子
长程任务在第 N 步开始失忆	上下文膨胀、状态无结构	引入结构化状态摘要区与外部记忆检索；按占用率触发压缩
模型陷入“重试同一失败动作”循环	缺少进展检测	增加 stall 检测与强制重规划；把失败原因显式写回状态区
工具调用成功率低但单步准确率高	缺少跨步骤一致性约束（参数与先前结论矛盾）	在状态区维护关键中间结论；训练时保留失败轨迹参与 RL
采样吞吐跟不上训练	长轨迹全部阻塞等待、环境串行	启用部分轨迹回放与异步调度；环境容器化并水平扩容

八、优化建议

性能与成本：

• 采样侧用连续批处理与 KV 缓存复用，把 RL 阶段的采样成本压下来；采样与训练在时间上错峰，提高集群整体利用率；
• 分级模型路由：简单任务用小模型或低预算配置，复杂任务才启用长思维链与高步数预算，能显著降低平均成本；
• 对高频相似任务做结果缓存与计划复用。

稳定性：

• 所有环境执行必须沙箱化、资源限额、超时熔断，防止工具调用拖垮服务；
• 训练侧保留完整检查点与数据版本谱系，任何一次效果回退都能追溯到具体数据配比与配置；
• 推理侧对“超长任务”设置优雅降级路径，输出部分结果而非直接失败。

安全：

• 工具权限最小化，写操作与破坏性操作需要显式确认或人工审批；
• 对模型执行的代码与命令做白名单与审计日志留存；
• 防止提示注入：把外部返回内容视为不可信数据，不与指令混淆。

可维护性：

• 把任务集、环境定义、评分细则全部版本化管理。评分细则本质是产品的“验收标准”，它的演进应该和代码一样走评审流程；
• 建立固定回归评测集，每次数据或配置变更都跑一遍，避免“改一处、坏两处”。

九、总结

把这篇教程的链路压缩成一句话：预训练阶段用更高效的优化器与更干净的改写数据把 token 效率榨出来，后训练阶段用真实环境跑出来的轨迹加上评分细则驱动的奖励把“会用工具”训出来，推理阶段再用测试时扩展把能力上限抬上去。

三个最容易被忽视、但决定成败的要点：

1. 智能体数据必须来自真实环境运行，构造出来的假轨迹会显著拖累泛化；
2. 奖励与评分细则的质量决定 RL 的天花板，必须先做评判模型校准；
3. 长程能力不是模型单方面的事，上下文管理、预算控制、进展检测这些工程机制同样关键。

后续可以深入的方向包括：更低成本的推理期扩展（自适应思考预算，简单问题不多想）、训练与推理一致性问题的系统性解法、以及开放式任务的可验证奖励扩展。如果你在公有云上落地这套方案，可以优先复用通用的容器平台做环境与采样集群的弹性伸缩、对象存储做语料与检查点、日志与监控告警做训练与线上双端观测，把精力集中在数据流水线和奖励设计上，这才是决定效果的部分。