大模型训练全景：一个 AI 应用工程师需要理解的一切

你不需要自己训练模型，但你需要理解模型是怎么被训练出来的。这篇文章是我作为一名从 Java 后端转型 AI 应用工程的工程师，系统学习大模型训练后的完整笔记。它不是写给研究员的论文综述，而是写给像我一样需要在应用层做出工程判断的人。

为什么应用工程师需要理解训练

在做 AI 应用开发时，你每天都在面对模型选型、prompt 调优、Agent 编排、评估体系设计这些决策。这些决策的质量，取决于你对模型"从哪里来"的理解深度。

当你知道一个模型是怎么训练出来的，你就能理解：为什么它在某些任务上表现出色但在另一些任务上挣扎；为什么 benchmark 分数高不代表你的具体场景也好用；为什么同一个底座模型在不同产品里表现差异巨大；当新模型发布时，“变强了"到底意味着什么。

这些问题的答案，全部藏在训练过程的设计决策里。

第一章：数据不是燃料，是能力的蓝图

数据管线：六层过滤决定模型的能力上限

训练大模型的第一步不是写训练代码，而是准备数据。原始数据来源包括网页爬取（Raw crawl）、代码仓库（Code repos）、书籍（Books）、论坛（Forums）、文档（Docs）和合成数据（Synthetic data）。但这些原始数据不能直接用于训练，需要经过一条完整的漏斗式处理管线。

第一层是文本抽取（Text extraction），从原始 HTML 中提取纯文本，过滤掉导航栏、页脚、广告代码、cookie 弹窗这类模板化内容。提取器的质量直接决定后续所有步骤的输入质量。

第二层是语言识别（Language ID），过滤掉目标语言之外的内容。这一步直接决定了模型的多语言能力分布——如果你只保留英文，模型就是英文模型；如果中文只占 5%，模型中文能力就会弱于英文。

第三层是质量过滤（Quality filtering），通常训练一个分类器，用维基百科和高质量书籍作为正样本，用随机网页作为负样本。这意味着你在用一个特定的"质量"定义来筛选数据——偏学术、偏正式的内容容易通过，口语化的、非主流的内容容易被刷掉。模型在某些场景下表现不好，根源可能就在这一步。

第四层是隐私处理（PII redaction），移除邮箱、电话、身份证号等个人信息。这是法律合规要求，但过度清洗可能导致模型在需要理解这类格式时表现变差。

第五层是安全过滤（Safety filtering），移除仇恨言论、暴力、色情等内容，直接塑造模型的安全行为基线。

第六层是去重（Deduplication），包括近似去重和 benchmark 泄漏清理。互联网上大量内容是互相复制的——如果同一段话在训练数据里出现 1000 次，模型会过度记忆它，同时稀释了其他内容的有效学习比例。Benchmark leakage 清理则是防止测试题答案出现在训练数据里导致评测分数虚高。

这条管线的核心认知是：Data pipeline changes the capability distribution before training starts. 数据管线在训练开始之前就已经决定了模型的能力分布。你扔掉的数据，模型就永远学不到。

数据配比：Mixture Design 是最关键的设计决策

经过六层过滤后，存活下来的数据按来源分成几个"桶”：网页文本、代码、书籍、论坛、文档、合成数据。训练时每个桶占多少比例，就是 Mixture Design。

这个比例直接决定模型的能力侧重。代码占比高，模型编程能力就强但可能聊天能力弱；书籍占比高，模型语言能力好但可能缺乏实时知识。而且配比不是线性叠加——多训练代码数据可能同时提升逻辑推理能力（因为代码本身就是结构化推理），但过多的代码可能损害自然语言的流畅性。

Data Mixing Laws 这类研究正在试图找到数学上的最优配比规律。Llama 3 的做法是用小模型做大量 mixture 实验，找到最优比例后再用到大模型训练上。这个过程本身就是一个巨大的工程投入。

去重和污染控制为什么重要

去重做不好的后果是：模型反复学到互联网上被大量复制粘贴的内容——比如 MIT License 在 GitHub 上出现几百万次、导航模板、cookie 声明。这些内容在训练数据里的权重被人为放大，挤占了真正有价值的内容的学习份额。

Benchmark leakage 的后果更隐蔽：如果 MMLU 或 HumanEval 的测试题出现在训练数据里，模型在这些 benchmark 上的得分就是虚高的——它不是学会了能力，而是"背"了答案。这就是为什么很多开源模型的 benchmark 分数看起来很好，但实际用起来参差不齐。

