Gemini 玩《宝可梦》的诞生过程

本文信息来源：jcz.dev

Google CEO Sundar Pichai 在舞台上庆祝 Gemini 战胜《宝可梦》时，开玩笑地将 “API” 称为 “Artificial Pokémon Intelligence（人工宝可梦智能）”。

大型语言模型能否打败一款已有 29 年历史的电子游戏？这个问题表面上看似简单，但答案却演变成了一场深夜编码、诡异 AI 行为以及大量高关注度曝光交织而成的旋风。当我启动 Gemini Plays Pokémon 项目时，我想看看 Google 最新的 AI 是否能在其他模型曾经受挫的地方取得成功。随之展开的旅程最终迎来了 Google CEO Sundar Pichai 的点名称赞 ，也揭示了这个看似简单的问题背后究竟有多么复杂。

为什么选择《宝可梦》？乍一看，让 AI 打通一款已有 29 年历史的游戏似乎有些无关紧要，但 《宝可梦 蓝》 为 AI 推理能力提供了一个极具吸引力的测试场景。这款游戏要求进行长期规划、战略性决策，以及在开放世界中的空间导航——这些都是迈向更通用人工智能道路上的核心挑战。

从旁观者到创作者

我与这个项目的缘分始于一名充满好奇的旁观者。几个月来，我在 Reddit 和新闻中反复听说 Anthropic 的 Claude Plays Pokémon 实验。然而，当我去观看直播时，很快就发现这个模型在理解 2D、俯视角像素风格游戏方面存在严重不足。Claude 的流程缓慢且经常陷入困惑。观众指出，它很难“看清”2D Game Boy 图像中的关键细节。比如，它的 harness 并未提供哪些树是可以砍伐的信息，迫使它依赖不可靠的视觉输入，结果经常卡住。Claude 也经常把告示牌误认为是建筑入口，甚至有一次，这个可怜的 AI 还把自己的玩家头像当成了 NPC。正如之后 Gemini 2.5 技术报告中对 Gemini 的描述（同样也适用于这里）所说，该模型“难以直接利用 Game Boy 屏幕的原始像素”，并且“有必要将屏幕上所需的信息转化为文本格式”。正是由于这些不足，我开始思考：如果为它提供真正需要的信息和工具，它究竟能走多远。

Google 的 Gemini 2.5 Pro 于 2025 年 3 月发布，带来了新的可能性。它拥有 100 万 token 的上下文窗口 （相比 Claude 的 20 万 token，这是一次巨大的飞跃）以及强大的推理能力，整个 AI 社区都为之沸腾。在 Reddit 上，用户们已经开始呼吁一场对决。“需要有人把它拿来和 Claude 3.7 对比一下，看看谁能最快通关宝可梦，” 一位用户写道，并指出了 Claude 在上下文窗口方面的挣扎。你可能会惊讶地发现，这一切并没有立刻激发我的兴趣。但当时我正在寻找另一个可以做的项目，把这个想法搁置了几天之后，它对我的吸引力越来越大。2025 年 3 月 25 日太平洋时间 15:35:51，我回复了那个帖子，并 公开表态加入竞争 ：“我打算着手做这个，看看我能做到什么程度。” 就在那天下午，我开始编写后来被称为 Gemini Plays Pokémon 的 harness。

两天的原型开发

我天生是个完美主义者。无论是做后端还是前端，我都喜欢构建打磨精致的东西，经常会反复确认每一个细节是否做到像素级完美。但在创业公司度过的八年让我深刻体会到了 Minimum Viable Product (MVP) 的价值。我希望在投入更多之前先衡量市场兴趣，因此暂时搁置了宏大的计划，专注于以 快速 的方式让一个基础原型跑起来。

在两天之内，我就搭建了一个极其简陋的系统，让 Gemini 2.5 Pro 来操控《精灵宝可梦 蓝》。最初的设置尽可能简单：Twitch 直播左边展示我的终端，右边是游戏画面，没有任何花哨的叠加层。整个 harness 本身是用 Node.js 编写的，在底层，一段 Lua 脚本作为通往 Game Boy 模拟器（mGBA）的桥梁，使其能够读取游戏内存并发送按键输入。每一回合，Gemini 都会获得一张带注释的截图 ，以及一份屏幕信息的文本转储。这个注释过程随着时间推移变得更加复杂，但从一开始，其核心理念就是将视觉化的游戏世界转译为结构化的文本格式。它每次只会输出一个动作（比如 “Up”、“Down”、“A” 等），而我的代码会将其转换为一次按键操作。在这个早期版本中，Gemini 一次只能移动一个格子。当时还没有任何点评系统或上下文摘要，而这些后来都会成为这个 harness 的核心组成部分。

