引入全局状态感知与分层自愈机制，降低脚本对固定流程的依赖

[syokounya]

Validations

• 我已经阅读了 用户文档 并尝试自己解决问题，同时在社群中进行了讨论
• 我无法找到任何 open issue 提出了相同的建议

问题描述

当前后端的核心战斗、导航与任务执行流程是开环设计：系统严格依赖预设的状态转移图和页面跳转路径执行，但缺乏对"实际游戏画面"的通用兜底感知能力。

一旦现实偏离预设路径（手动误触模拟器、模拟器卡顿掉帧、网络延迟、意外弹窗、动画跳过），脚本无法定位自己的真实状态，也没有标准化的恢复路径，最终只能抛出异常并终止任务。

典型故障场景

1. 战斗状态机超时即宕机：CombatEngine._try_recovery() 仅检查是否到达 end_phase，若用户误触返回导致回到主页面/地图页面，直接判定为识别超时并 SL。
2. 导航系统无兜底恢复：goto_page() 在 identify_current_page 连续 5 次失败后直接抛出 NavigationError，没有"安全回退到主页再重试"的通用逃生通道。
3. 通用弹窗无统一拦截：网络错误、远程登录、公告浮层等弹窗的处理分散在各个 ops 模块，战斗/导航过程中出现即导致流程中断。
4. 任务级无断点续传：run_for_times() 等循环一旦单次 run() 异常，整个批次终止，不会区分"可恢复错误"与"不可恢复错误"。
5. 固定超时无法应对卡顿：大量 time.sleep() 和固定 timeout 在模拟器卡顿时频繁触发假阳性超时。

解决方案

建议分阶段引入**"全局状态感知 + 分层自愈"**机制，将系统从"按剧本执行的演员"转变为"能随机应变的玩家"。

Phase 1：战斗引擎增强 — 状态重新同步与全局定位

改造 CombatEngine._try_recovery()，在识别超时后执行三级恢复：

1. 全局页面定位：调用 identify_current_page() 判断当前是否处于主页面/地图页面/活动地图页面。若是，说明战斗流程被打断，抛出可恢复的 CombatInterruptedError，由上层 Runner 重新进入战斗，而非直接 SL。
2. 战斗状态重新同步：在所有 CombatPhase 中搜索当前截图，若匹配到某个中间态，将 self._phase 直接修正为该状态并继续执行。
3. 通用弹窗处理：检测并点击网络重试、远程登录确认、公告关闭等常见弹窗。

Phase 2：导航系统增强 — 安全回退与自适应重规划

改造 goto_page() 的错误处理链路：

1. 安全回退（Safe Retreat）：当页面识别完全失败时，执行 safe_retreat_to_main() —— 连续发送 Back 键并轮询，强制回到主页面这一稳定锚点。
2. 动作后置验证：edge.action(ctx) 执行后，增加短暂的状态验证（如是否离开原页面），未生效时自动重试该步。
3. 异常截图诊断：NavigationError 已保存截图，可进一步增加规则判断（黑屏/转圈/弹窗），自动选择延长等待或关闭浮层。

Phase 3：建立 OverlayManager — 统一弹窗拦截层

新增 OverlayManager 模块，在统一的截图入口（或每次轮询前）自动检测并处理通用浮层：

• 网络错误 → 点击重试
• 远程登录 → 点击确认
• 资源/船坞确认 → 点击确认
• 公告/新闻 → 点击关闭
  该层优先级高于业务状态机，确保弹窗不会击穿到战斗/导航逻辑。

Phase 4：任务执行框架 — 分级重试与断点续传

新增 TaskExecutor 包装 run_for_times() 等入口：

1. 错误分级：
   • 可恢复：NavigationError、CombatRecognitionTimeout、NetworkError
   • 不可恢复：ConfigError、EmulatorConnectionError
2. 分级重试策略：
   • 战斗内识别超时 → 局部恢复（3 次）
   • 局部恢复失败 → 全局回退到主页并重新进入（2 次）
   • 连续失败 → 熔断暂停，通知用户
3. 断点续传：记录当前进度（如第 3/10 次，节点 B），重试时从断点继续。

Phase 5：模拟器健康监控 — 动态超时

在 AndroidController 层增加截图帧率统计：

• 若平均截图耗时 > 500ms，自动延长后续所有 timeout 和 interval。
• 将固定 time.sleep() 逐步替换为"状态变化轮询"，降低卡顿导致的假阳性。

