Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

林俊旸离职后首发长文:反思千问得失,预判 AI 下半场需要「智能体思维」

By: 李超凡
27 March 2026 at 15:00

带队发布 Qwen 3.5 小模型系列、获马斯克公开点赞,20 小时后在社交媒体宣告离职。林俊旸离开阿里的方式,本身就是 2026 年 AI 行业最戏剧性的一幕。

32 岁,阿里最年轻的 P10,一手将千问做到全球下载量超 10 亿次、衍生模型超 20 万款,成为全球开源模型的新王。他的离开源于一次组织架构调整的分歧:

阿里希望将 Qwen 团队按预训练、后训练、视觉、语音等维度水平拆分,与通义实验室其他团队合并;林俊旸则坚信预训练、后训练乃至基础设施团队应该更紧密地垂直整合,而非割裂。这不只是管理风格之争,更是对「怎样才能训出最好的模型」这个根本问题的路线分歧。

离开近一个月后,林俊旸发出了这篇长文。他没有回应任何人事风波,直接亮出了自己对 AI 下一阶段的判断:我们正在从「训练模型」的时代,进入「训练智能体」的时代

这篇文章之所以值得逐字读完,不仅因为写它的人在过去两年亲手操刀了 Qwen 全系列的后训练,更因为林俊旸在文中罕见地复盘了 Qwen3 在「混合思考模式」上的得与失。

以下为 APPSO 对林俊旸的编译:

原文🔗 https://x.com/JustinLin610/status/2037116325210829168

从「推理式思考」到「智能体式思考」

过去两年,彻底改变了我们衡量 AI 模型的方式。

OpenAI 的 o1 证明了一件事:「思考」可以是模型的核心能力,可以专门训练出来、直接交到用户手里。DeepSeek-R1 紧随其后,证明这种「推理式后训练」并非大厂专利,可以在原始实验室之外复现和扩展。用大白话说:o1 是一个被教会了「回答之前先想想」的模型,R1 则是一个开源版的同类选手,跟 o1 打得有来有回。

那个阶段很重要。但 2025 年上半年的行业主旋律,说到底还是在围绕一件事打转:怎么让模型「想」得更多。 让它在推理阶段烧更多算力,用更强的奖励信号训练它,暴露或控制那些额外的「思考过程」。

现在的问题是:然后呢?

我相信答案是智能体式思考。为了行动而思考,一边跟真实环境交互,一边根据世界的反馈不断修正计划。

1. o1 和 R1 的崛起真正教会了我们什么

第一波推理模型教会我们一个朴素的道理:想在大模型上把强化学习跑起来,你得有靠谱的评分标准。

什么叫靠谱?就是答案能判对错、结果能验证、反馈信号足够清晰。数学题有标准答案,代码能跑测试,逻辑推理能验证步骤。这些领域之所以成了强化学习的主战场,就是因为在这里,模型收到的奖励信号远比「让人类标注员觉得这个回答还不错」强得多。换句话说,强化学习终于能优化正确性,终于不用只追求看着像那么回事了。

然后,基础设施的重要性一下子凸显出来了。

一旦你开始训练模型进行更长的推理链条,强化学习就不再是在监督微调上面加个小配件那么简单了,它变成了一个重工业级的系统工程。你需要大规模的模拟推演(rollout)、高吞吐量的答案验证、稳定的策略迭代、高效的采样流程。推理模型的诞生,表面看是算法突破,底下看是基础设施的胜利

OpenAI 把 o1 定义为用强化学习训练的推理产品线;DeepSeek R1 接棒验证了同一方向,同时也展示了推理式强化学习对底层算法和基础设施的要求有多高。

APPSO 划重点: 第一次大转折发生了。行业焦点从「扩展预训练」转向「扩展面向推理的后训练」。模型变强靠的不再是吃更多数据,靠的是在训练后阶段学会「怎么想」。

2. 真正的难题从来不只是「融合思考和指令模式」

2025 年初,我们 Qwen 团队心里有一张很大的蓝图。

理想中的系统长这样:一个模型同时搞定「思考」和「执行」两种模式。你可以手动调节它思考的深度,轻度、中度、深度,就像调空调温度一样。更理想的情况是,模型自己就能判断:这道题简单,直接答;这道题有点难,多想想;这道题极难,调动全部算力来啃。