来自后期版本胸背带的标注屏幕示例。系统从游戏内存中提取关键信息——例如对象位置、瓦片属性以及可通行性信息——并将其以简洁的文本叠加层形式呈现。你可以看到该设计是如何从其第一版和第二版逐步演进而来的。

走到这一步需要解决大量细枝末节的技术问题：连接到模拟器、将原始像素数据转换成 Gemini 能理解的形式、对模型的 API 调用进行限流等等。但到了三月底，Twitch 直播上线了，Gemini 已经能在真新镇四处走动，完全独立地玩《宝可梦》。直播开始后，我邀请了 Claude Plays Pokémon 直播的观众来看看我的项目，观众群很快就增长起来了。更重要的是，这一切几乎不花我一分钱：Gemini 2.5 Pro 可以免费使用（虽然有一些速率限制），而我还发现通过 OpenRouter 代理使用它可以绕过严格的速率限制。在最初的几周内，Google DeepMind 的一位友好联系人主动联系了我。他们告诉我，Google 内部有很多人都在满怀热情地关注这个项目，并慷慨地为我提供了免费且不限量的 API 访问权限，于是我从 OpenRouter 切换了过去。这是一个极其令人鼓舞的信号，预示着未来会有更多可能。

发布后的第一个月几乎一片模糊。我每天在胸背带上工作超过 12 个小时，被关在办公室里，甚至让我妻子开玩笑说她几乎再也见不到我了。平时我很喜欢睡懒觉，但在最初的那几周里情况彻底改变了。我会在清晨早早醒来，大脑立刻被各种新调整的想法占满，或是迫切地想要查看 Gemini 的进展——我根本无法再睡回去。那种高度的专注是必要的，因为我很快就遇到了第一个重大障碍：模型自身的记忆。

驯服长上下文循环

Gemini 2.5 Pro 被宣传的一大“超能力”是其巨大的上下文窗口。理论上，我可以把一切 ——整个游戏历史、所有观测数据——全部喂给模型，而无需重置其上下文。我当时决心充分利用这个 100 万代币的上下文长度。然而在实践中，很快就显现出：这个模型依然存在我在其他大上下文窗口模型中见过的缺陷。

随着提示词不断增长，模型最终会陷入模式重复状态 ，为了维持重复循环而牺牲了新的决策能力。

一旦超过某个阈值（大约 10 万代币以上，这一点在 Google 的 Gemini 2.5 技术报告中也有所提及），模型就会陷入行为上的重复循环，而不是提出新的策略。

一个例子是 Gemini 被困在常青市道馆后面的一个有围栏的后院里。该区域被一排高低差的台阶“围住”，你在任何位置都可以直接跳下去离开，或者从一个小缺口走出去。经过数小时的游戏过程后，Gemini 开始一遍又一遍地原地打转，声称自己被困住了。这种情况持续了大约 8 个小时，直到我通过强制清除模型的上下文进行干预。之后，它就能够直接走下台阶离开后院，不再被困在这种重复循环中。

这次经验促使我实现了一种带总结的周期性上下文重置 。每 100 轮，系统都会将最近发生的所有事件压缩成一段简要总结，并将其连同必要的持久化信息一起，作为全新的上下文前置给 Gemini。这样一来，Gemini 不需要背负一个不断膨胀的成绩单，但也不会完全忘记之前的进展。本质上，我为它赋予了一种长期记忆的形式——代价是牺牲了一些细节保真度。抛弃那个百万 token 的窗口确实有点让人惋惜，但在这些模型真正能够在不陷入循环的情况下处理超长上下文之前，这是一个必要的权衡。

