Jev 用 37 小时完成 Pokémon Red，但 Claude 帮助构建了获胜系统

Jev 在 37 小时 40 分钟内完成了 Pokémon Red，为这场需要 16,150 次模型决策的 Jev Pokémon Red 挑战画上句号。与此前耗费数周甚至数月、在类似游戏中徘徊的聊天机器人实验相比，这一结果格外引人注目。然而，这一非 LLM 系统的表面胜利有一项重要限定：开发者表示，Claude Opus 5 协助诊断了失败，并改善了 Jev 周围的决策环境。

这一差异很重要，因为 Jev 并不会观看游戏画面、记住完整历程，或直接操作控制器。一个定制的软件框架从 Game Boy 内存中读取选定数据，构建合法选项，并补充每个选项的相关信息。随后，Jev 在这些预先准备好的行动中作出选择。

据称，Claude 在系统的另一层级发挥作用。它审阅日志，找出 Jev 缺少有效信息的情境，并帮助优化呈现给决策模型的选项与指令。因此，这次挑战动摇了一项关于 AI 智能体的常见假设，但并未证明小型决策模型能够独立胜过前沿聊天机器人。

Jev Pokémon Red 挑战在 37 小时后结束

在开发者公开的设置中，这一核心结果确实成立，但其衡量的是一套完整的软件系统，而非孤立的模型。

Frigade 开发者 Christian Mathiesen 构建了这项开源实验，并于 2026 年 9 月 25 日至 26 日直播了最终通关过程。项目的公开运行数据显示，Jev 在 37 小时 40 分钟内完成 Pokémon Red。

该仓库记录了 16,150 次决策，以及约 3,920 万个输入 token。据称，单次决策通常耗时约 0.4 秒。Jev 共经历 16 次全队战败，其中 14 次发生在挑战 Elite Four 期间；它在第 15 次挑战 Elite Four 时才完成通关。

其最终队伍包括一只 83 级 Charizard 和一只 62 级 Graveler，另有 Nidoqueen、Beedrill、Haunter 和 Primeape。这些细节表明，该系统并非只是沿着预定的短路线穿过前期区域。

Jev 选择初始宝可梦、管理队伍、捕捉生物、选择招式、购买物品、治疗、训练，并决定前往何处。它还处理菜单并回答剧情提示。根据该仓库，框架并未直接写入游戏内存，也没有修改事件标记。

不过，系统获得的结构化信息远多于手持 Game Boy 的玩家。该框架从内存中读取地图、队伍信息、战斗状态、背包和屏幕文本，并将这些状态转换为附有实用信息的明确选项。

在导航方面，常规代码负责碰撞检测与 A* 路径规划；这是一种计算通往既定目的地路线的算法。Jev 并不会决定地图上的每一次单独方向键操作，而是选择更高层级的目标，由确定性软件承担大部分实际执行。

该框架还包含剧情里程碑，说明下一个目标及其位置。进度则依据游戏实际的事件标记进行验证。这让智能体获得了自己在剧情中所处位置的结构化表示，尽管隐藏物品仍然不可见。

循环保护又增加了一层机制：此前尝试过却未产生变化的选择可能会收到警告；重复失败则可能触发替代选项。系统最终还可以重新加载最近的里程碑检查点。

这些干预并不会否定这次通关。所有实用的 AI 智能体都依赖周边软件、记忆、工具和恢复逻辑。但这意味着，相关成就应被视为精心设计的智能体架构，而不是单一模型与一张卡带之间的原始竞赛。

最稳妥的结论是有限的：一个决策模型与专用环境及确定性控制机制结合后，完成了一款需要数千次连续选择的长篇游戏。该实验并未展示 Jev 在面对像素画面、无限制行动空间或没有外部状态管理时会有怎样的表现。

为什么 Pokémon 总能暴露 AI 智能体的弱点

从单回合来看，Pokémon 似乎很简单；但其漫长且相互依赖的决策链，会严厉惩罚记忆薄弱和恢复能力不足的问题。

原版 Pokémon Red 是回合制游戏，画面表现有限，且相较于快节奏动作游戏更为宽容。但它仍要求智能体在漫长数小时中持续保持目标。玩家必须探索地图、阅读对话、组建队伍、管理资源，并记住哪些障碍会阻断后续进程。

一次糟糕的战斗选择很少会直接终结整场游戏，但反复出现的小错误仍可能耗尽道具、削弱队伍，或让玩家回到治疗中心。智能体必须认识到，一个局部看似有利的行动，可能会损害其长期计划。

这种组合让 Pokémon 成为通用 AI 模型的公开测试。2025 年 2 月，Anthropic 为 Claude 3.7 Sonnet 配备了记忆、截图和按键工具。其扩展思考研究描述了持续数万次交互的游戏过程。

