科技丨入职 OpenAI 前的全年复盘：2026 年值得做的几个方向

源济

科技丨入职 OpenAI 前的全年复盘：2026 年值得做的几个方向

知乎日报

2025年12月18日 06:01

2025 年，对科技行业来说是快速变化、持续加速的一年。年关将至，知乎科技邀请 AI 行业的亲历者们分享自己的「 AI 中场时刻」 —— 不论是高光、迷茫，还是转折。以期为更多同行者提供行业与人生的样本。

知友谢天宝在博士期间参与过很多项目，他在文章中总结了自己科研路上的几个瞬间、从 OSWorld 到 Qwen 的经历，以及在他看来 2026 年值得去做的几个方向。

PS.本文对原作者内容顺序略做调整，可点击文末「阅读原文」查看原文、与笔者交流互动。

@Timothyxxx

HKU PhD, Qwen, incoming OpenAI

我眼中 2026 研究者的下一步

讨论研究我们要讨论下历史了，如果说只让我用一个词总结最近几年的每一年的最关键的进展，我可能会这么列举：

2022 年的关键词是 以 CoT，ReACT 为代表的离散 prompt 技术；

2023 年的关键词是以 ChatGPT，Alpaca 等为代表的 instruction following 技术；

2024 年的关键词是以 OpenAI 的 o1 和 DeepSeek R1 为代表的 test time scaling 技术；

从全局的角度来看，总的路线图其实一直很稳定，即 OpenAI 在 2024 年中指出来的五个级别的区分。

到目前为止这个路线图的判断都很正确。截止到2025 年年末，我认为我们在 Level 3 智能体阶段，并且有望在 2026 年解决鲁棒性和实用性的问题，并且进行到下一步的创新者阶段。而所谓创新者，也就是 AI Researchers，或者 self-evolving 的技术，其实已经逐步有迹象，比如很多有意思的 zero 系列工作 Absolute Zero，Agent0 等。我们目前正在通过巩固 RL infra 和继续 Scaling 数据迭代模型和方法为下一步做铺垫。

网传的 OpenAI 路线图

如果说 2025 年一定有一个关键词总结，我觉得是工程巩固。

即 AI 研究者乃至工业界中场休息、在基础设施和基础范式上工程巩固的一年。整个社区和行业都在进行再教育，互相渗透，巩固基础。

对我个人的工作而言，也是中场休息的一年。

2025 年年初我觉得 AI 研究已死，2025 年年末，我对 2026 年的 AI 研究充满信心。

下面是我认为 2026 年值得去做的几个方向：

更扎实的基础、更工业化的工程，考古

在看今年的论文和一些工作的时候，其实会发现更受欢迎和影响力的工作巧思越来越少了，越来越夯的工业级框架越来越多，比如说 verl，比如说 sglang，等等。其实宏观上我们在开源社区和研究界复刻谷歌和 OpenAI 一些内部实现，而这些实现之前因为社区基础不扎实和不重视而被忽视。深度学习的基础和机器学习的基础，以及计算机科学与工程的那些基本知识，在规模扩大后能够被清醒地运用拿来理解，甚至考古一些过去的 ICML，NeurIPS，有很多宝藏。

推进 AI Researcher

这个就很具体了。给 AI 注入自我改进的能力和「主动性」。其实现在工业界提升模型的能力的方式，尤其是 post-train 后训练，抽象出来已经有了一些固定的 pattern，无非就是运行指令训练，看一些指标，分析，调整数据和参数，再次训练，直到指标收敛符合预期。那如果说我们科学到已经有一些很有效的指标，来让模型「意识」到自己需要什么样的数据，自己上网，或者甚至自己下单这些数据和运算资源。我们可以给模型操作训练自己的 GPU 集群的权限，他可以合成代码运行下一个版本的自己，并且通过 context 把自己的记忆传输到下一轮，甚至扩大自己的训练的规模，那是不是理想情况下，我们可以从这种枯燥的 loop 中完全解放这些算法工程师，让他们去缪斯更难被建模的事情。

测试时训练（Test Time Training，TTT）

最近 Nested transformer 很火，其实 TTT 这个概念现在被用的很杂，和 RNN，linear attention 也有点联系，我这里的测试时学习，更多的是指的是持续学习，在线学习，乃至知识编辑这些 topic。因为过去我们已经燃尽了互联网 corpus 这种化石燃料，人力驱动的 sft 数据和 rl 数据又是线性生产的，我们 24 年开始 c 端 app 爆炸和推理扩展的结果是推理部分的算力占据的越来越多，对于模型来讲在很多维度上自我改进可能还是为时过早。设想未来如果说我们能够找到合适的人类监督窗口，让模型在推理和各种人交互的时候学到东西更新自己（稳定的更新），那么我们 30 亿人类用户的知识将会共同消灭掉长尾和 ood，所有场景被 ai不 断的训练和学习，在这种能 把 inference  与  training  融合的范式下，我们可以再造一个transformers，megatron，sglang，vllm。Test-time training 只是它的早期版本。我对这个方向充满好奇和信心。欢迎关注我整理的 paper list：

