GPT 6 的 「AGI」，不是你我想要的AGI｜Hao好聊趋势

文｜博阳

编辑｜徐青阳

在大家都在聊RSI（自动进化模型）是通向AGI之路时，OpenAI发布了GPT Astra 6，并宣称AGI已经到来了。

那是OpenAI找到了RSI的诀窍？似乎并没有。

在2025年10月，Sam Altman在接受采访时曾经说到过OpenAI内部的RSI路线图，认为到2026年9月会出现自动化研究实习生，2028 年 3 月推出完全自主的 AI 研究员。

根据他们在9月7日放出的《研究加速，OpenAI内部视角》一文，目前AI在自动化研究上仍然处于实习生角色，即在人类指导下，可以完成定义清楚、熟练研究者需要数天才能完成的任务。他们成功完成的 4—8 小时任务中，超过一半经历过人工介入。研究方向和结果取舍仍由人决定。

这说明目前的RSI进度在OpenAI内部只能说是符合路线图，并没有超越。它们的实践现在甚至还比不过智谱全自动AI训练的野心。

那GPT 6凭什么说自己已经到了AGI？只需要看看GPT 6这次升级了什么。

这次发布最值得注意的并不是Coding。在 GPT 6 上，涉及编程的 DeepSWE 的提升只有 1.4 个百分点，而屏幕元素定位评测 ScreenSpot-Pro 的成绩，从 GPT-5.6 Sol 的 76.9% 提升到 92.7%。业务流程评测 AutomationBench 则从 18.1% 提升到 41.4%。甚至设计类 CAD 任务的成绩也提高了 12.6 个百分点。

在发布演示中，OpenAI强调的也是具体软件和工作文件的使用能力，我们能看到3D建模、Power BI、电路板设计、法律文档排版等各种场景中的应用。

不再是只能Coding的AI，而是所有软件都能用的AI，这不就是AGI吗？

但这其实并不是OpenAI一家的表现倾向。Fable 5.1 上我们也能看到类似的情况。编程的CursorBench 就提高了 2.9 个百分点，AutomationBench 则提高了 14.3 个百分点。科研的Terminal-Bench Science 0.1 提升了近一倍。

甚至在 Gemini 3.8 Flash 的发布中，我们也看到它专门强调了专业领域的多步骤分析。Gemini甚至特别拿出了领域benchmark来比较提升，比如专注金融的 Finance Agent v2 和 专注法律的 Harvey benchmark。

这不是OpenAI一家的选择，这些发布都在表达一个意思：我们的模型，现在能做的事儿更多了，更通用了，更AGI了。

这种提升是怎么来的？是模型能力提升带来的突然「涌现」吗？还是来自于现实的压力，和一些工程能力的提升？

这篇文章，就来拆解这条看起来通向AGI的路径，是由什么铺就的。

01

AGI，在Coding之外

首先，是现实的情况，让大家走上了这条通用之路的。

从Computer use这个功能的轮回史就可以窥见这一节奏的变化。

2024 年 10月 Anthropic 发布 computer use 时，GPT 6所展示出的这套通用操作电脑的空间就已经打开了。但当时 Anthropic 自己也承认，它慢，而且容易出错。模型成功点几次按钮是够做出吸引人的演示了。但要连续完成工作，它比人还慢，稳定性又差。

但之后2025 年 2 月 24 日，Claude Code 上线，直接带火了Coding Agent 市场，到 2026 年 2 月，Anthropic 披露 Claude Code 的年化收入运行率已超过 25 亿美元，仅当年年初以来就翻了一倍以上。

而且 Coding Agent 里有现成的代码仓库、命令行和测试工具，对这些任务而言，直接执行命令通常比看屏幕找按钮更有效率。

由此 CLI 和 MCP 所代表的结构化工具接入一度引发了消灭GUI的讨论。既然软件可以提供结构化接口，为什么还要让模型费力、低效地找按钮、点鼠标呢？

Computer use 也在去年年中到今年年中这个时段内，从每场发布会的展示焦点，转变成了不再重要的注脚。

直到这次 GPT 6 Astra 发布会，它才再度闪亮回归。

因为环境变了。

Codex产品负责人在8 月 21 日宣布，其月活已达到2000万以上。更领先的Claude Code虽然没有数据，但应该并不比这个少。

而全球有多少开发者呢？

SlashData 在 2026 年第一季度估计，云原生开发者有 1,990 万，占全球开发者的约 39%，倒推总量约为 5,100 万人。这个口径还包括非职业开发者，真正以编程为工作、能持续形成付费需求的人群更小。

而且这个市场已经被迅速教育过一遍了。JetBrains 在今年 5—7 月对超过 1.5 万名专业开发者开展的调查显示，90% 的职业开发者每周都在工作中使用 AI coding agent，68% 每天使用。按这份调查，尚未成为每周用户的人只剩约一成。

因此，继续寻找尚未尝试过Coding Agent 的程序员，空间已经很有限。

这个趋势也反映在了数据上。第三方机构 TickerTrends 估算，截至 8 月 10 日，Claude Code 的四周收入运行率增幅为 5.2%，低于此前几个月的扩张速度。

对这些大厂而言，Coding Agent已经进入了争夺现有用户、提高使用频率、增加企业付费的深度竞争阶段，再也不是高速增长的荒蛮期。

而 Coding 之外，另一批用户才刚刚开始进来。

OpenAI 在 6 月披露，非开发者知识工作者已经占 Codex 用户的约 20%，增长速度超过开发者的三倍。

到 8 月更新企业数据时，自 2 月以来，工程职能的 Codex 周活规模增长了 5 倍，确实不少。但对应的，法律职能增长了 108 倍，销售和招聘分别增长了 41 倍。

这就是市场的下一个争夺点。

但一个律师、财务分析师或者运营人员，不会仅仅因为模型更会写代码，就开始为它付费。他们需要的是，模型能进入自己每天使用的软件，处理手上的材料，完成能够交付的工作。

CLI、API 和 MCP 可以承担其中大量操作，但它们的覆盖还不完整。

牛津大学3月25日发布的调查《How are AI agents used? 》分析约 17.7 万个 MCP 工具，其中软件开发占工具数量的 67%，占其可观测下载量的 90%。Toolradar 8 月发布的分类报告 中，我们仍可以发现开发者工具占主导。

