从毫秒响应到整局结果：Jev 与 DeepSeek 的一次塔防对照实验

一个模型通常几百毫秒就能回答，接进游戏之后，是否也能让操作快上几倍？它更快做出的决定，又能否保住更多血量？

为了观察这两个问题，我选择开源塔防环境 TowerMind，让 Jev 与 DeepSeek 在相同起点下各玩三局。两边都读取结构化游戏状态，逐步选择动作，再由程序执行。

正式测试的开局画面，种子 20260922：基地 20 血、金币 500。黄色旗帜是建塔位置，模型需要在建塔、调兵、技能和等待之间作选择；这张截图供读者观察，未发送给模型。

结果有一个很有意思的落差：正式对局中，DeepSeek 的单次完整响应中位数约为 Jev 的 2.9 倍，但每步决策所需的全部 API 时间，中位数之比约为 1.5。 Jev 三局存活两局，DeepSeek 存活一局；同时，DeepSeek 有 105 次回答未通过输出校验，被控制器转换成了等待。

这几组数字放在一起，才逐渐解释了这次实验：模型的响应速度、一次操作需要问几个问题、回答能否执行，以及最终战果，分别影响着完整任务。

一、先让双方做同一种决定

Jev 1.13 接受文本、JSON 对象或文本数组，不直接接收图像、音频和视频。它适合在给定状态和候选项的条件下作出受约束的判断。TypeSafe 官方模型说明

因此，这次接入从 TowerMind 的游戏状态中取出血量、金币、单位与位置等信息，组成模型输入。截图用于观察和回放。双方实际处理的都是文本与结构化状态。

为了对齐决策粒度，控制器把一次操作拆成两个问题：

1. 做什么？ 在建塔、调动单位、使用技能、等待等候选动作类型中选择一项。
2. 在哪里做？ 固定第一步选中的动作，再选择对应位置或目标；如果只有唯一目标，就直接执行。

例如，选择“调动骑士”后，通常还要决定调到哪个位置；选择“等待”则无需第二次询问。每个问题只负责当前这一层选择。

两边都需要交出同一组结果字段：所选候选项、全部候选项的概率，以及置信度。接入程序会检查概率总和、候选项是否完整、数值范围，以及所选项是否对应最高概率。概率总和允许约 0.01 的舍入误差。回答无效时，统一记录错误并等待一步。

这里对齐的是输入信息、决策粒度和应用接收的字段。Jev 使用其决策接口，DeepSeek 使用 JSON 输出；各自的原始接口封装仍有差别。具体配置如下：

游戏沿用原战斗配置，运行环境修复了一处状态纹理传输的过滤问题。正式开跑前固定计划、代码和种子；运行中保持提示词与错误处置规则不变。每对初始状态及首个问题也核对为一致。随着双方选择不同，后续局面会自然分开。

还有一个影响解释的条件：游戏会等模型完成决定后，才继续推进约 0.32 游戏秒。 这让响应较快的一侧在现实时间里推进得更快，但没有检验敌人持续移动时，模型能否赶上实时操作期限。

二、先测同题响应，再看完整决策

整局游戏中，双方遇到的状态很快就不一样了。为了先看同一内容下的响应差异，我另做了一组固定问题测试：12 个问题，每个模型各回答三次，共 72 次调用。每题的状态、规则、选项和排列顺序保持一致。

在这组测试里，Jev 的完整响应中位数是 0.343 秒，DeepSeek 是 0.927 秒，后者约为前者的 2.70 倍。双方各 36 次回答都通过了完整输出校验。

固定问题还带来一些局部观察。12 个问题中，Jev 有 11 个在三次重复中选择一致，DeepSeek 有 6 个。只有其中 4 个问题具备几何覆盖、既定目标下移动选择等参考答案，重复回答的正确次数分别为 11/12 和 9/12。独立有标签问题仍然只有 4 个，这部分更适合用于发现局部差异，无法支持整体策略准确率的判断。

进入六局正式游戏后，时间关系变成了这样：

三种时间口径分别汇总。正式局的单次调用数为 Jev 1,742 次、DeepSeek 948 次；决策步数为 879 步、758 步。