该实验暴露了流畅聊天对话往往掩盖的弱点。模型可以听起来逻辑连贯，却可能忘记自身位置、重复失败路线，或固守过时计划。游戏让这些错误显而易见，因为每一次决策都会改变一个持续存在的环境。

此后，其他开发者也直播了围绕 Gemini、GPT 和较新 Claude 模型构建的系统。有些最终完成了 Pokémon 游戏，但横向比较仍然困难：每个项目公开的信息不同，采用的记忆系统不同，允许的开发者协助形式也不同。

2026 年 1 月的一篇游戏智能体分析称，领先模型在这些挑战中表现缓慢、混乱且容易过度自信。该批评指出了一个比 Pokémon 更广泛的问题：即使模型对环境的内部认知并不完整，通用模型仍能生成看似令人信服的解释。

Jev 采取了不同的方法。TypeSafe AI 将其描述为 System One 模型，即针对快速、受限判断优化，而非长篇文本生成。它接受上下文和聚焦问题，随后返回选择、评分或“是/否”概率。

该公司将这些输出定位为普通软件中的组件。其Jev 介绍强调分类、路由、评分和分支，而非将 Jev 描述为可替代 LLM 一切能力的产品。

开发者一旦重构游戏，这种更狭窄的角色便与 Pokémon 出奇地契合。在大多数时刻，玩家并不是在撰写文章或构思开放式计划，而是在选择招式、目的地、购买物品，或决定是否训练。

真正的难题在于生成恰当的选项集合，并附上正确的信息。如果模型看到了所有相关选项，快速决策引擎便能保持游戏推进；如果框架隐藏了一项关键事实，速度只会帮助智能体更快地重复错误判断。

这正是 Jev 的结果会给完全围绕聊天模型构建智能体的团队带来压力的原因。它表明，许多重复性的智能体步骤并不需要昂贵、开放式的回答。专业模型可以处理预先准备好的决策，而常规代码则负责精确计算与执行。

它同样挑战了这样一种观点：一个大型模型应在一次持续对话中同时承担感知、记忆、规划、判断和控制。Pokémon 挑战将这些职责拆分为不同组件。这种分离似乎是该实验最重要的贡献。

Jev 与聊天机器人不是正确的比较对象

真正有意义的较量，是单体 AI 与分工系统之间的较量；后者将每项任务交给最适合的组件处理。

聊天机器人接受开放式提示并生成语言。这种灵活性使其能够解释陌生情境、撰写计划、理解模糊指令，并通过对话恢复。相同的灵活性也可能在软件只需作出一次选择时，带来不必要的延迟和不可靠的格式。

Jev 无法撰写新的战略文档，也不能自由描述屏幕内容。它会根据应用程序提供的问题和选项返回类型化判断。这种限制使代码更容易使用其输出。

在 Pokémon 系统中，分工是明确的。模拟器生成机器可读状态；框架转换这些状态、计算路径、估计战斗结果，并准备合法替代选项。Jev 则在刚性规则难以妥善处理的地方提供判断。

这种架构更像成熟的生产工作流，而不是聊天机器人的演示。可靠系统通常会将确定性操作与概率性操作分开。代码应计算算术、执行权限控制并验证 schema；模型则应处理固定规则无法清晰解决的模糊性。

此次挑战也体现了外部化记忆的价值。Jev 不需要不断增长的对话记录，因为框架会为每次决策重新构建当前状态描述。相关历史必须由应用程序存储，并在需要时插入。

这种设计降低了长上下文被过时计划填满的风险，也迫使开发者决定哪些事实重要。这种清晰性可以提高可靠性，但也将大量责任从模型转移给系统设计者。

通用聊天机器人掩盖了其中许多工作。开发者可以传入截图、给出宽泛目标，并要求模型决定下一步。界面看起来很简单，但模型却要承担感知、解释、规划和生成回应等工作。

这种表面上的简单性带来的成本不止于计算。当某处失败时，开发者必须判断问题究竟来自视觉、记忆、推理、工具选择，还是不清晰的指令。较长的自然语言回答或许能提供线索，却无法保证精准诊断。

类型化决策流水线会暴露不同的证据。Jev 项目记录了每次调用的完整状态、选项、概率和延迟。开发者可以检查哪些选择可用，以及模型是否表达了不确定性。

这些日志将一次智能体失败转化为更具体的工程问题：模型是否在上下文充分时仍作出了糟糕选择？框架是否遗漏了必要选项？一个正确的高层决策是否变成了错误的按键序列？每种答案都指向不同的修复方式。

这并不意味着决策模型总能获胜。开放式环境会不断引入开发者未曾预料的事件。受限选择模型无法选择应用程序从未提供的行动。