与摘要重置相辅相成，我引入了一种自我批评机制 。系统会调用一个新的、临时的 Gemini 实例，并赋予其专门的“批评者”人格。这个新实例会分析主 AI 的性能历史，重点关注糟糕的策略、毫无意义的目标，或潜在的幻觉。此外，它还会为 AI 当前的主要目标生成一份游戏通关指引，解释接下来应采取的步骤，完全基于模型自身的训练数据得出。这个独立批评实例的输出随后会被反馈到主 AI 的上下文中。这是一把双刃剑：有时这些批评很有洞察力，能帮助 Gemini 走出僵局；而在其他时候，批评者会在生成的指引中产生错误的幻觉，比如指示主 AI 向东南方向寻找出口，而实际上出口在西边。但总体而言，这种额外的反思让 AI 变得更加稳健。

另一个用于对抗幻觉的调整涉及宝可梦招式管理。起初，Gemini 有一个坏习惯： 为实际上已经完全恢复的招式幻觉出 0 PP（Power Points）。例如，即使刚刚访问过宝可梦中心（会恢复所有 PP），它也可能拒绝使用某个招式，因为在其较长的上下文中，它记得该招式之前被耗尽过。模型过度信任了自己的记忆。我尝试过基于提示词的修复（指示 Gemini“不要假设招式是 0 PP；始终查看屏幕”），但幻觉依然存在。最终，我通过直接注入真实数据解决了这个问题：我从游戏的 RAM 中提取每只宝可梦当前的招式和 PP，并将其包含在 Gemini 的提示词中。有了提示词里的实时 PP 信息，Gemini 不再担心那些不存在的空招式，并且在可用时开始使用最强的攻击。

为确保在清空上下文后 Gemini 仍能记住其目标，我利用了现有的、简单但极为高效的 goals system。该胸背带引导 Gemini 设定主要目标、次要目标和第三目标，并在每次重置后将这些目标重新注入到上下文中。

• 主要目标： 主要的推进目标，例如获得下一个道馆徽章。
• 次要目标： 一种直接促成主要目标的支持性目标，例如寻找通行所需的关键物品。
• 第三目标： 一种在条件允许时可顺带完成的机会性目标，比如探索路线的剩余部分，或捕捉一只新的 Pokémon。

如果没有这些，AI 很可能会在下一步行动上犹豫不决，尤其是在流程不那么线性的中期阶段。

这些早期的障碍强化了我对该项目的核心理念。不同于 Claude Plays Pokémon 实验似乎侧重于测试原始模型的极限，我希望构建的是一个能够通关游戏的智能体——不是通过手把手引导，而是通过对 harness 的整体改进来实现。

我的目标并不是给 AI 手把手地提供完整攻略，而是为它提供更好的工具，让它能够自己解决问题。

绘制世界：赋予 Gemini 空间记忆

AI 在玩电子游戏时最大的限制之一是缺乏心智地图 。Claude 和 Gemini 项目都受到这一问题的困扰，因为 AI 只能感知当前屏幕上直接呈现的内容。Claude 之前曾尝试生成 ASCII 地图，但效果并不理想。人类玩家会在大脑中构建自己探索过区域的内部地图，而语言模型在默认情况下并不具备这种空间记忆能力。这就意味着， 每一次 Gemini 进入类似迷宫的区域时，都仿佛是第一次进入——它会漫无目的地游走，忘记自己去过哪里，常常迷路，或者不断原路返回。

为了解决这个问题，我实现了一个 Map Memory 系统。本质上，我给 Gemini 添加了一个类似战争迷雾的小地图，该地图在整个流程中持续存在，记录它曾经看到过的每一个格子。在内部实现上，这些信息以已发现格子的 JSON 列表形式存储；而在 Twitch 直播中，我将其可视化为一个俯视地图，随着 Gemini 的探索逐步被填充。（Gemini 自身从未看到渲染后的地图图像——它只接收到一份关于已知地形的文本表示。）这样一来，当 Gemini 再次进入 Viridian Forest 时，它就“知道”哪些路径已经尝试过，哪些区域仍需要进一步探索。

在此基础上，我引入了可到达但尚未探索的地块这一概念。每个回合，胸背带都会分析地图数据，并提供一份坐标列表，标明从 Gemini 所在位置当前可以到达、但尚未探索的地块。我最初将这些信息作为一种温和的提示注入到 prompt 中，希望能鼓励 AI 系统性地开拓新区域，而不是陷入循环。然而，Gemini 有时仍然声称自己被困住了，尽管地图上实际上还有它尚未走过去的未见区域。说实话，看着它放弃并考虑采取极端措施（比如故意让自己的队伍黑屏以在宝可梦中心复活）确实令人沮丧，而距离它所需的出口其实只差几步之遥。