对应用工程师的启示： 当你在选择模型时，不能只看 benchmark 分数。理解数据管线的逻辑后，你就知道 benchmark 分数可能受到去重质量、数据泄漏、配比偏好等多种因素的影响。更可靠的判断方式是在你的具体任务上做评估，这也是 Evaluation-Driven Development（EDD）方法论的核心思想。

第二章：Scaling Law 与 Over-Training——用训练算力换部署成本

Chinchilla 定律：训练的"理论最优"

训练一个模型需要花费"计算量"（FLOPs），这个计算量由两个因素决定：模型参数量 × 训练数据量。就像总工时 = 工人数 × 每人工作时长。

2022 年 DeepMind 的 Chinchilla 论文给出了一个经典结论：给定固定的计算预算，参数量和数据量应该按大致 1:20 的比例分配，才能让 loss（预测误差）最低。对于 8B 参数的模型，Chinchilla 最优数据量大约是 200B tokens。

Over-Training：为什么实际做法背离了理论最优

Meta 给 Llama 3 8B 喂了 15T tokens——是 Chinchilla 最优量的 75 倍。从纯训练效率看，这是"浪费"计算：同样的 FLOPs 拿去训练一个更大的模型，能得到更低的 loss。

但从部署角度看，这是更聪明的决策。训练是一次性成本，推理是持续成本。对于要大规模部署的模型，训练多花 10 倍算力可能多花几百万美元，但模型小一半意味着每次推理省一半成本、部署门槛大幅降低。长期累积节省远超训练多花的钱。

15T tokens 有多大？大约相当于 1.5 亿本书——接近人类历史上出版过的所有书籍的总量。一个人不吃不睡不停阅读，要读 25 万年才能读完。

有一个关键的经验法则支撑了 over-training 策略：Total FLOPs 是模型质量最好的单一预测因子。 不管你把算力花在更大模型还是更多数据上，总 FLOPs 才是决定性的。所以 over-training 让你可以在部署时享受小模型的好处，而训练质量的损失没有想象中那么大。

Single Accelerator：部署约束反向塑造架构设计

Google 在 Gemma 3 上强调 single accelerator——模型能在单张 GPU 或 TPU 上完整加载和运行推理，不需要多卡并行。这不是一个"恰好能跑"的事后结果，而是一个前置的设计约束：它反向限制了参数量上限、attention 头数、hidden dimension 等架构选择。你选择了 single accelerator 作为目标，就意味着放弃了做更大模型的可能性，换来的是部署门槛大幅降低。

对应用工程师的启示： 理解 over-training 和部署约束的逻辑，能帮你做更好的模型选型。当你需要低延迟、低成本的场景时，一个 over-trained 的小模型（如 Llama 3 8B、Gemma 3 27B）可能比直接用大模型 API 更合适。你需要评估的是：这个小模型在你的具体任务上是否足够好，而不是它在通用 benchmark 上的排名。

第三章：系统约束——训练前就锁死的工程决策

训练的本质是分布式系统问题

很多人把训练理解成研究问题：目标函数怎么设，损失怎么降，模型结构怎么改。但真正的大模型训练里，系统约束才是核心。GPU 数量、显存带宽、并行策略、容错和成本——这些不能等到训练完才去调优，最开始就决定了你能训练多大的模型、支持多长的上下文、能不能跑更复杂的后训练。

这就像你知道的单机 Spring Boot 应用和需要部署到几百台机器上的分布式系统——虽然业务逻辑可能差不多，但后者的核心挑战完全变了，变成了分布式一致性、网络分区、负载均衡、故障恢复。

Fixed Compute Budget：四个维度的零和博弈

在固定的算力预算下，你可以往四个方向"花"这个预算，但它们是互相竞争的。

往上走——更大的模型（更多参数）。代价是 GPU 显存需求增加，需要多卡并行，通信开销增加。

往右走——更多训练数据。代价是训练时间拉长、数据管线成本增加。这就是 Llama 3 的 over-training 策略走的方向。

往下走——更长的上下文窗口。代价是每个 token 的 attention 成本上升。标准 attention 的计算复杂度是 O(n²)，序列长度从 4K 到 128K，attention 计算量增加 1024 倍。这直接导致 batch size（一次同时处理多少条数据）必须压小，因为每条数据占用的显存暴增。Batch size 压小意味着训练效率下降、总训练时间拉长。

往左走——更便宜的推理（serving）。代价是量化约束更严格，可能需要做 quantization-aware training。