在2月到8月间，MCP、CLI 的增长主要发生在办公领域、支付与商家财务以及设计领域中，但各领域进度不同，距离覆盖所有工具、所有操作仍有明显距离。

除此之外，许多工作的完成标准包含视觉效果和实际交互。文件成功保存、脚本顺利运行，只能证明操作执行了，无法保证模型做出的东西符合要求。

这两天每日刷屏的 Astra 用 Blender 3D建模的视频就是一个很好的实例。按照 OpenAI 公布的过程，这种建模是通过 Blender 的 Python API 创建场景来实现的，也是用后台脚本设置相机和渲染。但为了保证精确，它必须同时通过 computer use 打开和检查 Blender，并结合渲染图继续修改。

在OpenAI的范例中，正是借助视觉理解和computer use，模型在发现水槽表面的着色异常后，修正了相关几何属性。

Computer Use 的回归，并不是 GUI 战胜了 CLI，而是模型进入 Coding 之外后，任务验收本身重新包含了视觉与交互。

这就是Computer use再度兴起的背景。

但问题是，不是能用软件了，就会干活儿了。从看到软件说明书，到完成工作之间，是需要学习的。

之所以GPT 6 Astra 在 这些任务上表现惊艳，是因为都加训过了。在 Astra的发布页内，OpenAI 明确提到 Astra 接受了面向专业环境的定向训练。

那么这种训练是如何可能的呢？

02

工作轨迹，成了新时代的富矿

要训练模型干活，首先得让它在活儿里学着干。这就是训练任务。

在 Coding 里，这些东西并不难找。

比如 GitHub 上，一个已经解决的 Issue 就可能是一道现成的题，甚至都有答案和具体的环境。用户描述了问题就有了题、仓库保留着修改前的代码就有了上下文、开发者提交了解决方案就有了答案，甚至还有热心大哥的测试和审查意见能帮你筛选这些修改是否有效。

这样，找到已经解决的问题后，把代码恢复到修改前让模型重新做一遍就可以再去训练了。

所以在Coding范畴下，训练团队就不太需要工作轨迹，从GitHub扒就行。

但走出 Coding 之后，这些就不再唾手可得。没有GitHub，要么你让专家脑补想象工作，要么就从已经有的工作轨迹里总结。

专家贵，手搓慢。后者要用好了，肯定是既省钱又快。

因此，工作轨迹成了新的富矿。

围绕工作轨迹的收集、整理和利用，市场和研究界都在加大投入，原因就在这里。

比如Handshake，本来是个高校和求职者网络，现在AI数据收集却成了主要工作。他们所搜集的正是现在的工作流程。在官网中他们表示，现在的工作方式是通过录屏和轨迹分析了解工作流程，用专家制定的评分标准评估 Agent，再在模拟环境中改进表现。

Sunset 原本是一家帮助创业公司办理关停的公司，它的工作是封存业务数据。但到了2026年，它也成了一家AI数据公司，专注工作流程。其4 月 14 日的官方文章披露，公司会直接购买符合条件的内部数据，整理并处理隐私合规问题，再授权给 AI 实验室和研究机构。材料包括内部沟通、产品开发历史以及客户反馈等。Sunset 把这类产品称为 RL gyms，翻译过来就是用于强化学习的训练场。

这些工作轨迹，现在真的能被强化学习用上吗？

03

用传统 Agentic RL 的眼光看，这个富矿不好采

从 Agentic RL 的角度看，要用好工作轨迹，至少有两道关要过。

第一道是把记录变成可执行的题目和环境，让模型能够重新尝试。第二道是构造有效奖励，得能判断任务完成得好与坏，最好还能知道哪里好哪里坏。这样模型才能在一个训练场里（环境）被有效的训练（通过奖惩学习）。

但Coding之外的世界，光是出题和构建相关的环境就难度重重。

环境之难

一个对于 RL 来讲可用的环境，至少要让模型能在里面根据环境反馈尝试不同做法。一次操作失败了，它可以修改方案再试，同一道题也可以重复执行，比较不同策略的结果。

但工作轨迹 ≠ 训练样本 ≠ RL 环境。

人的工作记录只记下了发生过什么。但训练样本还要有任务边界。RL 环境则需要更多的条件。

录屏能告诉我们，一个人打开了哪份表格、修改了哪些内容。但模型如果打开另一份文件，或者换一种公式，录屏不会给出新的结果。要让它重新做这份工作，得先1）还原模型当时面对的上下文（比如文件和表格） 2）还原出可操作的空间（比如软件/系统） 3）明确当时的要求。

对于不同的工作来讲，收集到的工作轨迹所对应的这三个条件都完全不同。

版本之子 Coding 已经越过山丘

Coding在利用工作轨迹这方面可谓是占尽了优势。因为他们的可操作空间是编程软件，开发过程中又会留各种结构化记录去帮助你恢复场景。

代码仓库本身就存着历史版本、依赖文件，拉出来就可以恢复运行条件。模型拿到一个工作副本，就能直接上手开始做后续操作。失败后也可以马上恢复初始状态，再尝试另一种修法。

题目也有唾手可得的来源。GitHub 上的一条修复记录，有对应的 Issue 描述问题，修复前的 commit 提供起点，PR 给出参考补丁，相关测试帮助检查结果。

这里面程序员们日常使用的协作系统，就已经替模型训练团队保存了一部分题目、答案和环境信息。

想把这些工作轨迹用起来，训练团队要做的主要是数据清洗。去筛选合适的记录，确认原始问题可以复现，再把解题入口交给模型去练就行。

过去这类对GitHub上问题的数据清洗还是人去从GitHub里扒，但到25年，这个过程就开始自动化了。

2025 年 6 月 12 日，中山大学团队提交了 SWE-Factory 的初版论文《SWE Data Construction, Automatically!》。

在这里，研究人员把环境准备直接放手交给四类 Agent。一个阅读项目说明，弄清楚怎么安装。一个根据前面Agent的指示去搭建运行环境。第三个准备测试脚本。最后一个实际运行，查看哪里报错，再让前面的助手修改。