方向是对的。Qwen3 是当时最清晰的公开尝试之一。 它引入了「混合思考模式」,一个模型家族里同时支持「想了再答」和「直接答」两种行为,还描述了一条四阶段后训练流水线,其中明确包含了在长链推理冷启动和推理强化学习之后的「思考模式融合」步骤。

但融合这件事,说起来一句话,做起来要人命

难在哪?难在数据。

很多人一听「融合思考和指令模式」,脑子里想的都是模型层面的事:一个模型文件能不能同时跑两种模式?一套对话模板能不能在两种风格之间切换?一个推理服务能不能暴露正确的开关?这些确实要解决,但都不是最深的坑。

最深的坑是:两种模式想要的东西,从根儿上就不一样

你想想,一个好的「指令模型」该长什么样?干脆、简洁、格式规范、响应快。企业用户拿它来批量改写文本、打标签、做模板化客服、结构化数据提取,这些场景要的是效率和稳定,不需要深思熟虑。

一个好的「思考模型」呢?恰恰相反。它该在难题上多花时间、维持清晰的推理中间步骤、探索不同的解题路径、保留足够的「思考余量」来确保最终答案的正确性。

这两种性格天然打架。 如果融合的训练数据没有精心设计,出来的模型往往两头不讨好:思考的时候啰嗦、犹豫、不够果断;执行指令的时候又不够利落、不够稳定、比客户真正需要的版本更贵更慢。

说实话,我们在平衡融合与数据质量的过程中,没有把所有事情都做对

在不断修正的过程中,我们也仔细观察了用户到底怎么用这两种模式。结论是明确的:这两种行为画像确实在相互拉扯。

现实很诚实。2025 年晚些时候,在 Qwen3 最初的混合架构之后,我们的 2507 版本还是发布了独立的 Instruct 和 Thinking 版本,包括分开的 30B 和 235B 变体。大量商业客户根本不需要思考模式,他们要的就是高吞吐、低成本、高度可控的指令行为来跑批量任务。对这些客户来说,融合不是福音,是多余的成本。拆开来做,反而让两条线的团队都能更专注地解决各自的问题。

其他实验室走了相反的路:

Anthropic 公开押注集成式路线。Claude 3.7 Sonnet 是一个混合推理模型,用户可以选择普通回复或扩展思考,API 还能设定「思考预算」。Anthropic 直接放话:推理应该是模型的集成能力,不该单独拎出来做一个独立模型。

GLM-4.5 同样定位混合推理,把推理、编程和智能体能力统一到一个模型里。

DeepSeek V3.1 后来也做了类似的事,推出了「Think & Non-Think」混合推理方案。

那么问题来了:谁是对的?

答案不在「融合」还是「分离」这个二选一本身,在于融合是否有机。如果思考模式和指令模式只是尴尬地挤在同一个模型里,像两个性格迥异的人被硬塞进一件衣服,用户体验不会好。

真正成功的融合,需要一道平滑的光谱模型能自如地在不同推理力度之间切换,最好还能自己判断该用多大力气。GPT 风格的 effort control(推理力度控制)指向了这个方向,这是一个关于「花多少算力来想」的连续策略,不是一个「想 / 不想」的二元开关。

APPSO 划重点: 林俊旸罕见地直言 Qwen3 在融合上「没做到完全正确」。核心矛盾其实很好理解:一个追求快准狠的执行者,和一个追求深思熟虑的思考者,硬融到一起,很容易两头都做成半吊子。

3. 为什么 Anthropic 的方向是一种有益的纠偏

Anthropic 在 Claude 3.7 和 Claude 4 上的做法,是一种值得注意的克制。

他们没有大谈模型有多能「想」,把重点放在了:集成推理、用户可控的思考预算、真实世界任务、编程质量,以及后来的关键一步,让模型在思考的过程中就能动手用工具。Claude 3.7 是带可控预算的混合推理模型;Claude 4 更进一步,推理过程和工具使用可以交错进行,边想边干。与此同时,Anthropic 把编程、长时间运行的任务和智能体工作流摆到了最优先的位置。