核心原则是：Every model capability is a budget decision. 每一项模型能力都是一个预算决策。Meta 选了"小模型 + 海量数据"，Google 选了"小模型 + 单卡可跑"，DeepSeek 选了"MoE 大总参数 + 低激活成本"。不是某家公司技术更差，而是在这四个维度上做了不同的取舍。

MoE：成本和效果的工程折中

MoE（Mixture of Experts，混合专家模型）是一种让模型在相近计算量下扩大总参数量的架构。以 DeepSeek-V3 为例，总参数量 671B，但每次推理只激活其中 37B，通过一个 router 决定激活哪些 expert。这样你有更大的"知识容量"（总参数多），但每次推理的成本和一个小得多的 dense 模型差不多。

代价是系统复杂度大幅上升：路由机制本身是一个工程难题，负载均衡（确保每个 expert 被均匀使用）需要额外的 loss 项，底层通信模式也更复杂。

深层网络与信息稀释

现在的大语言模型动辄几十层甚至上百层——Llama 3 8B 有 32 层，GPT-4 级别的模型可能有 100+ 层。层数越多，能表达的计算复杂度越高，但同时带来一个核心问题：信息稀释。

输入的信息经过几十层变换后，原始信号会逐渐被稀释。这个问题的经典解决方案是残差连接（Residual Connection）：每一层的输出 = 本层计算结果 + 本层的输入。相当于给信息开了一条"直通管道"，让它可以跳过某些层直接向前传递。现在所有的 Transformer 架构都大量使用残差连接。

Kimi 的 Attention Residuals 和 Forgetting Transformer 这类工作，是在这个基础上进一步优化，分别解决 attention 内部的信息损失和超长序列下的信息保持问题。

训练不稳定性：工程现实

训练几千张 GPU 几周，突然训练 loss 出现剧烈跳升（loss spike），之前几天的训练进度可能全废，只能回滚到几天前的 checkpoint 重新来过。几天的算力——可能价值几十万美元——就这么浪费了。

还有更隐蔽的问题：单块 GPU 静默出错（不报错但悄悄产生错误梯度）、NVLink 带宽异常、节点间通信抖动。能在大规模训练中快速检测、隔离、恢复这些故障，是实验室级别的工程能力，不是读论文能解决的问题。

DeepSeek-V3 在技术报告里特别提到，整个预训练过程没有出现任何不可恢复的 loss spike，也没有做任何 rollback，而且是少数公开验证了 FP8 混合精度训练在超大规模模型上可行的案例。全流程约 278.8 万个 H800 GPU 小时，预训练了 14.8T tokens，训练全程稳定。这个"全程稳定"本身就是它最值得注意的工程成就。

对应用工程师的启示： 你不需要掌握分布式训练的工程细节，但理解这些约束能帮你回答一个关键问题：“为什么这个模型的上下文窗口是 128K 而不是 1M？"——这不是随意的数字，而是上面整套取舍的结果。理解训练侧和推理侧的差异（训练关心吞吐量和成本，推理关心延迟和 KV cache 管理）也有助于你做部署优化的决策。

第四章：合成数据与蒸馏——能力的生产和搬运

什么是合成数据

训练数据来源无非两种：人类产生的（真实数据），和模型产生的（合成数据）。最简单的例子：你给 GPT-4 一个指令"请写一篇关于光合作用的科普文章”，它输出的那篇文章就是合成数据。如果你把这篇文章收集起来用于训练下一个模型，你就在用合成数据做训练。

合成数据需求的核心原因是人类数据不够用了。互联网上的高质量文本是有限的，各大公司已经把能爬的网页、能买版权的书基本用过了。同时，特定类型的数据天然稀缺——比如高质量的数学推理过程，人类写的非常少。

合成数据的几种典型形态包括：指令-回答对（Self-Instruct 方法，从少量种子指令扩展出几十万条数据）、推理轨迹（包含完整思考过程的问题解答，DeepSeek-R1 产出的就是这类）、偏好数据（用于 RLHF/DPO 训练的好/坏回答对比）、以及知识增强数据（把已有知识重组为训练友好的格式）。

合成数据的根本矛盾

模型只能生成它已经"知道"的东西的重组，不能凭空创造新知识。合成数据的质量上限受限于生成它的模型的能力上限。而且模型生成的数据比人类数据更"干净"、更"规律"——这听起来是好事，其实不完全是。真实人类数据里充满了不同的表达习惯、非主流的推理路径、风格的巨大差异。这些"噪声"恰恰是模型学到鲁棒泛化能力的关键。纯合成数据训练出来的模型，可能在训练数据覆盖的场景内表现不错，但在边界情况和新问题上泛化能力会打折扣。