解决方案是让 Gemini 对探索变得痴迷 。我在它的提示中大幅提升了一条指令，要求它揭开地图上的每一块地块 ，并将这一优先级甚至置于其主要目标之上，比如击败下一个 Gym。只要在可到达的区域还有未探索的战争迷雾，那就是头号优先事项。这个改变具有变革性——Gemini 几乎从不再说自己卡住了。它会勤勤恳恳地搜遍每一个角落，而当某一层的整张地图都被揭示后，它自然就拥有了和人类一样多的信息，可以找到出口或关键商品。这种外部化的空间记忆，正是克服其导航能力限制的关键。

说实话，这个方案有时显得有些简单粗暴。AI 会养成一种糟糕的强迫症，不停抱怨自己还不能进入某个关键建筑，只因为地图另一端还有一块毫不重要的地块没有探索。虽然有效，但并不优雅。后来在 Pokémon Yellow 的流程中，我通过放宽这一限制找到了更好的平衡，在不引发这种强迫行为的情况下，效果同样出色。

代理人委员会

即使拥有完整地图可供使用，Gemini 在某些需要提前很远进行规划的谜题上仍然表现吃力——尤其是火箭队基地（地下三层）中臭名昭著的旋转地板迷宫，以及胜利之路里的推石 Strength 谜题。这些谜题之所以棘手，是因为正确路径往往是反直觉的 。例如，在火箭队基地的旋转迷宫中，显而易见的视觉目标（楼梯）就在附近，但如果你直线朝它走是根本无法到达的 ；你必须先反向前进，穿过一整套把你绕来绕去的传送带。一次又一次地，我看到 Gemini 掉进这个 “吸引子” 的陷阱——它看到目标，就试图径直冲过去，结果被机关送回起点。这个 AI 就是不会退一步，去规划一条更长、更迂回的路线。

月见山中的一个经典“吸引子”解谜。直线路径（红色所示）被封锁。正确的路径（洋红色所示）需要先远离目标，找到通向出口的循环路线。

问题的一部分在于，Gemini 并未完全理解旋转地块的运作方式。这些地块会让你不由自主地朝某个方向滑行，直到撞上终点为止。它会反复踏上同一个旋转地块，似乎以为自己会被送往不同的方向。为此，我在地图记忆中加入了针对 旋转路径 的特殊注释。这包括预先计算 Gemini 已经完整探索过的任意旋转序列的终点坐标，使它能够以确定性的方式了解每一个 已见过 的旋转地块会产生什么效果，而不必再去猜测。

但即便理解了这些机制，这些迷宫中的 路径寻找问题 依然并非易事。我并不想简单地硬编码一个解决方案，或给它一个自动移动玩家的典型路径寻找算法。我仍然希望 Gemini 能够 自己找出路径 ——只是，也许它可以借助一些额外的脑力。因此，这促成了胸背带的一次重大升级：引入了专门的 规划代理 。

我创建了一个工具，让 Gemini 本质上生成一个次级的 Pathfinder Agent（另一个 Gemini 2.5 Pro 实例），带着一块空白画布和单一的目标：找到从 A 点到 B 点的路径。当 Gemini 遇到一个它无法轻易解决的迷宫（或者根本不明白为什么不能穿墙而过）时，它就可以调用这个 Agent，并向其提供当前的地图布局和地块机制。

随后，系统提示该 agent 在脑海中模拟一个最优的路径寻找算法 来寻找路线。在脱离完整游戏上下文的干扰、独立思考的情况下，agent 会规划出一条符合 A* 或 Breadth-First Search 的路径——这是纯粹推理能力的惊人展示。我第一次尝试这种方法时，Pathfinder agent 一次性解出了 Rocket Hideout 的 B3F 迷宫 ，而这个任务此前曾让主 agent 困扰了好几天。

这次成功仿佛魔法一般，强有力地展示了 Gemini 2.5 Pro 的推理能力。

