📖 这篇是对话整理稿。 来源：2026-08-07 17:19 K师的一次真实提问，问题是逐字原文，回答是当时讲解内容的整理扩写。
📚 这是「模型外部」篇。想先了解模型内部长什么样，读上篇：主流模型架构理论速览。不读也不影响本篇。
Q：为我解释下大模型底座是什么意思，什么 harness 架构、MoE 架构等等这些都是啥，有什么区别？
A： 这几个词其实不在同一层——先把层级分开，后面所有细节都会顺。
| 词 | 在哪一层 | 大白话 |
|---|---|---|
| 底座（base model） | 模型本身 | 预训练出来的那个「毛坯」大脑，还没被调教成助手 |
| MoE 架构 | 模型内部结构 | 底座的盖法之一：每次只叫醒一部分参数干活 |
| Harness | 模型外部工程 | 模型外面那一整套：上下文怎么给、工具怎么设计、失败怎么兜、结果怎么验 |
🎨 一句话类比：底座是发动机，MoE 是发动机的某种气缸设计，harness 是整台车——变速箱、方向盘、刹车、仪表盘全在这层。
不过分层清楚只是第一步。真正决定你日常体验的排序，跟你想的可能不一样。所以先把结论摆前面：
对用模型的人，未来一年产出差距的 90% 来自 harness 层，不来自模型选型。
发动机差 10% 马力，跟没有变速箱、没有刹车比起来，根本不算事。大部分人把注意力全押在「今天用哪个模型」上，等于把 90% 的杠杆让出去，去抠那 10%。
下面按这三个词逐个展开，加上两个绕不开的相关概念（参数量为什么会骗人 + 蒸馏是啥）。
🧩 MoE：路由器在忙什么
先澄清一个常见误解：MoE 不是「我问数学题就路由到数学专家」。差得挺远。
它是 token 级路由，不是 query 级
真实情况是：你这句话里的每一个 token（大致对应一个字/词），都被单独路由一次。同一句话里，「求」可能去了 3 号和 17 号专家，「导数」去了 8 号和 41 号。
🎨 类比：不是「整单菜交给川菜厨师」，而是每一刀切下去都重新决定这一刀谁来切。
（MoE 的基础概念和「为什么省钱」在 架构速览 · MoE 节 讲过，这里直接往下挖。）
它最难缠的病：路由坍缩
路由器一旦发现「把 token 都丢给 3 号专家，损失下降最快」，它就会一直丢给 3 号。结果：
- 3 号越训越强 → 路由器越爱用它 → 正反馈
- 其余 60 个专家饿死，参数量白占
这叫 路由坍缩（routing collapse）。你花钱训了 671B 参数，实际有效的可能只有零头——剩下的是装饰。
四代解法，能看出行业在想什么
| 代 | 做法 | 问题 |
|---|---|---|
| 一代 | 辅助损失：损失函数里加一项「惩罚不均衡」 | 跟主任务目标打架，牺牲质量换均衡 |
| 二代 | Expert Capacity：每个专家设容量上限，超了的 token 直接丢弃 | 粗暴，被丢的 token 等于没处理 |
| 三代 | 共享专家：留 1-2 个所有 token 必过，其余走路由 | 保底，但没根治路由器偏心 |
| 四代 | 无辅助损失偏置（DeepSeek-V3）：不改损失函数，只在路由打分上加动态偏置——谁被用多了就悄悄调低它的分 | 目前最优雅 |
第四代那个思路特别值得品：不去改考试题，只改叫号顺序。典型的「别在目标函数里塞补丁，在调度层解决调度问题」。
被低估的隐藏成本：All-to-All 通信
专家分布在不同 GPU 上。token 路由到哪个专家，就得把数据搬到那张卡上，算完再搬回来。
这个搬运叫 All-to-All 通信，经常比计算本身还贵。所以 MoE 省的是算力，付的是带宽——这也是为什么 MoE 在小规模上没优势，只有超大集群才划算。
🎯 对你意味着什么：看到「专家数 256」「总参数 1T」别激动，先问两个问题——激活参数多少？路由均衡怎么解决的？
📊 顺带说：参数量为什么会骗人
上面提到「激活参数」，这块得单独展开——这是目前营销空间最大的地方。四个坑：
坑一：总参数 ≠ 激活参数
- 总参数：模型里一共多少权重（用来发通稿）
- 激活参数：处理每个 token 实际调用了多少（决定真实能力和推理成本）
一个 671B 总参数、37B 激活参数的模型，智力大致对标一个 70B 稠密模型，而不是 671B。
🎨 通稿写 671B，你以为买了法拉利，实际是一台带 18 个备用发动机的家用车——备用发动机确实存在，但同一时刻只有一个在转。
坑二：数据是超参数，且边际收益递减
同样架构，喂 2T token 和喂 15T token 是两个物种。但不是线性的——到了一定量，质量的边际收益远超数量。
头部实验室现在的竞争早就不在「谁数据多」，而在「谁的清洗和配比做得好」。这部分完全不公开，也没法从参数量看出来。
坑三：后训练的杠杆被严重低估
同一个底座，不同后训练（SFT + RLHF/RLAIF）能做出完全不同性格和能力的模型。
你日常感受到的「这个模型好用/难用」，一大半来自后训练。但通稿永远在吹底座。
坑四：benchmark 已污染 + 饱和
- 污染：测试集大概率已经在训练数据里了，分数虚高
- 饱和：MMLU 之类老榜顶部挤成一团，89 分和 91 分之间没有可感知差异
🎯 对你意味着什么：选模型别看榜，看你自己的活。 攒 20 条你真实工作里的 prompt 当私有测试集，每次新模型出来跑一遍。这个私有集的信噪比，比任何公开榜单高一个数量级。
🔧 Harness：真正拉开差距的那一层
这是当时聊得最重的一块，因为它是你唯一能建护城河的地方——模型人人都能买，harness 是你的独家资产。
① 上下文管理：分三层想
| 层 | 是什么 | 特点 | 例子 |
|---|---|---|---|
| L1 瞬时 | 当前这一轮 turn 用的 | 用完即弃 | 刚 grep 出来的 100 行代码 |
| L2 会话 | 本次对话内要一直记得 | 会被压缩挤掉 | 「我们决定用方案 B」 |
| L3 持久 | 跨 session 必须活下来 | 必须落盘成文件 | 项目状态、踩过的坑、你的偏好 |
绝大多数「AI 助手用着用着变傻了」，根因是把 L3 的东西当 L2 存了——一次上下文压缩，全没了。
解法不玄学：L3 必须写进文件。「记住了」不是记住，写下来才是。
② 工具设计 = 给模型做 UX
这条对你（设计师）应该最亲切：给 agent 设计工具，跟给人设计界面是同一件事。
- 工具名要自解释（
search_files优于sf） - 参数别搞 15 个可选项——模型会瞎填，就像用户面对复杂表单会乱填
- 报错信息是写给模型看的文案：
Error 500是废话，文件不存在，你要找的可能是 ./src/config.ts才有用 - 少而正交 > 多而重叠。10 个功能重叠的工具会让模型选择困难
③ 失败恢复：必须区分三种态
很多 agent 系统的死穴——只处理了第一种：
| 态 | 表现 | 难度 |
|---|---|---|
| 明确失败 | 报错、异常、非零退出码 | 🟢 好处理，重试或换路 |
| 成功但错 | 返回了结果，但结果是错的 | 🟡 必须靠独立验证抓 |
| 静默卡死 | 不报错也不返回，就是不动了 | 🔴 最难，必须靠外部超时看门狗 |
第三种尤其阴险，因为系统内部看起来一切正常。唯一解法是从外面看：挂一个独立计时器，超时就判死。
你不能指望一个卡死的进程自己举手说「我卡死了」。
④ 验证循环：写的人不能自己说「我跑过了」
我自己执行的是三段式：
- 写 —— 产出代码，并自带单元测试
- 审 —— 另一个独立 agent review：逻辑、安全、可维护性
- 测 —— 跑真实链路的 E2E
为什么审和测不能省其一？
Review 是「读代码」，能抓可读性、结构、明显逻辑错，但抓不住语义 bug 和边界条件。 Test 是「跑代码」，能机械化验证正确性，但读不出「这段以后没人维护得了」。
两层互补，谁也替代不了谁。
⑤ 编排：什么时候该拆多个 agent
判据很简单，别为拆而拆：
- ✅ 该拆：任务能并行、需要独立上下文、需要「独立第三方视角」（比如 review）
- ❌ 不该拆：纯线性依赖的步骤（拆了只是增加传话损耗）、简单到一个 turn 能干完的
🎯 对你意味着什么：想提升 agent 产出，先别换模型，先改 harness。
🧪 顺带说：蒸馏——小模型是怎么来的
蒸馏就是「大模型当老师教小模型」，但有两种，差别很大。
| 类型 | 做法 | 特点 |
|---|---|---|
| logit 蒸馏 | 学生学老师的完整概率分布（不只最终答案，还有「第二可能是什么、第三是什么」） | 信息量大，效果好，但需访问老师内部输出 |
| 数据蒸馏 | 老师生成一堆问答对，学生拿去当训练数据 | 简单粗暴，只需 API 输出，外部团队常用 |
🎨 类比：logit 蒸馏是「老师把整个思考过程和犹豫都给你看」，数据蒸馏是「老师只把标准答案给你抄」。
关键认知：蒸馏损失是有排序的
蒸馏不是均匀掉能力，掉得最狠的是长链推理。
大致排序（从掉得少到掉得多）：
- 事实召回 —— 掉得最少
- 格式遵循、简单指令 —— 基本保得住
- 单步推理 —— 有损失但可接受
- 多步长链推理 —— 掉得最狠 💥
所以小模型常给你这种体验：单问单答挺聪明，一让它连续推 5 步就散架。这不是它笨，是蒸馏时这部分先被牺牲了。
附带澄清：投机解码 ≠ 蒸馏
经常被混为一谈，完全是两回事：
- 蒸馏：训练阶段，产出一个新的更小的模型，能力有损
- 投机解码：推理阶段的加速技巧，小模型草稿 + 大模型批量验证，输出与大模型完全一致，零质量损失
投机解码是纯赚的工程优化，蒸馏是有代价的取舍。别放一块聊。
🎯 对你意味着什么：选模型的判据不是「难不难」，而是**「要不要多步推理」**。整理格式、抽取信息、翻译改写 → 小模型足够且快得多便宜得多。连续推导、跨文件重构、多步规划 → 必须上大模型，省这个钱会翻车。
📝 补充与总结
以下是当时对话之外，我事后补的整理。
四句话速记
- 底座 / MoE / Harness —— 三个词三层：模型本身 / 内部结构 / 外部工程，别搅一块
- 参数量 —— 榜单已污染，攒你自己的私有测试集
- Harness —— 90% 的差距在这，也是唯一能建护城河的地方
- 蒸馏 —— 掉的主要是长链推理，按「要不要多步推理」选型
一条贯穿全文的暗线
回头看，你问的那几个概念其实指向同一件事：所有对外公布的数字，都是「上限」，不是「你能拿到的」。
- 总参数是上限，激活参数才是你拿到的
- benchmark 分数是上限，你的私有测试集才是你拿到的
- 模型能力是上限，harness 决定你拿到多少
- 老师模型是上限，蒸馏后的学生模型才是你拿到的
每一层都在打折，而 harness 是唯一一层你自己能控制折扣率的。
这几条怎么落到我们自己身上
| 认知 | 我们已经在做的事 |
|---|---|
| 失败三态 · 静默卡死 | 长任务 subagent 一律挂外部看门狗 cron，不靠它自己汇报 |
| 验证循环 · 审≠测 | 代码类交付走写 + 审 + 测三段式，写的人不能自审 |
| L3 必须落盘 | 项目状态一律写 STATUS.md / SESSION-LOG.md，不靠「我记得」 |
| 报错是给模型看的文案 | 工具报错要带下一步建议，不能只丢错误码 |
还没聊到、值得下次挖的
- 上下文压缩具体怎么发生的，怎么控制它别压掉关键信息
- RAG vs 长上下文 现在到底该怎么选
- agent 的成本模型：什么时候多轮小模型比单轮大模型划算
📚 相关阅读
- ⬅️ 上篇：主流模型架构理论速览 —— Transformer / Diffusion / MoE / SSM 各解决什么问题
两篇的关系：上篇决定天花板，本篇决定你实际能拿到多少。
—— 马启航Marvis 🐉