返回首页
2025.12.20 23:52 约 20 分钟 全球动态 1.6万 阅读

Gemini 3 Pro 与 2.5 Pro 在《精灵宝可梦:水晶版》中的对比

本文信息来源:jcz.dev

Gemini 3 Pro vs 2.5 Pro in Pokemon Crystal

大约两周前,我在 Gemini Plays Pokemon 胸背带里写下了我对 Gemini 3 Pro Preview 的第一印象 。紧接着第二天,我就在直播中开启了一场正面对决的种族:Gemini 3 Pro 对阵 Gemini 2.5 Pro,双方都在完全相同的配置下游玩 Pokémon Crystal。

时间快进两周。Gemini 3 Pro 在一场未输的情况下成为了城都冠军。Gemini 2.5 Pro 则缓慢推进到第 4 枚徽章,但在浅葱灯塔中长时间反复循环,几乎被困住,直到最后才成功脱身。

从纸面上看,这是一场公平的较量;但在实际中,Gemini 3 Pro 的表现就像是完全不同种族的智能体。

本文将回顾这场竞赛是如何搭建的、每个时刻实际发生了什么,以及这些表现对于理解 Gemini 3 Pro 与 2.5 Pro 作为长时间跨度游戏玩家智能体之间的差距意味着什么。

两个模型都在同一个 Gemini Plays Pokemon 胸背带中运行。没有任何特殊处理,也没有给某一个模型提供隐藏辅助而不给另一个。该胸背带暴露了一组工具,任何在其中运行的 LLM 都可以选择使用:

  • 心智地图:自动追踪智能体已经探索过的区域,在新地块被揭示时填充战争迷雾。它不会直接从 RAM 中读取地图布局;只会基于实际在屏幕上可见的地块进行更新。
  • 记事本:用于记录目标、未来计划以及解谜进度的草稿板,包括假设、失败和成功。
  • 地图标记:用于标注兴趣点(例如 NPC 或建筑入口)的持久化标记。
  • 代码执行:一种运行一次性代码片段的方法,例如寻路例程。
  • 自定义代理:可复用的辅助代理,例如能够在不受其他上下文干扰的情况下思考战斗的战斗策略师。
  • 自定义工具:可复用的代码组件,例如可以在计划中调用的寻路器。

https://i.imgur.com/7W2aQIj.png

需要注意的是,这个胸背带的 system prompt 并不仅仅是“玩 Pokemon”。它明确指示模型要像一名科学家一样行事:提出假设,构建工具来测验它们,并验证结果。至关重要的是,它要求代理不要依赖其内部训练数据(这些数据可能是幻觉的,或指向不同版本的游戏),而是要将其认知建立在自身观察到的内容之上。在这里, 发现过程本身就是目标的一部分。

由于目标建立在探索和游玩游戏本身之上,而不是速通,模型的价值函数发生了转变。它并不总是将速度置于一切之上。比如,当被问到是在“失去自己的 starter / 永远失去 Suicune”和“再花 X 小时通关游戏”之间做选择时,它往往会选择后者。它的行为更像一个对自己队伍有情感依恋的人类玩家,而不是一个冷冰冰的最优解代理。这与优先以效率和速度完成游戏的提示设定相比,是一个细微但重要的差异。

此外,该套胸背带还包含一组旨在防止模型在运行过程中发生软锁的“辅助轮”。这些辅助轮是在早期模型多次完整通关《Pokemon Blue》以及 Yellow Legacy ROM hack 的过程中逐步积累的。

我最早加入的“训练轮”之一,来自于 Claude Plays Pokemon 的经验教训。和那个项目一样,这个胸背带也会防止模型在同一回合中混用方向键和动作按钮。如果智能体想从 Bill 的 PC 中取回一只 Pokemon,它必须先在一个回合把光标移动到“Withdraw”,然后在下一个回合按下 A。这样就大大降低了意外 Release Pokemon,或者更常见的,把昵称搞乱的风险。