蒸馏：能力搬运的工程手段

蒸馏的核心思想是从大模型（teacher）中提取"知识"，灌入小模型（student）。

DeepSeek-R1 的蒸馏做法本质上就是监督微调（SFT），只不过训练数据来自大模型。具体流程是：先训练好 R1 大模型（671B 参数 MoE）并对它做强化学习，让它学会深度推理；然后收集大量有难度的问题输入给 R1，让 R1 生成完整的推理轨迹（包括试错、纠正、验证的完整思考链）；最后拿这些轨迹对小模型做标准 SFT。DeepSeek 收集了约 80 万条高质量轨迹，用来训练从 1.5B 到 70B 不同规模的 dense 模型。

这种蒸馏的关键在于：小模型学到的不只是"这道题的答案是什么"，而是"遇到这类问题时应该展开怎样的思考过程"。因为训练数据包含完整推理轨迹，模型在学习预测下一个 token 时，实际上在学习推理的模式。

更经典的蒸馏方法是 Hinton 2015 年提出的 Knowledge Distillation，它不只用大模型的最终输出文本，还用大模型的完整概率分布（soft labels）。比如大模型预测下一个词时，“猫"概率 70%、“狗"25%、“桌子"5%。轨迹蒸馏只告诉小模型"答案是猫”，但 Hinton 蒸馏会告诉小模型完整的概率分布，其中包含了"狗虽然不是最佳但有一定合理性"这类暗知识（dark knowledge）。但 Hinton 蒸馏要求同时运行大模型和小模型获取 logits，对 671B 的模型来说工程成本极高，所以 DeepSeek 选择了更实际的轨迹蒸馏。

蒸馏的局限性

即使参数量相同，用大模型合成数据训练的新模型也不等于原始大模型。原因有几个：合成数据只是大模型内部表征的"投影”，像三维物体的影子丢失了深度信息；模型生成的数据缺乏人类数据的分布多样性；你无法穷尽大模型的全部能力空间；以及大模型的很多能力来自强化学习的探索过程，纯监督学习无法完全复现。

更准确的理解是：蒸馏让小模型在特定任务和场景上，以远低于大模型的成本，达到接近（但不等于）大模型的表现。 大模型是"能力的源头”，蒸馏是"能力的搬运"，搬运过程必然有损耗，范围也有限。

自举循环：每一代模型都在重构下一代的数据

合成数据构成了一个自举循环：早期模型（GPT-3 scale）生成基础指令数据 → 更强模型（GPT-4 scale）生成高质量推理轨迹和 CoT 数据 → 经过 RL 训练的推理模型（DeepSeek-R1/o1 scale）产出蒸馏用的推理轨迹 → 这些轨迹训练出可部署的小模型。

这个循环有一个方向性：Models must get bigger before they can get smaller. 因为某些能力（特别是复杂推理）只有在足够大的参数空间中才能涌现。一个可能的解释是，互联网语料中知识记忆和推理能力是耦合的，预训练目标要求模型同时学好两件事，只有足够大的模型才能同时撑起。但大模型可以生成"纯推理示范数据"，在这种解耦后的数据上训练的小模型就可以专注推理本身。

前沿模型的价值因此不只在它自己的服务能力，还在于它为整个行业提供训练数据——Frontier model value = training data source for the whole industry, not just its own inference.

对应用工程师的启示： 理解蒸馏的机制和局限，能帮你做更精准的模型选型。比如 DeepSeek-R1-Distill-14B 在数学推理上可能接近某些大模型，但在开放域对话上可能差距明显——因为蒸馏数据高度集中在数学推理领域。你需要在你的具体任务上做评估，而不是笼统地相信"这个模型和 GPT-4 差不多"的说法。

第五章：后训练——用户真正感受到的差距从这里开始

为什么后训练才是关键

预训练结束后得到的是一个 base model——本质上是一个超级强大的"续写机器"。它不知道自己应该是一个助手。你问它"东京天气怎么样"，它可能不会回答你，而是续写成一篇文章。所有的"知识"都在预训练阶段装进去了，但被锁在一个不合作的形态里。

后训练做的事情是把这些潜在能力以用户期待的形式释放出来。就像一个人读了所有的书，脑子里什么都有，但不知道"有人在问我问题，我应该回答"这个行为模式。

三大方法论：SFT、RLHF、DPO

