从“刷分”到真实应用：评估AI的底层逻辑已经彻底改变

文｜晓静

编辑｜萌萌

当前，AI领域出现了一个现象：当各大科技公司竞相宣布其模型在HumanEval、MMLU等权威基准测试中突破90%甚至达到93.9%的高分时，实际部署的对话机器人和代码助手却频频在真实场景中“死机”。

它们能完美解答标准题库中的抽象代数题，却无法处理客户一句带有口音的简单咨询。

微软 CEO 萨提亚·纳德拉把这一现象称作 “Benchmark hacking”——模型在人工试卷上大杀四方，却难以胜任开放世界的琐碎任务。

现实与测评的脱节，迫使行业重新审视“什么才算进步”。

两个月前，OpenAI 研究员姚顺雨在热议文章《AI 下半场》中深入讨论了这个问题：AI的焦点正从“解决问题”迁移到“定义问题”，评估本身比训练更稀缺、更重要。

文章指出，传统 Benchmark （测试标准）已无法约束大模型 + 强化学习的组合拳，与真实世界差距巨大；真正的 Agent 必须拥有 thought → action → observation 闭环，能够调用工具、执行操作并持续感知环境。

在技术层面，姚顺雨揭示了两个关键问题。首先是记忆问题：依赖检索的RAG方案无法让模型真正“记住”长期经验，记忆必须写进模型参数里，Agent才能摆脱健忘症。其次是评估困境：开放式任务面对动态、多元的人类偏好，天然难以被统一打分，统一的Reward Model（奖励模型）在此失灵。

这些技术挑战指向了一个更深层的认知转变：在AI的下半场，焦点已从“解决问题”转向“定义问题”。

在腾讯科技近期举办的《想象力沙龙》闭门活动中，OpenManus Founder、SophiaPro联合创始人向劲宇做了主题分享，他围绕姚顺雨文章中提到的“定义问题比解决问题更重要“这一观点，从Agent技术架构、记忆机制、评估困境以及产品驱动的新范式等多个维度，分享了他对AI下半场的独特见解。

以下是向劲宇关于AI下半场思考的完整分享：

精彩观点摘录：

• ChatGPT像个被关在屏幕里的“缸中之脑”，几乎只能聊天。真正的跃迁来自动作空间——就像模型能删除一份服务器数据，它其实是获得了影响现实世界的能力。

• 人类说出“我爱你”并非临时检索旧日对话，而是那段体验早已内化成神经连接。要让Agent拥有这种内化式记忆，光靠RAG远远不够。

• AI下半场的焦点从解决问题转向定义问题——评估比训练更重要。

• 开放式任务天生“评不了”，原因并非技术不够强，而是这类任务的终点是服务人，而“人”在不断变化。不要幻想一把万能尺子可以衡量所有开放任务。

• 真正能拉开一流与二流差距的，不是论文分数，而是“用户→反馈→迭代”闭环跑得多快、链路多顺。

图：OpenManus Founder、SophiaPro联合创始人向劲宇

以下为分享内容整理（有删减）

一、从“缸中之脑”到智能体：Agent的进化之路

首先，要弄清楚“Agent”是什么。早在强化学习时代，Agent 的概念就已出现；区别只是当下谈论的更多是 LLM-based Agent——由大型语言模型驱动的智能体。因此，我们先看看这种“智能”是如何诞生的。

如果把时间拨回到 GPT-1（2018）到 GPT-3.5（2022 年底）的阶段，ChatGPT 的横空出世让大众第一次真切体验到 Transformer 模型的力量。彼时，人们兴奋地与它聊天，却很快在 2024 年初发现：它几乎只能“聊天”，像个被关在屏幕里的“缸中之脑”。

接下来发生的事是 Prompt Engineering 的兴起：Chain-of-Thought、Rephrase、Step Back……各种小技巧教模型“思考”。事实证明，通过让模型在 token 串中反复探索，回答质量得到了显著提升，也让大家意识到——AI 不只是会说话，它已经具备推理能力。

然而，光有语言仍无法真正解决问题；它的活动范围仍局限于语义空间，说到底还是 Chatbot。如今不论是聊天机器人还是自动化工作流，几乎都自称Agent，这让定义更显模糊。

真正的跃迁来自“动作空间”。一旦模型能够输出可执行代码、调用 API、操控计算资源——哪怕只是删除一份数据——它就获得了影响现实世界的能力。此刻，它不再是纯粹的对话系统，而是拥有感知与行动闭环的智能体，也就是我们今天所说的 Agent。