当然，这并非万无一失。在那些需要长距离绕行的复杂地图上，即便是 Pathfinder 智能体有时也会“幻想”出捷径（例如：“直接穿过这面墙走！”），或者说服自己认为一排不可通行的地图格子其实是一处可以跳下去的台阶。但总体而言，它极大地提升了 Gemini 处理复杂导航的能力。我在这里观察到一个有趣的规模差异：Gemini 2.5 Pro（大型模型）能够推理出相当长的路径，而较小的 Gemini 2.5 Flash 模型（我在一次简短的对照测试中使用）在同样的任务上往往会失败。Flash 模型虽然速度显著更快，但能力明显较弱，在导航方面表现吃力，在我的本地测试中始终没能成功走出月见山。

Pathfinder 代理的成功突显了一个关于评估现代 AI 的关键要点。模型在解读原始游戏 Visuals 方面的难度重新定义了挑战本身。通过向 AI 提供一种文本化的、“战争迷雾”风格地图，用于记录已探索的地块，我们绕过了不可靠的视觉系统，为其呈现了一种不同类型的测验。问题从“你能看到路径吗？”转变为“在给定一张结构化地图的情况下，你能否解读数据并推导出正确的路径？”这本身就是一项复杂的任务，要求模型基于文本信息对空间关系进行推理。Gemini 2.5 Pro 与更小的 Gemini 2.5 Flash 之间清晰的性能差距——前者能够解决复杂迷宫，而后者在同样的 harness 下表现吃力——表明这种方法有效测量了模型的核心推理能力。通过为 AI 提供更好的工具来隔离其推理能力这一原则，是一个基础性理念，我们后来在此基础上进一步扩展，甚至允许 AI 自行为导航方案进行编程。

另一个主要的游戏内挑战是力量巨石解谜 （可以把它想象成类似 Sokoban 的解谜玩法，需要推动岩石压到机关上）。Gemini 在第 1 次 Run 中实际上独立解决了胜利之路中大多数的巨石谜题，但在其中一个特别充满挑战的谜题上卡住了，这个谜题需要从很远的地方推动一块巨石。AI 无法在逻辑上意识到这块特定的、距离较远的巨石才是正确的选择。我相信如果给它足够的时间，它最终可以通过反复试错解开这个谜题，但为了观众的观赏性做出了取舍。

让 AI 束手无策的冠军之路巨石解谜。必须将正确的巨石从相当远的距离（红色所示路径）推动，才能到达 Switch。

我决定在这里应用与 Pathfinder 相同的思路：一个专门的 Boulder Puzzle Strategist 代理。这个代理会基于当前巨石、洞口和开关的布局，模拟哪些巨石能够到达哪些开关，确定正确的配对关系，并规划推动的操作顺序。

我甚至让 Gemini 2.5 Pro 帮忙为这个 agent 编写 prompt。我描述了问题，大致是这样说的：“为一个 LLM 编写 prompt，用来解决类 Sokoban 谜题，其中需要把巨石推到开关上”，然后让模型起草一个 prompt，我再对其进行优化。结果是得到一个能够一次性解决这些多步骤谜题的 agent，从而让主模型免于进行可能多达数百次的试错操作。就像 Pathfinder 一样，它并不完美，有时会声称不存在解决方案，但相比之前已经是极大的提升。实际上，它将原本可能需要无数小时反复推石头、重置、再重来的过程，压缩成了一次集中的推理爆发和一份清晰的行动计划。

当 《Pokémon Blue》的首次完整通关结束时，这个 harness 已经演化为一个复杂的支持系统。下面是最终架构的高层概览：

Gemini 2.5 Pro 在该脚手架的赋能下，能够在无需人工手把手引导的情况下通关整个游戏并克服每一个障碍。2025 年 5 月 2 日，在累计约 813 小时 的游戏时间后，Gemini 击败了四天王，成为关都地区的宝可梦联赛冠军。任务完成——然而，这仅仅是一个开始。

胜利与验证

当 Gemini 最终在《Pokémon Blue》中滚动出制作人员名单时，Twitch 聊天室、Discord 和 Reddit 社区一片沸腾。但这场庆祝并不只局限于常见的 AI 圈子。令我惊讶的是，这个项目还引起了一些 非常 高调旁观者的关注。Google 的 CEO 桑达尔·皮查伊一直在悄悄关注这场 AI 宝可梦的传奇故事。在 Gemini 夺得冠军赛的那天，皮查伊 在 X（Twitter）上得意地发文 ：“多么精彩的结局！Gemini 2.5 Pro 刚刚通关了《Pokémon Blue》！特别感谢 @TheCodeOfJoel 创建并运营了这场直播，也感谢一路为 Gem 加油的所有人。” 看到 Google 的 CEO 公开点名感谢我，感觉十分超现实。（他甚至在 Google I/O 2025 上为这个项目打了个广告，还打趣地称其为“Artificial Pokémon Intelligence”。）