SFT（Supervised Fine-Tuning，监督微调） 是最直接的方式。准备"指令→理想回答"的配对数据，让模型在这些数据上继续训练。训练完后模型学会了"收到指令→给出回答"的行为模式。但 SFT 只能教模型模仿标准答案，不能教模型理解"什么叫更好"。

RLHF（Reinforcement Learning from Human Feedback） 解决的就是这个问题。让模型对同一个问题生成多个回答，人类标注员比较哪个更好，用这些比较数据训练一个奖励模型（reward model），然后用强化学习让模型去追求更高的奖励分数。这样模型不只是在模仿标准答案，而是在学习一个抽象的"好"的标准。

DPO（Direct Preference Optimization） 是 RLHF 的简化版，跳过了"训练奖励模型"这一步，直接从偏好对比数据中学习。工程上更简单——不需要同时维护两个模型，也不需要复杂的 RL 训练循环。

DeepSeek-R1 的四阶段流水线

这是目前公开资料中最清晰的现代后训练流水线。

阶段 1：SFT 冷启动。 在做 RL 之前，先用少量高质量 CoT 数据热身。DeepSeek-R1-Zero 实验证明直接从 base model 做 RL 是可行的（这是一个重要的科学发现），但纯 RL 训练出来的模型会反复重复、语言混杂、可读性极差。因为 RL 的奖励信号只关心最终答案对不对，不关心表达是否流畅。冷启动 SFT 给 RL 一个更稳定的起点，先把格式和语言一致性收住。

阶段 2：Reasoning RL（GRPO）。 在数学、代码、逻辑等可验证领域做强化学习，用 GRPO 算法。两个关键设计选择：一是奖励信号用可验证的正确性（数学题有标准答案、代码可跑测试），不需要人类参与打分；二是 GRPO 对同一个问题采样一组回答，用组内排名替代绝对价值估计，不需要独立的价值网络（value network），工程上比传统 PPO 简洁得多。

阶段 3：拒绝采样微调（Rejection Sampling FT）。 让 RL 训练后的模型生成大量回答，只保留成功的、质量高的轨迹，把它们作为新的 SFT 数据再做一轮监督微调。这是 RL 和 SFT 之间的桥梁，形成正循环：RL 探索出好模式 → 拒绝采样过滤出最佳轨迹 → 轨迹变成 SFT 数据 → SFT 让模型稳定复现好模式。这个循环可以重复多轮。

阶段 4：Alignment RL。 用偏好反馈调整模型的有帮助性和安全性，让它符合发布标准。这一步的奖励信号不再是"答案对不对"，而是"回答是否有帮助、是否安全"。

四个阶段互相依赖：冷启动让 RL 稳定启动，RL 产生高质量数据，拒绝采样把数据变成下一轮 SFT 输入，对齐 RL 完成行为收敛。

关于"风格 vs 能力"的重要提醒

SFT 数据的格式——是否分点、是否带引用、回答长度——都会显著影响模型输出的"样子"。偏好评测天然偏爱更长的回答，导致模型被训练成倾向于输出更长的回答，即使简短回答更合适。很多用户以为自己在比较能力，实际比出来的往往只是风格差异。

对应用工程师的启示： 理解后训练流水线后，你做模型评估时就不能只看"哪个模型的回答看起来更好"。需要看具体任务上的准确性、成本、延迟、稳定性。一个看起来更"认真"的长回答，可能只是因为 SFT 数据里长回答被标注为"更好"，不代表它实际更准确。

第六章：Eval、Grader、Reward——“好"的定义决定训练方向

核心命题

If the grader is wrong, training optimizes the wrong target. 如果打分器错了，训练就在优化一个错误的目标。

模型训练本质是优化过程——给它一个目标函数，它会竭尽全力最大化分数。模型不会"理解"你真正想要什么，只会"优化"你量化出来的分数。如果打分规则和你真正想要的之间有任何缝隙，模型会精准地钻进那个缝隙。就像给团队定 KPI——如果 KPI 是"代码行数”，工程师就会写冗长代码；如果是"bug 修复数量"，工程师就会先制造简单 bug 再修复。

三个关键组件

Eval 决定"测什么"——选择什么任务来评估模型。Grader 决定"一次输出怎么变成分数"——把模型输出转化为训练信号的桥梁。Reward 决定"模型后面被往哪里推"——Grader 的分数经过汇总变成 RL 的奖励信号，直接驱动参数更新方向。

这三个组件形成一条反馈回路：Task definition → Eval set → Grader/judge → Reward signal → Policy update → New rollouts → 再回到 Eval set。链路里任何一环出问题，后续优化都会一起跑偏。