我们常说的LLM-based Agent的雏形，可以追溯到姚顺雨在ReAct论文中提出“thought → action → observation”三元循环：模型先在脑海中思考，然后付诸行动，再根据环境反馈调整思路，如此往复。这与强化学习中的“观－行－评”框架极为类似，只是把驱动力换成了大模型。

二、记忆的困境：RAG之外的思考

到 2023 年 6 月，Lilian Weng（当时仍在 OpenAI）在博客中把 ReAct 的骨架进一步扩展为“memory、planning、action、observation”闭环。这里的 planning 相当于推理——Agent 会在心里预演动作及其后果，等价于自带一个小型世界模型；action 空间通常由可用的 tools 决定，写代码、调用 API 或执行 MPC 指令都可以，只要能对外部世界产生影响就是“动作”；observation 则是现实反馈信号，反过来驱动模型更新思路；memory 负责承载长期上下文，防止 Agent 每次互动都“失忆”。

真正棘手的是 memory。市面上所有“有记忆”的产品基本都靠“复杂工程 + RAG 检索”组合拳：什么时候检索、检索什么、如何检索——始终绕不开这三件事，却难以让信息真正写进模型参数。人类说出“我爱你”并非临时检索旧日对话，而是那段体验早已内化成神经连接。同理，要让 Agent 拥有这种内化式记忆，光靠 RAG 远远不够。未来若要彻底解决记忆问题，恐怕还是得深入模型底层，也许会由模型厂商在后续版本里实现参数级的持续更新，让 memory 成为模型本身的一部分；届时，Agent 才算真正拥有“长时记忆”。

图：Lilian Weng定义的LLM-based Agent的雏形（怎么描述才更准确）

三、AI下半场：从解决问题到定义问题

现在我来谈谈姚顺雨这篇《AI下半场》的文章。文章发出后，很多人质疑说："你怎么知道是下半场？为什么不是1/4场或1/5场？"大家执着于纠结“下半场”这个词，但我觉得下半场本身并不重要，关键是这篇文章在说我们处在一个关键的转折点上。

这篇文章提到，上半场大家主要在做方法创新。比如有人提出了Transformer，有人提出了GPT-3，你会发现他们都在说“我提了一个新的架构，我可以解决新的问题，并且我这个方法是很general（通用的）”。做完这个方法，我可以在提高所有的Benchmark分数。所以几乎所有论文背景都是这些做方法的，而不是做Benchmark的。

其实在他这篇文章发布之前，我和几个比我更有经验的AI工程师聊过，他们当时就强调评估很重要。但我当时觉得这会不会是做学术的一些偏见？因为发Benchmark其实比做方法要简单得多——只要提出一个问题，在上面标一些数据，让它跑，大家有一个分数，然后就可以发一个paper。它的循环是很快很短的。

但做方法不同。之前我们可以通过造一个新模型，在一些公开的Benchmark上刷分，就可以发论文。为什么大家喜欢做这个事情？因为它是”一招鲜吃遍天“的——我不需要针对这个场景去刷，或者针对另外一个场景去刷，而是我研究一个新东西，所有评估标准都可以被打爆。但这是基于Benchmark还没有被打穿的前提，就是说大家觉得这些Benchmark都是有意义的。

举个例子，假如现在学生都还在高考，大家去高考是因为高考的分数能够差异化，有考得差的，也有考得好的，考得好的可能间接说明学习能力更强一些。所以高考这个模式暂时还是比较合理的，当然肯定会有一些bias（不同意见）。

但是到我们这个时间点，大家开始用LLM加RL（强化学习），其实你可以去攻破每一个Benchmark，只要它有明确的评估机制。在之前强化学习的泛化没有成立的时候，实际上大家的关注点是反过来的，认为算法是最重要的，然后关注环境，最后才关注模型在学习环境里面的状态和先验。

但当我们重新走到现在，就像姚顺雨在文章中说的，我们发现事情是反过来的，先验才是最重要的。因为之前我们做RL，比如说我在这个房间里面做RL，我想让它能够快速地打扫这个房间的卫生，这个东西确实是可行的，因为它在不断学习这个房间的布局，以及怎么把这个房间打扫干净。

但问题在于，它学完了这个以后，我没有办法去用这个房间的知识把它带到另一个房间，让它能打扫得更快或者更干净。到了另一个房间，它得重新去学习一遍，所以实际上就一直没有办法被泛化。

但我们发现它有了先验以后，我在这个房间里面探索的东西，其实是可以通过训练内化下来的。虽然到了一个新的房间，但可以学得更快。所以现在无论是做模型的还是做Agent的，其实都是同一个秘诀——这一套秘诀就可以攻克编程，可以攻克数学、电脑操作。

