杨植麟访谈：K2 模型、Scaling Law 与 Agent 未来

LaTeX 源码 · 备用 PDF

字段	内容
作者/整理	基于公开课程资料整理
来源	张小珺商业访谈录
日期	2025年7月

攀登无尽的雪山：AI 创业的心路

从"向延绵而未知的雪山前进"到"Beginning of Infinity"

杨植麟是月之暗面（Moonshot AI）创始人兼 CEO。时隔一年（2025年7月），再次接受访谈时，他用《无穷的开始》（The Beginning of Infinity）的哲学来描述自己的感受：

问题不可避免，但问题可以解决

David Deutsch 在《无穷的开始》中提出两句核心命题：

问题是不可避免的（Problems are inevitable）
问题是可以解决的（Problems are soluble）

研发 AI 的过程恰好体现了这一哲学：解决了强化学习的很多问题，就面临评估、验证等新问题；解决了预训练效率问题，又面临 Agent 泛化问题。每次解决一个问题，技术就再攀登几百米，同时看到新的问题。

杨植麟认为，AGI 可能不是某一级台阶，而是一个方向。今天的 AI 在很多领域已经比 99% 的人类做得更好——在某种意义上可以视为部分 AGI。但很难说某个时间点突然达到 AGI，它更像是持续攀登的过程。

雪山可能没有尽头

杨植麟表达了一个乐观的观点：他希望这座雪山一直没有尽头——"所谓的 Beginning of Infinity 就是这个意思，它可能是一座无限的山"。而且到某个阶段，可能不再是人类在爬，而是用 AI 来攀登——比如用 K2 模型来参与模型训练、数据处理相关的工作。AI 正在成为"人类文明的放大器"。

本章小结

AI 创业是一个持续解决问题、又发现新问题的过程。AGI 不是一个终点，而是一个方向。AI 正在从工具演变为研发过程中的参与者。

过去一年全球大模型的范式级变化

第一个范式：强思考的推理模型

以 O1 为代表的基于强化学习的推理模型（Reasoning Model），是过去一年最重要的技术突破之一。

推理模型的本质：猜想-验证循环

推理模型的核心能力是"反思"（Reflection），它本质上包含两种能力：

提出猜想：在解决问题过程中不断提出新的假设
自我验证：对每个猜想进行隐式的验证，判断对错

通过多次"猜想→验证→新猜想→再验证"的循环，模型可以将 Pass@2 的问题变成 Pass@1——本质上是等价地尝试了多次。这与人类做科研、解题的过程非常相似。

杨植麟将这种推理模型形象地比喻为"缸中之脑"——它不需要与外界交互，只是在自己的大脑中思考，就能通过猜想-验证循环解决问题。

串行 vs. 并行采样

推理模型的有效工作方式主要是串行的——每次猜想基于前一次的结果。虽然也可以搭配并行策略（同时采样多个方案），但最近的研究表明，串行的上限通常更高。这与月之暗面的实验结论一致。

第二个范式：Agent 强化学习

与推理模型的"缸中之脑"不同，Agent 模型通过多轮交互与外界环境进行互动：

边思考边执行操作（搜索、浏览器、写代码等）
通过多轮方式解决问题
下一步行为取决于外界反馈和状态更新

两种 Test-Time Scaling 的统一

推理模型和 Agent 模型都指向同一个核心概念——Test-Time Scaling：

推理模型：Scale 单轮内的思考 Token 数量（更多的内部推理）
Agent 模型：Scale 多轮交互的轮次数量（更多的外部交互）

两者都是在推理时投入更多计算资源来完成更复杂的任务。传统对话模型可能只输出几百个 Token，而推理/Agent 模型可以花费数小时、消耗大量 Token 来完成复杂任务。

Claude vs. OpenAI 的技术路线差异

Reasoning 和 Agent 不必然是线性依赖

杨植麟指出一个有趣的观察：Claude 的模型在 Reasoning 基准上表现并不突出，但在 Agent 任务上表现非常好。这说明：

Reasoning 和 Agent 对应两种不同的 Test-Time Scaling 维度
两者在研发上不是必然的先后顺序
但要达到 Agent 的最高水平，最终仍需要很强的 Reasoning 能力

Claude 可能更多投入在 Agent（多轮交互）方向，OpenAI 更多投入在 Reasoning（深度思考）方向。不同的技术路径会导致短期产品差异，但长期来看两者都不可或缺。