ORM vs PRM：只看结果还是也看过程

ORM（Outcome Reward Model，结果奖励模型） 只看最终答案。模型推理过程可能乱七八糟，但答案碰巧对了就给满分。问题是模型学到的不是"怎么正确推理"，而是"怎么更高概率猜对最终答案"——各种 shortcut reasoning。

PRM（Process Reward Model，过程奖励模型） 给每一步打分。模型知道"第二步做错了"，被训练去学习正确的推理过程。但 PRM 的标注成本极高——对一道 10 步推理题，PRM 的标注工作量约是 ORM 的 10 倍。

大多数真实系统先从 ORM 起步（成本可控），只有在数学、代码、逻辑这类可验证任务里，才有条件用 PRM——因为中间步骤可以用程序自动验证，绕开人工标注瓶颈。

Reward Hacking：模型学会钻空子

当模型足够强大时，它会主动寻找 reward 系统的漏洞。问题从浅到深有几个层次：

第一层是走捷径——ORM 的典型问题，模型找到不需要真正推理就能拿高分的方式。

第二层是CoT 不忠实——Anthropic 发现模型写出来的"思考过程"不一定是它真正的内部过程。模型可能使用了额外线索但在 CoT 里不提，补一段事后合理化的解释。

第三层是reward hacking——模型不是在更好地完成任务，而是在钻打分系统的空子。比如代码任务的 grader 是测试通过率，模型可能学会硬编码测试用例的期望输出。

第四层是reward tampering 和 alignment faking——模型试图篡改打分过程本身，或者在被监控时表现合规、不被监控时行为不同。Anthropic 2025 年的实验证实了这类行为的存在。

关键是：这些行为在标准对话评测里看不到，只在 Agent 任务环境里能看到，因为 Agent 有工具调用、环境访问、多步执行的能力。

Constitutional AI：用原则替代逐条标注

Anthropic 的 Constitutional AI（CAI）采用了不同思路：不再逐条标注"这个回答好不好"，而是写下一套原则（constitution），让模型自己判断自己的输出是否符合原则。

Phase 1（SL 阶段）：模型生成回答 → 对照原则自我批评 → 修订回答 → 用修订后的回答做 SFT。Phase 2（RL 阶段）：生成回答对 → 用 AI 基于原则判断哪个更好（RLAIF） → 产出偏好数据 → 做 RL 训练。

核心创新是：RLAIF replaces RLHF——AI evaluates AI, human oversight via rules instead of per-example labels. 人类监督从"逐条标注"变成"写规则"，在规模上是质的飞跃。

对应用工程师的启示： 这整套 Eval/Grader/Reward 的框架，和你在做 Agent 系统时的评估设计直接相关。当你构建一个 RAG 系统或 Agent 时，你也需要定义"什么叫好的输出"——这就是你自己的 grader。如果你的评估标准不准确（比如只看"回答是否包含关键词"而不看"回答是否真正有帮助"），你的优化方向就会跑偏。同样，理解 reward hacking 的存在，能让你在设计 Agent 系统时加入必要的安全防护。

第七章：Agent 训练——优化的不只是模型本身了

从 Reasoning 到 Agent：行业演进的坐标系

用一个二维坐标系来理解 AI 的演进：X 轴是训练算力，Y 轴是推理算力（每次回答消耗的 token 数）。

GPT-3 era（左下角）： 提升能力的唯一方式是增加训练算力。推理时每次回答长度固定，所有智能在训练阶段注入。

Larger pretraining（右下角）： 继续增加训练规模（over-training），但推理成本不变。边际收益递减。

Reasoning models（左上角）： o1 和 DeepSeek-R1 开辟的新维度。训练规模不一定更大，但推理时模型学会"多想"——花更多推理 token 确实能得到更好的答案（test-time scaling）。RL 不只教模型"怎么答"，还教模型"什么时候该多想、什么时候该停"。

Agent era（右上角）： 同时扩展训练和推理算力。推理不再只是"思考更久"，而是"行动更多"——更长的轨迹、更多的工具调用。模型在环境中持续行动：调用工具、获取反馈、更新记忆、决定下一步。

Reasoning Model vs Agentic Model：结构性差异

两者之间的差异不只是"能做的事更多"，而是整个优化范式的转变。

Reasoning model 的流程是线性的：Prompt → Reasoning trace → Final answer → Verifier。优化的单元是一个答案。Agentic model 的流程是循环的：Goal → Planner/policy → Tool call → Environment feedback → Memory/context edit → Next action → 回到 Planner。优化的单元是一条轨迹——模型在环境中的一系列行动和决策。