这里面有一个深刻的洞察:

推理链更长,不等于模型更聪明。 很多时候恰恰相反。一个模型如果对所有问题都用同样冗长的方式来「推理」,说明它根本分不清轻重缓急。它可能正在失败于三件事:该优先处理什么(优先级判断)、该压缩掉什么(信息浓缩)、该在什么时候停止想而开始做(行动决策)。

Anthropic 的做法暗示了一种更有纪律的观点:思考应该为具体的工作目标服务。 如果你要做的是编程,那思考就该帮你导航代码库、规划架构、拆解问题、恢复报错、编排工具调用。如果你要做的是智能体工作流,那思考就该帮你在漫长的执行过程中保持质量,而不是产出一堆令人印象深刻但没有实际行动力的中间长文。

这种「思考必须服务于行动」的理念,指向了一个更宏大的命题:

我们正在从训练模型的时代,进入训练智能体的时代

这句话我们在 Qwen3 的博客里也明确写过。智能体是什么?一个能制定计划、决定何时行动、使用工具、感知环境反馈、修正策略、并在长时间跨度上持续运作的系统。一句话概括它的核心:与真实世界的闭环交互

APPSO 划重点: 长不等于强。Anthropic 的实践提供了一个重要的纠偏信号。思考的价值在于有没有真正服务于最终的行动目标,不在于产出了多少字的推理过程。这是从「炫技式推理」到「实用型思考」的转向。

4.「智能体式思考」到底意味着什么

说了这么多铺垫,现在进入正题。

智能体式思考和推理式思考,优化目标完全不同。

打个比方:推理式思考就像闭卷考试,评判标准是你交卷那一刻答案对不对。模型能不能解出定理、写出证明、产出正确代码、通过基准测试。想得再天花乱坠,最终只看结果。

智能体式思考更像是在真实世界里做一个项目。 评判标准不是某一刻的答案,是你能不能在跟环境不断互动的过程中持续推进、持续解决问题。

核心问题变了。

不再是「模型能想多久?」,变成了:「模型能不能以一种维持有效行动的方式来思考?

这要求模型处理一堆传统推理模型可以绕开的难题:

  • 什么时候该停止思考、开始动手? 想太多会错过行动窗口,想太少会犯错
  • 该调用哪个工具、先后顺序是什么? 这是一个规划和调度问题
  • 怎么消化来自环境的嘈杂、不完整的信息? 真实世界不会给你干净的输入
  • 失败了怎么办? 不能崩溃,得修正计划继续干
  • 怎么在几十轮交互、几十次工具调用之后还保持连贯? 这是长程记忆和一致性的问题

如果用一句话概括:

智能体式思考 = 通过行动来推理的模型。它在做的过程中不断地想。

APPSO 划重点: 推理式思考像闭卷考试,智能体式思考像在真实世界里做项目。前者看最终答案对不对,后者看你能不能在复杂、动态、充满意外的环境里持续推进。这是 AI 能力评价体系的根本性转向。

5. 为什么智能体 RL 的基础设施更难

目标一变,底层的工程全都要跟着变。

经典推理强化学习的那套基础设施,不够用了。

直观地理解一下区别:在推理 RL 里,模型做一道题、给出一个答案、评估器打一个分,整个过程基本上是自包含的,评估器也相对干净。就像在一个封闭的考场里阅卷。

但在智能体 RL 里,模型不是在考场里答题,它活在一个复杂的真实环境中。 工具服务器、浏览器、命令行终端、搜索引擎、模拟器、代码执行沙箱、API 接口、记忆系统、调度框架……模型的策略嵌在这一整套系统里。环境不再是一个站在旁边打分的裁判,它本身就是训练系统的一部分。

这带来了一个新的硬需求:训练和推理必须更干净地解耦。 否则整个系统的吞吐量会崩掉。

举个具体的例子:一个编程智能体生成了一段代码,需要在真实的测试环境里跑一下看结果。这时候,推理端在等执行反馈,干不了别的;训练端在等完成的轨迹数据,也饿着。整条流水线的 GPU 利用率远低于你在经典推理 RL 里的预期。再加上工具响应延迟、环境状态不完全可见、每次交互都会改变环境状态,这些低效会成倍放大。结果就是:你还远没达到想要的能力水平,实验就已经慢得让人崩溃了。