第三个趋势：模型公司做一方产品

正向设计 vs. 逆向工程

杨植麟区分了两种产品开发方式：

第三方逆向工程：基于现有基础模型，通过设计腳手架、工具、System Prompt 来逆向工程模型的训练过程，找到最佳的使用方式（如 Manus 等）
一方正向设计：模型公司先设计好工具和 Context Engineering 方法，然后在这个环境中训练模型，使模型天然在自己的环境中表现最好（如 Claude Code、ChatGPT Agent）

第二种方式的上限可能更高，因为可以更好地整合工具和模型，端到端地做训练。

本章小结

过去一年的三大范式级变化：(1) 推理模型（缸中之脑式的猜想-验证循环），(2) Agent 模型（与外界多轮交互），(3) 模型公司做一方产品。推理和 Agent 是两种 Test-Time Scaling 维度，最终需要结合。

OpenAI L1-L5 分级的再思考

五个层级的含义

OpenAI 定义了 AI 能力的五个层级：L1 ChatBot → L2 Reasoning → L3 Agent → L4 Innovation → L5 Organization。

层级之间不是线性关系

杨植麟对 L1-L5 的关键洞察：

这五个层级并不完全是串行的——有些能力是并行发展的
Agent 的上限取决于 Reasoning 能力，但 Agent 不必等 Reasoning 完全成熟才能开始
Innovation 的标志是"模型参与模型开发"——比如 K2 参与 K3 的开发
Organization 的雏形已经出现——Multi-Agent 系统中不同 Agent 承担不同角色

用 L4 的技术解决 L3 的问题

一个有趣的循环依赖：要解决 Agent 泛化问题（L3），可能需要 Innovation（L4）的技术——即用 AI 来训练和对齐 AI。这说明这些层级之间存在复杂的交互关系，而非简单的顺序依赖。

本章小结

L1-L5 是几个重要的技术里程碑，但并非严格的线性关系。Reasoning 和 Agent 是 Innovation 和 Organization 的前提，但它们之间存在复杂的相互依赖。每个层级的能力都会持续提升，没有明确的"封顶"。

K1.5 到 K2：月之暗面的技术演进

K1.5：强化学习技术验证

K1.5 主要是强化学习技术路线的验证——月之暗面是较早在这条路线上投入的团队。关键发现：

端到端 Reward 胜过 Process Reward

K1.5 的重要技术发现：不太需要 Process Reward Model（PRM）或 Value Function。直接使用端到端的 Reward 就可以把训练做得非常好。Process Reward 在训练过程中甚至可能有副作用。这在早期并不是非常明确的结论。

K2：追求更好的基础模型

K2 的设计目标有两个核心方向：

方向一：Token Efficiency——把每份数据的价值最大化

为什么 Token Efficiency 比 Compute Efficiency 更重要

高质量数据的增长非常缓慢——可以近似看作一个常数（如 30T 高质量 Token）。在这个约束下：

Compute Efficiency（训练更快）：虽然有价值，但不能提升智能上限——你只是更快地训练完同样的数据
Token Efficiency（学得更好）：同样的数据，模型吸收得更多、压缩率更高、loss 降得更快——直接提升智能上限

月之暗面通过三种方式提升 Token Efficiency：

Muon 优化器：基于矩阵正交化的新优化器，取代使用了 10 年的 Adam。在 Compute Optimal 条件下，Token Efficiency 提升约 2 倍——等于学 1 份数据相当于 Adam 学 2 份
更大的稀疏度：通过更大的稀疏度加入更多参数，参数越多，同样数据的吸收效果越好
数据 Rephrase：对高质量数据进行改写，使同一份数据以不同形式被多次学习，提升泛化性

Muon 优化器的技术背景

Muon 优化器由 Keller 提出，核心思想是不把矩阵中的每个参数元素独立考虑（如 Adam 那样），而是考虑参数之间的依赖关系（dependency），通过矩阵正交化的方式实现更高效的学习。

月之暗面的贡献是将 Muon 在大规模语言模型上实际落地。早期通过 Moonlight 项目首次在一定规模的语言模型上验证，后续进一步 Scale 时发现新问题（如 MaxLogit 爆炸），通过提出新的 Clipping 方式解决。

数据改写不等于简单复制

单纯重复学习同一份数据会导致过拟合和泛化问题。改写的关键是引入"新的熵"——使改写后的数据在保留核心知识的同时具有一定的多样性，从而提升泛化能力。但改写方式的选择至关重要，如何引入新的信息熵仍是活跃的研究方向。