https://github.com/Timothyxxx/TestTimeTrainingPapers

当我 2024 年 9 月末从新加坡飞北京，从晴空万里的热带回来觉得天灰蒙蒙的像冬日的哈尔滨。和惠哥吃完烤串喝完酒从亚运村的柳叶刀走出来的那一刻，没有想到会在短短一个月后再次回到北京阿里巴巴朝阳科技园，和 Qwen 团队开启我博士的下半场，一呆就是一年有余。发生了好多故事。感谢知乎邀请来写一份年度总结，感觉最近几年越来越多的时间花在工程上，就像上班一样，扑进去之后手指一直点键盘一直敲时间突然变得好快。好像如果没有专门的去往回想，也确实不觉得自己做了些什么。很高兴给我自己的最近一年的工作有一个总结的机会。或许多年后回来看还能记住这一年。简单挑一些工作上让我难忘的几个瞬间。

LLM Physics

语言模型的能量理论

时间回到估摸着 2024 年的最后几天或者是 2025 年的头几天，临近元旦加上周末，公司里几乎没有人，我和晓川坐在一起合成数据应付之前的工作，然后搭建一些 infra 上面的事情，和隔壁的包容哥搭上话，一起吃饭，聊聊八卦。很幸运认识包哥，包哥对研究很有激情，就从最近他的研究聊到了 Math，从 long CoT 聊起来了 Allen Zhu 和他的 LLM Physics 理论。

推荐阅读 https://physics.allen-zhu.com/

其中有很多有意思的理解，「解决 1+1 不困难所以说只需要消耗推理一个 token 的能量，微积分更加困难，需要更多的演算，更本质的是需要更多的能量，所以说说需要更多的 token。这就是为什么是 long cot 解决更难的推理问题。」RL 作为一种更好的范式就是能够让模型自己学会去控制和释放能量。

这种解释在当时的我听来懵懵逼逼但是似乎醍醐灌顶，长期以来搞 NLP 的研究者尤其是我们 semantic parsing 的研究者的角度都是找到更紧凑高效的文本表示形式，来降低语言模型理解和输出的压力，进而提高性能，进而很长一段时间难以理解输出越长性能越好的原因。而在那一刻我突然觉得我们不仅要加以人为的先验和压缩，也要想办法让语言模型能够学会判断表达消耗能量，以及为什么泛化解决问题一定要具备这种能力，过去 sft 可能无法继续扩展的问题。有时候长期浸淫在应用的场景中做工程的科学，就是需要科学的科学和科学的机理来格物致知深刻再次抽丝剥茧认识一下手里的这一坨。LLM Physics 现在已经出到 Part 4，我们持续关注一下！

多模态 agent 难以泛化的事实，数据量少时贴近分布和思维链质量很重要

从 24 年暑期开始我们组开始了 AgentNet 项目，构建标注工具来大规模的收集人类使用电脑的轨迹来构建大规模数据集和训练模型。到 24 年底的时候我们手里也大概有了几千条数据集，于是开始做数据的清洗和模型训练。

当时收集来的数据是「动作-观测-动作-观测」序列，观测是屏幕的截图，有时候还存在一定的错位情况。最早我们使用 Claude 和 GPT-4o 等模型进行动作前思维链的逆向补全，印象深刻的就是我们在阿里巴巴的访客中心一遍遍对 pipeline 生成 cot 和最终轨迹进行检查，改进生成 cot 的 pipeline ，然后再次合成，加了超多 tricks 提升带图和动作作为输入的 prompt 方法质量。但是这样打出来的思维链怎么都不 work，即 sft 训练 Qwen2VL 之后没办法在 OSWorld 上获得性能提升，迭代多轮无果。我们因为这个是用标注的轨迹还构造了一个静态数据集，也只获得微弱提升，跨 app 的性能迁移几乎为零。

后面继续迭代了超多轮 sft，最后怀疑到两件事上才 work：

• 思维链的质量要高，也就是链条内容要有一定的结构，不能是简单的下一步要做什么的自然语言描述，应该有现状的总结、任务的进展、当前的反思、未来的规划等等，并且要不同的长度混合训练；