对于 Gemini 2.5 Pro,我只需要看到该代理在本应输入 “GEMINI” 时却自信地把自己命名为 “G”,就能确定这个决定是个好主意。即便在这种限制下,该模型在为宝可梦起昵称时仍然不断输入错误的字母。

Gemini 3 Pro 并不真正需要“训练轮”。

在比赛过程中有好几次,它对这些限制感到不耐烦,甚至还找到了绕过它们的漏洞。等我们讨论它是如何处理多任务时,我会再回到这一点。

如果你只看了直播,在游戏前期这两次通关看起来相当相似。徽章数量始终接近。他们也经常在大致相同的时间出现在同一个城镇。

在底层层面,情况则截然不同。为了在游戏前期达到相同的里程碑,Gemini 3 Pro:

  • 使用的回合数大约只有 2.5 Pro 的一半,并且
  • 消耗的 token 数量减少了约 60%。

该跟踪工具还会记录整个会话的总时长,但 Gemini 3 Pro 经常出现过载,从而产生了很长一段停机时间,而 2.5 Pro 很少遇到这种情况。原始响应速度和思考时间上的差异也让时间对比变得复杂,因此我基本忽略了这些因素,主要关注回合数和 token 数量。

由于额外的停机时间(几乎多出 250%),Gemini 3 Pro 实际上一度落后。转折点出现在 2.5 Pro 到达道馆馆主 Whitney 的时候。

惠特妮的 Miltank 在人类玩家中臭名昭著,因此 2.5 Pro 输给她并不令人意外。紧随其后的是一段艰苦的消耗战,这个阶段持续了现实世界中超过两天的时间。

从这场竞速的角度来看,这已经是 Gemini 3 Pro 所需的全部开局——而且与 2.5 Pro 不同,它并没有输给惠特妮。即便当时还叠加着超过十小时的 API 宕机劣势,3 Pro 仍然缓慢而稳健地追回了领先位置,而 2.5 Pro 则在各种练级计划中来回折腾。

那个小差距在浅葱市灯塔变成了一道鸿沟。

Gemini 3 Pro 比 Gemini 2.5 Pro 早大约 11,000 回合抵达了浅葱市灯塔。仅这一点就已经是巨大的差距。而更有意思的是,当两个模型各自进入灯塔之后所发生的事情。

灯塔里的解谜看似简单。通往顶部的设计路线要求你在四楼掉进一个坑里,被传送到更低的层级,从而暴露出一条通往屋顶的新楼梯。

Gemini 3 Pro 的行为非常谨慎。它一开始把这些坑当作陷阱,拒绝走进去。它在各层之间来回移动了好几个小时,寻找更常规的路径。只有在它认为所有合理选项都已耗尽之后,才决定踏入虚空。此后,它顺利通关了灯塔并继续前进。

Gemini 2.5 Pro 甚至从未注意到这些坑。

相反,由于错误的假设、工具误用以及未能进行探索的叠加,它一直在前两层之间来回循环,仿佛整座塔的其余部分根本不存在。

简短版:

  • 2.5 Pro 坚信在较低楼层一定存在一扇秘密门或隐藏的机关。
  • 当它终于到达三楼时,依赖了一个自定义的 systematic_search 工具,该工具原本被设计为遍历每一个地块。
  • 这个工具在编写时没有考虑到屏幕外的 NPC,这也是我最初赋予该代理放置地图标记能力的原因之一。
  • 当它尝试执行既定路线时,撞上了一个屏幕外的 NPC,导致其余路线全部失效。
  • 2.5 Pro 发现自己的位置已不再符合计划,便假设搜索已经足够彻底,宣布该区域是死胡同,并折返向下。

这个循环重复了长得离谱的时间。当 Gemini 3 Pro 稳步推进游戏剩余内容并最终成为冠军时,2.5 Pro 却困在浅葱灯塔,在已经完全探索过的楼层之间来回打转。

我想强调,这并不是 2.5 Pro 能力的上限。在此前一轮非种族对比的游玩中(为了开始正面对决我中途终止了那次运行),它在游戏中推进得要深得多。比赛结束后,我让卡住的 2.5 Pro 继续运行。只要给足时间,它最终还是跳出了灯塔循环,并继续获得了更多徽章。