“完整响应”从客户端发起请求开始，计入接收完整回答、解析、校验和共同指标计算；发生重试时，也计入等待。它包含网络与服务端开销，无法从中单独得到模型的纯推理时间。日志里 DeepSeek 有两次连接超时后的重试。

“一步全部 API 耗时”则把选动作、选位置的调用时间加起来，不含游戏执行和截图耗时。表中的倍数是两边全部观测的中位数之比。正式局来自不同后续局面，因此要结合动作分布理解。

三、一个频繁调兵，一个大量等待

查看动作日志后，2.89 与 1.48 的差距就更容易理解了。

Jev 的 879 步中，有 797 步调动骑士，占约 90.7%。DeepSeek 的 758 步中，有 620 步等待，占约 81.8%。

先看同一现实时间里的游戏画面：

左右都运行了约 57 秒。Jev 已推进到游戏时间 18.56 秒、剩 18 血；DeepSeek 推进到 10.56 秒、剩 20 血。下方动作栏分别是调动骑士与等待。这一帧呈现了推进节奏与当前动作，完整动作占比见下图。

动作计数包含控制器的回退等待：Jev 16 次等待中有 2 次来自输出失败，DeepSeek 620 次等待中有 105 次来自输出失败。

两边实际调用的结构也因此不同：

Jev 几乎每步都要回答第二个问题；DeepSeek 的大量等待一步就能完成。Jev 单次回答较快，却也承担了更多串行调用。动作组合由此影响了操作落地的速度。

这解释了部分时间差异，但还没有把所有因素单独分离出来：两边面对的状态、候选项数量和实际回答也不同。后续若要量化“多一次目标选择究竟增加多少延迟”，需要固定这些条件另做对照。

动作日志还提醒了我另一件事：调兵次数多，只能说明操作频繁。重复调动也会计数，是否形成有效拦截、是否浪费了建塔机会，需要结合具体局面判断。等待同样可能是在积累资源。仅凭画面更忙碌，还无法评出战术优劣。

四、概率总和 1.15，怎样变成一次等待

最具体的一类失败，发生在概率字段上。

种子 20260922 中，DeepSeek 在第 30 步的目标选择里返回了 20 个候选项的概率。其中一个为 0.20，其余 19 个都是 0.05：

所选候选项：a018
该项概率：0.20
其余 19 项：每项 0.05
概率总和：0.20 + 19 × 0.05 = 1.15

选择编号虽然存在，概率分布却没有满足约定。控制器拒绝了这份回答，执行等待，游戏随后推进一步。模型原本打算执行的操作没有落地。

正式六局里，这类问题累计到了可见的规模：

按调用计，Jev 的失败率约为 0.115%，DeepSeek 约为 11.076%；按游戏决策步计，DeepSeek 有 13.85% 的步数因回答失败而等待。两个比例使用不同分母。

要求完整概率有实际用途：可以保留模型在不同选项间的犹豫程度，为后续分析或路由提供信息。不过，这也给生成式回答增加了一个必须履行的数值约束。本轮观察到的是这套完整输出要求下的任务表现。只返回一个动作编号，或在程序里重新归一化概率，会形成另一套接入方案，其结果需要另行验证。

置信度也需要单独理解。实验保留了模型返回的原生值，并从两边概率分布计算共同指标；但分布集中程度与实际答对概率是两件事。本次没有建立置信度与正确率之间的校准曲线，因此无法比较谁的置信度更可信。

另外，回答通过校验后，执行仍可能失败。Jev 有 14 次增援动作被游戏拒绝，错误码均为 8，而动作前可见倒计时已经是 0。这些记录属于状态观察与动作执行的边界问题，需要与输出格式失败分别统计。

五、最终血量：Jev 赢两对，DeepSeek 赢一对

三对正式局全部保留，终局血量如下：

Jev 两局守完全部波次并存活，DeepSeek 一局；双方均未达到原游戏要求的终局血量大于 15 的成功门槛。

按这三对的终局结果看，Jev 占优。结合响应和输出记录，可以说：在本轮配置下，Jev 响应更快、完整输出更稳定，并且存活局数更多。

其中种子 20260922 的终局，保留了 DeepSeek 获胜的这一对：