所有这些看似不相关的任务，只要在Benchmark上有明确的评估，模型就在上面跑，去重复地迭代，拿到更多解决这个问题的数据，再重新训练回去，最终就可以把这个Benchmark给hack了，它就变得已经不太那么有意义了。

像O系列和R1这种通过RL训练的模型，它就把Benchmark的分很轻松地刷掉了。我们可以看到这个现象：Benchmark提出的时间点和刚开始的分数，比如说分数很低，到很快就被大家刷出来的时间是越来越短的。

我们能够很容易想象，如果我们提一个新的Benchmark，可能半年不到，就几个月，就有人已经能刷到七八十分了。然后这个Benchmark相当于就没用了，因为大家不会去刷一个七八十分的。因为就算刷到90分，大家会觉得你就涨了几分没什么意义，就会更愿意刷新的Benchmark。所以相当于它的边际成本就开始下降了。

所以姚顺雨说到evaluation或者说定义问题才是下半场的核心，就是评估这个东西本身比训练更重要。这里有两个问题，一个是现在的Benchmark和真实世界其实差异很大。比如说为什么刚才你看那个分数全部往上提，但实际上你用的时候你还是觉得它很蠢，或者说它确实还是在很多场景里面没有办法去端到端地帮你完成一个任务，是因为它和真实世界存在差距。

就比如说哪怕是一些Agent的Benchmark，可能环境是要做一个computer上面的操作，但实际上，电脑上会有很多广告，会有一些弹窗，会有一些消息，会有一些很异常的情况。但是Benchmark其实是没有办法完全去模拟这些东西的，就导致模型可以在这个Benchmark上可以刷得比较高，但是到真实环境里面其实很容易崩掉。

另外，真实的人类是可以连续积累记忆的。但是现在没有一个模型，或者没有一个Agent，它是在解决这样一个事情，就是在完成这个事情的时候，同时去积累了如何解决这个东西的能力。所以这就是为什么记忆也是一个很重要的问题。

最后，模型或者Agent在Benchmark上是超越人的，但是其实真实情况是——它帮我们做了多少事情，其实能力和经验并没有同步地增长很多。

所以未来真正有价值的是怎么去重新设计评估的模式。

原来是做一个任务，最终检验那个任务是不是完成了，这种简单的方式有可能是要被重新改变的。一些新的范式应该是要被提出来的，而不是简单地验证答案是不是完全一致这种方式。

这就是姚顺雨的原文观点——AI的下半场焦点从解决问题要转向定义问题，评估会比训练更重要。我们可能要去重新追问，不只是追问到底训练一个模型来做什么，而是应该说清楚我们要训练模型去做什么。

我在我的工作里面，确实遇到了这个问题，我去追问“我要做什么才能让我的模型能解决我现在遇到的问题？”

所以姚顺雨也提到了，AI时代，其实我们做科研的同学应该更像做产品经理一样，去看怎么定义具体场景下的问题。

四、评估的重要性：为什么定义问题比训练更关键

下面谈一下我的个人观察。

首先我觉得定义问题确实很重要。一个是从研究的角度来说，“好的问题”其实应该代表着人类在关注什么，或者说整个社会在关注什么。只有定义好了这个问题，解决掉了问题才具有意义。

另一个问题是模型的智能不是无限的。比如我在给实习生安排任务的时候，不会要求他“你一个月之内把Meta干掉”，我不会定这样一个很general（泛泛）的问题，而是会在某一个具体场景下给他定义一个问题。

所以定义问题的颗粒度本身也是重要的，应该根据现有模型的能力上限给它定义合适颗粒度的问题，它才能去做智能的提升。

这在训练模型的时候本身也有课程设计的考虑。就是说，你要训练一个模型，从刚开始它其实是没有太多智能，到有很多智能，你其实要在前期做一个比较“简单”的Benchmark（测试标准）。这个“简单”怎么界定呢？它的跑分不能太低，不能完全是0，否则它学不到任何东西。就好像我们给幼儿园的小同学做高考题，他是学不到东西的。

但是也不能太简单，比如给初中生做幼儿园的题，刚开始就90多分，其实也学不到东西。应该给它（模型）适合的问题，可能刚开始从四五十分，通过这种scale（规模定律）来提升。

这种scale是怎么来的？就是RL里面其实它在做的事情是pass at k变成pass at one。意思就是，重复做k次，我能解决多少问题？比如说我在做一套高考题，重复做了五次，五次以后面对同一个考题，只要对了一次，我就算那个题对了。

对于高考题来说，比如说我的数学的pass at 10是满分，我通过RL可以把这些我做对的思考过程重新训练给系统。我可以让这个pass at 10变成pass at 1，就是相当于之后只要一次，我就可以做对这150分的题。