所有成功的配置会被保存，同一个项目的其他题目可以接着用，不必每次从头准备。

这一模式在26年初就已经跑通。在2026 年 1 月 5 日的修订版中，团队使用 GPT-4.1 mini在 671 个候选问题中成功构建了 337 道有效任务。

虽然还不能每次成功，但它已经可以自动利用工作轨迹，去完成一批原本需要人工准备的环境构建工作。

到了 2026 年 2 月 2 日，Qwen 团队提交《SWE-Universe: Scale Real-World Verifiable Environments to Millions》把这种自动出题的方法进一步做大。

团队专门用成功搭建环境的操作记录，训练了 Qwen-Next-80A3 构建模型，让它更快更好的去搭建环境。

最终，系统从 52,960 个仓库中构造了 807,693 个可验证训练实例，并用于后续轨迹生成、中训练和强化学习。

至此，从工作轨迹里自动搭建训练环境这件事，正式成立。

程序员们在GitHub上的PR，现在已经丝滑的进入了训练循环。

还在爬坡的中间件：OS和开放软件

但想要走出Coding，必须得进入完整的领域任务中去。

进入更开放的工作场景后，Coding 中这些有利条件就不再存在了。

首先是环境构筑，一个现实任务非常复杂，往往需要涉及多个复杂工具，记录也可能分散在整个电脑，乃至电脑之外。

还好，在完整的领域任务和Coding中间，还涉及很多软件和操作系统，比如现在爆火的 Blender、Office 等软件，以及连接它们的操作系统（OS）。

它们成了从Coding迈出去的第一步，而且也早都有了专门训练的途径和环境。

2024 年 4 月 11 日，《OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments》就把真实电脑做成了可重复操作的实验环境。团队整理了 369 个任务，每道题配有初始状态配置和结果检查脚本，任务还可以涉及多个应用之间的操作。

它让 Agent 在虚拟机里操作真实软件。准备任务时，配置好需要的文件和应用状态、模型尝试结束后，再重置环境。

Blender也是非常早就构建好了环境。早在 2025 年 4 月 2 日，斯坦福大学的项目《BlenderGym: Benchmarking Foundational Model Systems for Graphics Editing》，就把三维图形编辑也组织成了类似的任务。

他们设计了 245 个 Blender 场景，覆盖灯光、材质和几何形状等编辑操作。每道题都有一个基础场景文件，还有分别生成初始场景与目标场景的脚本，以及对应的渲染图和文字说明。

但到这里，工作轨迹其实依然只能作为人工出题的参考。因为即使有工作流程，它们也缺少PR、Issue 那样成套、可追溯的任务记录。最好用的可能反而是论坛里的题库。

软件有了。但还需要人准备初始文件、写清修改要求、制作参考结果，并设计验收方式。 这需要大量的标注工作和总结清洗，因此每个训练集的成本都极高。

比如 OSWorld 为了搭建369道题目，需要 9 名学生、三个多月、约 1,800 人时才能完成。

在 Epoch AI 于 2026 年 1 月发表的行业访谈中，相关从业者完成这样一道题目的价格大概是 200—2000 美元。

这还是在题目已经拆好、数据都已给到的情况下，只是出题和出评分器的价格，环境构建并不包含在其中。

既然这么贵，大家也不是不想自动化应用这些工作流程。

香港大学与 Salesforce Research 于 2024 年 12 月 12 日提交的 AgentTrek，就是去教程里扒题，让模型整理目标与步骤，然后用Agent在真实网络里重新执行，看看能不能走的通，走的通的可以当训练轨迹用去蒸馏 / SFT。

但当时它主要生成训练轨迹，并没有能力为每项任务恢复一个可重置、可探索其他路径的 RL 环境。

直到最近，才有人初步尝试自动化应用这部分工作轨迹。

2026 年 5 月 21 日，Banghao Chi 等人提交《Spreadsheet-RL: Advancing Large Language Model Agents on Realistic Spreadsheet Tasks via Reinforcement Learning》，直接针对 Excel 任务训练 Agent。

团队从公开表格论坛的问题中，自动构造环境。发布的训练集包含 5,925 道经过筛选的 ExcelForum 任务。每次尝试，模型都在独立工作空间里修改表格。将指定答案区域与论坛里的正确答案比较，用结果给模型奖励。

论坛的题目，都比人的工作轨迹好清理和自动化。

除了从论坛里去挖矿或者从 Sunset 这样的数据公司去高价购买，也可以现采数据，那样能保证记录环境符合要求。

2026 年 5 月 28 日，腾讯混元及合作高校团队发布的《PhoneWorld: Scaling Phone-Use Agent Environments》就大概描述了一下现采数据可能是怎么被用起来的。

研究者先收集人在真实 App 中操作的截图和动作记录，从中识别常用页面、页面之间的跳转关系，以及哪些操作会改变数据。

然后，研究人员把这些信息整理成开发要求，让 Coding Agent 编写、编译和修复模拟 App。收藏、发消息等操作会修改本地数据库，重置时恢复初始状态，因此可以反复执行任务、检查结果。

6 月 22 日的《PhoneBuddy: Training Open Models for Agentic Phone Use》就直接把这些环境构建用在了RL之中，去结合真实 App 和 PhoneWorld 模拟环境训练模型了。

这可能是未来潜在的一种大规模方法，但现在还是不普遍。

数据公司做的还是比较古法的环境构造模式。

Scale AI 2026 年 2 月 27 日披露，当下它们接近一半的新数据训练项目涉及 RL 环境。产品主要覆盖工具使用、电脑操作和领域工作流，包含初始状态、专家设计的任务，以及过程和结果验证器。

也因此，我们在GPT 6 里看到的最大的进步，主要集中在这个数据公司专攻挖掘的领域。

到了真实的领域工作，还是只能回到古法操作

更完整的领域工作，难度又增加了一层。

因为我们需要恢复的东西，往往比记录下来的多得多。

一位分析师制作报告，留下了查询数据库、修改表格和生成文档的操作记录。我们可以知道他查过什么、改过什么，却未必知道任务开始时，数据库里还有哪些内容，哪些文件是他当时有权访问的，以及客户在会议里补充过什么要求。