其他 Google 领导层成员也在一旁加油助威。Google AI Studio 的产品负责人 Logan Kilpatrick 随着 Gemini 的推进不断在推特上更新进展 ——他曾指出，Gemini 仅用约 500 小时就拿下了第 5 个 Gym 徽章，而“目前表现次优的模型只有 3 个徽章（尽管使用了不同的 agent harness）”。这个“另一款模型”指的是 Anthropic 的 Claude，仍停留在游戏的更早阶段。媒体也捕捉到了这场 AI 对决：《TechCrunch》和《India Today》等媒体都刊登了关于“Gemini vs Claude”的报道，并探讨了将《宝可梦》作为 agentic AI 基准测试的更广泛意义。我甚至在 Google 官方的 Gemini 2.5 技术报告中获得了署名致谢——他们专门用整整一节来介绍 Gemini Plays Pokémon，将其作为长时程推理的案例研究，并将该项目作为复杂 agentic 工具使用的示例进行了引用。

在一片热闹声中，我之前确实在我的直播常见问题中提醒观众，不要过度解读“Gemini vs Claude”的叙事。没错，Gemini 2.5 Pro 最终通关了游戏，而 Claude 还没有，但比赛条件并不公平。Gemini 受益于我定制的胸背带，里面包含了许多额外的工具和信息，而 Claude 的配置则要简陋得多。“请不要把这当作衡量 LLM 玩 Pokémon 能力的基准，”我在直播页面上写道——当它们周围的 脚手架 不同时，直接进行模型对模型的比较是很棘手的。不过，这次经历确实凸显了对这类评估而言，一个中立、标准化平台的必要性。最终，这两个 AI 代理都需要大量帮助（以那些外部工具和输入的形式）才能应对像 Pokémon 这样的游戏。在我看来，真正的成就并不是 Gemini 比 Claude “更聪明”，而是展示了在合适的支持下，AI 可以在数百小时内应对复杂、开放式的任务，经受挫折并最终取得成功。

话虽如此，通关《宝可梦 蓝》（而且还是两次！）的满足感依然难以言喻，而且我们在过程中还意外地创造了一些“首次”：

• 在第二次通关过程中，Gemini 在双子岛遭遇了一个鲜为人知的故障——基本上成为第一个自主发现《宝可梦》代码中漏洞的 AI。
• 它还因为训练数据而产生了有趣的幻觉 ，一度坚信自己需要找到 “TEA” 来给一名口渴的守卫（这是另一个《宝可梦》游戏中的机制，并不存在于《宝可梦 蓝》中）。
• 我们甚至目睹了社区所称的 “model panic”。当它的宝可梦体力偏低时，AI 的推理能力会下降，导致它忘记自己那些高级工具，并执着于一些简单、且往往无效的逃生策略。

只有一只健康的宝可梦时一切都很正常。但一旦加入低 HP 的队伍成员，就会触发恐慌，尽管那只健康的宝可梦并没有发生变化。这种非理性的恐惧常常导致它的推理能力崩溃。（梗图来源：Discord 上的 mrcheeze_）

顺带一提，为了修复跨游戏的幻觉，我在第二次运行时重新提示 AI，让它扮演一位新手玩家。这解决了一个问题，却又制造了另一个问题：它持续地误以为 Full Heal 可以恢复 HP。（公平地说，这些名字确实容易混淆：Full Heal 只治疗异常状态，而 Full Restore 才是能够恢复 HP 的物品。）这个单一的错误引发了一次完全没有必要的 100 小时循环：不断输给四天王，然后回到冠军之路继续练级。这也让人明白，提示工程有时是一门微妙的艺术——一句指令就可能在下游产生复杂且难以预测的后果。

截至 2025 年 6 月 9 日，第二次完全自动化的运行（使用最终版胸背带，且我完全未进行任何手动干预 ）已经完成——而且速度快得多，游玩时间约为 406 小时 ，大约是开发运行时间的一半。Gemini 已经真正成为了一名宝可梦大师，而我也准备好迎接下一个挑战。