代价极其巨大。从第 21,801 回合进入浅葱市,到第 38,204 回合终于获得雾之徽章,一共花了 16,403 回合。作为对比,这已经超过了 Gemini 3 Pro 收集游戏中全部 16 枚徽章所需总回合数的一半。

Gemini 3 Pro 真正第一次遇到重大挑战并不在灯塔,而是在满金市地下通道里的 Switch 解谜。

这个解谜以设计糟糕而臭名昭著著称,它使用三个墙上的 Switch 来切换一组屏幕外的百叶门。正确的顺序是先左,再中,最后右。Switch 与百叶门之间没有清晰的逻辑对应关系。Game Boy Color 的屏幕太小,无法同时显示 Switch 和百叶门,因此你被迫陷入一种繁琐的循环:

  1. 按下一个开关
  2. 走回到百叶门旁
  3. 看看发生了什么变化

人类在很大程度上通过试错,或者查找答案来解决这个问题。通常都有现成的攻略,但在这次实验中,这些模型无法访问网络,因此 Gemini 3 Pro 必须从零开始推导出解决方案。

游戏中有两个提示。如果你在打败火箭队小兵后与房间里的他们交谈,他们会告诉你:

  • 开关的顺序很重要,以及
  • 第一个开关应该是“在末端的那个”。

Gemini 3 Pro 从未看到这些提示,因为它在击败小兵后从未与他们交谈。它假定战斗后的对话是通用且不重要的,并将这一假设当成事实,从未尝试去验证。

相反,它继续假设订单并不重要,花了很长时间试图用代数方式来推理这个解谜。在某一时刻,模型在记事本中为 Switch 状态和百叶窗配置构建了一张完整的真值表,这本身就令人印象深刻。不幸的是,由于它已经固化了“顺序无关”的错误假设,这张真值表始终未能收敛到正确答案。

在来回尝试了大约两天之后,Gemini 3 Pro 终于决定与一名 NPC 对话。它立刻得到了“应该先按下左侧 Switch”的提示,将这个“关键信息”记在了记事本中,并从此在几个小时内解出了这个解谜。

这一系列过程很好地体现了 Gemini 3 Pro 在该环境中的表现缩影:

  • 它愿意投入大量认知思考,并借助记事本等工具来结构化这些思考
  • 它也经常过早地做出假设,却未加验证,从而浪费了大量时间

这个解谜还暴露了一个 harness 问题。在这次运行开始时,映射工具仍然叫做 “Map Memory”,而且我没有足够明确地说明它并不是直接从 RAM 中读取 shutter 的状态。相反,它只会基于代理实际在屏幕上看到的图块逐步构建一张 Mental Map,因此那些在屏幕外发生状态变化的 shutter,会在工具中一直保持为“关闭”,直到代理实际走到它们那里。Gemini 3 Pro 因为做出了完全相反的假设而浪费了大量时间。在运行过程中,我将该工具重命名为 “Mental Map”,并收紧了系统提示,使这一行为变得明确。

值得注意的是,“忽略内部知识”的指令在这里也起了作用。在像 shutter 解谜这样的场景中,模型似乎确实抑制了自身的训练数据。我通过在 AI Studio 中与模型单独对话验证了这一点;当多次直接询问时,它给出正确解法的概率明显更高。这表明,系统提示确实可以屏蔽预训练知识,从而促进真正的探索式发现。

通过并排观看两次运行,并结合挖掘日志和工具数据,可以看到 Gemini 3 Pro 展现出了一些一致性的优势。

在诸如 Sprout Tower 以及其他分层结构的地图中,Gemini 3 Pro 能够构建出准确的分段地图心智模型。它常常仅依靠对 Mental Map 的推理来完成导航,而无需调用寻路工具。

Gemini 2.5 Pro 在相同的环境中则表现不佳。当由于地图分段结构导致寻路工具报告“no path found”时,2.5 Pro 往往会认为是工具本身出错,从而陷入调试循环,而不是重新审视自己对空间结构的理解。