这些信息没有出现在操作记录里，不代表它们对任务不重要。分析师可能正是因为提前知道某个条件，才没有去查另一份资料，也没有采用另一种分析方法。

如果这些条件没有恢复，模型重新做题时，面对的就不是同一个问题。

而且这些环境有些还不在已有系统内。

在Agent 环境下，我们需要训练模型通过一连串操作完成任务。模型执行一个动作，环境返回结果，模型再根据结果决定下一步。由此，模型获得了整个流程的结果信息，然后再根据动作带来的变化，以及之后得到的系统反馈来学习。

因此，一个模型想要尝试不同的可能性，就需要一个环境告诉它接下来会发生什么。

从训练效率看，理想的环境应该让模型能够低成本地反复尝试，而且每次尝试都有可比较的条件。

可比性越强，模型学习的准确性越高。如果两个环境的上下文和系统都不同、完全不可比较，模型在训练过程中就不知道，结果的差异到底来自自己的动作，还是环境的不同。

因此最好这个环境是能够重置的。模型第一次把任务做坏了，文件删错了，配置改乱了，环境可以恢复到任务开始的状态，再让它尝试另一种做法。

对于长程任务，能从中间状态恢复是最佳的状态。假设前面几十步都是准备工作，模型只在最后几步遇到困难，如果能保存中间状态，就可以从那里反复探索。这给局部试错和不同策略的比较提供了条件。

标准的软件往往能够实现这些功能，但实际的任务是分散在软件之间、甚至是系统之外的。我们要从不完整的记录中恢复任务要求，确定环境边界，补齐关键状态，还要让它能够承受原记录之外的操作。然后再用软件把它们串联起来。

因此，想从Coding进入到其他领域的训练，基础条件往往需要重新建设，还是得回归人力手搓。

最近前OpenAI员工，LoRA发明人Edward Hu 在 9 月 1 日发布的《Training frontier knowledge work agents: A 397B RL training guide with SkyRL》，就介绍了后训练领域专门模型的过程。

他们使用的是 1,928 道专家构造的任务，覆盖企业法律、投资银行和管理咨询，与评测集中的任务和工作场景相互独立。

根据Mercor 1月发布的APEX-Agents，我们可以知道这些任务都是先调查了数百名专业人士，了解律师、投行分析师和咨询顾问平时把时间花在哪里。随后，请有五到十年相关工作经验的专家，在 Google Workspace 里模拟同事共同推进一个项目，制作项目需要的文件和沟通材料。

例如，团队可以围绕一家虚构公司的咨询项目，准备业务背景、分析材料和项目文件，让模型面对的工作空间，接近专业人士日常需要整理和查阅的资料集合。Mercor 还与 Box 合作，设计这些文件的组织方式。

按 Mercor 披露的流程，专业人士会花五到十天构建一个资料丰富的项目环境，然后根据环境中的文件设计具体任务。他们需要先把原本散落在工作经验里的背景和约束，变成模型可以访问的材料，再确定哪些工作适合交给模型完成。

APEX-Agents 最终包含 33 个这样的环境，以及 480 道任务和对应的评分标准。

因此这里RL的环境，是每道题背后一个模拟公司的工作环境，里面放着文档、表格和演示文件，还提供邮件、聊天等工具。

在这条路线上，工作轨迹还不能自动变成训练环境。都得靠专家手搓，把一段工作经验重新组织成可操作的项目，再由工程系统负责复制环境、运行 Agent 和检查交付结果。

但Mercor的经验，至少说明用RL来训练更长程的，超越Coding的任务是可能的。

但就是贵和慢，得靠巨量的人力scaling。

潜在的救星，用Agent内的轨迹训练Agent自己

既然轨迹收集又贵、又分散，很多时候甚至不如专家直接颅内出题来的快。那怎么办？

那干脆就用 Agent 自身留下的工作轨迹吧。

Agent这个产品与之前的产品不太一样，它的整个Harness构建的逻辑完全是按照编程去做的，所以它有保存好的上下文相关条件库、有issue（命令），有执行环境（Agent自己）、也有解题的流程。

虽然现在Agent并不是全能的，但大家用起它来，可是会覆盖几乎所有任务的。因此我们可以从中找到各种复杂、多样任务的轨迹。

这就是一个可能满足了GitHub水平信息丰富度和环境可控性的通用工作 / 领域工作的工作轨迹库啊。

不用岂不是浪费了？模型公司也想到了这一点。

比如 2026 年 9 月 3 日，阿里巴巴 Qwen 团队与清华大学提交《Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments》。

它利用了Codex、Claude Code 这类编程 Agent 在运行时，由 harness 记录下来的工具调用轨迹。Agent 读过哪些文件、执行过什么命令、修改过哪些内容，以及工具返回了什么，都可能保存在其中。这些信息虽然不完整，却足以帮助我们恢复一部分工作目录。

系统先梳理轨迹中的文件操作，尽可能找回 Agent 修改前的内容，并排除它在解题过程中新增的文件。再由另一个 Agent 补齐缺失文件和依赖，检查恢复后的工作空间是否足以支持任务。

团队最终构造了约 3.73 万个这样的环境，并在其中提出新任务、重新生成解题轨迹，用于 SFT 训练。

虽然论文恢复的主要依然是软件开发类的任务和环境，但它确实给出了一条一般任务如何利用Agent记录的明路。

我们完全可以想象，一次Excel处理的要求，可以如何在Agent的记录中被自动化变成可以继续探索的环境。

当然，要真的把通用领域的工程轨迹用好，还需要一些前置条件。

第一是Agent数据跨任务拼接的可能。一项日常事务可能先在一个对话里搜集资料，再在另一个任务里制作表格，随后由人打开软件修改，最后交给第三个 Agent 生成报告。各段记录分别存在，但Agent得在之后学会标明它们如何关联完成一个完整任务。

其次是中间状态的保存和恢复。harness 随之有机会保存更多信息。任务开始时的文件版本、关键节点的状态、需求变更，以及交付后得到的反馈。只有这样，每个节点的变化才能回退。

第三则是让大家把过去不在Agent里用的软件，现在尽量在Agent里用，以有效保留最完整的任务信息。这需要操作系统层面的使用更通畅，各类软件也能被 Agent 稳定调用和操作。这样，一项工作从接收需求、查找资料、跨软件处理，到交付和修改，才可能更连续地经过 Agent。