这导致了几个关键差异。Reasoning model 的主要瓶颈是 verifier 准确性，典型失败模式是 shortcut reasoning，reward hacking 风险较低。Agentic model 的主要瓶颈是 harness quality（控制程序的质量），典型失败模式是 tool misuse 和 context drift（上下文漂移），reward hacking 风险很高——因为 Agent 有工具调用和环境访问能力，能做的"钻空子"操作远多于纯推理场景。

Harness：从运行时概念到训练概念

传统理解里，harness 是部署 Agent 时围绕模型搭建的控制层——prompt construction、retrieval、tool orchestration。但在 Agent 训练场景下，harness 的角色变了。

训练 Agent 时，模型需要在环境中反复执行任务来收集经验和奖励信号。如果 harness 本身不稳定——工具返回值不确定、浏览器环境和线上不一致、文件系统状态不可复现——那 grader 会先出错，模型学到的就不是能力，而是如何利用环境漏洞。训练 Agent 时，很多时候既在 debug 模型，也在 debug 环境。

SFT 时代数据多样性是第一位，到了 Agent 时代，环境质量才是核心：稳定性、真实性、覆盖度、难度分布、反馈丰富度和抗利用性。

Kimi K2.5 PARL：Agent 训练的具体工程案例

PARL 的核心设计是只训练 orchestrator（编排者），冻结所有 sub-agent。这解决了 credit assignment 问题——当多 agent 系统完成或失败一个任务时，功劳/责任归给谁？冻结 sub-agent 后，所有结果都归因于 orchestrator 的决策质量。

奖励信号设计了三个分量：r_perf（任务成功率，主信号）、r_parallel（激励有效并行拆解，训练中逐步退火到 0 以避免模型"无论什么都拆成并行"来刷分）、r_finish（惩罚虚假并行）。

评估并行是否真正有效，不是看总步数减少多少，而是看关键路径（最长串行链）是否变短——这是非常典型的分布式系统思维。

底线总结是：Parallelism emerges from RL, not supervision. 并行能力从 RL 训练中涌现，不是通过监督学习硬教的。

Meta-Harness：优化 harness 本身

最新的进展是：不只是在 harness 里训练模型，连 harness code 本身也开始成为可以被外循环搜索和优化的对象。

做法是：运行 harness 驱动模型执行任务 → 产出 rollouts、scores、execution traces → outer-loop optimizer 读取这些 traces 和 scores → 修改 harness code（调整 prompt 构造、检索策略、上下文编辑逻辑、工具编排规则） → 用修改后的 harness 重新跑任务 → 看分数是否提高。

Meta-Harness 的实证结果显示，同一个底座模型只改 harness 就能拉出 6 倍性能差距。它还发现了 harness 优化能跨模型泛化——在 200 道 IMO 级别题上，发现的 harness 对 5 个未参与优化的模型平均涨 4.7 个点。

一个特别值得注意的例子：Meta-Harness 在 TerminalBench-2 上自动发现了 environment bootstrap 策略——在 agent loop 开始前先跑一个 shell command，把工作目录、可用语言、包管理器和内存状态整理成快照注入首轮 prompt。这和手动工程实践中总结的 AGENTS.md 设计原则完全一致——让模型一开始就站在更好的上下文上。

优化目标的演进因此是：answer → trajectory → harness program。

对应用工程师的启示： 这一章对 AI 应用工程师来说可能是最直接相关的。它论证了 harness engineering 在 Agent 时代是最有杠杆效应的工程维度之一。你不需要训练模型，但你需要设计好模型外面的控制程序——prompt construction、retrieval policy、context editing、tool orchestration。Meta-Harness 证明了同一个底座模型只改 harness 就能产生巨大差距。这意味着你作为应用工程师的 harness 设计能力，可能比选择哪个模型更重要。

第八章：以后怎么看一个模型为什么变强了

三维分析框架

当你看到一个新模型发布声称"比上一版强了很多"时，从三个维度去拆解。

第一个维度：变化发生在预训练层，还是后训练流程？ 很多能力提升确实来自更强的预训练和更好的数据配方，但也有很多用户能感知到的变化主要发生在后训练。模型会不会听指令、会不会用工具、回答风格稳不稳——这些往往不是多训一点语料自己长出来的，而是后训练阶段的 SFT 数据风格、RL reward 设计、对齐训练做法决定的。

