现在 OpenGameAgent 已经有 IGameActionHandler、DurableGameActionDispatcher、动作日志和收据，文档里也说明了游戏动作需要回到宿主的主线程执行。不过目前每个游戏接入时，仍然要自己写一套动作队列、主线程 Pump、取消、关闭清理和恢复逻辑。
在实际接入游戏 AI 时，比较常见的流程是：
游戏线程采集状态快照 → 后台线程调用 LLM → 生成动作请求 → 回到游戏线程验证并执行 → 返回动作结果
这里通常还要处理队列积压、场景或存档切换、请求超时、重复提交和已经派发但还没有收据的动作。
想请教一下，是否考虑在现有 IGameActionHandler 基础上提供一个通用实现，例如 QueuedGameActionHandler，由宿主在主线程调用 Pump(maximumWorkItems)，统一处理：
- 有界待处理动作队列；
- 每次 Pump 的处理上限；
- 尚未执行动作的取消；
- 运行时停止时清理等待中的动作；
- 已开始执行的动作不因调用方超时而盲目取消；
- 通过主线程执行
RecoverAsync；
- 继续复用现有的
GameActionReceipt、operationId 和 generationId。
这样游戏接入方只需要负责游戏状态验证和实际动作执行，主线程交接和等待任务管理可以由 Runtime 统一处理。
想先确认几个方向：
- 这类实现是否适合放在 OpenGameAgent 核心 Runtime 中？
- 还是主线程队列应该继续完全由各个宿主自行实现？
- 如果提供标准实现，
generationId 的过期判断应该由 Runtime 处理，还是由游戏宿主处理？
如果这个方向合适，我可以提交一个pr
现在 OpenGameAgent 已经有
IGameActionHandler、DurableGameActionDispatcher、动作日志和收据，文档里也说明了游戏动作需要回到宿主的主线程执行。不过目前每个游戏接入时，仍然要自己写一套动作队列、主线程 Pump、取消、关闭清理和恢复逻辑。在实际接入游戏 AI 时，比较常见的流程是：
游戏线程采集状态快照 → 后台线程调用 LLM → 生成动作请求 → 回到游戏线程验证并执行 → 返回动作结果
这里通常还要处理队列积压、场景或存档切换、请求超时、重复提交和已经派发但还没有收据的动作。
想请教一下，是否考虑在现有
IGameActionHandler基础上提供一个通用实现，例如QueuedGameActionHandler，由宿主在主线程调用Pump(maximumWorkItems)，统一处理：RecoverAsync；GameActionReceipt、operationId和generationId。这样游戏接入方只需要负责游戏状态验证和实际动作执行，主线程交接和等待任务管理可以由 Runtime 统一处理。
想先确认几个方向：
generationId的过期判断应该由 Runtime 处理，还是由游戏宿主处理？如果这个方向合适，我可以提交一个pr