除了 GPT 6 在 OS、computer use 以及开放软件的使用方面大幅增强外，目前的 Agent 系统还不满足其他条件。

因此在可预见的这段过渡期，数据清理、背景补全和专业验收仍需要大量人工。最多做到半自动，还不是很专业。

这已经是最大化的利用工作轨迹做传统Agentic RL 的方法了。

即使这些问题都解决，得到一个能反复运行的环境，也只是过了第一关。

我们还有第二关，奖励和奖励分配。

奖励，新算法也解决不了旧问题

有了题，我们得让模型知道做的好坏才能教它。这就需要奖励。但可惜的是在开放领域，奖励不存在。

benchmark之所以重要，其实很多时候都意味着一种角度的奖励模型，改造改造就能成评分规则rubric。

但Benchmark也是专家攒的，自动生成的通用奖励并不存在。

Coding之外，Universal Verifier不存在

模型修复代码，靠测试我们就知道它成没成功。但到了Excel做的对不对、3D建模是不是够好，就已经非常不直观了。

2026 年的 Spreadsheet-RL 就是在真实 Microsoft Excel 中，评分时结合数值对错，以及适用的公式和结构检查。这说明，对能够建立可靠验收器的表格任务，原来的训练范式仍然有用。

但这只是很基础的训练的奖励，即算没算对的奖励。

实际上我们用Excel时候，还希望它能保持结构可审计，这样可以持续更新，跨表后也可以做计算。所以MBABench 已经把端到端金融表格的评估拆成 Accuracy、Formula、Format 三类，同时检查了计算行为、专业语义和交付质量。

3D领域这个问题也是一样的，26年6月的CodeBench 就同时使用执行成功率、多视角视觉相似度、三维几何指标，以及人类成对偏好来评价一个3D建模是否符合要求。

这其实都是在一个个领域，乃至具体任务中重新搭出来的rubric（规则）类的终局奖励标准。

这还是在一个软件中，目标相对统一。放到更大的领域内，任务更加多样，想建立起这种通用的奖励规则就更难了。

比如 Mercor 的 APEX-Agents 面对金融、法律的任务，专家就不得不为每项任务编写能够独立判断真假的标准与评分。

公开基准中，每种任务平均都有约四项评分标准。专家得把原来藏在专业判断中的验收依据写出来，让开放工作的一部分质量要求能够被反复评估。

而且要细化到每种任务。

没有RLVR的好用奖励，还只是问题的一部分。

（想了解这部分可以看Hao好聊的往期文章，目前Universal Reward这方面的进展仍然在当时文章的框架内）

信用分配，越来越麻烦

信用分配问题在Coding之外的领域也变得更加复杂。

在数学和Coding Agent的训练里，我们可以给同一道题生成多条候选，用答案检查或执行测试评分，再强化相对较好的结果。这种方法的代表就是GRPO。

它不用太考虑过程中哪个步骤对，哪个步骤错，怎么给这个流程进行更好的评分。

因为Coding的题目和环境已经可以自动化，题目多，同一任务也可以反复尝试，训练就能从大量比较中逐渐提高成功率。

但对于目前rubric这么难写，环境构造又慢的Coding之外的领域来讲，再用GRPO这种相对粗线条的评价体系就太狂放和浪费了。

除了题目少、不能浪费之外，相对于 Coding，其他任务还有一些特征也使得传统的GRPO类后训练方法变得很难收敛。

很多 Coding 训练任务的工具接口和动作语义相对稳定。读文件、搜索代码、编辑、执行命令、运行测试，虽然参数和内容千变万化，但训练模型反复面对的是相近的操作体系。这种稳定性可能让价值模型更容易复用经验。

但扩展到多种职业工作后，工具的使用流程往往会变得更复杂。而每一步到底有没有帮上忙，还要用不同的办法判断。

搜到一篇文章，要看它有没有提供有用的信息。改好一个公式，要看计算是不是正确。发出一条消息，要看有没有推动对方解决问题。完成一次审批，要看业务是否被正确推进。

这就导致只用一个1/ -1的终局分数去处理变得非常困难。

因此最近一段时间，算法方面的很多改动都是围绕着这点进行的。路径大概有三条：改造 GRPO、或者重新回归更经济、更可靠的 PPO 与 critic，以及通过 rubric 和工作轨迹构造更多学习信号。

第一条路，是保留类似 GRPO 的简洁性，改造它怎样比较和利用轨迹。

既然只有1 /-1的分数太糙，那我们就在里面稍微加点checkpoint，

2026 年 2 月，南洋理工大学与东南大学的 HGPO 发现当前环境一样，模型此前知道的事情可能不同。

例如，同样打开一个商品页面，一个 agent 已经查过预算和尺寸，另一个还没有。它们接下来是否购买，不能只根据开始的页面一样就放进同一组比较。

HGPO 按历史上下文的一致程度去拆分比较rollout。没到环境状态分叉的地方就单独拆出来一组。然后把所有的分叉去分别计算优势，再加权结合。

这样既利用更贴近当前决策处境的比较，也避免分组过细、每组只剩一两个样本。但这中间的动作信息，其实在这种分组中是有被考虑到的。

2026 年 7 月，穆罕默德·本·扎耶德人工智能大学提出 BPO。它在可保存、恢复的沙箱里，在一条执行过程中，从模型对选择比较不确定的地方分叉，尝试不同动作，再比较后续结果。它的思路和2025 年 5 月，南洋理工大学与 Skywork AI 提出的 GiGPO非常相似。

采用终局奖励的普通 GRPO，主要比较同一道任务的几次完整尝试：哪条最终成绩高，就提高那条轨迹上动作的概率。GiGPO 也是利用不同轨迹中重复出现的环境状态，既然几次尝试都走到了同一个地方，就比较从这里采取不同动作之后的结果，再给这些动作一个局部优势，与整条轨迹的优势结合。

只是BPO在这方面更主动，更细致。

这样既不用重新训练一个评分器，还可以在关键点加强训练，方便信用分配。

论文在网页购物、家务模拟和代码修复任务中，报告了相同计算预算下相对 GRPO、RLOO 更好的效果。