---

预期收益：按此路径实施后，可解决当前约 80% 因"误触、卡顿、弹窗"导致的非预期宕机，实现接近无人值守的稳定性。

[github-actions]

Issue 概要

• issue：#422
• 版本 / 分支 / 环境：main@c72ed6acbae1f59bb47ac28b0d1f896d5ad27eb2；issue 未提供模拟器型号、控制方式、复现日志与时间戳
• 任务 / 入口 / 相关设置：聚焦常规战/活动战执行链路（战斗状态机、跨页导航、任务循环重试、弹窗处理、超时策略）
• 关键提示 / 报错文案：战斗状态识别超时、无法识别当前页面，导航中止
• 用户现象：当前流程偏“开环”，一旦出现误触、卡顿、意外弹窗、页面偏移，缺少统一恢复机制，任务易中断

附件概览

• 实际可读文件：Issue 正文、1 条机器人评论（仅提示 AI 分析流程启动）
• 缺失或未上传的证据：运行日志、截图/录屏、配置导出、崩溃信息、具体 task_id/session_id

关键证据

点击此处展开

• issue 正文 / 评论：
  • 正文是“改进建议型 issue”，不是单次故障复盘；没有给出可对齐日志锚点（时间/任务 ID/报错堆栈）
  • 评论仅为自动化流程提示，暂无维护者技术结论
• 运行时日志：
  • 未提供，无法建立真实故障时间线
• UI / 服务日志：
  • 未提供，无法确认“误触/弹窗/卡顿”在用户现场中的主导因素
• 配置快照：
  • 未提供，无法确认当前 timeout、计划参数、模拟器参数是否为默认值
• 现场图 / 转储：
  • 未提供