聊天机器人有时能够为陌生情境构思恢复计划。它可以理解异常文本、解释当前工具为何不足，或提出新的操作序列。Jev 的狭窄接口依赖另一个组件来完成这些工作。

Jev 与 LLM 的对比框架因此掩盖了真正成功的架构。最终完成的运行结合了快速决策模型、详细状态翻译器、路径规划代码、检查点、循环保护，以及在开发期间使用的前沿模型。

这套技术栈并未消除大型语言模型，而是将其中一个置于监督角色。

Claude Opus 5 如何引导系统走出死胡同

Claude 的参与使这一成果不再只是一次模型逆袭，而成为两层 AI 架构的证据。

据开发者通过 Google News 报道的说法，Claude Opus 5 监控日志，并协助调整提供给 Jev 的选项与措辞。据称，当决策模型陷入死胡同时，这项工作变得尤为重要。

这种干预似乎是通过开发阶段的系统修改实现，而不是由 Claude 在每个游戏回合中直接选择动作。这一区别保留了 Jev 在作出记录决策中的角色，但也让“非 LLM 系统独立在聊天机器人失败之处取得成功”的说法变得更复杂。

模型只能基于它接收到的世界作出良好选择。假设一个智能体反复走向被阻断的路径，是因为提示中没有标出所需物品。重新表述可选项或许有帮助，但更深层的修复是补上缺失的状态信息。

前沿模型很适合审查这类失败。它能够阅读长轨迹、比较重复尝试、推断缺少了哪项事实，并提出对执行框架的修改建议。这些都是涉及诊断和生成新文本的开放式任务，恰恰不是 Jev 的设计目标。

由此形成的安排类似于快思考与慢思考的区分。Jev 处理高频且边界明确的判断；当系统表现不佳，或遇到设计者未能表示的情形时，Claude 则进行频率较低的分析。

这并非只是 Jev 局限性所迫使的折中方案，也可能是一种有价值的生产模式。大多数软件事件都很常规，只有较小一部分需要更深层的解读。把每个事件都交给能力最强的模型，可能会浪费资源并引入额外延迟。

监督模型则可以分析不确定案例、审查成批失败，或重写决策策略。其改进随后可以惠及更快组件发起的数千次后续调用。

不过，在研究人员能将这次运行视为一次干净的对比之前，辅导过程仍需要更严格的文档记录。公开摘要没有提供使用最终执行框架的、受控的纯 Jev 基线，也没有量化 Claude 修改系统的频率，或每次修改带来了多少进展。

该代码库的历史中包含数百次提交，原则上使其演变过程可供检查。然而，一系列开发提交并不等同于实验协议。恰当的对比应冻结环境、定义干预规则，并在受控随机种子下进行多次试验。

还有另一层模糊性。每个智能体基准测试都包含脚手架，但脚手架可能蕴含大量任务知识。Jev 的执行框架了解剧情里程碑和地点、计算路径、估算伤害，并准备合法动作。

仅接收截图和宽泛按钮工具的聊天机器人运行，面对的是不同的问题。它必须在模型内部完成更多感知和规划。若不匹配这些接口，比较完成时间就有可能把执行框架提供的优势归功于模型。

公平的解读既不是否定，也不是庆祝胜利。Jev 在一个最终完成游戏的系统中作出了数千项具有实际影响的选择。Claude 协助工程师改进了该系统。二者共同取得了比若干知名聊天机器人演示更快的结果，但它们并未进行同一种测试。

这一结果并不能证明什么

一次成功通关无法证明决策模型通常比 LLM 智能体更聪明、更自主或更可靠。

最大的未知因素是可复现性。公开结果描述的是在周边系统持续开发后的一次完成运行。《Pokémon》包含随机遭遇、不确定的战斗结果，以及许多可能的队伍配置。

第二次运行可能采取不同路线，或在另一个地点停滞。重复实验将揭示该系统是否能够可靠通关，还是受益于一条有利轨迹。

该设置也缺少匹配的竞争者。要公平比较 Jev 与 Claude，两个模型都需要拥有相同的状态表示、选项、确定性导航、恢复规则和检查点。否则，该基准测试衡量的是模型与软件的两种不同组合。

一项有用的实验将运行三种配置。其中一种是在冻结的执行框架中使用 Jev；另一种是在保留所有其他组件的前提下，用通用模型替换 Jev；第三种则使用由监督模型审查选定失败案例的混合系统。

研究人员随后将比较多次试验中的完成率、决策数、干预次数、实际耗时和恢复行为。这些指标将显示专用模型在哪些方面带来帮助，以及前沿模型在哪些方面仍然不可或缺。