第二条路，是重新引入 PPO 式的 critic，但用更便宜的或更有效的。

早先的强化学习中，PPO的方法就是训练一个价值模型，判断「任务做到这里，继续执行预计能拿多少回报」，并由它给每个步骤打分，是一个稠密的过程评分模型。

这样，模型就可以利用这些中间估计形成更细的学习信号，在一定程度上解决了GRPO的信号信用分配问题。

而且它不用取很多Rollout，利用这些中间估计形成更细的学习信号就能训练，而不必完全依赖同题多次尝试之间的比较。

在很多很难比的工作轨迹中，这个方法就很有用。

比如智谱在 2026 年 6 月发布的 GLM-5.2 技术说明中，就提到过在长任务Agentic RL的部分场景中，他们用回了PPO。一般这些场景是经过上下文压缩后，会形成数量和长度差异很大的执行片段，GRPO很难比较。团队因此采用带 critic 的 PPO，从单次执行中估计 token 级优势，将压缩后的片段纳入训练。

这是critic模型重新进入长程 agent 训练的一个实际案例。

但它的问题就是训练一个critic模型非常贵，也不一定准，整体训练速度也因为需要打分而变慢。要让这条路线重新有吸引力，就需要改造critic模型，让它别那么贵，尽可能快。

别那么贵的方法主要就是不再单独训练critic。

厦门大学与南洋理工大学在 2026 年 8 月提出 SAPO，尝试让执行任务的模型兼任 critic。

这一个模型不仅生成下一步操作，还会顺道预测一下每一步操作交互最终能获得多少奖励。跑完一个流程后，这个模型就看看实际结果与当时在交互轮次里作出的预测差了多少，当作训练讯号。

比如要搜索，操作前模型预测最终得分是 0.3。但搜索后找到了符合要求的商品，下一轮预测变成 0.6，这一步就产生了约 +0.3 的改善信号。

这样，每道任务在一次采样中只需跑一条完整轨迹，也能获得不同轮次的训练信号，同时省去独立 critic 模型的显存开销。

在 ALFWorld 和 WebShop 上，这个方法都取得了相对普通 PPO、GRPO 的改善，同时减少了独立 critic 带来的显存负担。

另一个修改方向，就是从现有轨迹中提取局部信号，让 critic更准确，也更关注关键步骤去评分。这样critic就可以比较快，省算力，还准。

过去的critic准确度其实不高。它虽然能在每个 token 的位置给出价值预测，但这个数是判断从目前的内容继续生成，最终能获得多少奖励。

按理说它需要同时理解当前思路、预判后续难点，还要估计执行模型能否完成剩下的工作，但这又难又慢。传统 critic 其实就是训练了一个读完当前的解题过程后，就直接预测最终奖励的转换器。

但复杂任务本身就更复杂，搜索空间大，照这种方法训练出来的模型准确率并不高。

因此我们得抓住任务的关键节点。

最简单的方法就是靠rubric（规则）本身，去增加除了1/ -1之外的关键判断点。

2026 年 9 月，卡内基梅隆大学与 IBM Research 提出的 DRACO就是这个思路。

它根据任务和实际执行过程生成rubric检查表，再让评审模型逐项检查，并指出相关步骤在哪里。例如，rubric规则里需要判断「是否核对了必要信息」，那它对应的就是前面的查询动作。算法根据这个结果是否达成了检查表的要求，调整各步骤受到的鼓励或惩罚。

在 AppWorld 上，论文报告比使用稀疏真实奖励训练的 GRPO 高出 5.3 个百分点。这说明 rubric 有可能提供可用的训练信号，但效果仍然依赖评分标准和步骤对应是否可靠。

以上这些，都暴露了目前进入开放工作以后，终局 reward 不够，轨迹也没有很好的被重新按任务依赖关系切分。

在有效利用工作轨迹做奖励和分配这块，业界比去年整体进步的并不多。

富矿难采

综合来看，当 Agent 想用传统 Agentic RL 的方法跳出 coding 的鱼池时，工作轨迹用起来并不丝滑。

当前主流的还是专家标数据，手搓为主。真实工作确实可以进入 Agentic RL，但每个领域都需要把任务条件整理到训练能够承受的程度。

这也是为什么数据公司，造环境的公司都在创业风口上，因为广阔的现实有手搓不完的环境。而商业逼迫着这些模型公司，必须去买新的环境数据，再做RL，再扩展Agent的边界。

唯一的光亮就在 Terminal-Universe 这种方法中，在Agent自己环境里去取工作轨迹，然后尽可能利用Harness快速造出环境来。

但这个光还比较暗淡，也解决不了奖励和信用分配问题。

04

跳出传统Agentic RL，有出路吗？

既然Agentic RL的传统造环境做训练的路子用不起来工作轨迹，那干脆我们就换条路走。

如果真实工作反馈可以直接训练模型，那就不用造环境了。

有人就找到了这样一个狭窄的捷径。

6月，李飞飞参投的 AI 实验室 Trajectory 的联合创始人 Arjun Karanam 在公司官网发表《Continual Learning: End of Frozen Software》。

他表示，工作每天都在发生，但发生过的工作没法直接拿来训练。工作轨迹之所以好使，是因为用户在实际工作中，可能已经把问题指出来了。比如模型做了一张表，用户告诉它这里应该按客户去重，你算成订单数了。

这句话不只是表达不满意，还指出了哪里错、应该怎样改。

如果最后只把它压成一个负分，再让模型靠反复尝试找出问题，就浪费了反馈里已经有的信息。

一次用户请求通常只有一次执行，后续修改可能几小时后才出现。所以要拿它造环境、题目和评判标准，光数据标注和清洗你就受不了。

确实，从我们上面的分析看他说的很合理。

那怎么让模型快速学到这个反馈呢？用自蒸馏SDPO。

SDPO 沿用了 Thinking Machine 的 OPD 方法。

在OPD里，有一个比较强的教师模型，和一个等着被训练的模型。学生拿到任务，自己生成回答，或者执行一段操作。老师随后沿着学生实际走过的过程，判断每个位置接下来怎样做更合适。训练让学生的预测向老师靠近。