方向二：Agentic 能力与泛化

Agent 泛化是当前最大挑战

对于 Agentic 模型，当前最大的挑战是泛化：

现有 RL 技术的局限：训练任务和评价指标往往是单点的（如只训练 SWE-Bench）
指标提升不代表泛化提升：SWE-Bench 分数提高，不意味着模型在其他代码任务上也好
Agent 的泛化问题比对话模型更严重
Benchmark 不够用或已失效

杨植麟认为可能的解法是"用 AI 训练 AI"：让模型参与到自身的训练和对齐过程中，用更 AI-Native 的方式提升泛化性。

K2 的研发过程

技术积累从一年前开始（Muon 优化器等技术需要长周期的 Scaling 实验验证）
K2 本身的训练周期并不长，但前置的技术准备需要大量时间
遇到的主要挑战：Muon 优化器在大规模训练时出现 MaxLogit 爆炸问题（小规模实验中无法复现）
研究团队和训练团队是同一个团队——因为训练中的问题需要深入理解底层技术才能解决

本章小结

K1.5 验证了端到端 Reward 的强化学习路线。K2 聚焦两个方向：(1) Token Efficiency（Muon 优化器 + 稀疏度 + 数据改写），(2) Agentic 泛化能力。Agent 泛化是当前最大瓶颈，可能需要用 AI 训练 AI 来突破。

Agent 的定义与未来

Agent 的两个核心特征

Agent = 多轮 + 工具

杨植麟对 Agent 的定义简洁而本质：

多轮（Multi-turn）：可以进行多次交互，这是 Test-Time Scaling 的一种方式，使模型能完成复杂任务
工具（Tool Use）：连接大脑与外部世界的方式——搜索引擎连接互联网，代码能力连接数字世界的一切自动化

通用性是 Agent 最缺的能力

从通用 Agent 到垂直应用

如果 Agent 有足够好的泛化能力，就不需要大量的垂直 Agent：

通用 Agent 只需接入不同的工具（定制数据库、定制 API、定制文档接口等），就能完成垂直领域任务
但当前 Agent 最缺的正是这种泛化能力——能否泛化到训练中没有见过的工具和环境
Benchmark 过拟合是一个风险：刷几个 Benchmark 的分数，不代表真实场景的泛化能力

Agent 的目的不是模拟人

杨植麟指出一个重要的区分：Agent 的目的是通用（General Purpose），而不是模拟人。人类也是通用的（Universal Constructor），Agent 的行为方式与人类相似只是一个巧合结果——就像飞机的设计目的是交通工具，不是为了像鸟一样飞。

本章小结

Agent 的两个核心特征是多轮交互和工具使用。当前最大挑战是泛化能力——能否在没见过的工具和环境上表现良好。Agent 的目标是通用智能，不是模拟人类行为。

Scaling Law 与模型架构

预训练 Scaling 的新瓶颈

高质量数据接近常数

高质量训练数据的增长速度远慢于算力增长：

高质量文本数据量可以近似看作常数
多模态数据无法有效提升文本的"智商"
这使得 Token Efficiency 成为比 Compute Efficiency 更重要的优化方向

Muon 优化器：突破 Adam 的 10 年统治

Adam 优化器统治了深度学习训练领域近 10 年。Muon 优化器通过考虑参数之间的矩阵结构依赖关系，实现了约 2 倍的 Token Efficiency 提升：

Adam：独立考虑每个参数元素，忽略参数间的结构关系
Muon：考虑矩阵参数间的 dependency，通过正交化方式优化
效果：30T 高质量 Token 的学习效果等价于 Adam 学习 60T Token

RL Scaling 的发现

强化学习中的 Curriculum 设计

在 Agent 训练中，不能一上来就让模型解决最难的任务（如证明未解数学猜想），否则 Sample Efficiency 极低。更好的方式是：

使用中等难度的任务进行训练
逐步提升难度（爬山过程）
搭配好的 Sampling 策略

这本质上是一个 Curriculum Learning 的过程。

本章小结

预训练 Scaling 的新瓶颈是高质量数据的有限性。Muon 优化器通过矩阵正交化突破 Adam 的 10 年统治，实现 2 倍 Token Efficiency 提升。RL 训练需要 Curriculum 设计来保证 Sample Efficiency。

模型训练的评估困境

