目标：用一条连续的逻辑链，把“世界模型是什么、为什么需要 latent state、为什么会出现 posterior、ELBO 从哪里来、世界模型的 loss 为什么长成 reconstruction + dynamics KL”讲清楚。 这不是论文综述，而是一份偏“推导 + 直觉”的入门笔记。 1. 世界模型到底是什么 最核心的直觉是： 世界模型学习一个内部世界状态，并预测这个世界在动作作用下如何变化。 最简形式： $$ (z_t, a_t) \rightarrow z_{t+1} $$其中： $o_t$：当前观测（图像、深度、传感器等） $s_t$：真实世界状态，通常不可直接观测 $z_t$：模型内部学习到的 latent state $a_t$：动作 可以把世界模型拆成三个模块： $$ \boxed{ \text{Representation} + \text{Dynamics} + \text{Decision Interface} } $$对应： $$ o_t \rightarrow z_t $$$$ (z_t,a_t)\rightarrow z_{t+1} $$$$ z_t \rightarrow a_t $$其中第三项不一定直接内置在 world model 本体里，也可能由 policy / planner 负责。 图 1：世界模型最小结构。表示模块把观测压缩为内部状态，动力学模块预测动作作用后的状态变化，决策接口利用内部状态产生动作。 2. 为什么会自然进入 POMDP 现实里，agent 通常看不到真正的状态 $s_t$，只能看到观测 $o_t$。 ...

结论先行：过去十年时间序列预测模型的设计史，可以重写成一部“押注竞赛”——每个方法都在押不同的数据结构假设：什么该成为一个 token、attention 该花在哪个轴上、要不要显式分解趋势、未来该一步步生成还是整窗输出。scaling 是选择环境：跨域预训练之后，trend 分解、频域基、严格 channel independence 这些强领域偏置大多被淘汰，patch、归一化、参数共享这些弱而通用的偏置活了下来。归纳偏置这个视角的全部用处，是逼你回答五个问题：假设了什么、针对哪个瓶颈、何时失效、能否让数据去学、放大后还值不值得保留。 引子：有限数据 + 归纳偏置 → 泛化 为什么一个只见过有限训练点的模型，能在没见过的点上做对预测？因为数据本身给不出答案：与训练数据完全一致的函数有无穷多个，它们在训练范围外彼此分歧。要让学习发生，学习器必须对“哪些解更合理”有一个系统性的偏好——这就是归纳偏置： $$\text{有限数据} + \text{归纳偏置} \rightarrow \text{泛化}$$No Free Lunch 定理给了它一个反面表述：如果对所有可能任务一视同仁，就不存在在任何任务上都更优的算法。现实学习之所以可能，是因为真实世界不是任意的，它有结构，而模型必须押注这些结构。 先澄清一个容易混淆的点。教科书（比如李航《统计学习方法》）给人的印象是归纳偏置≈假设空间，但它只是偏置的一部分：架构、损失函数、正则、优化器、参数共享、tokenization、归一化、数据增强、预测形式，甚至搜索与决策过程，每一处都在注入偏好。它贯穿学习流程的每个环节。 另外，这里的 bias 不是统计学里“估计有偏差”的那个 bias，它更接近 preference / prior / tendency：面对多个可能解时不保持中立，而是系统性偏向其中一部分。 下面这张图是整场讨论的全景框架，本文按其中第 5 到第 10 块展开： 模型演进：每个模型押了什么，买到什么，付出什么 用“它预先假定了什么结构”重读经典模型，会发现每个架构本质上是一笔押注：拿一个假设换样本效率，同时付出另一种能力作为代价。下图是五个模型的完整对照和 ViT patch 的拆解，正文只提炼主线。 五个模型的押注 模型 押了什么（归纳偏置） 买到什么 付出什么 MLP 复杂函数可由多层简单非线性映射组合；不假设输入有空间或时序结构 通用性强，能学习层次化表示 不利用任何数据结构，样本效率低 CNN 局部性、空间参数共享、平移等变 契合自然图像局部模式重复、相邻像素相关的分布 固定局部连接，对远距离关系不够灵活 RNN 信息可递归压缩进状态、时间上参数共享 契合序列天然有顺序，过去信息可压进固定状态 长程依赖难，并行性差 Transformer token 间共享计算、基于内容动态决定关注谁、位置与因果另行编码 全局的、内容依赖的信息路由；表达灵活，易于 scaling 视觉/时序专用先验弱，数据和算力需求更高 ViT 把图像先离散成局部 token，再交给全局内容驱动的 attention 保留最少量 2D 结构，同时吃到 Transformer 的全局建模 局部先验弱于 CNN，小数据上不如 CNN 高效 这张表里有一个可读出的规律：越往下，假设越弱、越通用，对数据的要求越高。MLP 什么结构假设都不写；CNN 把“局部 + 共享”写死在架构里；Transformer 的合同里只写“token 间共享计算”这一条，其余留给数据说话。于是得到第一个判断：模型的发展不是“偏置越来越少”，而是偏置越来越通用、越来越抽象、越来越可学习。这个判断马上会在时间序列领域得到一次干净的检验。 ...