开发者对内存检查的使用也限制了更广泛的结论。读取结构化游戏状态消除了视觉感知问题。这种选择适合测试决策，但并不能证明 Jev 能够直接在杂乱的视觉环境中运作。

现实应用很少提供完美的合法选项清单。支持路由器可能收到超出所有已知类别的新问题。浏览器智能体可能遇到重新设计的页面。实体机器人可能观察到其规划器从未表示过的物体。

边界明确的模型需要为这些情形提供安全的退出路径。置信度阈值可以将不确定决策交给人工或通用模型。应用还需要一种方法，用以检测正确选项是否完全缺失。

仅靠概率无法解决这个问题。模型可能在糟糕的备选项中表达出很高置信度，因为所有可选项都是错误的。开发者必须验证动作集合，并监控下游结果。

Jev 的循环保护展示了此类保障机制的必要性。执行框架会标记无效选择、在重复失败后抽样替代选项，并在最后关头恢复检查点。这些机制防止一次糟糕判断让系统永远受困。

这也意味着，通关并非纯粹源于每一步都作出正确选择。该系统容忍错误并能从中恢复。生产级 AI 同样需要这种能力，尽管业务工作流往往没有能够逆转损失的便捷检查点。

一次错误的游戏操作可能损失几分钟；一次错误的删除、付款或客户回复则可能造成持久后果。考虑采用 Jev 式架构的开发者，必须界定哪些决策可逆，哪些决策需要审批。

这项实验对安全性的说明也很有限。消费外部来源文本的模型可能遇到操纵性指令或误导性上下文。将输出限制为类型化选择会缩小动作面，但并不能保证正确理解。

最后，《Pokémon Red》是一个已知且稳定的环境。其地图、战斗机制、菜单和剧情结构在运行过程中不会变化。这种稳定性让工程师能够构建异常详细的状态翻译器。

许多企业环境则持续变化。文档以新格式到达，政策不断演变，工具返回不完整的数据。环境越不稳定，执行框架所需的维护就越多。

因此，这次运行支持的是一种设计假设，而非普遍排名。当动作边界明确、上下文可被结构化、确定性软件能够执行结果时，专用决策模型看起来很有前景。当系统必须解读新颖事物、生成计划或修复自身表示时，通用模型仍然很有价值。

三个信号将显示 Jev 的结果是否重要

下一项考验在于：这种架构能否经受重复实验、匹配对比，以及未经过专门准备的环境。

首先，关注使用冻结版执行框架进行的、可复现的 Pokémon 通关运行。多次无人值守的完成将强化这样一种说法：该系统代表了可靠的决策循环。公开失败案例同样很有价值，因为它们将揭示状态表示中哪些部分仍然脆弱。

最有价值的发布应包括完整轨迹、固定模型版本、干预日志，以及清晰的完成定义。它应将自动恢复与两次运行之间的人为修改分开。没有这种区分，开发者就无法判断改进是来自模型，还是持续的工程工作。

其次，寻找匹配的 Jev 与 LLM 测试。两个系统应接收完全相同的状态、选择、导航代码和检查点规则。这样才能把当前的架构对比转化为可衡量的模型比较。

匹配测试可能显示，LLM 的表现相近，但响应更慢；也可能显示 Jev 擅长常规选择，却在罕见情形中失利；还可能揭示，详细的执行框架已经从任一模型身上移除了大部分智能负担。

第三，关注游戏之外、结果拥有客观标签的应用。工单路由、审核队列、文档分类、工具选择和警报优先级排序都是合理候选。这些工作流会产生团队可以依据后续结果进行审计的重复决策。

最有力的证据不会是一场夺目的演示，而是在变化输入下保持稳定准确性、具备清晰校准、低例外率，并在预设选项均不适用时安全升级处理。

对开发者而言，眼前的教训很实际。不要仅仅因为聊天界面使这种安排看似方便，就要求一个模型执行所有认知功能。应分离感知、状态、判断、执行、记忆和恢复，然后评估每个边界。

团队也可以将同样的思路用于自身的 AI 工作流，保留每项决策背后的源材料。一个可搜索的工程知识库可以帮助审查者将模型行为与规范、日志和既往修复关联起来。

Jev 的 Pokémon Red 实验之所以重要，是因为它让这种架构变得可见。一个专注模型处理了数千项选择，常规软件执行精确操作，而据报道，当系统的表示失败时，Claude 协助重新设计了该系统。

这并不是对 LLM 的干净胜利，而是支持更少、更审慎地使用它们的理由。

接下来的问题是，开发者能否在无需数月任务专属调优的情况下复现这种劳动分工。如果独立团队能够冻结执行框架、重复运行，并将这一模式带入真实工作流，Jev 所展示的将不只是完成 Pokémon Red 的一种不同寻常方式。