• 第二点是 in domain 很重要，极致的 in domain 就是 ood，我们围绕 ubuntu 和相关的 app 构造了很多数据（但是没有 overfit ）发现效果较为显著，最后到底是把这个项目结账了。

总结来看，反思自己缺少成熟的 know how 的方法论和套路，过去更多的知道该定义什么问题，但是到了解决问题的时候和需要的知识，方法不够系统和有条理，实验做得比较混乱，导致可能的情况被较晚些才探究。那时候读论文的方向也不太对，要是能早点读到更多 test time scaling 和合分布的文章并且融会贯通本质，我们就能使用恰当的 sft recipe 也达成效果，在我们把多模态的 RL infra 完全构建好之前。另外 agent 数据之路任重道远，我们仍然需要继续把这条路的质量和数量拉上去，继续沉淀吧。

在阿里巴巴园区的半夜线上面试，与 OpenAI 的一次邂逅

今年还有一件有意思的事情就是在年初的时候拿到了 OpenAI 的 reach out，兴奋劲过了之后就当时在犹豫要不要参与面试，因为觉得自己学术上貌似还有想做的一些事情没有做完（后面会提到），然后手头确实事情也很多。中间犹犹豫豫，3 月份先准备了两三天面掉了第一面，然后就一直拖到 5 月才准备一周继续完成剩下的若干轮面试。

感觉自己的思维逻辑还是比较吻合公司的 vision，但是确实基础和技术细节不是最强的部分吧，运气成分比较大。依稀记得每一次面试基本都在北京时间的凌晨一点多两点多，强行打起精神抓起几罐红牛和椰汁，最近几年最紧张的时刻，进入 Google Meet 会议室前手都在发抖。还是那个熟悉的阿里巴巴朝阳科技园区访客中心 4 楼的半夜。感谢，感谢当时身边人的支持陪伴。很幸运碰到了很 nice 的赏识我的 manager，也感谢当时推荐我的涛哥、顺雨哥，很幸运能够和大家志同道合地推动 CUA，并且被给予机会为我逐渐掀开了过去神秘的彼岸的另外一角。

令人心动的Offer

现在回头看，机会有很多，也有很多在物质上更加诱人的机会，甚至人生目标也因为这些选择产生动荡。我们处在漩涡中心，我们处在浪潮之巅，我们每个月的想法都可能不同。此刻穷且益坚不坠青云之志，彼时白日放歌须纵酒。幸运的是我仍旧对很多事情充满好奇心。

OSWorld 维修大工程！

与硅谷公司的搏斗中认识生态链

五六月份发生了两件事，首先是 o3 版本的 operator 出来了，刷新了 OSWorld sota，但是报了两个 OSWorld 分数，并且一行小字写着说我们估测我们准确率已经达到 50%，但是 OSWorld 标注错误太多导致我们只测出来 40 多；另外是一家hud 的公司邮件联系我说，要寻求「合作」。我看了一下这家公司，主要是卖模型的测评服务的，主打的业务居然还是我过去的工作 OSWorld，说是还融了不少钱。

说到这，硅谷保守估计有五家以上公司使用或者间接使用 OSWorld 创业的，有卖训练题目的，有卖容器服务的，甚至直接把 OSWorld 评测拿来卖的，加一起也得几个亿的融资了。

HUD主要是通过云服务并行环境来压缩评测时间，但是其实OSWorld本身就支持早期也给他们提供了帮助

（我并没拿到一分钱）不由得感叹硅谷的生态之好，任何一个环节都能冒出来一家公司，算法公司可以真的只操心算法，其他的都可以作为 API。

公司的 leader 之一一个印度哥拉了一个会，这公司列了一个表单说 OSWorld 居然有一半的任务标注有问题，真是看得我面红耳赤。然后说他们打算进行修复并推 出OSWorld Verified，但是要他们来推出。在和导师涛哥仔细讨论了方案之后，我们决定还是要自己先动手做一版本的修改，全盘交给这个公司之后这个项目可能失去学术性质也会让公众对我们损失一定的信任。于是就是昏天黑地的收集问题，整理，一个个的修改修复，在这里再次感谢 MoonShot AI，OpenAI，Human Data，ByteDance Seed TARS，Anthropic，Simular，HKU Data Intelligence Lab，Qwen 等团队。

