Gemini 玩《宝可梦》：对 Gemini 3 Pro「Riftrunner」的初步印象
本文信息来源：jcz.dev
随着 Gemini 3 Pro Preview（代号“Riftrunner”）的发布，我想分享一些过去几天测试中的初步观察。由于我在 Gemini Plays Pokemon（一个在 Twitch 上运行的长期智能体项目） 中的工作，我作为“可信测试者”之一获得了来自 Google 的提前访问权限。在该项目中，Gemini 2.5 Pro 已经通关了 Pokemon Blue 和 Yellow Legacy，目前正在推进 Crystal。
本次测试所使用的 harness 与我在 Yellow Legacy 运行时首次部署的版本完全相同，而 2.5 Pro 已经在该系统下于 Pokemon Crystal 中操控运行了超过 522 小时。该系统使模型能够通过一套高层能力与游戏环境交互：它可以通过地图标记和记事本来维护持久状态，实例化用于特定推理任务的自定义子智能体，并创建自定义的 Python 工具来自动化输入序列或处理游戏数据。
我一直在用新模型进行一轮全新的 Crystal 测试，看看它在游戏世界导航这一具体挑战上的表现与 2.5 Pro 基线相比如何。虽然这只是初步印象，但提升非常明显。
空间推理与导航
我观察到的一个显著改进是在空间推理方面。Gemini 2.5 Pro 往往依赖对其并未完全理解的地图进行强行尝试式的导航操作，而 Riftrunner 则展现出对游戏几何结构要素更为扎实、直观的理解。
下面是胸背带在正常游戏过程中提供的一张示例截图。在 Gemini CLI 中，我给出的提示是：“给出到达屏幕顶部 NPC 右侧所需的精确步骤。”
Riftrunner 回复道：
在查看网格后，你无法直线上移，因为建筑及其门的传送点阻挡了那条路线，所以你必须从右侧绕行。
以下是到达 (25, 7) 的精确移动列表：
- 向右 4 次（将你移动到 28, 11）
- 向上 4 次（将你移动到 28, 7）
- 向左 3 次（将你移动到 25, 7）
这将使你正好位于 NPC 的右侧。注意不要踩到位于 (25, 9) 的门格子，否则你会触发传送。
相比之下，以下是使用 2.5 Pro 执行相同提示的会话记录：
@ saves/screenshot_enlarged.png 给出到达屏幕顶部 NPC 右侧所需的精确步骤
根据图片，步骤如下：
- 向左移动 1 次
- 向上移动 4 次
- 向右移动 2 次
\> 你确定吗？玩家是从哪个坐标开始的，每一步移动分别到达哪个格子？
你质疑得对。我犯了一个错误。
玩家从 (24, 11) 开始。
这是正确的路径：
- 向左移动 2 次，到达 (22, 11)
- 向上移动 4 次，到达 (22, 7)
- 向右移动 3 次，到达 (25, 7)
＞你无法穿过 NPC
你是对的。那是另一个错误。这里是一条实际上可行的路径。
玩家从 (24, 11) 开始。以下是一条可行的路径：
- 向右移动 4 次 ，到达 (28, 11)
- 向上移动 4 次 ，到达 (28, 7)
- 向左移动 3 次 ，到达 (25, 7)
总体而言，Riftrunner 对地图几何结构的直觉明显更强：
- 地图分割： 当地图被分割时，Gemini 2.5 Pro 往往会遇到很大困难。当目标与当前位置被墙壁或虚空隔开时，它的自定义寻路工具会因为当前数据中不存在有效路径而返回失败。2.5 Pro 经常将这种工具失败误判为代码本身的 bug。相比之下，Riftrunner 能够正确识别出地图只是被分割了，而工具本身是按预期工作的，从而继续寻找一条有效的路线。
- 处理未知区域： 这专门适用于“未见过”的格子（战争迷雾）。2.5 Pro 往往将无法在未揭示的格子中进行寻路视为一个不可逾越的硬性边界，而 Riftrunner 似乎能理解“ 当前未找到路径”和“无法抵达”之间的区别，认识到它只需要通过探索来揭示连接的地形结构。
- 缺口识别： 它准确识别出两个岩架之间仅一格宽、可供通行以抵达传送点的缺口。在之前的测试中，2.5 Pro 往往会将其标记为死路，并尝试回溯。
- 手动路径规划： 有趣的是，Riftrunner 往往更偏好采用逐步手动导航，而不是使用其自定义的寻路工具。尽管采取手动方式，它几乎不会撞墙——这是 2.5 Pro 经常出现的问题——并且能够通过识别其周围可行走的地块，成功应对复杂的障碍。
- 视觉理解： 我用游戏截图做了一些测试。Riftrunner 不仅能够正确识别 NPC 的位置，甚至还能准确辨认出具体的环境细节（见上文）——这两点相比 2.5 Pro 都有巨大的提升。这种高保真度为尝试基于“原始”视觉的胸背带打开了大门，减少了对直接 RAM Extraction 的依赖——这或许是迄今为止最重大的改进。
- 网格导航： 在给宝可梦起昵称时，2.5 Pro 经常错误计算键盘界面上所需的光标移动，导致越过目标字母。Riftrunner 则能够持续规划出正确的按键输入序列来输入所需文本。后续它甚至创建了一个自定义工具来自动化这一过程，而这是 2.5 Pro 从未考虑过的。
元认知与错误恢复
2.5 Pro 的一个常见失败模式是“归咎于工具”。如果一个自定义路径寻址工具返回空结果，旧模型往往会认为工具本身出了问题，并进入反复尝试调试 Python 代码的循环。
Riftrunner 展现出更高的倾向去信任工具并重新评估环境。一个明显的例子出现在上方所示的 Sprout Tower 中（ 此处为完整回合截图链接 ）：
- 模型需要到达一楼西侧的一架梯子。
- 直接路径被中央的一排墙体阻挡。
- Riftrunner 没有一味地强行寻路或反复重写导航工具，而是分析了地图结构，意识到自己实际上被“困”在了中央区域。
- 它制定了一个跨楼层的计划：先上到 2F，在二楼横向移动到另一架梯子，然后再下到 1F，进入隔离开的西侧走廊。
类似的恍然大悟时刻也发生在上图所示的桧皮镇。模型最初将一名火箭队小兵标记为封锁了通往城镇的道路。在之前的运行中，2.5 Pro 往往会将这种障碍视为绝对的死胡同。然而，Riftrunner 重新检查了地图坐标，意识到这名小兵实际上只是把守着呆呆兽之井，并正确识别出了一条可以绕过该 NPC、继续进入城镇的可行路径。 在此查看完整回合的截图。
指令遵循
对复杂系统提示的遵循有所提升，但仍不完美；Riftrunner 对提示中大量指令的关注度明显更高。
该胸背带还包含一个针对“未标记传送点”的警告系统，将相邻的两个格子标记为独立条目（因为它会独立评估每个坐标）。2.5 Pro 将它们视为不同实体，导致重复检查；Riftrunner 则能正确推断它们在逻辑上是同一个传送点。
当前限制
虽然它在推理方面表现更好，但该模型并非没有缺陷：
- 主动 vs. 被动： 和 2.5 Pro 一样，Riftrunner 在主动管理长期次级目标方面仍然存在困难。例如，它识别出了一个目标：训练一只低等级的 Onix。在战斗中，它正确地判断出在对阵 Zubat（如上图所示）时进行一次安全的 Switch 机会——公平地说，与 2.5 Pro 相比这是一个显著改进，因为后者往往会忽略这些不那么重要的目标。然而，它却未能采取更明显的主动步骤，在战斗之前就将 Onix 移动到队伍的首发位置。
- 代码编辑： 在使用 Gemini CLI 进行代码重构时，它仍然会偶尔引入语法错误，例如删除右括号。此外，在大型代码库中，它有时难以识别需要重构的正确位置，在采取行动前未能充分检查完整的上下文。
- 工具使用： 我观察到有些情况下，模型调用了自定义自动化工具（例如按键操作），但忘记设置执行该动作所需的参数，结果默认返回了“dry run”。不过，与 2.5 Pro 不同的是，它通常能很快意识到这个错误，并在随后的回合中进行自我纠正。
- 视觉能力： 即使使用了网格叠加层，从截图中估算敌方 HP 百分比仍然不稳定。这可能与模型管线或 API 中图像的处理方式有关，仍需要进一步测试。
结论
虽然在仅测试了几天之后就给出最终裁决还为时尚早，但 “Riftrunner” 正逐渐显现出其相对于 2.5 Pro 基线模型的明显优势。它展现了更强的推理能力、更高的执行水平，以及在处理复杂、开放式任务时整体上更卓越的智能表现。这次更新无疑配得上 3.0 的名号，我也非常期待它在接下来的城都地区旅程中会有怎样的表现。