Benchmark 失效与 Agent 泛化

Benchmark 过拟合的风险

当前 Agent 领域面临严重的评估问题：

可用的 Agent Benchmark 数量有限
刷高 Benchmark 分数不代表真实能力——很多时候是对特定任务的过拟合
用户在 OOD（Out-of-Distribution）场景的体感与 Benchmark 分数脱节
"种瓜得瓜、种豆得豆"——训练什么就提升什么，但泛化有限

评估困境的根源

杨植麟认为，评估困境的根源是：

强化学习最终依赖于好的评估/验证——数学题和有 Test Case 的编程可以自动验证，但复杂的端到端任务很难找到好的评估方式
模型能力提升带来的新问题：任务复杂度增加，评估方式需要跟上
Agent 任务的长尾分布特性：难以覆盖所有真实场景

本章小结

Benchmark 失效和 Agent 泛化不足是当前最突出的评估困境。根源在于复杂任务难以自动验证，以及训练分布与真实使用场景之间的 Gap。用 AI 参与评估和训练（AI 训练 AI）可能是突破方向。

一方产品 vs. 第三方生态

两种产品范式

模型公司做一方产品的逻辑

第三方范式：给定一个模型，逆向工程最佳的使用方式（System Prompt、工具设计、Context Engineering），本质是去拟合模型的训练分布
一方范式：先设计好工具和环境，然后在这个环境中训练模型。模型天然在自己的环境中表现最好，无需逆向工程

Cloud Code 和 ChatGPT Agent 都是一方产品的代表。月之暗面目前仍以模型为主线，但认为一方产品将是重要趋势。

本章小结

一方产品通过正向设计环境+训练模型，上限更高；第三方产品通过逆向工程模型使用方式，灵活但受限于模型训练分布。未来两种范式将共存互补。

从 K2 到下一代 Agent：哪些问题最难

Token Efficiency 与系统约束

访谈里一个非常明确的判断是：未来大模型竞争不只是 “谁的 compute 更大”，而是谁能更高效地消化高质量 token。杨植麟把 Muon 优化器、数据改写、合成数据、测试时扩展能力都放在同一张图里，本质上是在回答一个问题：当高质量训练数据越来越稀缺时，怎样让每个 token 产生更高回报。

为什么 Token Efficiency 比表面上的 Compute Efficiency 更关键

真正高价值的数据本来就少，不能指望无限堆数据解决问题；
Agent 任务训练代价更高，因为还要支付 rollout、tool use、环境执行和评估成本；
如果 token 利用率不高，即便算力更大，也会在高质量数据瓶颈前停下来。

K2 之后的三道硬门槛

如果把访谈里的判断压成更工程化的表述，K2 之后至少还有三道门槛没有真正跨过去：第一是 Agent 泛化，第二是评估体系，第三是系统级闭环。

门槛	访谈中的判断	为什么难
Agent 泛化	Benchmark 分高不代表真实场景能做对	任务分布长尾，训练分布与实际使用不一致
评估体系	复杂端到端任务缺少自动验证方式	没有稳定 verifier，就很难高质量做 RL
系统闭环	一方产品更容易把环境与训练绑在一起	第三方生态要靠逆向工程拟合模型训练分布

K2 之后真正困难的部分，不是 “会不会做演示”，而是如何稳定扩展到真实任务

最容易被低估的不是模型能力，而是评估成本

访谈里对 Benchmark 的批评非常尖锐：Agent 任务不像数学题或有 test case 的代码任务，很多真实工作没有天然标准答案。没有可靠评估，就无法稳定做强化学习；没有强化学习，就很难把长链路能力内化进模型。这是 Agent 迭代速度慢于外界想象的重要原因。

本章小结

如果说 K2 代表了模型能力的一次向前推进，那么下一阶段真正决定天花板的，将是 token 效率、可靠评估和系统化产品闭环。也正因此，杨植麟在整场访谈里始终把 “模型”、“数据”、“评估”、“产品” 放在同一张图里讨论。

对组织与产品团队的启示

这场访谈对研究团队之外也有直接启发。如果未来一方产品会越来越重要，那么组织形态也会跟着变化：模型团队不能只负责训练，产品团队也不能只负责包一层 UI，双方都需要理解工具环境、评估闭环和用户真实任务。

为什么一方产品路线会倒逼组织重构