总之对 OSWorld 进行了一次大的升级 ---  OSWorld-Verified，修复了过去发布一年发现的任务初始化，任务评测，方案漏判，反爬虫等各种问题。更好的支持了云服务平台用来 eval，可以通过并行将单次 eval 的时间压缩到 1 小时之内。同时我们把 doc 进行了仔细的完善，对于原理，配置环境，中间的一些参数，如何实现自己的 agent 都给予了更进一步的说明。重新运行了现在 leaderboard 上的 models。说完这些真是令人再次头大，说着轻松，实则一点也不容易。hud和OpenAI说的很对，确实大大小小修了一百多个问题 。后面我们推出来两周后 hub 也发了一个自己的版本，同时上架两个版本为大家提供测评。这次的感悟是，硅谷的生态真的很恐怖很健康，RLVR 在 agent 上真是大工程！可能 math 和 open domain QA（也就是 deep research）只算个答案匹配就行，但是 OSWorld 这种比较难标注的 agent 任务，哪怕标注的时候平均每个任务就走了两三遍花了几个小时，这次仍然发现问题仍然要修，更何况还有很多任务更复杂更开放（这里广告一下，敬请大家期待一波 v2），cua 也好，swe 也好，随着模型能力的增加，新的问题依然会涌出来，这真的是一个持续的精力投入。如何可持续发展，如何管理精力最大化人类监督的注入，逐渐成为一个很好的问题。

工业级别的 RL 框架复杂的不是强化学习训练这一段

对于智能体的强化学习是重头戏，在工业界也算是 25 年一个超级重点的部分。可以分成几部分做：任务数据集，训练的 infra，和环境的 infra。

在工业界能看到的大家会先去看 rollout pass@N（N=4，8，16等）的一个分数作为预估的上界，然后用这个分数来预估模型使用强化学习之后的性能上界，结合观察 entropy 的指标来看 RL 有没有必要实施，是要调整题目难度和数量等，还是说一定需要回到 cpt 和 sft 阶段补充知识，一些数据还没那么够的场景比如说 agent，在这个指标上可能和 math 还是存在一定的不同，需要在强化学习之前专门进行数据训练和提升。这些工业实践后面被 Zhewei 的使用 confidence 作为 reward 训练 RL 和 Yilun Du 前一阵的在采样阶段激发 CoT 能力的结论所支持。

https://arxiv.org/pdf/2508.09123

另外一个大家公认的点是 cpt 之后模型的 sft 可能也不要做的太厚，只是用来冷启动学一个格式，sft 要限制一个 tokens 容量不要放太多东西。那这其实倒逼着，确实存在 Ilya 所说的我观测到各个厂商均存在一些结合着 eval 来构建题目的问题，但是只要对预训练阶段足够自信，这一阶段稍微 fit 一点，合版合的好后续进一步 scale 仍然可以 generalize。

对于 CUA，显而易见的任务和环境的 scaling 都是比较已知的事情，基于 OSWorld 往下面做就好（虽然后面也意识到环境可以继续做很多工程优化，然后任务数据确实需要超强的人力管理/砸钱）。那么就是训练 infra 比较难写，test 上 RL 训涨就花了我们很多时间。

就本人来讲，verl 从年初火了就跟着跑了一把 gsm8k 的 aha moment，但是断断续续一直没时间深入读，很早期的时候晓川写了一个但是没搞完就去 CMU 读博润了，后面空了一阵子，再后面铺垫了一阵后基本全靠白姐来 carry 和各种敲大哥们来干活那这块推进起来，借着这个契机跟着学到了特别多的东西，比如说训推不一致（中间 dk 老师做诗一首训推不一致乃阴阳调和，足见被折磨至深），token in token out 这些要扣的细节，说实话要不是对 QwenVL 模型结构稍微还算了解点加上有一些强化学习和并行系统的基础，真的很难理解和下手。但是其实在了解这些之后，问题立刻变成了推理引擎和训练框架的问题，先怀疑自己，在怀疑 sglang，稍微怀疑下 verl，最后再怀疑 megatron。感觉工业级别的框架的理解，要从端到端到流水线，最后再到端到端，即一个人从无法掌握所有需要的知识，到理清楚是哪里出问题找那些专业的人物去解决，再到最终融会贯通，是一个过程。社区需要这个过程，25 年教育我们都成为这样的人。

多任务合版本

顺分布的重要性

Thinking Machines on-policy Distillation 博客

在杭州出差的时候很巧的在良渚洲际大堂和白姐多次偶遇 N 次惠哥和 junyang 老师，有次就讨论说这这么多方向在做，尤其都在做强化学习，那么最后怎么让一个模型具有全部方向的能力呢？

