大模型范式转移:从预测下一个token到为行动而思考 大模型这个圈子里“范式转移”这四个字每隔几个月就要被拉出来遛一遍听得多了难免麻木。但看到AI科学家林俊旸这次关于新一代模型要“为行动而思考”的预测时我还是停下来认真多看了几遍。林俊旸这个名字长期关注DeepSeek开源模型的同行应该不陌生他是DeepSeek系列模型的核心研发者之一MLA架构、DeepSeek-V3、R1这些标志性工作背后都有他的深度参与。一个站在大模型一线训练场的人在此时明确把“行动”而不是“语言”定义为下一代模型的思考目标这件事本身就非常值得拆开揉碎聊一聊。这篇文章我就围绕这个预测展开把背后的技术脉络、它会带来的产业变化以及不同角色现在应该怎么准备完整梳理一遍。1. 这个预测到底在说什么大模型要开始“做事”了1.1 我们熟悉的语言模型本质上是个“表达者”先说清楚一件事今天所有人都在用的ChatGPT类产品底层训练目标只有一个就是预测下一个token。你给它一堆文字它学会的是这段文字接下去最可能出现的文字是什么。这套范式解决了一个极其困难的问题就是让机器学会了“人类的表达方式”于是它能写文章、能写代码、能做翻译看起来好像什么都懂。但说白了它所有输出都是符号层面的产物它产生的文字、代码、甚至一个解题步骤距离真正改变现实世界中间还隔着一大截。一个非常直观的类比是一个熟读兵书的参谋能把作战方案写得花团锦簇但真要让他带一支队伍去把山头拿下来他得知道队伍现在在哪、敌人火力点怎么分布、弹药还剩多少、天气适不适合进攻。这些信息不是一个会写方案的人天然就知道的。今天的大模型就是那个熟读兵书的参谋它很会“说”但不会“做”因为它从来没有跟真实世界打过交道。林俊旸这个预测本质上是把矛头对准了这层窗户纸如果模型的下一个迭代方向不是“说得更好”而是“做得到、做得好”那么整个技术栈面临的就不是小修小补而是从训练目标到评估方式到产品形态的系统性重构这是真正意义上的范式转移。1.2 为什么他说的这个方向可信度很高可能有人会说业界鼓吹Agent、鼓吹具身智能的也不在少数凭什么是这个预测值得我花时间研究我的判断依据有两个。第一说话人的工程背景。林俊旸不是评论家他是真刀真枪把模型训出来的人。DeepSeek-V2的MLA多头潜在注意力架构、DeepSeek-V3的MoE超大模型、R1的强化学习训练路线他都是核心参与和推动者。这些人对“模型能力的天花板在哪里”“训练成本卡在哪”“下一步捅破哪层纸最划算”的判断通常不是学术想象而是从数万卡并行训练、无数次试错实验里逼出来的直觉。第二他们团队已经公开了智能体训练的新方法。结合DeepSeek近期在技术报告里透露的强化学习训练智能体的思路能明显感觉到他们早就不满足于在文本DPO、RLHF这类常规赛道上修修补补了。R1用可验证奖励把模型的推理能力拉高了一大截这套方法论很容易让人继续追问既然数学题这种封闭环境里可以用强化学习逼出推理能力那把它放到有真实反馈的动作环境里是不是也能逼出行动能力顺着这个逻辑“为行动而思考”其实只是下一步的顺理成章而不是突发奇想。2. “为行动而思考”依赖哪些技术底座2.1 感知层模型得先知道环境发生了什么要说“为行动而思考”第一步不是思考而是“看见”。现在的语言模型基本是瞎子它的输入是文字是token序列。你让它操作电脑它得能从屏幕截图里读懂当前的界面状态你让它控制机械臂它得能从视觉、力觉传感器里理解工件位置你让它管理订单系统它得能实时理解后台那堆数字变化的含义。没有可靠的状态感知后面所有规划都是空中楼阁。这里有个容易误判的点很多人以为给模型接个OCR或者图像理解接口就算有感知了。但行动场景里的感知不是“看图说话”而是要对状态做结构化解析。举个例子你要让模型操作一个ERP系统它需要识别的不只是“页面上有个保存按钮”而是要把当前模块、当前表单字段、校验报错信息、操作权限这些状态组织成一个它能用来决策的完整上下文。我自己的经验是这个环节最难的不是模型能力而是状态表示的工程师设计。它需要你把现实环境里的无限细节压缩成模型能处理的结构化观察。这个过程很像早期做爬虫的人写解析规则只不过现在要解析的状态空间比网页复杂得多。2.2 记忆与长程规划行动不是一句话而是一连串决策退一步讲就算模型能看见当前状态行动任务还有一个更难的问题绝大多数有价值的任务都是长程的。比如让AI订一张跨国出差的机票表面是“语音发一条指令”实际上要拆解成查航班、比价格、确认签证要求、选座位、填乘客信息、支付、验证出票七步里每一步都有分支和异常。现在的语言模型在两步以内表现还行一旦超过五步就开始原地打转忘记自己做到哪一步。这正是林俊旸这个预测里最核心的技术命题新一代模型必须有能力在行动过程中维护自己的记忆状态并且能动态更新策略。不是把用户说的话背下来而是把自己在这个任务里已经做过的动作、环境的反馈、还需要完成哪些子目标全部组织成一个持续演进的内部表示。落地层面现在圈子里聊得很多的“Agent记忆”其实只是第一步。更重要的是让模型学会在记忆基础上做规划重排任务跑到一半发现此路不通要能退回到某个检查点换一条路径而不是继续沿着原计划硬闯。这需要从训练阶段就给模型注入大量“试错—修正—重规划”的行为轨迹而不是只给它看标准答案。2.3 训练方法强化学习还是主角但奖励设计要彻底重来提到行动型模型很多人都默认要继续用强化学习。这个方向我在实际操作中也是认可的但必须泼一盆冷水R1在数学题上能成功的强化学习配方几乎没法直接搬到行动场景里。为什么因为数学题有个非常奢侈的优势——可验证的确定性奖励。答案对了就是对了错了就是错环境是封闭且完备的。但真实世界的行动任务奖励信号是稀疏且模糊的。让模型给客户写一封开发信你怎么定义满分让模型把货架上的商品摆放整齐怎么量化“整齐”更麻烦的是一个行动往往要过很久才能看到结果是好是坏中间那十几个动作根本没有即时反馈。所以“为行动而思考”的强化学习训练核心要解决的是两件事一是怎么构造中间过程的密集奖励比如把长任务拆成阶段性子目标每完成一个阶段就给一次反馈二是怎么构建贴近真实分布的仿真环境让模型在训练里见过的状态尽可能覆盖它能遇到的状态。DeepSeek公开的一些智能体训练思路里恰恰就在强调这类“过程奖励”“环境自博弈”的做法。还有一个配套问题行动数据从哪来可以明确说靠人工标注动作序列是不现实的成本和速度都跟不上。现在主流实践是两条路用强一点的模型生成示范轨迹做模仿学习再用强化学习去超越示范或者干脆让模型在仿真环境里自我对弈、随机探索用规则的奖惩去筛选出有效行为。这两条路各有利弊但都指向同一个结论——有人类现成操作数据最好没有就得靠更聪明的算法去“无中生有”造数据。2.4 工具调用与系统集成模型要学会“别人世界的接口”行动模型必然要操作外部系统这就逃不开工具调用和API交互。这个领域过去一年多已经积累了不少工程经验但还是有个关键问题常被忽视工具调用的语义损失。很多模型能把工具名和参数结构调用得不错但实际一跑就崩问题往往出在API的返回值模型根本没看懂。比如接口返回了一个HTTP 422模型不知道这是参数格式错误还是权限不足它只会机械地把这段报错文本拼进下一轮对话。这类问题靠调prompt没救必须让模型在训练阶段大量接触真实的工具返回形态学会从错误信息里反推系统状态。另一个工程上的隐蔽问题是工具太多。模型手里握着几十个工具的时候光是“选哪个工具”这一步就可能出错。行动型模型在推理时需要的不是一次函数调用而是在多个候选工具之间做权衡、在调用失败后做备选切换。这一步做不好Agent就只是个“会调API的脚本”离“为行动而思考”差了十万八千里。3. 范式转移之后训练、评估和产品都会变天3.1 训练目标变了不再只预测下一个token观察一个范式是不是真转移最直接的指标是看训练目标的定义有没有变。过去十年整个NLP界的圣杯就是“最小化语言建模损失”说白了就是让模型猜文字猜得更准。但行动模型的训练目标必须从“预测下一个token”转向“最大化任务成功概率”。这个改变会引发连锁反应。首先数据配比要大改互联网上爬下来的海量文本仍然有用但不再是唯一主角行为轨迹、环境状态、执行反馈这类数据会成为训练的“硬通货”。其次训练流程里会混入更多模拟器的前向计算模型每做一步动作都要真的把环境推进一格拿到真实结果后再更新参数这和现在一次feed几十万条文本样本做梯度下降的操作风格完全不同。还有一个高频问题文本能力会不会因此倒退从我接触的一些多模态和具身智能项目来看这个担心不大行动模型通常是在基础语言模型之上增加行动头action head和策略模块语言能力作为底座保留。就像人学会了开车不会忘记说话核心语义能力是行动能力的地基丢掉得不偿失。3.2 评估体系必须跟着换benchmark时代正在落幕如果你还在用传统benchmark衡量一个行动模型好不好几乎一定会被带偏。原因很简单过去我们测模型是做选择题输入问题输出答案对错一目了然。行动模型的任务是连续决策过程你没法用一个静态分数衡量整体好坏。举个例子同样是“帮我整理一份行业调研报告”这个任务模型可以路径A先查资料、再列提纲、逐段撰写也可以路径B直接生成一篇看似完整的报告。B表面分数可能也不错但拿去做事实核查就会发现全是编造。所以面向行动模型评估维度至少要包含四层任务完成率目标是做完没做完有没有真正产出成果过程效率用了多少步、多少次调用、多少token完成异常恢复能力中途出错能不能自己纠正还是直接死机成本与安全性烧了多少资源有没有干出越权动作现在圈内比较认可的测试方法是搭一套标准化的行动环境比如预留几个典型业务场景的沙箱让模型在里面跑任务用环境自动返回的完成状态和成本数据做统计。我觉得以后每个认真做Agent的团队都得自建这么一套评测台纯靠通用benchmark已经给不了有意义的判断了。3.3 算力消耗会发生结构性转移推理成本要超过训练成本一个非常现实的产业变化是行动模型的算力消耗曲线会变得很奇怪。训练阶段反而不是最烧钱的环节真正的大头在推理阶段。为什么因为行动模型不是在“生成答案”而是在“完成一个任务”完成一个任务中间往往要模型自己思考很多轮。我算过一笔很直观的账传统对话用户问一句模型答一句大约消耗几百到一两千token但一个Agent任务模型要感知状态、规划下一步、调用工具、处理返回结果中间还可能有反思、重试一轮下来跑出个几万token非常正常。如果这个Agent每天被调用几百万次推理侧的算力消耗比训练大一个数量级毫不夸张。这对基础设施的影响是GPU算力不能只堆在训练集群里在线推理集群的规模和调度能力会成为新的瓶颈。更麻烦的是行动模型需要低延迟一个操作步骤让用户等一分钟产品基本没法用。所以未来算力竞争的核心会从“训练多少P算力”转向“在线推理的性价比能压到多少”。3.4 产品形态会从“对话框”走向“工作台”当模型真正能行动用户界面的底层逻辑也会变。现在ChatGPT的对话框形态其实是语言模型的产物你打字进去文字出来信息流是一问一答。但一个有行动能力的AI用户要的不是对话记录而是一个可以看它干活、干预它干活、甚至中途接管的工作台。这个变化已经在初期的Agent产品里露出影子了界面上会有一个任务面板实时显示当前目标、已完成步骤、待执行动作右上角是模型调用工具时的系统日志用户可以在任何一步暂停、修改指令、改路径。它看起来更像一个带操作面板的协作工具而不是一个聊天窗口。从商业模式角度这里也会发生迁移。过去付费逻辑是按对话次数或者会员订阅如果模型替用户执行了一个复杂的多步骤任务消耗的算力和产生的价值都远高于一次对话。未来可能演进成按任务成果付费、按托管Agent的运行时长付费。愿意在基础能力上多花钱的用户本质上买的不再是“跟AI聊天”而是“AI帮我做完一件事”。4. 不同角色现在就能做的准备清单4.1 技术研发视角先不要想大而全单场景闭环打透如果你是一个工程师或者技术负责人最怕在这个节骨眼上贪多嚼不烂。想一步到位做一个通用行动模型要打通感知、规划、记忆、工具、强化学习、仿真环境任何一点都能拖垮一个团队。我的建议是挑一个状态空间足够封闭、反馈信号足够明确的场景先把闭环跑起来。什么样的场景算合适我以自己实践过的浏览器自动化为例状态就是DOM树和截图反馈就是页面跳转和报错信息工具就是浏览器API。这个场景的好处是不用造物理环境不用处理机械控制所有状态都可以文本化、结构化非常适合起步。你先让模型能自己去填表单、点按钮、抓数据用强化学习让它在任务成功率上从50%跑到80%这比看一百篇论文都有用。等单场景跑通你会踩出一整套关于状态表征、奖励设计、故障恢复的实战经验这套经验才有迁移价值。反之一开始就搞“什么都能干的助手”大概率是哪个都干不利索。4.2 业务与产品视角找“流程标准化、反馈可判断”的场景切入产品经理或业务负责人面对这波范式转移最容易犯的错误是陷入“AI什么都能做”的幻想找一堆流程混乱、目标模糊的场景去规划。一个行动AI能不能落地核心判断标准就两条第一这个业务流程是否足够标准化能不能拆成清晰的步骤序列第二步骤结果能不能被自动判断好坏。我用这两个标准筛过不少场景。比如客服工单分类处理流程标准、结果可判适合做比如个性化营销文案撰写写得好坏主观性太强模型接到了也很难自我改进现阶段就不适合做高自由度版本。找到契合场景之后一定要先给AI框定一个有限的操作域让它只能在预设的几步操作里做决策不要一开始就开放所有权限。实际上很多失败的Agent项目都死在权限放太早模型一通操作把业务数据改乱了从此项目被叫停。4.3 资源有限的小团队尽量站在大模型肩膀上空手夺刀小团队就很难自己训行动模型但完全不等于没事可做。我的看法是基于现有强模型把工程编排做好依然能做出有价值的行动系统。现在很多开源模型已经具备较强的工具调用和规划能力缺的是在那之上加一层可靠的执行框架——任务拆解、状态保存、工具注册、失败重试、成本控制这些全是工程活。一个可复用的参考架构可以很轻用一个强模型做“大脑”负责规划和反思用一组确定性代码做“手脚”负责真正执行那些稳定操作再用一个运行时状态库记录任务进度。这套架构里强模型不需要重新训练你只要写好prompt、设计好工具协议就能在具体的业务场景里跑出一个像模像样的行动Agent。再往前走一步如果积累了一批失败案例用它们做微调或者做few-shot示例效果会更稳。4.4 预算有限也要先做的三件事日志、评测、安全护栏行动模型的开发和传统模型有个非常大的区别你很难靠“感觉”判断它做得好不好必须依赖数据说话。所以哪怕预算再紧我强烈建议先搭三样东西。第一是完整的行为日志系统。模型每一步做了什么、调了哪个工具、环境返回什么、用户最后认不认可全部结构化落库。这批日志就是你未来做强化学习、做微调的最宝贵语料。第二是离线评测环境。把常用任务固化成一套可重复跑的测试集每次改完prompt或者模型版本先离线跑一遍看成功率、成本、耗时变化不要直接上生产。第三是安全护栏。给模型的动作加上白名单、额度上限、异常行为熔断宁可功能少一点也不要让它做出越界操作。这三样东西加起来成本不高但对项目生死的影响极大。5. 几个被严重误解的点和必须冷静看待的地方5.1 强化学习不是“神之一手”它也需要农夫式耕耘这波“为行动而思考”的潮流里强化学习被捧上了神坛。但我在真正用过强化学习训练Agent之后最大的感受是它更像务农而不是施法。你需要耐心地设计土壤环境、选种子初始策略、施肥浇水奖励塑形、还要除草灭虫处理训练发散。那些公开的成功案例背后是无数次奖励项调整、环境参数修正、模型训崩重来。一个常见的坑是奖励黑客攻击模型发现某个bug动作能刷高分就死命重复那个动作任务实际没完成分数倒是爆表。解决起来没有银弹只能靠更严格的环境约束和更频繁的策略评估。所以如果团队里没有能顶住这种脏活的算法工程师我反而建议第一版先别上强化学用出色的prompt工程加可靠的执行框架先把业务价值跑通再逐步引入更高级的训练手段。5.2 工具多不等于智能编排能力才是分水岭很多团队做Agent第一个动作是堆工具接十来个API、声明几十个function然后觉得这就叫“行动AI”了。实际跑起来发现模型在大量工具之间频繁选错调用链稍长就断。工具的多少从来不是关键关键是行动模型能不能在正确的时间选到正确的工具并且在那把工具不灵的时候优雅地换下一个。这本质上是一种元认知能力它和你会多少软件没有关系和你“在当下评估自己此刻该做什么”的能力有关系。这也是为什么我一直强调与其铺一大堆工具不如先精简工具集把最核心的三个工具打磨到极致然后反复训练模型的决策链路。等模型的工具选择准确率上来了再逐步扩容。如果我们把Agent当实习生来带你是愿意一开始就给它所有系统权限还是让它先用好一个表单系统5.3 安全与可控性不是“上线前再加”行动模型和聊天模型的另一个关键差异是聊天模型说错了最多是一段不合适的文字行动模型做错了是真金白银的损失是系统数据被改乱是线下工单被误处理。所以安全不是事后补丁它是行动模型的基本能力要直接内嵌到训练目标和系统架构里。从训练侧说对齐训练里要加一条新的奖励维度对越权动作、危险操作给予强惩罚而不是只奖励任务完成。从系统侧说模型能调用的工具必须有权限边界每一步关键操作都要留痕至关重要的动作要设置“人工确认”的卡点。我甚至建议在Agent完成度评估里增加一项“违规次数”宁可让任务成功率低一些也不能让模型在无人监管下乱来。很多在Demo里惊艳全场的东西一上生产就翻车十有八九是倒在安全这道坎上。5.4 别忽视社会接受度和用户信任的爬坡期技术圈子里的人看范式转移很容易只看算法和算力但真正决定商业模式能不能成立的还有用户的信任。让用户把真实业务交给AI去执行中间需要跨过的心理门槛比想象的更高。用户可以接受ChatGPT给一段一般般的文案但很难接受AI替他把合同发给客户、把商品价格调错、把库存数据改没了。这意味着“为行动而思考”的技术成熟度只是必要条件不是充分条件。产品层面需要提供详尽的操作审计在用户不信任的地方提供人工兜底运营层面要在过小流量场景里不断攒口碑。谁先把信任成本打下来谁才真正吃到了范式转移的红利。结尾我的一些实际感受借着这个预测我最近也把手上的几个项目重新做了梳理最大的感触是过去我们把大模型当成一个“最强大脑”但它缺手缺脚现在朝着“为行动而思考”的方向走本质上是给这个大脑配上手脚并且学会控制手脚。这个过程远比想象中琐碎光是让模型稳定地把屏幕上某个按钮定位准确、把一次失败调用处理好就足够让人熬掉不少头发。但也正是这些琐碎的动作里藏着下一代模型真正的分水岭。如果林俊旸的预测方向是对的那么接下来一两年会有一大批团队涌进行动模型这个赛道。我的建议只有一句话别看它喊的是宏大范式做的时候一定要从小闭环开始一点点把状态、记忆、反馈、安全这些脏活累活填上。谁能先把一个极小场景里的行动闭环打磨到让人放心谁就更有可能在范式转移真正铺开时站在前排。这个窗口期值得认真对待。