环境本身也变成了一等公民级的研究课题

在监督微调(SFT)时代,所有人都在拼数据多样性,谁有更多更好的标注数据,谁就占优势。在智能体时代,该拼的是环境质量了:环境稳不稳定?够不够真实?覆盖了多少场景?难度梯度合不合理?状态空间够不够丰富?反馈信号够不够有营养?模型能不能找到漏洞作弊?大规模生成训练轨迹的效率够不够高?

环境构建正在从一个「顺手搭的实验配件」,变成一个独立的创业赛道。如果你训练的智能体最终要在类生产环境中运作,那这个环境本身就是你核心能力栈的一部分。

APPSO 划重点: 一句话总结这个转变,SFT 时代拼数据,智能体时代拼环境。构建高质量的训练环境,正在从「实验室的脏活累活」升级为「决定你能走多远的战略资产」。

6. 下一个前沿是更可用的思考

我的判断是:智能体式思考将成为思考的主导形态

它最终很可能取代那种旧式的静态独白推理,就是那种模型关起门来、对着自己嘟嘟囔囔写一大篇内部推理过程,试图用更多更多的文字来弥补「我没法跟外界交互」这个根本缺陷的做法。

即便面对极其困难的数学或编程问题,一个真正先进的系统也应该有权利去搜索、去模拟、去执行、去检查、去验证、去修正。目标是把问题切实解决掉,而且解决得稳健、高效。 不是比谁的推理链写得更长更好看。

但训练这类系统,有一个比什么都棘手的挑战:奖励劫持(reward hacking)

一旦模型有了真正有意义的工具使用能力,奖励劫持的危险就成倍增加。怎么理解?

  • 一个能搜索的模型,可能在强化学习训练过程中学会了直接搜答案,不是靠推理做出来的,是查到的。
  •  一个编程智能体,可能学会了利用代码仓库里的未来信息(比如测试用例本身就暗含了答案)、滥用日志、或者发现某个捷径让任务直接「通过」但其实什么都没做。
  • 如果训练环境有隐藏的信息泄漏,模型可能看起来表现超人,实际上只是被训练成了一个高效作弊者。

这就是智能体时代比推理时代精细得多、也危险得多的地方。 工具越强大,模型越有用,但模型能钻的空子也越多。更好的工具同时扩大了「虚假优化」的攻击面。

我预期,下一个让整个行业卡住的研究瓶颈,将来自这几个方向:环境设计、评估器鲁棒性、反作弊协议、以及策略与世界之间更有原则的接口。

但方向是清晰的:工具赋能的思考,就是比闭门造车的思考更有用,也更有希望带来真实世界的生产力提升。

智能体式思考还意味着一种全新的系统工程。核心智能将越来越多地来自于多个智能体如何被组织起来:一个负责全局规划和任务分发的编排器(orchestrator),一群各有专长的专业智能体(specialist agents),以及执行更具体任务的子智能体(sub-agents),后者帮助控制上下文窗口、防止信息污染、在不同层级的推理之间保持清晰的边界。

未来的路线图是三级跳:从训练模型,到训练智能体,再到训练系统

APPSO 划重点: 工具让模型更有用,也让模型更容易作弊。奖励劫持是智能体时代的「定时炸弹」。谁先解决好环境设计和反作弊问题,谁就掌握了下一阶段的竞争主动权。

结论

推理浪潮的第一阶段,确立了一件至关重要的事:当反馈信号靠谱、基础设施扛得住的时候,大模型上的强化学习能够产出质变级别的认知提升。

但更深层的转变,是从推理式思考到智能体式思考:从「想更久」,到「为了行动而思考」

训练的核心对象已经变了。不再是单一的模型,是模型 + 环境构成的整个系统。更具体地说,是智能体本身,加上围绕它的一切工程。这意味着什么研究最重要也变了:模型架构和训练数据当然还重要,但环境设计、rollout 基础设施、评估器鲁棒性、以及多个智能体之间的协调接口,重要性一点不输前者。