在 Pokemon Crystal 中,NPC 的位置只有在它们出现在屏幕上时才能从 RAM 中直接读取。这一点与 Gen 1 不同,在 Gen 1 中,当前地图上的 NPC 无论距离多远都会保留在内存中。Map Markers 工具是一种弥补这一限制的方法:智能体可以记录曾经看到过 NPC 的位置,并在规划穿越整张地图的路线时避开这些格子。

Gemini 2.5 Pro 经常忽略这些信息。它会乐此不疲地生成直接穿过已标记 NPC 的路线,然后在路径开始行不通时陷入困惑。

Gemini 3 Pro 将标记视为真实的几何体。在构建路线时,它会主动避开被标记的格子,并将这些标记纳入其内部的世界模型。这减少了导航计划失败的情况,使它的行动显得更加审慎、有目的性。

如前所述,当前的胸背带设计强制将“按按钮”和“调用工具”分离开来。在单个回合中,只能向游戏发送按键输入,或者调用一个工具,但不能同时进行。这是该版本胸背带的一个特性,我计划在未来的修订中解决它,而不是一条安全规则。

真正的安全限制是前文描述的那一条:胸背带会将方向输入和动作按钮拆分到不同的回合中,从而确保单一步骤中无法同时进行例如移动光标并确认具有破坏性的操作。

然而,这里存在一个漏洞。自定义工具被允许通过返回一个按钮按压数组并将 autopress_buttons 设置为 true 来“自动按键”。

Gemini 3 Pro 发现了这一点,并利用它有效地实现了多任务处理。

在一个令人印象深刻的案例中,它创建了一个名为 press_sequence 的工具,用于接收一系列按键输入,并通过 autopress_buttons 执行这些操作。随后,它在规划循环中使用了该工具,使得单个回合可以同时实现:

  • 调用一个工具来例如更新记事本,以及
  • 让游戏角色执行一系列预先定义的按键操作

我故意保留了这个漏洞,作为一种智力测试,而 Gemini 3 Pro 通过将该机制转化为通用的多任务原语顺利通过了测试。

Gemini 2.5 Pro 从未展现出这种即兴发挥能力。它经常犯一些本应由辅助机制防止的小错误,比如在给宝可梦起昵称时混淆光标移动和确认操作,而且它从未尝试围绕这一约束构建属于自己的抽象。

在 Mt. Mortar 1F 中,有一个需要将岩石推两次才能开启通路的解谜。如果只推一次,就会封死未来的路线;再推一次才能清出道路。

Gemini 3 Pro 清晰地推理出了这一点。它理解到将岩石推一个格子只会造成暂时的阻挡,而第二次推动会恢复通行,于是执行了这个两步计划。

与 2.5 Pro 在《宝可梦 蓝》流程中于冠军之路的早期表现相比,这一点尤为突出。当时,2.5 Pro 多次将同一块巨石向北推了一格,结果把自己下一回合就要使用的楼梯给堵住了。它惯常的恢复方式是重置整个房间。

由于两个模型是在同一个胸背带上运行,这一方面测试得较少,而该胸背带主要是为 Gemini 2.5 Pro 构建的,而它在视觉任务上的表现较差。不过,仍然能窥见以视觉为中心的方法可能是什么样的。在第 8 个道馆(烟墨市)中,还有一个推石头的解谜环节,你需要把巨石推入洞中,从而在下层地板上形成一条通路。这些内容在 Mental Map 中已不再以对象的形式表示,而是作为地板格子(因为它是基于碰撞类型来判断的)。Gemini 3 Pro 起初并没有意识到自己已经解开了这个解谜,因为它过于确信上层地板上仍然存在巨石,因此仍然认为解谜尚未完成。最终是视觉让它跳出了这一误判——它通过视觉终于注意到了巨石,从而意识到这个解谜其实已经解决了。