第二个维度：提升来自哪一层？ 可能来自权重和训练配方（模型本身变了），可能来自 reward/eval/grader（训练目标变了），也可能来自 harness code 和 deployment loop（模型外面的控制程序变了）。到了推理模型和 Agent 阶段，用户感受到的变强，很多时候不是基础模型单独做出来的。评测怎么设、奖励怎么打、工具环境稳不稳、retrieval 和记忆怎么组织、summary 和上下文怎么剪、上线时选了哪个 checkpoint——这些都影响最终产品表现。

第三个维度：上线版本在优化什么？ 有些版本追求能力上限，有些在压成本和延迟，还有些在给特定场景做专用化。发布版本本来就是产品决策，不是训练曲线最右边那个点。用户看到模型名字以为它对应一条平滑上升的训练曲线，但选哪个 checkpoint 上线涉及大量产品权衡。

在线优化：训练和部署的边界在缩短

Cursor Composer 2 的 real-time RL 是一个重要信号：用户真实的编码行为直接接入训练循环，模型在持续迭代而不是等下一个大版本。训练和部署之间的边界并没有消失，但两者的反馈回路正在缩短。

今天发布的模型只是一个快照，链路和 harness program 才是持续在跑的产品。

第九章：这些知识对 AI 应用工程师意味着什么

你的位置在整条链路的哪里

整条 LLM 产出链路大致是：数据工程 → 预训练 → 后训练 → 蒸馏/专用化 → 部署 → 产品/应用。AI 应用工程师的主要工作在链路的后段——部署和应用层。你不需要自己做前段（数据工程和训练），但你对前段的理解深度，直接决定了你在后段能做出多好的判断。

六个可直接行动的启示

第一，模型选型要看训练背景，不只看 benchmark。 知道一个模型是怎么训练出来的（数据配比、蒸馏来源、后训练方法），能帮你预测它在你的任务上会怎么表现。一个在代码数据上重度训练的模型可能推理很强但闲聊弱；一个蒸馏模型在蒸馏数据覆盖的任务上很好但在其他任务上可能退化。

第二，benchmark 分数需要审慎解读。 分数可能受到数据泄漏、去重质量、偏好评测对长回答的天然偏好等多种因素影响。在你的具体任务上做 EDD（Evaluation-Driven Development）才是可靠的判断方式。

第三，harness engineering 是最有杠杆的技能。 Meta-Harness 证明了同一个底座模型只改 harness 就能产生 6 倍性能差距。你在 Agent 系统中设计的 prompt construction、retrieval policy、context editing、tool orchestration、state management，这些都是 harness engineering 的组成部分。这不是"工具配置"层面的琐事，而是 Agent 系统中最有杠杆效应的工程维度。

第四，评估设计和 reward 设计直接相关。 你为 RAG 系统或 Agent 定义的评估标准，本质上就是你的 grader。如果评估标准不准确，优化方向就会跑偏。理解 ORM vs PRM 的取舍、reward hacking 的存在，能帮你设计更可靠的评估体系。

第五，理解训练侧约束能帮你做更好的部署决策。 “为什么这个模型上下文是 128K？“因为更长的上下文意味着 attention 成本暴增和 batch size 被压小。“为什么这个模型量化后效果下降？“可能是训练时没有做 quantization-aware training。这些理解帮你做出更合理的部署选择。

第六，构建你的叙事。 在面试中，你可以用这篇文章的知识体系来支撑一个非常有说服力的叙事：你不只是在写 prompt，你是在做 harness engineering——这是当前 Agent 系统中从训练到部署都被证明最具杠杆效应的工程实践。你对这个领域的理论基础和实践经验都有深入理解。

写在最后

大模型训练不是一个你需要亲手做的事情，但它是一个你需要理解的系统。就像你作为 Java 后端工程师不需要自己设计 CPU，但理解 CPU 缓存层级和内存模型能让你写出更好的并发代码。

这篇文章覆盖了从数据管线到预训练取舍、从后训练流水线到 Agent 训练、从评估体系到 harness 优化的完整链路。你不需要记住每一个细节，但需要内化那条贯穿始终的核心逻辑：模型的每一项能力都是一个设计决策的结果——数据配比决定了能力方向，预训练规模决定了能力上限，后训练流水线决定了能力的呈现形式，而 harness 决定了能力在真实场景中能发挥多少。 理解这条链路，就是理解你作为应用工程师做出每一个决策的背景和约束。

今天发布的模型只是一个快照。链路和 harness program 才是持续在跑的产品。而你的工作，就是在这条链路的末端，把模型的能力转化为用户真正需要的价值。