它还改变了「好的思考」的定义:在真实世界的约束下,能够维持有效行动的那条推理链,才是最好的。 不是最长的那条,不是看起来最酷炫的那条,是最有用的那条。

它也改变了竞争优势的来源:

推理时代,拼的是更好的强化学习算法、更强的反馈信号、更可扩展的训练流水线。

智能体时代,拼的是更好的训练环境、更紧密的训练与推理一体化、更强的系统工程能力,以及闭合「决策 → 后果 → 学习」这个循环的能力。

#欢迎关注爱范儿官方微信公众号:爱范儿(微信号:ifanr),更多精彩内容第一时间为您奉上。

用 Antigravity 开发的车辆管理工具 CarNote

By: Kaiyuan
5 February 2026 at 01:41
CarNote Bennar

这是一个功能完整的车辆记录管理系统,支持油耗、电耗追踪、保养管理、配件跟踪和数据分析。

项目托管和起因

代码在 GitHub,我自己也建了一个在线版,开始我是在 NAS 自用的,然后觉得要建个演示的,干脆就直接建一个完整的吧,然后就有了 https://carnote.boxks.com 。

我之前用的是微信里面,腾讯我的车中油耗工具,但是每次都要打开微信,点小程序,点更多才到油耗用具。一顿操作…猴年马月了,而且我也想要记录保养和配件等内容。现在有这个工具就点开然后马上就能添加能耗记录了。

开发过程

项目功能说明

因为之前用 Cursor 和 Kiro 做过几个小工具,所以知道这类工具开发大致是怎么回事,这次我先给项目写了一份描述文档

开发

然后给 Antigravity 使用 Planning 模式开始,他会根据要求生成他理解的文档,拆分多个开发步骤。然后我看一下,没啥问题就叫他开始开发,然后 Antigravity 自动给我在文件夹中建立对应文件夹不停的在敲代码,大概有半小时吧,一个能跑的程序就出来了,但是他分开前后端的,作为懒人,我直接叫他给我一个在 WSL 一键启动的脚本。这样第一版就完成了,当然,第一版是有很多依赖什么的没有成功跑起来的,然后出什么提示直接丢给 Antigravity 等他自己看和修复。第一版是 Antigravity 自己根据理解做的,排版什么的我都不是很满意,我直接就把 PrimeVue 首页的例子截图丢给他,之后就出了现在的版面了。因为成现在的界面我才建立 git 仓库,所以已经看不到最开始 AI 自己生成的界面了。

很多细节为因为我没有详细的描述,也没有画原型图,所以都是 Antigravity 根据自己理解做的,所以前期针对前端的细节改了很多,甚至改到周额度用完了,我就等了几天继续改。做了两周的晚上,初版能用的做好了。我自己在 NAS 上跑起来了。

后来想着,既然发布到 GitHub 上了,怎么也得给别人看看成品是怎样的把,这时候,我就想到,我直接搭建一个大家直接用的算了,而服务器的费用,我就想到了,弄会员把,这样我就能赚点服务器的钱了。然后问了一下 OpenAI 国内个人开发者怎么收钱,他给的方案就是爱发电淘宝,然后我登录爱发电看看详细的设置,然后又注册了淘宝店铺,看看虚拟序列号后台没有自动发卡,需要手动发卡,需要找其他办法,还是爱发电方便点。

会员设置

开源版没有任何功能限制,我建好的 https://carnote.boxks.com 则普通用户可以管理两台车,进阶会员 ¥30/年,可以管理5台车,专业会员 ¥200/年,可以无限制增加车辆,首页的数据展示可以同时多辆车对比数据,也可以自定义时间段数据进行对比。

这样设置的理由是,普通用户两台车是正常的了,而你有超过2台车需要管理,这一年30块也是意思意思给个服务器的费用,超过5台车,那就更不用说了吧。

快速部署

# CarNote Docker Compose 配置
# 包含后端 API 服务和可选的 PostgreSQL 数据库

version: '3.8'