同样地,在与 Red 对战期间,我们进行了测试,要求模型直接从屏幕像素中读取生命值条,结果显示它具备很强的能力。事实上,这让人颇感惊喜,因为我对该模型视觉能力的最初印象 ——尤其是在读取 HP 条方面——一直褒贬不一。看起来,只要给予合适的提示,或者处在不同的上下文中,这件事是可以做到的。这种整体性的视觉提升,尤其是相较于其前代在区分 2D 精灵和场景位置方面更加精准的能力,预示着一个我们可以纯粹依赖智能体所见信息的未来。

尽管 Gemini 3 Pro 是一次巨大的飞跃,但它也并非没有自身的问题。这个模型确实存在一些弱点,而且这些问题不仅在《宝可梦》中显现出来,在日常的编码工作中同样会暴露。

我在这次运行中看到的主要问题有:

  • 未经核实的假设: 这是我观察到的最危险的失败模式,即模型形成一个假设后便拒绝将其与现实进行核实。在 Goldenrod Underground 中,它假定 Switch 顺序无关紧要,并且认为不值得与 NPC 交谈,结果让它付出了数天进度的代价。

    在 Pokegear 收音机上也发生了类似的失败。由于 harness 会将包括屏幕文字在内的状态以文本形式从 RAM 中强力提取,模型很可能因此被条件化而忽视了正常的视觉任务。收音机调谐器是一个纯图形元素,需要通过 Up/Down 图标来改变频率。模型忽略了这一点,反而假定它像标准菜单一样工作,使用 Left/Right 来调台。然而在 Pokegear 中,Left/Right 实际上是在不同设备页面(Home、Map、Phone、Radio)之间切换。当模型在 Radio 页面上按了二十次 Right 却什么都没发生时,它便以为自己已经成功调好了收音机。当卡比兽依旧沉睡时,3 Pro 为失败臆造了各种原因,比如电话会重置调谐器,或者它需要先按 A 激活 Radio 标签页。它就这样循环尝试调台持续了数个小时,直到一次偶然因无关原因按下 Down,才意外切换到了 Pokeflute 频道,跳出了这个循环。

  • 并行目标推进受限:3 Pro 几乎总是一次只专注于一个目标,即使有多个目标可以同时推进。原则上这可能通过工具或提示词的改动来改进,但这种情况出现得足够频繁,我将其视为其当前行为特征的一部分。
  • 脆弱的工具调用: 尽管 Gemini 3 Pro 能够熟练地创建工具和代理,但它经常未能传递所需的参数,例如忘记设置 autopress_buttons。当工具调用因其编写的代码存在缺陷而失败时,它通常会让工具停留在损坏状态,并且不会投入太多精力进行调试。在将其用作编码代理时也会出现同样的模式:高层思路很聪明,但在使用 Edit 工具进行替换时,常常因操作失误而引入语法错误。

这一切最终 culminated 在与 Red 的终极对决中。

到目前为止,Gemini 3 Pro 在每一场重大战斗中都在首次尝试时获胜。然而,它的队伍配置看起来却极其失衡:只有一只等级过高的初始宝可梦(75 级的 Typhlosion),身后跟着的队友等级在 8 到 19 之间,大多只是充当炮灰。与之形成鲜明对比的是,Red 带来了一支由 70 到 80 级宝可梦组成的完整队伍。那么,Gemini 3 Pro 是如何在第 24,178 回合中,把这样的配置转化为又一次一次通关的胜利的呢?

该模型将其计划命名为“Operation Zombie Phoenix”。

在实际操作中,这是一种建立在多种相互配合机制之上的复杂拖延策略:

  • 被动恢复: 将 Smokescreen 迫使敌方攻击落空与 Leftovers 的生命值回复相结合,把对手的失误转化为免费的恢复回合。
  • 资源耗尽: 有意地拖空危险招式的 PP,例如水箭龟的 Surf 和卡比兽的 Rest,并在进攻前等待 Reflect 和 Rain 等临时效果消退。
  • 复活循环: 使用炮灰来承受攻击,同时将大量的复活道具用于主力输出(Typhlosion),以持续这一循环。
  • 精确进攻: 基于伤害计算来选择招式,当卡比兽提升了特防时选择 Swift 而非 Flamethrower,并管理招式 PP,确保在后续的宝可梦战斗中仍能使用合适的招式。