• 代码依据（当前主线）：
  • 战斗识别超时后仅尝试识别 end_phase，失败即置 SL：

    AutoWSGR/autowsgr/combat/engine.py

    Lines 162 to 167 in c72ed6a

    	except CombatRecognitionTimeout as e:
    	_log.warning('[Combat] 状态识别超时: {}', e)
    	if self._try_recovery():
    	continue
    	result.flag = ConditionFlag.SL
    	break

    、

    AutoWSGR/autowsgr/combat/engine.py

    Lines 294 to 305 in c72ed6a

    	def _try_recovery(self) -> bool:
    	"""尝试从错误中恢复。"""
    	_log.warning('[Combat] 尝试错误恢复...')
    	time.sleep(3.0)
    	screen = self._device.screenshot()
    	end_phase = self._plan.end_phase
    	result = self._recognizer.identify_current(screen, [end_phase])
    	if result is not None:
    	self._phase = end_phase
    	return True
    	return False

  • 导航页识别失败 5 次即返回 None，goto_page 仅额外重试一次，没有“安全回主页面再重规划”通道：

    AutoWSGR/autowsgr/ops/navigate.py

    Lines 26 to 30 in c72ed6a

    	MAX_IDENTIFY_ATTEMPTS: int = 5
    	"""页面识别最大尝试次数。"""
    	IDENTIFY_INTERVAL: float = 1.0
    	"""页面识别重试间隔 (秒)。"""

    、

    AutoWSGR/autowsgr/ops/navigate.py

    Lines 49 to 59 in c72ed6a

    	for attempt in range(MAX_IDENTIFY_ATTEMPTS):
    	screen = ctrl.screenshot()
    	page = get_current_page(screen)
    	if page is not None:
    	return page
    	_log.debug(
    	'[OPS] 页面识别失败 (第 {} 次尝试), 等待重试',
    	attempt + 1,
    	)
    	time.sleep(IDENTIFY_INTERVAL)
    	return None

    、

    AutoWSGR/autowsgr/ops/navigate.py

    Lines 129 to 137 in c72ed6a

    	def goto_page(ctx: GameContext, target: str) -> None:
    	"""导航到目标页面，失败时自动重试一次。"""
    	try:
    	_goto_page(ctx, target)
    	except NavigationError as e:
    	_log.error('[OPS] 导航失败: {}', e)
    	current_page = identify_current_page(ctx)
    	_log.info('[OPS] 当前页面: {}, 执行一次重试', current_page)
    	_goto_page(ctx, target)

  • NavConfig 暴露了 handle_overlays，但 wait_for_page 轮询里未真正调用统一浮层处理逻辑（参数存在、逻辑缺位）：

    AutoWSGR/autowsgr/ui/utils/navigation.py

    Lines 67 to 75 in c72ed6a

    	handle_overlays:
    	是否自动处理游戏浮层 (新闻公告等)。
    	"""
    	max_retries: int = 2
    	retry_delay: float = 1.0
    	timeout: float = 5.0
    	interval: float = 0.5
    	handle_overlays: bool = True

    、

    AutoWSGR/autowsgr/ui/utils/navigation.py

    Lines 86 to 139 in c72ed6a

    	def wait_for_page(
    	ctrl: AndroidController,
    	checker: Callable[[np.ndarray], bool],
    	*,
    	timeout: float = DEFAULT_NAV_CONFIG.timeout,
    	interval: float = DEFAULT_NAV_CONFIG.interval,
    	handle_overlays: bool = True,
    	source: str = '',
    	target: str = '',
    	) -> np.ndarray:
    	"""反复截图，直到 ``checker`` 返回 ``True``。
    	内置浮层消除。遇到可消除浮层时立即处理并继续轮询（不计入睡眠延迟）。
    	Raises
    	------
    	NavigationError
    	超时仍未匹配。
    	"""
    	from autowsgr.ui.page import get_current_page
    	deadline = time.monotonic() + timeout
    	attempt = 0
    	_log.debug('[UI] 等待到达: {} -> {} (超时 {:.1f}s)', source or '?', target or '?', timeout)
    	while True:
    	attempt += 1
    	screen = ctrl.screenshot()
    	if checker(screen):
    	_log.debug(
    	'[UI] 已到达: {} -> {} (第 {} 次截图)', source or '?', target or '?', attempt
    	)
    	return screen
    	current = get_current_page(screen)
    	_log.debug(
    	'[UI] 等待 #{}: {} -> {}, 当前={}',
    	attempt,
    	source or '?',
    	target or '?',
    	current or '未知',
    	)
    	if time.monotonic() >= deadline:
    	msg = (
    	f'等待超时: {source or "?"} -> {target or "?"}, '
    	f'{attempt} 次截图后仍未到达, 当前: {current or "未知"}'
    	)
    	_log.error('[UI] {}', msg)
    	raise NavigationError(msg, screen=screen)
    	time.sleep(interval)

  • 现有浮层处理主要局限在“主页面浮层”（新闻/签到/预约）和部分页面内专用逻辑，不是全局拦截层：https://github.com/OpenWSGR/AutoWSGR/blob/c72ed6acbae1f59bb47ac28b0d1f896d5ad27eb2/autowsgr/ui/main_page/overlays.py#L42-L124、

    AutoWSGR/autowsgr/ui/main_page/controller.py

    Lines 152 to 166 in c72ed6a

    	def navigate_to(self, target: Target) -> None:
    	"""导航到指定子页面。
    	自动处理浮层后再执行导航。活动目标走专用流程。
    	Raises
    	------
    	NavigationError
    	超时未到达目标页面。
    	"""
    	self._ensure_clean_page()
    	if target is Target.EVENT:
    	self._navigate_to_event()
    	else:
    	self._navigate_standard(target)

    、

    AutoWSGR/autowsgr/ui/event/event_page.py

    Lines 174 to 189 in c72ed6a

    	def _detect_overlay(self, screen: np.ndarray) -> bool:
    	"""检测截图中是否存在可消除的浮层（地图进入页）。"""
    	result = PixelChecker.check_signature(screen, OVERLAY_SIGNATURE)
    	return result.matched
    	def _close_overlay(self) -> None:
    	"""点击浮层中的关闭按钮，返回地图基础页面。"""
    	_log.info('[UI] 活动地图: 关闭进入页浮层')
    	self._ctrl.click(*CLICK_CLOSE_OVERLAY)
    	wait_for_page(self._ctrl, self.is_current_page, timeout=5.0)
    	time.sleep(0.25) # 等待页面稳定
    	def _ensure_no_overlay(self) -> None:
    	if self._detect_overlay(self._ctrl.screenshot()):
    	self._close_overlay()

  • run_for_times()（常规战/活动战）本身不做异常分级与恢复；单次 run() 异常会中断该调用链：

    AutoWSGR/autowsgr/ops/normal_fight.py

    Lines 140 to 143 in c72ed6a

    	for i in range(times):
    	_log.info('[OPS] 常规战第 {}/{} 次', i + 1, times)
    	result = self.run(**kwargs)
    	self._results.append(result)

    、

    AutoWSGR/autowsgr/ops/event_fight.py

    Lines 174 to 177 in c72ed6a

    	for i in range(times):
    	_log.info('[OPS] 活动战第 {}/{} 次', i + 1, times)
    	result = self.run()
    	self._results.append(result)

  • 但 server 路由层“逐轮执行”已做了每轮 try/except，异常后可继续下一轮（说明问题是“能力分散”，不是完全缺失）：

    AutoWSGR/autowsgr/server/routes/task.py

    Lines 115 to 135 in c72ed6a

    	for i in range(request.times):
    	if task_manager.should_stop():
    	break
    	task_manager.update_progress(current_round=i + 1)
    	_log.info('[Task] 常规战第 {}/{} 轮', i + 1, request.times)
    	try:
    	result = run_normal_fight(
    	ctx,
    	plan,
    	times=1,
    	fleet_id=override_fleet_id,
    	fleet=override_fleet,
    	)[0]
    	results.append(convert_combat_result(result, i + 1))
    	task_manager.add_result(results[-1])
    	except Exception as e:
    	_log.error('[Task] 第 {} 轮失败: {}', i + 1, e)
    	results.append({'round': i + 1, 'success': False, 'error': str(e)})

  • scheduler 也有兜底，但目前将异常折叠为 DOCK_FULL，语义不够精确：

    AutoWSGR/autowsgr/scheduler/scheduler.py

    Lines 215 to 225 in c72ed6a

    	try:
    	result = runner.run()
    	except Exception as exc:
    	_log.opt(exception=True).error(
    	'[Scheduler] {} 第 {} 次异常: {}',
    	task.name,
    	j + 1,
    	exc,
    	)
    	result = CombatResult(flag=ConditionFlag.DOCK_FULL)

  • 战斗识别超时主要来自固定 default_timeout；缺少按设备实时性能动态调整的机制：

    AutoWSGR/autowsgr/combat/recognizer.py

    Lines 90 to 156 in c72ed6a

    	PHASE_SIGNATURES: dict[CombatPhase, PhaseSignature] = {
    	CombatPhase.PROCEED: PhaseSignature(
    	template_key=TemplateKey.PROCEED,
    	default_timeout=7.5,
    	after_match_delay=0.5,
    	),
    	CombatPhase.START_FIGHT: PhaseSignature(
    	template_key=None, # 过渡态，不直接用模板匹配
    	default_timeout=3.0,
    	),
    	CombatPhase.DOCK_FULL: PhaseSignature(
    	template_key=TemplateKey.DOCK_FULL,
    	default_timeout=3.0,
    	),
    	CombatPhase.FIGHT_CONDITION: PhaseSignature(
    	template_key=TemplateKey.FIGHT_CONDITION,
    	default_timeout=22.5,
    	),
    	CombatPhase.SPOT_ENEMY_SUCCESS: PhaseSignature(
    	template_key=TemplateKey.SPOT_ENEMY,
    	default_timeout=22.5,
    	),
    	CombatPhase.FORMATION: PhaseSignature(
    	template_key=None,
    	default_timeout=22.5,
    	pixel_signature=_CHOOSE_FORMATION_SIGNATURE,
    	),
    	CombatPhase.MISSILE_ANIMATION: PhaseSignature(
    	template_key=TemplateKey.MISSILE_ANIMATION,
    	default_timeout=3.0,
    	),
    	CombatPhase.FIGHT_PERIOD: PhaseSignature(
    	template_key=TemplateKey.FIGHT_PERIOD,
    	default_timeout=30.0,
    	),
    	CombatPhase.NIGHT_PROMPT: PhaseSignature(
    	template_key=TemplateKey.NIGHT_BATTLE,
    	default_timeout=150.0,
    	after_match_delay=1.75,
    	),
    	CombatPhase.RESULT: PhaseSignature(
    	template_key=TemplateKey.RESULT,
    	default_timeout=90.0,
    	),
    	CombatPhase.GET_SHIP: PhaseSignature(
    	template_key=TemplateKey.GET_SHIP_OR_ITEM,
    	default_timeout=5.0,
    	after_match_delay=1.0,
    	),
    	CombatPhase.FLAGSHIP_SEVERE_DAMAGE: PhaseSignature(
    	template_key=TemplateKey.FLAGSHIP_DAMAGE,
    	default_timeout=7.5,
    	),
    	CombatPhase.MAP_PAGE: PhaseSignature(
    	template_key=TemplateKey.END_MAP_PAGE,
    	default_timeout=7.5,
    	),
    	CombatPhase.EXERCISE_PAGE: PhaseSignature(
    	template_key=TemplateKey.END_EXERCISE_PAGE,
    	default_timeout=7.5,
    	),
    	CombatPhase.EVENT_MAP_PAGE: PhaseSignature(
    	template_key=None,
    	default_timeout=7.5,
    	pixel_signature=_get_event_map_signatures(),
    	),
    	}

    、

    AutoWSGR/autowsgr/combat/recognizer.py

    Lines 272 to 306 in c72ed6a

    	max_timeout = 0.0
    	phase_sigs: list[tuple[CombatPhase, PhaseSignature]] = []
    	for phase in candidates:
    	sig = self.get_signature(phase)
    	max_timeout = max(max_timeout, sig.default_timeout)
    	phase_sigs.append((phase, sig))
    	deadline = time.time() + max_timeout
    	_log.debug(
    	'[Combat] 等待状态: {} (超时 {:.1f}s)',
    	[p.name for p, _ in phase_sigs],
    	max_timeout,
    	)
    	while time.time() < deadline:
    	# 检查停止信号
    	if self._ctx.stop_event.is_set():
    	raise CombatStopRequested('任务被用户停止')
    	screen = self._device.screenshot()
    	if poll_action is not None:
    	poll_action(screen)
    	for phase, sig in phase_sigs:
    	if sig.template_key is None and sig.pixel_signature is None:
    	continue
    	if self._match_phase(screen, sig):
    	if sig.after_match_delay > 0:
    	time.sleep(sig.after_match_delay)
    	_log.debug('[Combat] 匹配到状态: {}', phase.name)
    	return phase
    	# 超时
    	phase_names = [p.name for p, _ in phase_sigs]
    	raise CombatRecognitionTimeout(f'等待状态超时 ({max_timeout:.1f}s): {phase_names}')

  • 控制器会记录单次截图耗时，但当前没有把该指标反馈给导航/战斗超时策略：

    AutoWSGR/autowsgr/emulator/controller/scrcpy.py

    Lines 380 to 410 in c72ed6a

    	def screenshot(self) -> np.ndarray:
    	self._ensure_stream_alive()
    	start = time.monotonic()
    	while True:
    	with self._frame_lock:
    	frame = self._last_frame
    	if frame is not None:
    	elapsed = time.monotonic() - start
    	h, w = frame.shape[:2]
    	_log.trace(
    	'[Emulator] 截图完成 {}x{} 耗时={:.3f}s',
    	w,
    	h,
    	elapsed,
    	)
    	return frame
    	if not self._alive:
    	self._ensure_stream_alive()
    	start = time.monotonic()
    	continue
    	if time.monotonic() - start > self._screenshot_timeout:
    	raise EmulatorConnectionError(
    	f'截图超时 ({self._screenshot_timeout}s)，scrcpy 视频流无数据'
    	)
    	time.sleep(0.01)

根因判断

• 直接结论：这是一个架构韧性不足的问题（功能缺口），不是单一代码 bug。Issue 的核心判断与当前代码现状大体一致。
• 证据链：
  1. 恢复逻辑存在但分散且层级不统一（战斗层、页面层、启动层各自兜底）
  2. 异常语义未分级（尤其 scheduler 将异常映射为 DOCK_FULL）
  3. 超时模型以固定阈值为主，未根据设备状态自适应
  4. 缺少“全局状态感知 + 统一恢复入口 + 任务级恢复策略”闭环
• 当前主线是否可能已修复：未修复为 issue 建议的目标形态；仅有局部恢复能力。

修复方案

1. 代码 / 配置 / 资源层修复
   先做最小闭环：
   • 新增可恢复异常类型（如 RecoverableNavigationError、CombatInterruptedError），避免用 DOCK_FULL 承载非船坞满异常
   • 在 goto_page 增加可选 safe_retreat_to_main() 分支（识别失败或路径失败时触发）
   • 在 CombatEngine._try_recovery() 增加“多候选阶段重同步 + 页面级识别（主页面/地图页/活动页）”
2. 需要补充的测试、日志或截图
   • 单测：导航识别失败→安全回退成功/失败；战斗识别超时→重同步命中/未命中
   • 集成日志：增加统一 session_id/task_id/round/phase 字段，便于跨层串联
   • 现场材料模板：要求 issue 自动附最近一次运行日志与最后 3 张截图
3. 如问题属于不支持场景，应如何限制入口或改进提示
   • 对“无法识别页面”区分为“可能卡顿/可能弹窗/页面未知”，给出不同提示与建议动作
   • 对连续恢复失败触发熔断，提示用户检查模拟器帧率、分辨率、遮挡与网络状态

给用户的建议

• 用户现在可以直接尝试的动作：先用 server 任务入口（逐轮 try/except）而非直接调用 run_for_times()；遇到间歇性失败时先降低并发干扰、保持模拟器前台稳定。
• 是否建议升级 / 重下完整包 / 重置配置 / 更换环境：建议升级到最新主线；若仍偶发识别超时，优先检查模拟器性能与帧稳定性，再决定是否重建环境。
• 是否有临时绕过方案：将任务拆成更短批次（减少单次长链路失败成本），并在批次间显式调用回主页面逻辑。

给修复 AI 的建议（可复制）

点击此处展开

现象：
战斗/导航流程在误触、卡顿、弹窗干扰时缺少统一恢复闭环，导致单轮异常扩大为整批任务中断。

关键证据：
- CombatEngine 超时恢复仅识别 end_phase，失败即 SL：
  autowsgr/combat/engine.py:162-167,294-305
- goto_page 识别失败即抛错，仅重试一次：
  autowsgr/ops/navigate.py:26-30,49-59,129-137
- NavConfig 有 handle_overlays 但 wait_for_page 未落地统一浮层处理：
  autowsgr/ui/utils/navigation.py:67-75,86-139
- run_for_times 无异常分级恢复：
  autowsgr/ops/normal_fight.py:140-143
  autowsgr/ops/event_fight.py:174-177

可能相关线索（待验证）：
1) 引入 RecoverableError 分层，并在 task/scheduler 统一判定重试策略
2) 在 navigate 增加 safe_retreat_to_main，再重走 find_path
3) CombatEngine._try_recovery 扩展为多候选 phase + 页面级定位（Main/Map/Event）
4) 将 screenshot 耗时统计接入 timeout 动态放大系数

置信度

• 中
• 还缺什么证据：用户现场日志、截图/录屏、配置快照（含模拟器参数与任务参数）以及至少一次可复现样本的时间线锚点

---

点击此处展开分析过程

● skill(generic-issue-log-analysis)

● Get repo remote and HEAD info (shell)
│ git --no-pager remote -v && git rev-parse HEAD && git branch --show-current
└ 5 lines...

● Get issue details (MCP: github-mcp-server) · method: "get_comments", owner: "OpenWSGR", repo: "Au…
└ [{"id":4230654597,"body":"🤖 AI 正在分析该 Issue... \n\n感谢您的反馈！AI
正在自动分析该问题，预...

● Get issue details (MCP: github-mcp-server) · method: "get", owner: "OpenWSGR", repo: "AutoWSGR", …
└ {"number":422,"title":"引入全局状态感知与分层自愈机制，降低脚本对固定流程的依赖","body":"###
Validations...

● Get issue details (MCP: github-mcp-server) · method: "get_labels", owner: "OpenWSGR", repo: "Auto…
└ {"labels":[],"totalCount":0}

● Search (grep)
│ "def goto_page|NavigationError|identify_current_page" in **/*.py
└ 93 lines found

● Search (grep)
│ "def _try_recovery|class CombatEngine" in **/*.py
└ 2 lines found

● Search (grep)
│ "def run_for_times|run()|retry|断点|recover" in autowsgr/**/*.py
└ 54 lines found

● Read engine.py
│ autowsgr/combat/engine.py
└ L1:420 (335 lines read)

● Read navigate.py
│ autowsgr/ops/navigate.py
└ L1:260 (137 lines read)

● Read normal_fight.py
│ autowsgr/ops/normal_fight.py
└ L1:360 (359 lines read)

● Read event_fight.py
│ autowsgr/ops/event_fight.py
└ L1:280 (280 lines read)

● Read startup.py
│ autowsgr/ops/startup.py
└ L220:380 (102 lines read)

● Read scheduler.py
│ autowsgr/scheduler/scheduler.py
└ L1:320 (300 lines read)

● Read task.py
│ autowsgr/server/routes/task.py
└ L1:420 (331 lines read)

● Read schemas.py
│ autowsgr/server/schemas.py
└ L1:260 (260 lines read)

● Search (glob)
│ "**/locale"
└ No matches found

● Read actions.py
│ autowsgr/combat/actions.py
└ L320:460 (108 lines read)

● Read startup.py
│ autowsgr/ops/startup.py
└ L1:220 (220 lines read)

● Search (grep)
│ "network_retry|远程登录|公告|overlay|dismiss|弹窗|retry" in **/*.py (autowsgr)
└ 9 lines found

● Read normal_fight.py
│ autowsgr/ops/normal_fight.py
└ L356:520 (70 lines read)

● Read copilot-tool-output-1775964470549-7urwge.txt
│ /tmp/copilot-tool-output-1775964470549-7urwge.txt
└ L1:220 (152 lines read)

● Search (grep)
│ "remote|login|公告|新闻|网络|retry|RETRY|overlay|dismiss|close" in **/*.py (autowsgr)
└ 10 lines found

● Search (glob)
│ "autowsgr/ui/**/overlay*.py"
└ 2 files found

● Read copilot-tool-output-1775964474832-ts7sl4.txt
│ /tmp/copilot-tool-output-1775964474832-ts7sl4.txt
└ L1:220 (154 lines read)

● Search (grep)
│ "dismiss_overlays|overlay" in **/*.py (autowsgr/ui)
└ 9 lines found

● Read init.py
│ autowsgr/ui/init.py
└ L1:260 (174 lines read)

● Read navigation.py
│ autowsgr/ui/navigation.py
└ L1:260 (260 lines read)

● Read navigation.py
│ autowsgr/ui/utils/navigation.py
└ L1:430 (368 lines read)

● Read overlays.py
│ autowsgr/ui/main_page/overlays.py
└ L1:320 (123 lines read)

● Search (grep)
│ "detect_overlay(|dismiss_overlay(|main_page.overlays|OverlayKind" in **/*.py (autowsgr)
└ 32 lines found

● Search (grep)
│ "CombatRecognitionTimeout|SL|ConditionFlag.SL|_try_recovery" in **/*.py (autowsgr)
└ 87 lines found

● Read exceptions.py
│ autowsgr/infra/exceptions.py
└ L1:220 (135 lines read)

● Read controller.py
│ autowsgr/ui/main_page/controller.py
└ L1:280 (226 lines read)

● Read event_nav.py
│ autowsgr/ui/main_page/event_nav.py
└ L1:260 (156 lines read)

● Read event_page.py
│ autowsgr/ui/event/event_page.py
└ L140:280 (141 lines read)

● Search (grep)
│ "time.sleep(|timeout|interval" in **/*.py (autowsgr/combat)
└ 41 lines found

● Read recognizer.py
│ autowsgr/combat/recognizer.py
└ L220:380 (122 lines read)

● Search (grep)
│ "screenshot(|frame|fps|耗时|latency|动态超时|adaptive" in **/*.py (autowsgr)
└ 9 lines found

✗ Read controller.py
│ autowsgr/emulator/controller.py
└ Path does not exist

● Search (grep)
│ "def screenshot|screenshot(|frame_rate|fps|latency|elapsed|perf|performance" in **/*.py
│ (autowsgr/emulator)
└ 11 lines found

● Read init.py
│ autowsgr/ops/init.py
└ L1:220 (135 lines read)

● Read scrcpy.py
│ autowsgr/emulator/controller/scrcpy.py
└ L330:450 (121 lines read)

● Read scrcpy.py
│ autowsgr/emulator/controller/scrcpy.py
└ L1:140 (139 lines read)

● Read protocol.py
│ autowsgr/emulator/controller/protocol.py
└ L1:180 (180 lines read)

● Search (grep)
│ "key_event(4)|KEYCODE_BACK|go_back(|back" in **/*.py (autowsgr/ops)
└ 7 lines found

● Search (grep)
│ "recover_to_main_or_restart(" in **/*.py (autowsgr)
└ 3 lines found

● Search (grep)
│ "TaskExecutor|断点|checkpoint|resume|continue from|熔断|circuit" in **/*.py (autowsgr)
└ 8 lines found

● List GitHub Actions workflows in a repository (MCP: github-mcp-server) · method: "list_workflow_j…
└ {"jobs":{"total_count":1,"jobs":[{"id":70945533260,"run_id":24297726567,"run_...

● Get details of GitHub Actions resources (workflows, workflow runs, jobs, and artifacts) (MCP: git…
└ {"id":24297726567,"name":"AI Issue Analysis","node_id":"WFR_kwLOHhoLA88AAAAFq...

● Get GitHub Actions workflow job logs (MCP: github-mcp-server) · owner: "OpenWSGR", repo: "AutoWSG…
└ {"failed_jobs":0,"message":"No failed jobs found in this workflow run","run_i...

● Check if copilot_answer exists (shell)
│ if [ -f copilot_answer.md ]; then echo exists; else echo missing; fi
└ 2 lines...

● Check working tree status (shell)
│ git --no-pager status --short
└ 1 line...

● Read engine.py
│ autowsgr/combat/engine.py
└ L155:310 (155 lines read)

● Read navigate.py
│ autowsgr/ops/navigate.py
└ L24:150 (114 lines read)

● Read navigation.py
│ autowsgr/ui/utils/navigation.py
└ L53:140 (86 lines read)

● Read controller.py
│ autowsgr/ui/main_page/controller.py
└ L139:206 (68 lines read)

● Read normal_fight.py
│ autowsgr/ops/normal_fight.py
└ L117:158 (41 lines read)

● Read scheduler.py
│ autowsgr/scheduler/scheduler.py
└ L204:246 (43 lines read)

● Read event_fight.py
│ autowsgr/ops/event_fight.py
└ L152:192 (40 lines read)

● Read recognizer.py
│ autowsgr/combat/recognizer.py
└ L44:160 (117 lines read)

● Read task.py
│ autowsgr/server/routes/task.py
└ L95:200 (106 lines read)

● Read recognizer.py
│ autowsgr/combat/recognizer.py
└ L268:308 (41 lines read)

● Read scrcpy.py
│ autowsgr/emulator/controller/scrcpy.py
└ L68:84 (17 lines read)

● Read scrcpy.py
│ autowsgr/emulator/controller/scrcpy.py
└ L380:410 (30 lines read)

● Read startup.py
│ autowsgr/ops/startup.py
└ L243:322 (79 lines read)

● Read expedition.py
│ autowsgr/ops/expedition.py
└ L1:80 (57 lines read)

● Read overlays.py
│ autowsgr/ui/main_page/overlays.py
└ L42:124 (82 lines read)

● Edit
└ Create copilot_answer.md

● Read copilot_answer.md
└ L1:260 (104 lines read)

● Check changed files (shell)
│ git --no-pager status --short
└ 2 lines...

已完成，Issue #422 的分析结论已写入 copilot_answer.md。

结论核心是：该 issue 更接近架构韧性能力缺口而非单点 bug；当前主线存在局部兜底，但尚未形成“全局状态感知 + 分层自愈 + 任务级恢复”的统一闭环。

Changes +105 -0
Requests 1 Premium (2m 53s)
Tokens ↑ 1.8m • ↓ 10.2k • 1.7m (cached) • 3.6k (reasoning)

🔗 GitHub Action 运行记录

[syokounya]

建议：开设长期 feature 分支分阶段推进

@OpenWSGR/maintainers 这个 Issue 涉及 5 个 Phase 的系统性改造，总改动量预计 2000+ 行，直接以单 PR 合并到 main 风险较高。建议开设一个长期 feature 分支（如 feat/self-healing）来承载：

1. 每个 Phase 独立提 PR 到该分支，review 粒度可控，维护者可以按需渐进合并
2. 充分测试验证，我和其他愿意参与测试的用户可以基于该分支长期运行，确认稳定性后再整体合并到 main
3. 并行协作，不同 contributor 可以认领不同 Phase，避免阻塞

建议路线

阶段	内容	预计改动	测试周期
Phase 0	建立 feat/self-healing 分支	—	—
Phase 1	CombatEngine 三级恢复（中间态重同步 + 弹窗处理 + 全局定位）	~300 行	1 周
Phase 2	导航安全回退（safe_retreat_to_main + 动作后置验证）	~400 行	1 周
Phase 3	OverlayManager 统一弹层拦截	~800 行	2 周
Phase 4	TaskExecutor 分级重试与断点续传	~600 行	1 周
Phase 5	模拟器健康监控（动态超时 + 帧率统计）	~400 行	1 周
最终	合并到 main	—	—

如果维护者同意，我可以先提交 Phase 1 的 PR 到该分支。这个 Issue 的整体设计已经很完整，分阶段落地既能控制风险，也能更快让用户感受到收益。