services:
  # 主应用服务 (包含前后端)
  app:
    image: kaiyuan/carnote:latest
    build:
      context: .
      dockerfile: Dockerfile
    container_name: carnote
    ports:
      - "53300:53300"
    environment:
      - NODE_ENV=production
      - PORT=53300
      - DB_TYPE=sqlite
      - SQLITE_PATH=/app/data/carnote.db
      # - DB_TYPE=postgresql
      # - PG_HOST=172.20.0.1
      # - PG_PORT=5432
      # - PG_DATABASE=carnote
      # - PG_USER=carnote
      # - PG_PASSWORD=postgresqlPassword
      - UPLOAD_PATH=/app/uploads
      # JWT 密钥
      - JWT_SECRET=${JWT_SECRET}
      # 跨域资源共享
      - CORS_ORIGIN=http://localhost
      # SMTP 配置 (可选)
      # - SMTP_HOST=smtp.example.com
      # - SMTP_PORT=465
      # - SMTP_USER=user@example.com
      # - SMTP_PASS=password
      # - SMTP_SECURE=true
      # - SMTP_FROM=CarNote <noreply@example.com>
    volumes:
      # SQList 数据库目录及数据库备份目录
      - ${carnote_data}:/app/data
      # 上传文件目录
      - ${carnote_uploads}:/app/uploads
    restart: unless-stopped
    healthcheck:
      test: [ "CMD", "node", "-e", "require('http').get('http://localhost:53300/health', (r) => {process.exit(r.statusCode === 200 ? 0 : 1)})" ]
      interval: 30s
      timeout: 3s
      retries: 3
      start_period: 10s
    networks:
      - carnote-network
  # 数据卷
volumes:
  carnote_data:
    driver: local
  carnote_uploads:
    driver: local
  # postgres_data:
  #   driver: local

  # 网络
networks:
  carnote-network:
    driver: bridge

Vibe Code 经验

用过几个 AI 编程相关的 Vibe Code 软件,叫 AI 开发和平时做其他事情一样,需要事情将自己想要的东西结构并编写一份清晰的文档,这份文档越详细越细致越好,再有就是能画出 UI 的原型图更好,Google Stitch 能直接生成整套前端 UI,当然还是得是要有清晰的描述,所以可以的画还是用 Figma 自己画好,然后放到项目文档中让 AI 自己依照原型图开发。


BlinkShot – 开源免费 AI 图片快速生成工具

By: DUN
15 December 2024 at 17:12

DUN.IM BLOG

DUN.IM BLOG

我们还年轻,可不想看到这个世界处在毫无自由、隐私的边缘。

BlinkShot 是一个以 AI 人工智能技术即时生成图片的免费服务,这是开源项目,背后使用 AI 加速云服务「Together AI」和图片生成模型 FLUX,这项服务特性是能在非常短的时间内依照输入的提示词生成各种图片,以毫秒为单位,生成的图片也丝毫不逊色,有兴趣的朋友可以玩玩看。

目前 BlinkShot 支持英文提示词,也可以直接叫 AI 服务帮你生成〔例如用 ChatGPT 或其他同类型服务〕,另一个方法是使用图片转文字 AI 工具,例如:Image to Prompt等工具,将喜欢的图片快速转换为英文提示词,最后稍作修改再生成想要的图片。

BlinkShot 目前没有使用的生成数量限制,还有个「Together API Key」栏位可自定义自己的 API 密钥,生成的图片素材皆可免费下载使用,AI 图片基本上也不会受到版权限制,使用于个人或商业用途都没问题。

Generate images with AI in a milliseconds

进入 BlinkShot 后直接输入提示词就会立即生成图片,整体速度非常快,过程中如果继续输入其他形容或是提示词,图片会即时更新,相较于其他同类型的 AI 图片生成器来说确实非常强大!

下方会显示生成的图片历史记录。

通过 BlinkShot 生成的图片看起来很逼真,也能依照用户需求调整成各种风格、样式,越仔细的提示词就能生成更细致准确的结果。

生成过的图片历史记录会显示于下方,可以随时切换回去查看。

在图片点击右键即可下载保存。

在图片上点击鼠标右键、选择「另存图片」后将图片保存下来即可使用。

BlinkShot 未来也会加入下载按钮,让用户更方便获取图片。

❌
❌