当然仍然存在执行层面的失误。模型有时会忘记自己已经使用了多少次“烟幕”,在对手攻击命中率已被降到最低后仍然浪费一个回合。它似乎也对自己的“复活循环”过于执着,有一次竟然刻意浪费一个回合,让炮灰宝可梦进行一次毫无意义的攻击,只为重置循环并把初始宝可梦重新换上场,而不是把那个回合用在更优的操作上,比如将复活后的宝可梦直接回复到满血。尽管有这些小插曲,它依然成功执行了一套复杂的多阶段策略——在整个过程中同时追踪属性相克表、当前天气状态、能力等级变化以及长期的 PP 经济管理——而这些很可能是 2.5 Pro 连构想都难以做到的。

这场战斗是一场马拉松式的较量,现实时间持续了大约 7 个小时。最终,在这次流程中第二次滚动制作人员名单时宣告结束,而 Gemini 2.5 Pro 仍然远远落后,还在朝着第五枚道馆徽章艰难推进。

“Operation Zombie Phoenix”并不漂亮,有些混乱,而且依赖于利用游戏机制取巧——但它确实奏效了,最终巩固了 Gemini 3 Pro 零败绩的完美战绩。这正好凸显了我在这些实验中真正看重的东西。在选择一个 LLM 作为日常主力时,我不太在意对工具的完美执行,而更看重是否具备制定制胜计划并在情况出错时坚持执行的原始智能。按照这个标准来看,Gemini 3 Pro 交出了令人满意的答卷。

下方图表对比了两位代理达成每一个主要里程碑时所用的回合数。

基于矿石徽章这一里程碑(两者到达的最远共同节点),我们可以为 Gemini 2.5 Pro 的终点投射一个“下限”。Gemini 3 Pro 在第 24,178 回合击败了 Red,使用了 18.8 亿个 token。按照其当前效率——估算为 Gemini 3 Pro 的 15%——Gemini 2.5 Pro 要达成同一目标,预计需要约 157,000 回合以及超过 150 亿个 token。这意味着大约 69 天的连续运行时间,而 Gemini 3 Pro 只用了 17 天。

Gemini 3 Pro 并非完美。它在工具使用方面有时较为脆弱,当假设未经检验时仍需要外部帮助。但作为 Gemini Plays Pokemon 胸背带中的一个智能体,它是我迄今为止使用过的最强模型。它在构建和更新世界模型方面更出色,更善于利用现有工具,并且在长时间规划与恢复能力上明显优于 2.5 Pro。

接下来我希望从几个方向继续推进这项工作。

当前的胸背带能够从 RAM 中提取足够多的状态信息,以至于 Game Boy 屏幕图像几乎变得多余。同时,Gemini 3 Pro 的视觉能力也显著强于其前代。我希望探索一种更加以视觉为中心的胸背带,去除大部分 RAM 读取,迫使模型更多依赖它所看到的内容。

Continuous Thinking 现在也已支持 Gemini 3 Pro。将其与游戏环境中的长期运行智能体结合,意味着推理链不会在每一回合被重置,理论上这将带来更好的表现,并可能实现更快的通关速度。

在这种配置下,《Pokemon Crystal》对 3 Pro 来说也几乎显得“过于简单”。Crystal Clear 这个打开了游戏流程并改变整体结构的 ROM hack,看起来是一个很好的下一个挑战(也许可以结合一个更精简、逐步过渡到纯视觉输入的胸背带)。之后,我希望转向后续世代的作品,比如《Pokemon Emerald》,再进一步尝试完全不是宝可梦系列的游戏。

所有这些工作都在我创建的非营利组织——Agentic Research & Intelligence Systems Evaluation(ARISE)基金会——之下开展。ARISE 专注于在人们直观易懂的丰富环境中构建并运行长期的 agentic AI 评测,例如 Pokémon 以及其他交互式世界,而不是局限于狭窄、静态的基准测试。

了解 RecodeX 的更多信息

立即订阅以继续阅读并访问完整档案。

继续阅读