讨论的结果是分别训不同的模型，然后拿 rollout 的数据类似于 rft 混起来训一开始的模型。我之前一直觉得要做多任务的一起的 online rl，或者拿着所有数据做 offline rl，（我确实对强化学习是小学生水平），但是这么做是不是有点太 end2end 实际上不太好组起来。然后过了几天终于有空看了一下 TML 的 on policy distillation 博客，里面提到了直接去蒸馏一个大师模型的轨迹就类似于国际象棋里你直接让一个新手去背一堆大师赛的下法，他们不在一个空间里，那么这种分布上的不同会导致新手在低段位对弈时候实际性能依旧不佳。那么应该做的事让新手逐步下，老师基于新手的下法给予按步骤的批注（token log prob），然后进行逐步学习。

https://thinkingmachines.ai/blog/on-policy-distillation/

其实这和 24 年的热门 topic rft，rl，以及前文的合版都是相通的，OpenAI 释放信号，我们快速跟随可能用了半年消化掉。我的思路可能从这时候更加深刻的从原来的应用侧蒸馏就是蒸馏，到了蒸馏也要考虑学生的耐受性，信号要一点点给，不要一下子拉到另外的 space 中，cpt sft rl 这些曾经死记硬背的阶段在那一刻融合成一个统一而自洽的理解。

GUI 方向的质疑，豆包手机

临近年底，貌似很多年初对 CUA 充满激情的公司小手稍有变形，转而更多的热血继续注入 coding agent 也就是 CLI 侧，也开始有越来越多的人泼冷水说一定要 GUI 吗等等。比年中更频繁的，逐渐也有很多人把问题问到我这里和身边的小伙伴上。我基本这段时间打了超多字在回复，在 25 年的结束我的理解是大家都没错，但是未来属于 Universal Digital Agent（UDA）。即混合使用 coding，GUI 和 search 其他 tools 的模型，模型要能意识到不同的 tools 怎么组合和顺序会更高效，哪个更重，什么时候一定要等等能力（苏哥的 ToolOchestra 就是这类角度的一个探索）。

其中，GUI 就是虚拟世界里面的人形机器人研究，为人而生，是这个世界的虚拟基础设施、楼房、家具，有人和电子设备交互的需要，GUI 这个形态就会一直存在，那么人工智能如果说想要触及我们所有能达到的范围内帮到我们，这就是必要一环，也可以说是很多场景的兜底最后一公里（长期我认为我们无法期待 API 通往一切，因为这是是反人性的，无异于你要求地铁把户户联通，就是为了否定共享单车和自己的两条腿）。话虽如此，CUA 需要一个杀手 app 来真正证明自己。ChatGPT Agent 和 UITARS2 是我看到最接近理想的状态，但是还远远不到，希望我们可以迭代出更好的。研究和工业投入上，我们可以逐个击破，但是 UDA 路线应该成为共识。

讨论着 killer app，年底豆包手机就横空出世，我也买回来了一台进行测试，但是当时我也没想到的的是，肉眼可见还没有寄到手就看到网上有人反馈微信已经用不了（后面变成用户能用但是豆包会拒绝用），后面支付宝和淘宝都不让用，银行 app 也不让用，再到后面等到手之后发现欢乐斗地主等游戏已经不能用，快手抖音也进不去了，连我这个测试者都失去兴趣。

估计一般受众使用者只会更加的没有耐心吧。不由得为 Yujia 老师他们感到菊花一紧，也为自己菊花一紧。UI-TARS 系列真的很厉害，砸了很多钱，这次估计也对于手机助手做了优化，但是现在厂商的做法，让我开始意识到先爱的商业模式导致消费性娱乐性的应用可能想抢流量入口，利益驱动就会被会用合规来卡一下字节豆包这种应用的尝试，人性面前的第一反应即使技术领先也没有办法。回看自己侧重一点的，感觉 computer use 稍好些，相较于 mobile use 的好处就是，相较于消费性娱乐性 app，作为生产力工具 app，在诸多情况下不存在封禁的动机；哪怕封禁，在 B 端依旧有实用性。对于学术界，依旧是 agi agent 的一个中长期等价物。长期来看，我并不持有悲观态度，因为这 computer use 和 mobile use 确实是一种下一代的体验，也就是「本该如此」，哪怕我到手之后只能用几个 app 了，我都能体会到在这几个 app 上我比之前爽太多，要是能都用那该有多爽。我相信对于一般的用户这种感觉只会更加明显，那么未来谁是流量入口，谁在挡路谁上快车道还真的是个未知数。

结语

曾经，神高高在上深不可测。现在，神虽并不近在咫尺，但是一切有迹可循。24 年和 25 年其实稍微陷入了一些些存在主义危机，但是到了年底我意识到，有太多值得去做，有太多好奇心需要被填充。我对 2026 年会发生的新故事和一切的一切充满期待。