与直接模仿标准答案的DPO方法相比，老师教的是学生实际遇到的问题。学生走了一条不同的解题路线，甚至中途犯了错，老师仍然可以在这个位置提供指导。学生学会的更可能是如果是我怎么做才能更接近这个答案，而不是抄答案。

但这需要一个能够指导学生的老师。如果老师也不懂这个领域，蒸也蒸的是错的。

这显然不适合去探索一个全新的没有老师的领域。

2026 年 1 月 28 日，ETH Zurich、斯坦福与马普所在论文《Reinforcement Learning via Self-Distillation》中提出了一种新方法，SDPO 把老师给删掉了。

他们认为模型自己做不出来，不代表看到反馈后还不明白。所以就让学生先尝试任务。同一个模型额外看到执行反馈后自己给自己当老师，回到学生原来的生成过程，重新判断下一步。学生再向这位事后诸葛亮靠拢学习。

这样就可以自己给自己当老师，利用反馈，让模型自己具备更好的指导能力去探索新的领域了。

用这种方法，论文在科学推理和工具使用任务上的汇总成绩为 70.2%，GRPO 为 66.6%。化学问答的一组实验中，同样使用四张 GH200，SDPO 约五十分钟达到 GRPO 五小时的准确率。

到了3月，ETH Zurich、MIT 与苏黎世大学发布的《Aligning Language Models from User Interactions》论文把这套思路直接用在了用户的数据轨迹上。

前一篇仍然需要学生不断生成新尝试，再从环境里拿反馈。这一篇的离线实验，直接利用已经发生的对话，连重新执行这一步都省了。

他们把一次交互整理为三部分，用户原来的要求、模型的回答，以及用户接下来的消息。

但日志里的回答来自 GPT-3.5 和 GPT-4，要训练的学生却是 Qwen、Olmo 等模型。因此，他们把日志中的回答逐步喂给学生，让它计算每个位置接下来会怎样预测。老师用的是同一个模型，但额外看到了用户的后续回复，也沿着相同的回答计算预测。

两边的区别，就是有没有看到用户的纠正。老师看过反馈以后，对下一步应该生成什么，有了不同的判断。再让学生的预测向老师靠近，把看过反馈之后才有的判断学进去。

因此，这组离线实验不需要新搭交互环境，也不需要先把用户反馈加工成奖励分数。

这篇论文还做了一个更进一步的实验：只围绕一道难题，模型能不能边做边学？

研究者让模型反复尝试同一道编程题，每次拿到反馈后，都通过自蒸馏更新参数，再用更新后的模型继续尝试。普通多轮对话是把经验放进上下文，这里则把经验逐步写进模型。

在选取的极难题目上，达到相同的解题发现概率，SDPO 可以比反复采样或多轮对话少用约三分之二的尝试。

这说明一条单次成型的工作轨迹，就能给模型提供足够的训练信号。

研究者从约 1.4 万段真实对话中提取约五万个样本。训练后，Qwen3-4B 的 AlpacaEval 长度控制胜率从 37.9% 提高到 46.1%；Qwen3-8B 从 49.3% 提高到 51.9%，IFEval 从 83.9% 提高到 85.0%。不过，4B 在 ArenaHard 困难问题上的成绩下降了 1.2 个百分点。

至此，这条用现成的单次工作轨迹，直接训练模型的路线就走通了。

Trajectory 在6月2日发布的《Scaling SDPO》则继续完善了这一做法。

如果我们用SDPO做异步训练的话，等用户反馈回来时，做事的模型可能已经更新了好几轮。

上午模型做错了一张表，下午用户才指出问题这时要学习的是现在的模型，留下错误的却是上午的旧版本。但旧模型容易犯的错，现在可能已经有所改善，还原封不动地照着旧记录猛改纯浪费。

在这种情况下，他们会先根据新旧模型的差别调整旧记录在训练中的分量。然后再给更新加上限制，让旧数据不能被过度放大。

这样，每项任务只留下一条轨迹也能训练，失败的过程也不必扔掉，只要事后的信息能帮助模型理解应该怎么改都可以用作训练。

用这套方法，在 APEX 上，GPT-OSS-120B 模型通过率从初始 5% 提高到 25%，比没有这些稳定措施的 SDPO 高九个百分点。

另一个 Tau-Retail 实验中，异步训练相对同步版本实现了约两倍的训练时间加速，最终准确率没有下降。

不过，这些结果仍来自测试环境。到了 8 月 11 日，他们发布了法律领域的新结果，应该就是他们实践的效果。在报告中，他们使用了一家律所的实际工作数据进行后训练，把 Nemotron 3.5 Lightning 在留出法律任务上的全部标准通过率从 0% 提到了 8.3%。

说实话，效果并不是非常显著。

但这已经是越过传统Agentic RL外，直接把工作轨迹用好的当下最优解了。

想绕路，没那么简单

而且这整套试图用SDPO替代RL的方法路径也越来越受到挑战。

UIUC、中国人民大学与北京大学研究者于 2026 年 5 月 11 日发布的《The Many Faces of On-Policy Distillation》发现，OPSD 容易把模型看了答案以后会接着说，当成模型已经学会不看答案也能做。

这中间其实差了一步。

比如一道数学题，学生不知道该用哪个公式，正在尝试。老师是同一个模型，但提前看到了完整解答。它当然更容易判断下一句应该写什么。

训练就让学生在每个位置向老师靠近。问题是老师的判断，一部分来自解题能力，另一部分来自它已经知道了答案。

学生需要学会的是前者，但训练信号可能告诉它的是后者。

让老师多看一点信息，并不自动等于给学生提供了它能学会、下次能独立使用的知识。

在他们的测试里，OPSD老师看最终答案的情况下，做完蒸馏准确率甚至还低了一个百分点。而 GRPO 则稳稳提升了12%。

这说明，OPSD可能在自己不清不楚的情况下，根本教不到点上，反而耽误了模型提升。

想用蒸馏逃开credit assignment，但是还是折在了credit assignment上。

这可能就是Trajectory效果不佳的原因。

这还没完。

普林斯顿大学 7 月发布的《 Rethinking On-Policy Self-Distillation for Thinking Models》在五个 Qwen／OLMo 推理模型上发现给老师完整参考解答后自蒸馏，长推理评测成绩全部下降。

