JEV 玩贪吃蛇每秒 3 步模型到底判断了什么我做了一个JEV 玩贪吃蛇的案例蛇每走一步就把当前局面变成一道选择题让判断模型给出方向和四个选项的概率。贪吃蛇适合拿来试这个思路因为问题很小结果却很直接——选完以后下一格会不会撞、会不会吃到食物马上就能看到。如果你也想从这个实验继续找 JEV 的其他用法文中附了一个 JEV 教学 Skill夸克网盘下载。它按场景整理了游戏、浏览器操作、模型路由等案例带截图和原帖链接放进 Agent 的技能目录后可以按自己的任务去找相近的做法。这个包是延伸阅读不含本文的贪吃蛇源码。这次实跑用本地 Laya 实现 JEV 式的state Choice → 选择 概率没有调用远程 JEV API。速度调到每秒 3 步后录了下面这段 GIF。录制约 10 秒蛇走了 30 步、吃到 1 个食物得分 100。页面当时显示 31 次请求平均往返约 220 毫秒超时和接口错误都是 0。这是一次运行片段不是胜率测试。调用数比已执行步数多 1也不能直接理解为“多走了一步”控制器执行完一步就会开始准备下一步的问题。为什么这里用 Choice而不是让模型自由回答JEV 的判断结构可以写成“state 问题 → 判断 概率”。贪吃蛇的一步恰好可以拆得很小state 说明现在的局面问题是“这四个方向选哪个”答案被限制在四个候选中。我们需要的是下一步动作不需要模型写一篇路线分析。但“把棋盘交给模型”和“把判断后的局面交给模型”是两种完全不同的实验。这版默认模式走的是第二种。浏览器把蛇身、方向和食物位置交给游戏代理代理用代码排除撞墙、撞身体和掉头的方向再计算每个合法方向走过去后的食物距离、可达空格和死胡同风险。可达空格由 flood fill 算出死胡同判断还检查能否沿着蛇尾出去。这些数字和标签都是程序算的不是模型看图算的。代理随后才发起 Choice。真实代码里最关键的是下面几行const request buildRequest(game, analyze(game), strategy); const res await client.systemOne({ state: request.state as never, questions: { move: choice(request.instructions, request.criteria as Recordstring, string) }, });拆开一条真实的输入和输出从logs/laya-trace.jsonl取出的一次原始输入如下。四个键slot 1/2/3/4在游戏里固定对应上、下、左、右。{ state: Safe route: yes. Food reachable through empty cells: yes., questions: { move: { type: choice, instructions: Choose the best safe move toward food., criteria: { slot 1: Poor. Safe. Longer route., slot 2: Good. Safe. Shortest route to food., slot 3: Worst. Blocked. Collision., slot 4: Poor. Safe. Longer route. } } } }返回的answers.move关键字段是{ choice: slot 2, probabilities: { slot 1: 0.0774, slot 2: 0.6358, slot 3: 0.059, slot 4: 0.2278 }, confidence: 0.286 }这一回模型选slot 2代理把它翻译为“向下”。这条记录还有input_tokens78、output_tokens0接口给的是选项分数不是一段生成的路线分析。0.6358是这个选项在本次回答里的概率confidence0.286是接口另一个字段。它们不能合成一句“模型有 63.58% 的把握不会死”。概率没有经过本游戏的生存率校准也没有自动证明这个选择能带来长期高分。这条输入还有一个更重要的细节slot 2的文字已经写着“安全、到食物的最短路线”。程序先用如下评分规则挑出偏好的方向再把好坏写进选项模型在这版模式里主要是在读这些等级标签const score (f: MoveFacts) (f.eats ? 1000 : 0) - 10 * (f.foodDistance ?? 99) 0.01 * f.reachable;吃到食物给了很高的优先级距离每缩短一格加 10 分可达空格只作很小的平局修正。这个规则是代码定的。把这段 GIF 说成“模型独立看懂棋盘、规划出了路线”就超过了证据。为什么把up/down改成slot 1-4这不是为了让字段看起来整齐。项目的排查记录发现直接用up/down/left/right当选项键时回答会受方向英文词本身影响。换成中性的slot才能更清楚地测它有没有按选项描述来选。标签里的Best/Good/Poor/Worst也有作用模型收到的是明确的等级而不只是四段杂乱的棋盘数据。项目此前的一次283 个局面对照记录同一份未微调权重、同一运行方式下“完整棋盘 事实型选项”的命中率是 34.3%“短 state 字面标签”是 64.7%。记录中的输入长度也从约 404 token 缩到 63 token耗时从约 256 毫秒降到 54 毫秒。这组数字来自此前的离线排查不是根据这段 GIF 重新测出的数也不是整局游戏的胜率。排查笔记还提到决策头会截断过长的输入。因此34.3% 不能直接当成模型在完整读取棋盘后的能力上限。短提示一方面减少了输入长度和等待时间另一方面也把答案线索提前写进了标签。结果变好不等于模型已经学会走棋。模型的选择不一定等于蛇最后走的方向每步约 330 毫秒。控制器在这段时间内等模型回答到点就执行已有的选择若回答没赶上会用代码保底。只有一个合法方向时也直接由代码走不必请求模型。即使模型及时选出一个方向安全覆盖还会检查它是否会撞或进死胡同若不安全就从安全方向里选概率最高的那个。所以复盘时至少要分清三件事模型原始选择、程序最终执行的方向、这一步后游戏发生了什么。只看最后的得分没法知道究竟是模型选对了还是保底与安全覆盖救了它。这版把每次原始输入输出写入 trace游戏记录另存最终动作、耗时、超时和安全覆盖标记就是为了能把它们分开看。本地部署只补充与判断有关的部分Laya 的 GGUF 主模型由 llama.cpp 提供逐 token 特征独立的 head 文件负责给 Choice 选项打分Python 桥接服务用 Laya 的 tokenizer 生成 token ID把两部分接起来。模型文件包括 GGUF、决策头和 laya_head.py。llama.cpp 这边启用了--embeddings --pooling none --ctx-size 8192 -b 2048 -ub 2045只加载 GGUF 而没有决策头不会得到上面这样的四项概率。下一步怎么验证它真的在“看棋盘”我会把测试拆成两部分。第一部分固定一批相同的棋盘局面分别让模型看短标签和完整棋盘比较每步是否选到安全且合理的方向同时统计各方向召回率和概率是否可信。这里不要在完整棋盘组预先写入Good/Poor否则还是在考它读标签。第二部分才是整局游戏固定初始随机种子分别跑代码基线、当前紧凑提示和完整棋盘提示。因为不同策略走几步后遇到的局面就会分叉整局结果要单独报告食物数、存活步数、死亡原因、回答耗时、超时次数和安全覆盖次数。这样才能回答一个更具体的问题把这个判断模型放进游戏究竟比代码本身多带来了什么。如果你也想从这个实验继续找 JEV 的其他用法文中附了一个 JEV 教学 Skill夸克网盘下载。它按场景整理了游戏、浏览器操作、模型路由等案例带截图和原帖链接放进 Agent 的技能目录后可以按自己的任务去找相近的做法。这个包是延伸阅读不含本文的贪吃蛇源码。
JEV 玩贪吃蛇每秒 3 步模型到底判断了什么我做了一个JEV 玩贪吃蛇的案例蛇每走一步就把当前局面变成一道选择题让判断模型给出方向和四个选项的概率。贪吃蛇适合拿来试这个思路因为问题很小结果却很直接——选完以后下一格会不会撞、会不会吃到食物马上就能看到。如果你也想从这个实验继续找 JEV 的其他用法文中附了一个 JEV 教学 Skill夸克网盘下载。它按场景整理了游戏、浏览器操作、模型路由等案例带截图和原帖链接放进 Agent 的技能目录后可以按自己的任务去找相近的做法。这个包是延伸阅读不含本文的贪吃蛇源码。这次实跑用本地 Laya 实现 JEV 式的state Choice → 选择 概率没有调用远程 JEV API。速度调到每秒 3 步后录了下面这段 GIF。录制约 10 秒蛇走了 30 步、吃到 1 个食物得分 100。页面当时显示 31 次请求平均往返约 220 毫秒超时和接口错误都是 0。这是一次运行片段不是胜率测试。调用数比已执行步数多 1也不能直接理解为“多走了一步”控制器执行完一步就会开始准备下一步的问题。为什么这里用 Choice而不是让模型自由回答JEV 的判断结构可以写成“state 问题 → 判断 概率”。贪吃蛇的一步恰好可以拆得很小state 说明现在的局面问题是“这四个方向选哪个”答案被限制在四个候选中。我们需要的是下一步动作不需要模型写一篇路线分析。但“把棋盘交给模型”和“把判断后的局面交给模型”是两种完全不同的实验。这版默认模式走的是第二种。浏览器把蛇身、方向和食物位置交给游戏代理代理用代码排除撞墙、撞身体和掉头的方向再计算每个合法方向走过去后的食物距离、可达空格和死胡同风险。可达空格由 flood fill 算出死胡同判断还检查能否沿着蛇尾出去。这些数字和标签都是程序算的不是模型看图算的。代理随后才发起 Choice。真实代码里最关键的是下面几行const request buildRequest(game, analyze(game), strategy); const res await client.systemOne({ state: request.state as never, questions: { move: choice(request.instructions, request.criteria as Recordstring, string) }, });拆开一条真实的输入和输出从logs/laya-trace.jsonl取出的一次原始输入如下。四个键slot 1/2/3/4在游戏里固定对应上、下、左、右。{ state: Safe route: yes. Food reachable through empty cells: yes., questions: { move: { type: choice, instructions: Choose the best safe move toward food., criteria: { slot 1: Poor. Safe. Longer route., slot 2: Good. Safe. Shortest route to food., slot 3: Worst. Blocked. Collision., slot 4: Poor. Safe. Longer route. } } } }返回的answers.move关键字段是{ choice: slot 2, probabilities: { slot 1: 0.0774, slot 2: 0.6358, slot 3: 0.059, slot 4: 0.2278 }, confidence: 0.286 }这一回模型选slot 2代理把它翻译为“向下”。这条记录还有input_tokens78、output_tokens0接口给的是选项分数不是一段生成的路线分析。0.6358是这个选项在本次回答里的概率confidence0.286是接口另一个字段。它们不能合成一句“模型有 63.58% 的把握不会死”。概率没有经过本游戏的生存率校准也没有自动证明这个选择能带来长期高分。这条输入还有一个更重要的细节slot 2的文字已经写着“安全、到食物的最短路线”。程序先用如下评分规则挑出偏好的方向再把好坏写进选项模型在这版模式里主要是在读这些等级标签const score (f: MoveFacts) (f.eats ? 1000 : 0) - 10 * (f.foodDistance ?? 99) 0.01 * f.reachable;吃到食物给了很高的优先级距离每缩短一格加 10 分可达空格只作很小的平局修正。这个规则是代码定的。把这段 GIF 说成“模型独立看懂棋盘、规划出了路线”就超过了证据。为什么把up/down改成slot 1-4这不是为了让字段看起来整齐。项目的排查记录发现直接用up/down/left/right当选项键时回答会受方向英文词本身影响。换成中性的slot才能更清楚地测它有没有按选项描述来选。标签里的Best/Good/Poor/Worst也有作用模型收到的是明确的等级而不只是四段杂乱的棋盘数据。项目此前的一次283 个局面对照记录同一份未微调权重、同一运行方式下“完整棋盘 事实型选项”的命中率是 34.3%“短 state 字面标签”是 64.7%。记录中的输入长度也从约 404 token 缩到 63 token耗时从约 256 毫秒降到 54 毫秒。这组数字来自此前的离线排查不是根据这段 GIF 重新测出的数也不是整局游戏的胜率。排查笔记还提到决策头会截断过长的输入。因此34.3% 不能直接当成模型在完整读取棋盘后的能力上限。短提示一方面减少了输入长度和等待时间另一方面也把答案线索提前写进了标签。结果变好不等于模型已经学会走棋。模型的选择不一定等于蛇最后走的方向每步约 330 毫秒。控制器在这段时间内等模型回答到点就执行已有的选择若回答没赶上会用代码保底。只有一个合法方向时也直接由代码走不必请求模型。即使模型及时选出一个方向安全覆盖还会检查它是否会撞或进死胡同若不安全就从安全方向里选概率最高的那个。所以复盘时至少要分清三件事模型原始选择、程序最终执行的方向、这一步后游戏发生了什么。只看最后的得分没法知道究竟是模型选对了还是保底与安全覆盖救了它。这版把每次原始输入输出写入 trace游戏记录另存最终动作、耗时、超时和安全覆盖标记就是为了能把它们分开看。本地部署只补充与判断有关的部分Laya 的 GGUF 主模型由 llama.cpp 提供逐 token 特征独立的 head 文件负责给 Choice 选项打分Python 桥接服务用 Laya 的 tokenizer 生成 token ID把两部分接起来。模型文件包括 GGUF、决策头和 laya_head.py。llama.cpp 这边启用了--embeddings --pooling none --ctx-size 8192 -b 2048 -ub 2045只加载 GGUF 而没有决策头不会得到上面这样的四项概率。下一步怎么验证它真的在“看棋盘”我会把测试拆成两部分。第一部分固定一批相同的棋盘局面分别让模型看短标签和完整棋盘比较每步是否选到安全且合理的方向同时统计各方向召回率和概率是否可信。这里不要在完整棋盘组预先写入Good/Poor否则还是在考它读标签。第二部分才是整局游戏固定初始随机种子分别跑代码基线、当前紧凑提示和完整棋盘提示。因为不同策略走几步后遇到的局面就会分叉整局结果要单独报告食物数、存活步数、死亡原因、回答耗时、超时次数和安全覆盖次数。这样才能回答一个更具体的问题把这个判断模型放进游戏究竟比代码本身多带来了什么。如果你也想从这个实验继续找 JEV 的其他用法文中附了一个 JEV 教学 Skill夸克网盘下载。它按场景整理了游戏、浏览器操作、模型路由等案例带截图和原帖链接放进 Agent 的技能目录后可以按自己的任务去找相近的做法。这个包是延伸阅读不含本文的贪吃蛇源码。