超越《宝可梦 蓝》：赋予 Gemini 更多自主性

在下一个阶段，我把目标瞄准了 Pokémon Yellow——具体来说，是一个提高难度的 ROM Hack，名为 Pokémon Yellow Legacy。Yellow 在底层机制上与 Blue 非常相似，这意味着我可以复用大量的 harness，但这个模组让体验变得更有意思：全部 151 只 Pokémon 都可以捕捉，训练师更加强力，并且还有一个可选的“Hard Mode”，会强制等级上限，并采用严格的不可换人战斗规则。由于 Gemini 已经通关过两次原版游戏，我启用了 Hard Mode 来给它带来一次全新的挑战。这次 Yellow 的流程既能作为娱乐填充（在我开发更大型升级时给观众提供一些有趣内容），同时也能充当新想法的测试平台 。

在 Yellow Legacy 流程中，我们还希望提升战斗在战略层面的要求。在标准流程中，战斗有时可能只是通过反复刷级、等级高于对手即可取胜。然而，本版本游戏中的“困难模式”引入了一系列限制，使战斗真正成为对战术技能的考验。严格的等级上限防止过度升级，而“定场”战斗模式则取消了对手倒下后可以更换出战宝可梦的优势，使得单纯依靠数值碾压的方式失去效果。取而代之的是，AI 必须进行更复杂的推理——谨慎管理队伍构成、属性克制关系以及招式选择，在公平条件下击败对手。这让每一场关键战斗都变成了一道高风险的解谜题，对模型的战略推理能力进行严格评估。

这一阶段的核心理念是转移权力平衡，并提升 Gemini 在开发解决方案方面的自主性 。蓝色阶段已经证明了强大脚手架的作用；而到了黄色阶段，问题发生了演变：AI 能否在更少支持的情况下学会取胜？目标是超越预先构建的解决方案，观察 Gemini 是否能够依靠自身涌现出的策略，在较弱的辅助框架下进行补偿。

为此，我从根本上更改了工具集。我移除了用于寻路和巨石谜题的专用代理，以及大多数环境提示，例如地块可通行性和严格的探索指令。取而代之的是，我引入了一套开放式的 meta-tools。Gemini 现在可以通过 define_agent 定义自己的迷你代理，使用 run_code 执行脚本，放置带标签的地图标记，并在记事本中存储长期计划。这为 Gemini 提供了识别子问题、制定计划并从零开始编写自身解决方案的构建模块——这是朝着真正的代理式行为迈出的重要一步。

这种新方法从根本上改变了评估的性质。例如，当面对一个复杂的导航问题时，Gemini 现在可以编写并执行自己的 Python 代码来生成路径。这展示了一种更高阶的能力，因此评估重点转向测试模型是否能够对问题有足够深入的理解，从而自行设计并实现解决方案，而不是依赖预先构建的工具。

在实践中，由于内置的代码执行工具无法存储和执行可复用的脚本，Gemini 开始将代理创建工具用作一种变通方案来实现这一目的。为此，我添加了一个专用的自定义工具功能，使 Gemini 能够构建一个属于自己的可复用函数库。这个改动让 define_agent 命令回归其最初的用途：为诸如战斗策略等专注或高度复杂、以推理为主的任务创建代理。看到 AI 通过编写新的提示和代码来有效地扩展自身能力令人着迷——这真正让人一窥 AI 自主性的未来。

另一个实验是引入了一个 “世界知识图谱”。其想法是通过允许 Gemini 记录区域之间的连接，为其提供更强大的世界地理感知。然而在实际运行中，这个代理经常在未检查是否已存在的情况下浪费时间添加节点和边，最终也未能有效利用这些数据进行导航。由于该功能在初始形态下并未带来显著收益，后来被移除。尽管最终并不实用，但在这样的实验性项目中，这种迭代仍然具有价值。

为了提高这一 AI 自主性新阶段的透明度，我对直播界面实施了多项相应升级。新增了一个 UI 面板，用于展示 Gemini 所定义的活跃智能体。为了提供更深入的洞察，我搭建了一个公共 Git 代码仓库 ，观众可以在其中查看底层代码和记事本差异，这些内容都会实时提交。直播还进行了视觉重构，包括为 Gemini 设计了新的头像，以及为其角色扮演人格添加了一个悬浮的“语言响应”气泡，让整个直播更具个性。