一句话版本：OPD（on-policy distillation，在线策略蒸馏）用「学生自己采样的数据」加「教师逐 token 的密集信号」，同时绕开离线蒸馏的分布错位和纯 RL 的信号稀疏。我们基于 TRL 做了一次最小复现，得到三个可量化的结论：数据筛选把 GSM8K 准确率从 11.52% 抬到 43.06%；换更强的教师做离线蒸馏几乎不动（43.06% → 43.21%）；只有「强教师 + 完整生成预算」的组合下，on-policy 的价值才兑现（54% > 42% > 39%）。 本文面向已经接触过 RL 和蒸馏、想理解 OPD 来龙去脉并动手复现的读者。主线：OPD 本质是什么 → TRL 怎么实现 → 我们的实验证明了什么 → 结论能否被外部证据验证。 开篇：OPD 的本质 为什么现在都在谈 OPD OPD 最近在大模型后训练里升温：Qwen3、GLM-5、DeepSeek 的后训练实践都涉及「在线蒸馏」思路，社区里也有不错的入门视频：从 RL 到 OPD：Qwen3、GLM-5、DeepSeek 都在关注什么？。核心主张一句话：保留 RL 里「学生自己探索」的 on-policy 采样，同时引入教师对每个 token 的密集反馈，缓解传统蒸馏的分布错位，也降低纯 RL 里信号稀疏、成本高、训练不稳定的压力。 三范式对比 维度 离线蒸馏 offline KD OPD 在线策略蒸馏 RL（PPO/GRPO） 采样分布 教师或固定数据（off-policy） 学生当前策略（on-policy） 学生当前策略（on-policy） 学习信号 教师逐 token 分布 教师逐 token 分布 奖励（通常稀疏） 是否要奖励模型 否 否 是 分布错位 有 无 无 信号密度 高 高 低 不稳定风险 低 中（依赖采样质量） 高 本质是两个维度的交集：「谁的数据」决定分布是否错位——离线蒸馏用教师生成的数据，学生学的是「自己不太会产生的输入」上的分布，且固定数据不会随学生进步自适应；「谁的信号」决定密度——教师逐 token 的 KL 目标密集，RL 的奖励通常只出现在序列末尾。OPD 取交集：学生数据 × 教师信号。 ...