做一方产品意味着环境设计、模型训练和产品交互需要同步规划；
如果组织仍按 “模型组”、“产品组” 完全割裂，很多关键反馈无法回流进训练；
Agent 产品越深入工作流，越需要把产品 telemetry、失败案例和训练数据打通。

访谈折射出的创业方法论

为什么模型公司不能只做模型

整场访谈虽然围绕 K2、Muon、RL 和 Agent 展开，但杨植麟反复强调的其实是一个更大的判断：模型能力、评估体系和产品环境必须同步演进。如果只把公司理解为 “训练一个更强基础模型”，就会低估后续最困难的环节，因为真正把能力变成用户价值的，是模型外面的系统。

从能力供给到任务闭环，价值链正在后移

预训练和后训练决定模型的能力上限；
评估体系决定这些能力是否能被稳定识别和持续迭代；
产品环境决定模型是否能在真实工作流中把能力兑现出来。

这也是为什么访谈里会同时出现 K2、Agent、Benchmark 和一方产品等话题。它们不是分散的热点，而是同一条价值链上的不同环节。

杨植麟没有把 “产品” 理解为最后包一层聊天界面，而是更接近 “给模型搭一个可以长期学习和执行的环境”。在这种视角下，产品既是分发渠道，也是训练环境的一部分。模型公司如果忽视这一点，很容易在 demo 层面看起来很强，但在真实任务上无法建立复利。

创业公司的节奏与窗口

这场访谈也隐含了一种创业节奏判断：在范式剧烈变化期，团队需要优先抓那些能够形成复利的基础能力，而不是追逐短期热点。无论是 Muon 优化器、Token Efficiency、Agent 泛化，还是评估体系，本质上都在争夺未来几年的技术坡度。

访谈中可以抽象出的三层窗口

算法窗口：谁能率先找到更高 Token Efficiency、更稳定 RL 和更好的 verifier，谁就能以更低成本扩展能力；
系统窗口：谁能把工具、环境、记忆和评估接到一起，谁就更容易把模型能力沉淀为产品体验；
组织窗口：谁能让研究、工程、产品数据形成快反馈回路，谁就更容易持续迭代。

最危险的误判是把短期领先误认为长期壁垒

访谈对 Benchmark 的警惕同样适用于公司判断。短期的演示效果、单点 benchmark 提升，甚至某次产品爆发，都不必然构成长期壁垒。真正的壁垒来自：能否持续吸收高质量数据、能否建立可靠评估、能否把用户任务反哺到训练与产品闭环之中。

“问题是不可避免的，问题也是可以解决的。” 如果把这句话放到创业语境里，它意味着团队不应该期待某个 “终局模型” 一次性解决所有问题，而应该围绕关键瓶颈建立一套持续爬坡的机制。K2 只是其中一个阶段性的高点，而不是路线结束。

本章小结

从这场访谈能够抽象出的创业方法论是：不要把模型、评估和产品分开看，而要把它们视作同一个系统的不同层。未来能赢下长期竞争的，不只是训练出强模型的团队，而是能把强模型持续变成真实任务闭环的团队。

总结与延伸

核心观点梳理

杨植麟访谈的核心要点

AI 是一座无尽的雪山：问题不可避免，但问题可以解决。每解决一个问题就攀登几百米，同时发现新问题
两种 Test-Time Scaling：推理模型（缸中之脑，Scale 思考 Token）和 Agent（与世界交互，Scale 轮次）
Token Efficiency 比 Compute Efficiency 重要：高质量数据是瓶颈，Muon 优化器实现 2 倍提升
Agent 泛化是最大挑战：Benchmark 过拟合严重，可能需要 AI 训练 AI 来突破
AGI 是方向不是终点：不会有某一刻突然达到 AGI，而是各项能力持续提升
一方产品趋势：模型公司正向设计环境+训练模型，上限更高

延伸思考

AI 的自我改进：当 K2 能参与 K3 的开发时，会形成怎样的加速循环？
评估范式革新：如何设计不会被过拟合的 Agent 评估方法？
数据瓶颈突破：除了改写和合成，还有哪些提升 Token Efficiency 的路径？
通用 Agent 的门槛：Agent 需要多强的泛化能力才能真正替代垂直解决方案？

拓展阅读

K2 技术报告（月之暗面官方发布）
David Deutsch, The Beginning of Infinity
Moonlight: 大规模语言模型上的 Muon 优化器
OpenAI L1-L5 分级体系
Claude Code 与 ChatGPT Agent 的一方产品设计