例如 Qwen3-8B 的三个数学基准平均成绩从 63.5% 降到 57.8%。

对此，研究人员认为老师已经知道答案就会倾向于直接往下走。而学生原本需要的核查、回退、重新考虑，却因此得到负面信号。学生学到了更短的过程，没有同时学到老师凭借额外信息才具备的判断力。

中科院相关团队与南京理工大学 7 月的《Denser ≠ Better》更是专门研究持续后训练。它发现 SDPO 可以更快适应当前领域，但在其连续训练设置中，也出现了更严重的遗忘，甚至崩塌的现象。GRPO 的适应更保守，旧能力保留反而更好。

要知道OPD当年的一个大优势，就是它没有SFT那样的灾难性遗忘，又比RL高效省钱。

但用在 Trajectory 希望的那种每天吸收用户反馈的场景下，可能反而灾难性遗忘更甚。那靠它学成AGI就不可能了。

这也是为什么现在大厂们，还是倾向于老老实实做环境的原因。

想绕路，没那么简单。

05

一口一口吃掉世界，能走到 AGI 吗？

所以，归根到底，目前GPT 6所显示出的这套「AGI」的路径，就是不断造环境，然后RL进入新领域。

一口一口吃掉世界。

但这样真的能吃掉 AGI 这么广阔的世界吗？那些被 RL 了的模型，它们的智能真的提升了吗？

而这一切的代价是什么？

交好泛化税

虽然RL带来的遗忘已经比SFT之类小很多，但泛化税还是不得不交的。

新任务成绩提高时，某些旧任务的表现可能下降。模型在目标任务上的收益，不能直接等同于整体能力的收益。

2026 年 1 月，Meta 与美国西北大学等机构的研究者发布论文《Paying Less Generalization Tax》观察到，训练过程中RL 的目标环境的成绩上升，未训练环境的表现却下降。

他们用 Llama-3.1-8B-Instruct 在 WebShop 购物环境训练后，购物成功率从 34.4% 升至 58.0%，但未参与训练的 ALFWorld 家务任务却从 25.8% 降至 10.8%。提前用 SFT 巩固部分领域，确实能减轻遗忘，但保护没有自动延伸到其他能力。

鱼与熊掌难兼得。

当然，用了10万 GPU训练的10万亿级别的GPT 6可能比8B模型有更多余裕保留更多技能。

但从用户反馈上看，那些不在主要Benchmark上的能力，GPT 6 可能表现的还不如前一代 GPT 5.6。

比如写作。

在由 ARC 测试作者 Louis-François Bouchard 维护、用于测试模型能否模拟其他文章风格的 ToneBench 上，GPT-6 Astra 就比 GPT 5.6 低了 2.7 分。

这就是模型升级带来的泛化税。不在主流Benchmark上的，通通可以舍弃。

比如这篇文章，我就是用GPT 6 辅助，但完全得一句一句重写，可以说是我最近几个月写的最费劲的文章了。

一口一口吃，能不能理解世界

一口一口吃，到底是不是真的能学到通用的技能？

这个真不好说。

2026 年 3 月，复旦大学、美团和上海人工智能实验室联合发布《Can RL Improve Generalization of LLM Agents?》就专门研究了这个问题。

他们发现，RL 的泛化效果很大程度上取决于「换的是什么」。

在同一个环境里换题目、增加难度，学到的能力往往还能用。但换掉知识背景和操作接口，收益就小得多。

比如让 Qwen2.5-7B-Instruct 只在 WebShop 的简单任务上训练，困难任务得分就从 17.4 提高到 77.5。但跨环境测试中，3B 和 7B 模型在未训练环境上的平均提升分别只有 3.32 和 3.44 分，个别组合明显出现泛化税型退步。比如7B 模型在 BabyAI 训练后，WebShop 得分从 28.59 掉到 10.25。

作者观察到，BabyAI 每一步都会提供可选动作，模型逐渐依赖这种提示，换到需要自己组织操作的环境就容易出错，根本泛化不来。

支持「只要持续增加行业训练，通用行动能力就会自然形成」这一判断的论据也有。

2026 年 7 月，Surge AI公开《Cross-Benchmark Generalization in Long-Horizon Agents》，在不包含软件工程任务的办公与多工具工作流上训练，仍然观察到了软件工程评测的提升。这说明某些工作方法可能跨过了训练领域。

当然，在很多领域中，我们都看到，数据本身的多样性可以提高整体泛化能力。

2025 年 10 月，卡内基梅隆大学、俄亥俄州立大学、香港大学、杜克大学、富士通和 All Hands AI 等机构的研究者公开 Agent Data Protocol，将编程、浏览器、工具使用等不同来源的轨迹统一后训练，观察到了优于单领域训练的结果。

这背后的解释，可能正是工作流程内在的同构性。

不同工作之间，也许存在足够多可以复用的方法。查错、核对证据、维持目标、发现信息不足，都可能在不同领域反复出现。更强的底座加上更丰富的交互经验，有机会让这些方法被稳定地学到和调用。

模型需要面对不同的问题结构，才有理由学会比固定流程更灵活的处理方式。

这也保留了那种朴素路线的可能性。

也许在足够长的时间里，一口一口吃掉世界，积累足够充分、质量可靠且配比合理的领域数据，最终形成超出单个领域的泛化。

也许OpenAI们在押注这种AGI。

不过，训练覆盖广与持续学习之间，依然隔着一个问题。

模型能否在面对新工作时，自己判断缺少什么知识，通过有限尝试获得经验，再把它保留下来，并用于下一次陌生任务？

现有的局部迁移证明不了它正在压缩出一套能够适应广泛变化的通用方法。

那怎么办，先一口一口吃，等着看。看这种变化会不会再一次神奇地「涌现」。

但我感觉，这条枯燥的造环境路径背后，商业逻辑的驱动力可能远大于对 AGI 的追求。

推荐阅读

DeepSeek的Harness，有一套新世界观｜Hao好聊趋势

Jeff Dean们，赶在贝叶斯AI到来之前跳船｜Hao好聊趋势

一键关注,明天见

看完点个爱心点个赞