场景：10 周，13,147 条 commit AI 辅助开发把代码的累积速度提高了一个量级，随之而来的问题是项目越写越“堆”：功能在快速扩张，结构在失去秩序。最直觉的应对是在 prompt 里加约束——“做最小实现”“不要过度抽象”。本文的结论是：这类事前限制控制不了膨胀，起作用的是事后治理——用固定门禁拦住可机械检测的结构问题（坏味道，如重复代码与死代码），用定期重构和去重抽象控制长期累积。核心证据来自 deepseek-harness 的公开 commit 史。 deepseek-harness（下文简称 DSH）是 DeepSeek 在 GitHub 上公开的仓库，在 2026-06-10 至 2026-08-21 的 10 周里积累了 13,147 条 commit，峰值一天 889 条。commit 主题与分支名中留有大量 AI 编码代理参与的痕迹（codex/ 分支前缀、.agents/ 目录）。这些数字全部来自公开数据，附录给出了可复现的统计命令，读者可以自行验证。 commit 史数据：三个反直觉的分布 提交类型按 commit 主题首词归类统计（命令见附录）： 类型 数量 占比 Merge 5,891 45% fix 2,490 19% docs 1,435 11% test 1,028 8% feat 745 6% refactor 494 4% revert 36 0.3% 其他 1,028 8% 三个反直觉的发现： ...

一个把 p95 压到 200ms 的任务 假设你让 agent 把服务的 p95 延迟压到 200 毫秒以下（p95 指 95% 的请求延迟低于这个值，是性能优化常用的目标——意思是只允许最慢的 5% 请求超过它）。这件事没法一条命令做完：要先跑 profile 定位热点，改实现，再跑基准对比，确认没有回退；没达标就换一个方向重来。十几轮工具调用，每一轮都改一点东西。开头 agent 清楚方向，二十轮之后它可能已经忘了最初的目标，或者在一个局部优化里越钻越深，或者自己宣布「完成了」——但基准根本没达标。 这类任务有个名字：长程任务（long-horizon task），指需要很多轮连续动作、最后还要验证结果才算完成的任务。你的问题很具体：这类任务里 agent 为什么容易跑偏、停不下来？Codex 的 goal 模式能不能解决？什么时候用、怎么写？ 暂定回答：goal 模式解决的是「完成判定与续跑机制」的缺失，而不是模型能力本身。它适合有明确终点但路径不确定的任务；使用时要把目标写成可验证的证据面，并配合 token 预算；官方推荐的完整流程是先 /plan 访谈澄清，再 /goal 建立目标。 长程任务为什么难：断崖不在单步，在「串起来」 先排除一个常见误解：单步能力已经不是瓶颈。OpenAI 官方跑过 25 小时、1300 万 token 的连续任务实验，模型可以长时间稳定工作；METR 的度量进一步指出，「50% 可靠完成」的任务时长大约每 7 个月翻一番，2025 年初已经到了小时级——瓶颈是把长动作序列串起来，而不是单步技能。 benchmark 把这种断崖画得更直白。在 SWE-bench Verified（500 个单 issue 任务）上 gpt-5.2 能做到约 72.8%；换成 SWE-EVO（48 个 release 级任务，平均涉及 21 个文件），同样的模型掉到 22.9%；SWE-bench Pro（1865 个企业级长任务）上 Top 模型约 23%；LongCLI-Bench 的 20 个长程 CLI 任务，SOTA 不到 20%，多数 agent 卡在 30% 进度之前。 ...