直播 UI 的演进：从最初的简单终端和游戏画面（左），发展为包含智能体、状态等自定义面板的功能丰富界面，以及更加精致的设计（右）。

在我写下这篇文章时，Pokémon Yellow Legacy 的流程仍在 进行中 ，而 Gemini 正在借助其强化后的自我驱动 harness 稳步赢得徽章。这里的前期工作也在为下一次重大飞跃做准备：Pokémon Crystal。最终目标不仅仅是通关基础游戏，而是挑战更具不确定性的内容，比如高难度 romhack 或 randomizer，其中许多都是基于 Crystal 构建的。第二世代游戏范围的扩大（更大的世界、更丰富的剧情，以及昼夜循环等新机制）意味着，相比从 Pokémon Blue 过渡到 Yellow Legacy，这一次 harness 需要进行更加大量的适配工作。我已经启动了一个 次级 Twitch 频道 ，用于在 Crystal 中对 Gemini 进行早期测试，看到 AI 在一个更庞大的世界中探索，既令人兴奋，也让人感到压力。计划是在 Yellow Legacy 结束后，将主项目全面转向 Crystal（以及基于 Crystal 的 romhack）。借助这些新的 meta 工具和世界建模能力，我对 Gemini 同样能够成为城都地区的冠军充满信心。

项目时间线

该项目从一开始就在直播中进行开发，这是一段涉及两个主要代码仓库的大型工作旅程。作为项目核心的后端 harness，累计完成了 2,300 多次提交，新增代码超过 63,000 行，删除约 31,000 行。前端 UI 虽然规模较小，但仍然需要 200 多次提交，新增代码超过 30,000 行，删除约 12,000 行。这张表从宏观层面概述了这一演进过程，展示了 AI 功能和直播 UI 改进是如何并行开发的。

期末思考

在短短几个月内，这个项目从一个简单的脚本演进为一个现实世界的展示，体现了当你将长上下文、多模态感知和创造性工具使用相结合时，现代 AI 模型能够做到什么。这是一次强大而务实的前沿技术实战课。我们看到像 Gemini 这样的模型仍然存在明显的弱点 ——它们可能陷入思维循环、误读简单的视觉信息，或臆造并不存在的目标。但我们也学会了如何通过巧妙的脚手架设计来对抗这些弱点。有时，突破并非来自更好的模型，而是来自对任务更好的框定，比如“探索每一个地块”的指令，或是为 AI 提供一个全新的思考上下文，比如 Pathfinder agent。

围绕 AI 的脚手架在处理复杂任务时与模型本身同样重要。

这是我从该项目中得到的一个核心收获。通过逐步为 Gemini 提供合适的工具和引导，我亲眼见证了它完成了一件相当惊人的事情：它通过规划、坚持和解决问题，独立从头到尾玩完了一款 30 小时的 RPG。曾经只存在于科幻小说中的场景，如今已变成任何人都可以收看的 Twitch 直播 。

这次深入探讨只是触及了为这个项目投入的无数编码、调试与探索时光的冰山一角。回首望去，从深夜里的实验到一个获得 Google 自家 CEO 认可的项目，这段旅程显得如梦似幻。这也提醒我们，即使是儿时的游戏，也能成为探索 AI 未来的前沿阵地。

我还要向 Discord 和 Reddit 社区中那些敬业的成员致以巨大的感谢，他们一丝不苟地记录日志并跟踪了 Gemini 的进展。当然，如果没有 Google DeepMind 的慷慨支持，这一切都不可能实现——正是他们提供的免费、无限制 API 访问为整个直播提供了动力。

对我而言，这只是一个开始。长期愿景是在这项工作的基础上持续拓展：继续进行公开直播，挑战未来世代的 Pokémon，以及其他回合制策略游戏，比如 Fire Emblem，同时也尝试像 Super Mario Bros. 这样的实时平台跳跃游戏。但正如这个项目所展示的，如果没有公平的竞技环境，就很难对智能体的表现进行比较。为此，也为了以标准化的方式继续推进这些长时程评测，我正在成立 ARISE 基金会 （Agentic Research & Intelligence Systems Evaluation Foundation）。该基金会将开源 Pokémon Blue 运行所使用的 harness，并将在可预见的未来成为我工作的重点。前路漫长，但我希望你能与我一同踏上这段旅程。