所以这里的定义问题，其实前提是要保证“pass at k”是能做对这些问题的。如果我的pass at k依然是0，就好像我们让小学生去做高考题，可能他的pass at k就是0，那是永远不可能靠这个RL去提升智能的。

另外，我认为定义问题更多是从产品角度出发的。因为我觉得产品本身就是在定义问题，而问题本身就是在定义用户是谁。产品解决了什么方面的问题，就吸引了哪一方面的人来用你的产品。

就比如说Cursor，最开始的时候它解决的是coding人群的问题，比如说要很快地去做编辑，也有可能是要对项目做一些重构和一些提问，那产品的交互，就是为了coding。

比如说像Lovart，它可能就是在刚开始的时候，就是瞄准设计师，所以最终的交互界面更适合设计师。我觉得这个是一个比较闭环的东西。

五、开放式任务的评估挑战

评估之所以被反复强调，第一层原因是它直接决定了模型能否真正从环境中学习。

当 Benchmark 过于理想化、缺乏真实交互细节时，Agent 只能在“温室”里刷分，却摸不到“浏览器的按钮该点哪、操作系统何时弹窗”这类现实知识；若测评场景足够贴近生产环境，模型便能在反复试错中获取真实反馈，逐步掌握这些操作规律。

在让评估更贴近现实这件事上，数据流是核心。

要让模型闭环，必须同时有两股数据：一股来自环境本身，包含网络延迟、系统弹窗、意外报错等噪声；另一股来自人，体现用户的偏好、情绪与需求。这两条数据流共同作用，才能让模型既懂“世界的规律是什么”，又懂“人想要什么”。

真正让人头痛的是开放式任务的评估——一篇文章是否够好、小红书的文案是否吸引人、一个段子好不好笑……这些都没有统一的评分尺子。过去一年我一直在琢磨如何衡量这类open-ended（开放式）任务，并尝试用RL（强化学习）框架做自迭代；结果发现只要任务无法量化，RL 就无从下手。

可用的评估场景其实很有限：数学、代码、问答，再往上做的 deep research 也只是把 QA 延伸到信息检索，本质仍能用“对/错”来打分。

起初我设想：若能给开放式任务设计可行的指标，就能把 RL 范式推广到所有场景。但后来意识到，open-ended 任务天生“评不了”。原因并非我们技术还不够强，而是这类任务的终点是取悦人，而“人”在不断变化。中国读者捧腹大笑的笑话，可能让美国观众觉得无聊至极；流行风向转得飞快，上月的热搜，下月就可能完全吸引不了用户的兴趣了。

很多团队尝试训练 reward model（奖励模型）来捕捉人类偏好，在定式任务里行得通，但遇到主观性极高的内容就失灵了。比如一篇立场激烈的女权文章：支持者会给 10分，反对者也许只给1分，如果把两极拉平均，得到5分，但是这个数字既不能反映真实分布，也不能说明文章放到不同平台会引发怎样的情绪反应。用这样模糊的分数回馈模型，只会得到一篇谁也不讨厌、但也打动不了谁的平庸作品。

事实是，开放式任务没有绝对的对错，评价标准取决于你把作品交给谁。用单一分值或静态reward（奖励）去衡量动态人群的多元审美，注定走不通。要想让模型在这类任务上进步，就得把评估重新落回具体场景和特定目标受众，让真实用户数据通过 A/B 实验、分层指标持续回流，不要幻想有一把万能尺子可以衡量所有开放式任务。

六、产品化：让评估回归现实

产品之所以至关重要，首先在于它把问题“实体化”：明确要解决什么痛点，并把解决方案交到用户手中，后续评估自然就来自真实使用场景。

以Cursor为例，用户是否接受它生成的代码，既取决于客观可执行性——代码能不能跑起来——也取决于主观偏好：风格是否符合团队规范、界面是否够美观。这些主观维度只能通过用户的实际反馈来量化，而不是靠实验室里的静态指标。

与此同时，产品本身还承担着“数据标注器”的角色。每一次用户的点击、修改或满意度评价，都可以回流为新的reward（奖励），驱动模型继续迭代。

这与早期搜索和推荐系统的演进路径极其相似：当年大家一开始也热衷于在公开 Benchmark上刷分。但抖音、腾讯视频等平台上线后，行业重心迅速转向A/B Test，用实时用户指标来衡量算法优劣。

我认为，未来的大模型产品大概率会走相同的道路——真正能拉开大模型一流与二流差距的，不是论文分数，而是“用户→反馈→迭代”这个闭环能跑得多快、链路有多顺。