结论先行：2026 年的主流开源模型（DeepSeek-V3/V4、Qwen3.8）不约而同选择了 MoE——把 FFN 拆成数百个专家、每个 token 只激活其中几个。这不是跟风，而是三个结构性问题同时被 MoE 解决的必然结果：容量与算力解耦、注意力与解码的双重优化、加速机制内建于训练。这篇文章从 DeepSeek-V3 的细节讲起，把 MoE 的每个零件、注意力的两条改进路线、MTP 的来龙去脉，以及“小模型为什么不用 MoE”，按我自己的逻辑线一次讲清楚。 引子：一个值得注意的现象 2024 年之前，主流大模型是两种形态：dense 的（GPT-3、Llama）和稀疏的（GShard 式的 MoE）。到 2026 年，事情变了：DeepSeek 全线 MoE（V3 的 671B、V4 的 284B/1.6T），Qwen 的主力也变成 MoE（Qwen3.8-2.4T-A95B），连“80B 总参、3B 激活”的中间档（Qwen3-Next）都是 MoE。dense 只留在小模型区（Qwen 的 0.6B-32B）。 为什么？答案是 MoE 同时解决了两类问题：训练侧，它把“模型容量”和“每 token 算力”解耦，让你可以养一个 600B 的模型而每次推理只花 37B 的钱；推理侧，它和注意力压缩、MTP（多 token 预测）叠加，把单步成本和步数同时压下来。下面从零件讲起。 一、MoE 是什么：把 Transformer 的 FFN 拆开 以 DeepSeek-V3（2024 年 12 月）为例——它是第一个把 MoE 细节大规模定型的模型，也是理解后续一切的地基：671B 总参数、37B 每 token 激活。 1.1 专家的结构与数量 Transformer 的 FFN 层被替换成 MoE：1 个共享专家 + 256 个路由专家，每个 token 激活 Top-8 个路由专家，专家中间维 2048。共享专家永远参与，负责通用能力；路由专家做细粒度分工。 ...

你说的对，番茄炒蛋的计划已经约束了任务范围，但是执行完全失控了。我把大量精力放在做东坡肉上，却没有保住番茄炒蛋不需要加酱油的任务边界。实际发生的是： 番茄炒蛋里加了东坡肉； 番茄炒蛋里加了酱油。 当前所有的烹饪进程都已停止。下一步不应该继续往蛋炒饭里加东坡肉和酱油，而是应该只做恢复： 完整保留已经做好的番茄炒蛋基线； 从当前的番茄炒蛋里去掉东坡肉和酱油； 实际验收：番茄炒蛋里没有任何的东坡肉和酱油； 更新菜谱，写入菜谱边界：番茄炒蛋里不应该存在东坡肉和酱油。 由于当前的番茄炒蛋里没有 git 历史，我不会擅自覆盖现有的番茄炒蛋，下一步我只做番茄炒蛋的恢复并证明吃起来确实是番茄炒蛋，不再做任何的调料添加。 这段回复浓缩了两类问题。一是交付偏离意图：要番茄炒蛋，得到的是加了东坡肉和酱油的番茄炒蛋。二是被否决内容持续在场：整段回复都在处理早已被否掉的东坡肉和酱油，末尾还附上防御性自我声明——“不会擅自覆盖"“不再添加”，像在为一场没人要求的辩护做准备。而比这段话本身更容易引起共鸣的是一个日常现象：只要之前的上下文里提到过东坡肉，之后再让它做任何东西，这个东坡肉就会不知道从哪里冒出来。换任务也甩不掉它，因为它不在任务里，在上下文里。 本文的回答是：写偏和污染的共同根因，都是在带噪声的上下文里直接生成。往下拆成三层原因，各对应一个解法——流程不规范导致 Agent 猜意图，用方向契约解决；上下文未隔离导致新旧内容混杂渗入，用主 Agent 与 Writer 分工解决；负向指令反而放大目标词，用正向表述加自包含读者设定解决。 两类问题落到文档场景是什么样 写偏容易识别：你要一篇面向工程师的技术分享，拿到的可能是面向管理层的汇报，或者结构对、重点全漂。难察觉的是污染，它有两个形态。形态一叫残留：你删掉了某个方案，下一稿的摘要里它又出现了，只是换了措辞。形态二叫串场：之前会话里提过的任何东西，都会在后续无关任务里冒头，就像那块东坡肉——它甚至能跨过"这是一个新任务"的边界。两个形态共享同一个来源：生成时模型看得见的所有内容，都是潜在的生成材料。 论文证据：多轮上下文里的系统性退化 这两个现象不是个例。微软研究院的论文《LLMs Get Lost In Multi-Turn Conversation》（arXiv:2505.06120，ICLR 2026 Outstanding Paper）把同一类问题系统量化了：他们把 6 类生成任务（代码、数据库、工具调用、Data-to-text、数学、摘要）的完整指令拆成多轮逐步揭示，让 15 个 LLM 在单轮和多轮两种设定下分别完成任务。 图 1 来自论文 Figure 1。多轮设定下 6 任务平均性能下降 39%，分解为 aptitude（最佳情况下的表现）下降约 16% 和 unreliability（最好与最差情况的差距）上升 112%。 关键不只是"变差了”，而是差在哪里。作者把性能损失拆成两个成分：aptitude（模型在最佳情况下的能力）只小幅下降，真正放大的是 unreliability——同一模型在最好和最坏会话之间的差距上升 112%。换句话说，能力还在，但发挥极不稳定。论文进一步发现一个和文档写作直接相关的机制：模型倾向于在信息不完整时就过早作答，一旦答错，这个错误答案会固化为后续决策的依赖，很难被后面揭示的信息纠正。Table 6 的数字更直白：在前 20% 轮次就首次作答的会话，平均性能 30.9；等到最后 20% 轮次才作答的，是 64.4——过早作答的会话性能不到延迟作答的一半。这和我们写文档时"模型读完一半材料就开始输出结构、后面怎么改都扭不过来"的体验是同一个机制。 原因一：信息多，指令少，剩下的靠猜 写文档的典型输入是一堆素材加一句模糊指令：“把这些资料整理成技术分享。“素材提供了内容，却没提供决定：写给谁、回答什么问题、多长、什么算证据。这些决定不会被跳过，只会被模型按最像的样本补全——猜的方向和你的意图不一致，就是写偏。这不是偶发事故，而是长期多轮写作对话里的普遍观察。Claude Code 的官方文档把这个取舍说得很直白：花时间把 spec（需求规格）写精确，比盯着实现过程更有回报。指令模糊的时候，精确的不是 spec，是模型的想象。 ...