两侧分别停在各自终局，时钟不再相同。下方血量来自最终状态记录：Jev 为 0，DeepSeek 为 5；游戏内小血条可能滞后一帧。原游戏要求终局血量大于 15，因此两边画面都会出现 GAME OVER，剩 5 血仍未达到它的成功门槛。

要进一步判断谁的策略能力更强，现有数据还混合着几种影响：战术选择、回答被拒绝后的等待，以及游戏执行错误。而且，独立配对样本只有三个；2,690 次调用都是这些对局里的连续记录，不能当作 2,690 场独立比赛。

整局耗时也容易造成误解。种子 20260924 中，DeepSeek 大约 281 秒就结束了，Jev 用了约 293 秒。但前者血量归零，后者最终剩 6 血。更早结束在这一局意味着更早阵亡。三个种子都没有双方同时存活的配对，因此本轮无法给出配对的通关提速倍数。

六、评估快速决策模型，我会一起看这三件事

这次实验让我更关注一次决定从提出到执行的完整过程。

第一，看同题完整响应。 固定状态和选项，记录完整回答的耗时，才能获得比较清楚的速度基线。这次同题测试中的中位数时间比是 2.70。

第二，看一次操作需要多少次询问。 选动作和选位置存在先后依赖，后一个问题需要等待前一个结果。若业务有类似的串行结构，就要累计整步调用时间。本轮正式局的单次时间比约为 2.89，整步约为 1.48。

第三，看回答是否真的执行，以及执行后的结果。 概率字段、候选编号、动作可用性都可能影响操作落地。最终血量提供结果，逐步日志解释结果是怎样形成的。

在需要高频、受约束选择的应用里，这三个层面值得一起记录。Jev 在本轮实验中表现出了可见的速度和输出可靠性优势；接下来值得追踪的，是这些更快返回的决定，有多少能够稳定执行，又有多少确实改善了局面。

七、未来畅想：当 AI 能更频繁地作出决定

如果把这次塔防实验往前推一步，我更想看到的是一种能够持续观察、及时调整的游戏角色：敌人改变路线，它重新安排拦截；金币刚好够用，它判断是否建塔；局面偏离预期，它主动重新规划。下面这些设想尚未在本轮实现，但它们让低延迟决策的用途变得具体。

一种可能，是让快模型负责局部动作，让更擅长规划的模型负责阶段目标。 在塔防里，规划者可以决定“这一波优先补防空，保留一笔应急资源”，快速决策组件再在这些约束下处理调兵、选目标和技能时机。只有进入新波次或防线出现明显缺口时，才重新请求规划。这样的协作能否胜过单模型，最终还要看额外沟通耗时、目标是否清楚，以及局部动作能否落实整体意图。

另一种可能，是让模型决定什么时候需要求助。 当几个候选项难分高下，或者连续操作没有改善局面时，可以请求更深入的判断，也可以暂时退回明确的规则。概率与置信度有机会成为这个流程的输入，但首先需要用实际结果校准：模型说自己有把握时，究竟有多大概率做对？本轮保留下来的概率分布，可以作为继续研究这件事的起点。

再往前，是把游戏变成真正持续变化的环境。 这次游戏会等待模型回答；未来可以设想，敌人持续前进，模型必须在有限时间内作出决定。那时，除了最终血量，还需要记录错过了多少操作窗口、行动执行时状态是否已经过期，以及遇到迟到回答如何处理。只有在这样的条件下，才能直接观察更低延迟是否换来了更好的临场反应。

这些设想也可以延伸到游戏之外：一个协助操作软件的助手，能否在每一步之后迅速检查结果、发现偏差，并调整下一步？交互式教学中的虚拟角色，能否根据学生刚刚的操作及时改变提示？它们都需要把观察、判断、执行和反馈接起来，具体收益仍需各自的场景验证。

游戏提供了一个能观察决策过程的窗口，更广阔的想象空间在日常使用中：操作软件时，助手能跟上界面变化；学习过程中，提示能回应刚刚出现的困惑；任务协作中，计划能随着新信息及时调整。如果快速判断能与可靠执行、持续反馈结合，AI 就有机会更自然地参与这些过程，在需要它的时刻作出有用的决定，并根据结果修正下一步。