Agent 已能对结构清晰、参考实现明确的算子稳定拿到 2-5x 加速；量化与复杂融合仍未解决。

一句话结论 FlashAttention 系列解决了"标准 attention 在 GPU 上跑不快"的系统问题——不改数学、不牺牲精度，靠 tiling（分块）和 IO-aware（感知内存层次）设计把 attention 推向硬件极限；Flash Linear Attention（FLA）系列则用同样的分块思想，把理论 O(N) 的线性 RNN 内核也提速到超越 FlashAttention。两条线在"长上下文高效序列建模"上汇合，共同构成了今天大模型长上下文能力的底层基础设施。 先说清一个名字：FlashAttention 是一系列论文（2022–2024），优化的是标准的 softmax attention；Flash Linear Attention（FLA） 是一个开源项目（2024 起），优化的是线性 attention / 线性 RNN。两者共享"分块 + 避免 HBM 往返"的思想，但不是同一个东西。 为什么 attention 慢：GPU 内存层次是第一瓶颈 标准 attention 需要计算 QK^T，时间与内存都随序列长度 N 二次增长。但很多人忽略一个更实际的问题：GPU 上跑的慢，往往不是算得慢，而是搬数据搬得慢。 GPU 内存是分层的：HBM（高带宽内存，容量大但慢）和片上 SRAM（容量小但快）。朴素实现把 N×N 的注意力矩阵完整写进 HBM 再读回来，大量时间花在内存搬运上，而不是矩阵乘上。 FlashAttention 系列盯住的就是这个"内存搬运"问题，用一句话概括它的核心策略：把中间结果留在离计算单元最近的地方，绝不落盘到 HBM。 先给出标准 attention 的数学形式，后面所有优化都是围绕它展开的： $$ \text{Attention}(Q,K,V) = \text{softmax}\left(\frac{QK^\top}{\sqrt{d}}\right)V, \quad S = QK^\top \in \mathbb{R}^{N \times N} $$其中 $Q, K, V$ 是查询、键、值矩阵，$N$ 是序列长度，$d$ 是每个头的维度。问题在于中间矩阵 $S$ 是 $N \times N$，序列变长时它主导了内存和时间。 ...