[10-1] NodeTracker 忽略带路条件，在分支点误判当前节点为 B

[syokounya]

在提交您的问题反馈之前

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

相关环境信息

• 操作系统: Windows 10/11
• 模拟器: mumu
• AutoWSGR 版本: 最新主干分支 (autowsgr/combat/node_tracker.py 等文件)

问题描述

在 10-1 地图的移动阶段，NodeTracker.update_node() 会忽略游戏内的带路条件，仅根据 YAML 地图数据中的 next 字段和几何距离来判定当前节点。这导致在满足去 A 节点的带路条件时，程序仍可能误判当前位置为 B 节点。

具体表现为：

1. 10-1.yaml 中节点 "0" 的 next 字段配置了 ["A", "B"]：

   "0":
     position: [900, 427]
     next: [A, B]

2. NodeTracker 在 update_node() 中（第 395-402 行）会将 A、B 全部作为候选；
3. 随后仅通过欧几里得距离（第 412-424 行）选择最近的一个，而不考虑当前舰队阵容是否满足去 B 的带路条件；
4. 当小船当前像素位置 (0.931, 0.719) 距离 B (0.820, 0.556) 更近时（距离 0.1979），直接判定为节点 B。

这导致 10-1 中所有基于节点 B 的后续决策（阵型选择、夜战策略等）被错误应用。
关键观察：

• 视觉检测完全正常（小船像素验证 OK，阵型识别 OK）。
• 问题出在 NodeTracker 的决策逻辑：候选列表包含 B 且距离最近，因此直接选了 B。

---

根因分析

查阅源码 autowsgr/combat/node_tracker.py：

# 第 395-402 行：确定候选节点列表
if current_data is not None and current_data.next_nodes:
    # 新格式：仅在 next_nodes 中搜索
    candidate_names = current_data.next_nodes

# 第 412-424 行：欧几里得距离选最近节点
for name in candidate_names:
    node = self._map_data.get(name)
    if node is None:
        continue
    dist = _euclidean_distance(sx, sy, node.x, node.y)
    if dist < best_distance:
        # ...

以及 autowsgr/combat/engine.py 中的轮询调用（第 266-270 行）：

def _poll_map(screen):
    click_speed_up(device)
    if tracker is not None:
        tracker.update_ship_position(screen)
        new_node = tracker.update_node()  # 纯几何距离，无带路条件过滤

NodeTracker 目前不具备带路条件评估能力，而 engine.py 也未在调用前对候选节点进行过滤。

---

建议的修复方向

1. 短期（文档/配置层）：在文档中明确说明，地图 YAML 的 next 字段应当仅包含当前条件下可达的节点。对于强带路分支地图，可能需要用户为不同带路条件维护多套地图配置，或精简 next 连接。

2. 长期（代码层）：在 NodeTracker.update_node() 或 CombatEngine._get_poll_action() 中引入带路条件过滤机制：

   • 在计算最近节点前，先根据当前 GameContext（舰队阵容、航速、索敌值等）过滤掉不可达的候选节点；
   • 或者允许 CombatPlan / 上层决策模块动态注入候选节点列表，而非完全依赖 YAML 中的静态 next。

---

附加上下文

• 上游仓库: https://github.com/OpenWSGR/AutoWSGR
• 涉及文件:
  • autowsgr/combat/node_tracker.py
  • autowsgr/combat/engine.py
  • autowsgr/data/map/normal/10-1.yaml

autowsgr_2026-04-22.debug.log

复现方法

1. 选择 10-1 地图。
2. 配置一个满足去 A 带路条件的舰队（例如满足航速/舰种条件，游戏内实际只会前往 A）。
3. 启动战斗脚本，进入地图移动阶段。
4. 观察日志输出：
   • NodeTracker 会正确检测到小船位置；
   • 但节点更新时会从 0 误判为 B，而非游戏实际前往的 A。

Log输出

23:25:18.698 | DEBUG    | combat/node_tracker.py:352 | [NodeTracker] 小船位置更新: (0.931, 0.719) [黄色簇检测+像素验证]
23:25:18.699 | DEBUG    | combat/node_tracker.py:397 | [NodeTracker] 当前节点 '0', 下一节点候选列表: ['A', 'B']
23:25:18.699 | DEBUG    | combat/node_tracker.py:465 | [NodeTracker] 节点更新: 0 → B (距离 0.1979), 位置: (0.931, 0.719)
23:25:22.393 | DEBUG    | vision/matcher.py:206 | [Matcher] 'choose_formation' OK (6/6 规则匹配, 策略=all)

[github-actions]

Issue 概要

• issue：#458
• 版本 / 分支 / 环境：Windows 10/11，MuMu；附件日志为 autowsgr_2026-04-22.debug.log（6911 行），对应 2026-04-22 晚间多次 10-1/极地海峡 常规战运行
• 任务 / 入口 / 相关设置：常规战 10-1，作战计划节点白名单为 ['A', 'C']（日志可见），但地图 10-1.yaml 起点 0 的 next 同时包含 A/B
• 关键提示 / 报错文案：无崩溃；核心现象是节点追踪日志持续出现 0 → B，随后在 节点=B 执行 SL
• 用户现象：满足去 A 的带路条件时，NodeTracker 仍把当前节点判成 B，导致后续节点策略（阵型/SL）按 B 分支执行

附件概览

• 实际可读文件：autowsgr_2026-04-22.debug.log
• 缺失或未上传的证据：舰队配置导出（用于证明带路条件）、对应计划 YAML 原文、现场截图/录屏、同次运行的 UI 导出

关键证据

点击此处展开

• issue 正文 / 评论：
  • issue 正文明确指出 10-1 分支点判定错误；评论仅有机器人“分析中”，无人工结论。
• 运行时日志：
  • 同一份日志内多次复现：当前节点 '0', 下一节点候选列表: ['A', 'B'] 后直接 节点更新: 0 → B（例如 23:25:18、23:34:00、23:35:18、23:38:00、23:51:07、23:52:13、23:53:19、23:54:44）。
  • 与之对应，[History] [FORMATION] | 节点=B | 动作=SL 多次出现（计数 5 次）。
  • 统计上，日志中 0 → B 出现 8 次，0 → A 出现 3 次，说明分支判定不稳定且明显受几何位置影响。
• UI / 服务日志：
  • 任务与地图识别正常（[OPS] 常规战: 10-1、地图识别: 第10章 10-1 极地海峡）。
  • 关键链路为：节点误判 B → FORMATION 阶段按 B 节点动作执行 SL → 强制重启游戏。
• 配置快照：
  • 日志显示计划节点为 ['A', 'C']，并非包含 B 的路线。
• 现场图 / 转储：
  • 无截图、无崩溃转储。
• 代码依据：
  • 10-1 地图起点同时声明 next: [A, B]：

    AutoWSGR/autowsgr/data/map/normal/10-1.yaml

    Lines 1 to 7 in 7578cfd

    	"0":
    	position:
    	- 0.938
    	- 0.793
    	next:
    	- A
    	- B

  • 地图解析仅读取 position/next，无“带路条件”字段：

    AutoWSGR/autowsgr/combat/node_tracker.py

    Lines 171 to 189 in 7578cfd

    	def _parse(cls, raw: dict[str, Any]) -> MapNodeData:
    	"""解析 YAML 数据为 MapNodeData。"""
    	nodes: dict[str, NodePosition] = {}
    	for key, value in raw.items():
    	name = str(key)
    	if isinstance(value, dict):
    	# 格式: {"position": [x, y], "next": ["B", "C"]}
    	pos = value.get('position', [0, 0])
    	next_nodes = value.get('next', [])
    	rel_x = pos[0]
    	rel_y = pos[1]
    	nodes[name] = NodePosition(
    	name=name,
    	x=rel_x,
    	y=rel_y,
    	next_nodes=list(next_nodes),
    	)

  • 节点判定候选来自 current + next_nodes，当前实现仍未引入舰队/索敌/航速等条件过滤：

    AutoWSGR/autowsgr/combat/node_tracker.py

    Lines 431 to 487 in 7578cfd

    	current_data = self._map_data.get(self._current_node)
    	# 要求地图必须包含路由信息
    	if current_data is None or not current_data.next_nodes:
    	_log.warning(
    	"[NodeTracker] 节点 '{}' 缺少路由信息 (next_nodes)，无法判定下一节点",
    	self._current_node,
    	)
    	return self._current_node
    	_log.debug(
    	"[NodeTracker] 当前节点 '{}', 下一节点候选列表: {}",
    	self._current_node,
    	current_data.next_nodes,
    	)
    	# 将当前节点也作为候选，避免在移动途中被强制前推
    	candidate_names = list(dict.fromkeys([self._current_node, *current_data.next_nodes]))
    	ray_hit_threshold = 0.01
    	best_node = self._current_node
    	best_ray_distance = float('inf')
    	best_euclidean_distance = float('inf')
    	candidate_metrics: list[str] = []
    	candidate_distances: list[tuple[str, float, float]] = []
    	for name in candidate_names:
    	node = self._map_data.get(name)
    	if node is None:
    	continue
    	euclidean_dist = _euclidean_distance(sx, sy, node.x, node.y)
    	if has_ray:
    	ray_dist = _point_to_ray_distance(node.x, node.y, sx, sy, vx, vy)
    	else:
    	# 无法构建射线时，退化为纯欧氏距离比较
    	ray_dist = euclidean_dist
    	candidate_metrics.append(
    	f'{name}(ray={ray_dist:.4f}, euclid={euclidean_dist:.4f}, pos=({node.x:.3f},{node.y:.3f}))',
    	)
    	candidate_distances.append((name, ray_dist, euclidean_dist))
    	ray_hits = [item for item in candidate_distances if item[1] < ray_hit_threshold]
    	if ray_hits:
    	best_node, best_ray_distance, best_euclidean_distance = min(
    	ray_hits,
    	key=lambda item: (item[2], item[1]),
    	)
    	elif candidate_distances:
    	_log.warning(
    	'[NodeTracker] 射线距离未命中阈值 (<{:.4f})，回退到最小射线距离选择',
    	ray_hit_threshold,
    	)
    	best_node, best_ray_distance, best_euclidean_distance = min(
    	candidate_distances,
    	key=lambda item: (item[1], item[2]),
    	)

  • 引擎在地图轮询阶段直接使用 tracker.update_node() 结果覆盖当前节点：

    AutoWSGR/autowsgr/combat/engine.py

    Lines 252 to 275 in 7578cfd

    	def _get_poll_action(self, last_phase: CombatPhase) -> Callable[[np.ndarray], None] | None:
    	"""根据当前状态和模式大类，返回每轮匹配前执行的动作。
    	MAP 模式下，地图移动期间执行加速点击、节点追踪、资源弹窗点掉；
    	SINGLE 模式下仅加速点击。
    	"""
    	category = MODE_CATEGORIES.get(self._plan.mode)
    	if self._phase is CombatPhase.FIGHT_PERIOD:
    	return lambda _: time.sleep(0.5)
    	if category is ModeCategory.MAP:
    	if self._is_map_routing_phase(last_phase):
    	tracker = self._tracker
    	device = self._device
    	def _poll_map(screen: np.ndarray) -> None:
    	click_speed_up(device)
    	if tracker is not None:
    	tracker.update_ship_position(screen)
    	new_node = tracker.update_node()
    	if new_node != self._node:
    	self._node = new_node
    	dismiss_resource_confirm(device, screen)
    	return _poll_map

  • 后续战斗决策按 _node 取节点策略执行：

    AutoWSGR/autowsgr/combat/plan.py

    Lines 262 to 270 in 7578cfd

    	def get_node_decision(self, node: str) -> NodeDecision:
    	"""获取指定节点的决策，不存在则返回默认决策。"""
    	return self.nodes.get(node, self.default_node)
    	def is_selected_node(self, node: str) -> bool:
    	"""节点是否在白名单中。"""
    	if not self.selected_nodes:
    	return True # 未配置白名单 = 全部允许
    	return node in self.selected_nodes

    、

    AutoWSGR/autowsgr/combat/handlers.py

    Lines 169 to 183 in 7578cfd

    	decision = self._get_current_decision()
    	# 白名单检查
    	if not self._plan.is_selected_node(self._node):
    	click_retreat(self._device)
    	self._last_action = 'retreat'
    	self._history.add(
    	CombatEvent(
    	event_type=EventType.SPOT_ENEMY,
    	node=self._node,
    	action='撤退',
    	extra={'reason': '不在预设点'},
    	)
    	)
    	return ConditionFlag.FIGHT_END

根因判断

• 直接结论：
  • 已证实根因是 NodeTracker 的候选节点来自静态 next，未接入“带路条件”评估；当 0 同时连向 A/B 时，会按几何规则选点，从而可能与游戏真实分支不一致。
• 证据链：
  • 日志反复出现 0 -> B，随后触发 B 节点动作（SL）；
  • 计划配置目标节点是 A/C；
  • 代码中不存在将舰队状态或带路条件用于候选过滤的实现。
• 当前主线是否可能已修复：
  • 未完全修复。当前主线虽然已将判定改为“射线优先 + 欧氏回退”，但仍缺少带路条件过滤，根因仍在（只是误判概率可能变化）。

修复方案

1. 代码 / 配置 / 资源层修复
   • 在地图数据层支持“带路条件”描述（建议按边定义，如 0 -> A/B 各自条件）。
   • 在 NodeTracker.update_node() 前增加候选过滤：输入当前 GameContext（舰队、航速、舰种等）后，仅保留可达边再做几何判定。
   • 若条件信息缺失，至少输出显式 warning，并在关键分支节点禁止执行高风险动作（如直接 SL）。
2. 需要补充的测试、日志或截图
   • 为 10-1 增加回放测试：同一轨迹下，满足 A 条件时不能落到 B。
   • 增加“候选过滤前后列表”调试日志，便于排障。
3. 如问题属于不支持场景，应如何限制入口或改进提示
   • 在文档中明确：仅靠静态 next 的地图，存在强带路图误判风险；对这类图建议禁用分支敏感策略或改成保守默认策略。

给用户的建议

• 用户现在可以直接尝试的动作：
  • 临时将 A/B（以及 B 的后续分支）配置为相同保守策略，避免误判后立刻 SL。
  • 若当前计划仅允许 A/C，可暂时放宽白名单并统一这些节点策略，先保证流程不中断。
• 是否建议升级 / 重下完整包 / 重置配置 / 更换环境：
  • 建议升级到最新主线（当前节点判定逻辑已有迭代），但该 issue 的根因在主线上仍可能存在。
• 是否有临时绕过方案：
  • 有：把分支敏感动作从“首分支点”后移，或在首分支前统一策略，减少误判影响。

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

点击此处展开

现象：
10-1 首分支在满足去 A 条件时，NodeTracker 仍可能把节点 0 判成 B，导致后续节点策略（含 SL）按 B 执行。

关键证据：
- 日志多次出现：
  [NodeTracker] 当前节点 '0', 下一节点候选列表: ['A', 'B']
  [NodeTracker] 节点更新: 0 → B (...)
  [History] 记录事件: [FORMATION] | 节点=B | 动作=SL
- 计划加载显示节点为 ['A', 'C']，与 B 不一致。
- 代码里候选来自 next_nodes，未按带路条件过滤。

可能相关线索（待验证）：
1) 地图边缺少“可达条件”建模（仅有静态 next）。
2) update_node 的几何判定应在“条件过滤后”执行，而不是对全部 next 直接算距离。
3) 条件缺失时，首分支节点应降级为安全策略而非直接执行高风险节点动作。

置信度

• 中
• 还缺什么证据：同次复现的舰队配置导出/截图（用于严格证明“游戏实际必走 A”），以及用户当时确切代码版本（日志行号与当前主线实现存在差异）。

---

点击此处展开分析过程

● skill(generic-issue-log-analysis)

● Get issue details (MCP: github-mcp-server) · method: "get", owner: "OpenWSGR", repo: "AutoWSGR", …
  └ {"number":458,"title":"[10-1] NodeTracker
    忽略带路条件，在分支点误判当前节点为 B","body":"...

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

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

我先把 issue 附件日志拉到本地并并行核对相关代码实现，确认这是否是当前主线仍存在的问题。

● Search (grep)
  │ "next_nodes|next:|NodeTracker|带路|route|condition|fleet|航速|索敌"
  │ (autowsgr/combat)
  └ 103 lines found

● Read node_tracker.py
  │ autowsgr/combat/node_tracker.py
  └ L320:520 (197 lines read)

● Read 10-1.yaml
  │ autowsgr/data/map/normal/10-1.yaml
  └ 98 lines read

● Read engine.py
  │ autowsgr/combat/engine.py
  └ L220:340 (116 lines read)

● Download issue log and get HEAD SHA (shell)
  │ mkdir -p .cache/issue-logs/issue-458 && curl -L --fail -o
  │ .cache/issue-logs/issue-458/autowsgr_2026-04-22.debug.log https://github.com
  │ /user-attachments/files/26978612/autowsgr_2026-04-22.debug.log && git
  │ rev-parse HEAD && wc -l
  │ .cache/issue-logs/issue-458/autowsgr_2026-04-22.debug.log
  └ 7 lines...

● Read node_tracker.py
  │ autowsgr/combat/node_tracker.py
  └ L1:240 (240 lines read)

● Search (grep)
  │ "next_nodes|next:|路由|带路|条件|condition" (docs)
  └ 16 lines found

● Search (grep)
  │ "NodeTracker|10-1|节点更新|下一节点候选列表|小船位置更新|choose_formation|ER
  │ ROR|WARNING|Warn|Exception|Traceback"
  │ (.cache/issue-logs/issue-458/autowsgr_2026-04-22.debug.log)
  └ 7 lines found

● Read usage_combat.md
  │ docs/usage/usage_combat.md
  └ L1:260 (260 lines read)

● Compute distances from reported ship position (shell)
  │ python - <<'PY'
  │ import math
  │ sx,sy=0.931,0.719
  │ A=(0.868,0.321)
  │ B=(0.82,0.554)…
  └ 6 lines...

● Extract relevant log lines around reported time (shell)
  │ rg -n "23:25|\[NodeTracker\]|choose_formation|10-1"
  │ .cache/issue-logs/issue-458/autowsgr_2026-04-22.debug.log | head -n 220
  └ 2 lines...

● Search (grep)
  │ "23:25:18|23:25:19|23:25:20|23:25:21|23:25:22"
  │ (.cache/issue-logs/issue-458/autowsgr_2026-04-22.debug.log)
  └ 12 lines found

● Search (grep)
  │ "\[NodeTracker\]"
  │ (.cache/issue-logs/issue-458/autowsgr_2026-04-22.debug.log)
  └ 7 lines found

● Search (grep)
  │ "10-1|chapter|map|normal_fight|fight|plan|舰队|fleet"
  │ (.cache/issue-logs/issue-458/autowsgr_2026-04-22.debug.log)
  └ 7 lines found

● Read copilot-tool-output-1776876524309-3rk488.txt
  │ /tmp/copilot-tool-output-1776876524309-3rk488.txt
  └ L1:220 (87 lines read)

● Read copilot-tool-output-1776876524314-fblpi5.txt
  └ /tmp/copilot-tool-output-1776876524314-fblpi5.txt

● Search (grep)
  │ "NodeTracker|next:|地图节点|路由信息|带路|分支|next_nodes" (docs)
  └ 11 lines found

● Read combat-engine.md
  │ docs/architecture/combat-engine.md
  └ L360:430 (68 lines read)

● Read engine.py
  │ autowsgr/combat/engine.py
  └ L286:320 (34 lines read)

● Read handlers.py
  │ autowsgr/combat/handlers.py
  └ L120:240 (121 lines read)

● Read copilot-tool-output-1776876524309-3rk488.txt
  │ /tmp/copilot-tool-output-1776876524309-3rk488.txt
  └ L80:160 (11 lines read)

● Read engine.py
  │ autowsgr/combat/engine.py
  └ L92:150 (59 lines read)

● Search (grep)
  │ "10-1|normal_fight|计划|plan|node_args|selected_nodes|SL|History]
  │ 记录事件|节点=B|节点=A|restart_game|强制重启游戏"
  │ (.cache/issue-logs/issue-458/autowsgr_2026-04-22.debug.log)
  └ 7 lines found

● Search (grep)
  │ "get_node_decision|is_selected_node|selected_nodes|nodes=|node_args|NodeDeci
  │ sion" (autowsgr/combat/plan.py)
  └ 23 lines found

● Read copilot-tool-output-1776876561343-om8l1h.txt
  │ /tmp/copilot-tool-output-1776876561343-om8l1h.txt
  └ L1:240 (95 lines read)

● Search (grep)
  │ "节点=B \| 动作=SL|节点=A \| 动作=SL|节点=B \| 动作=阵型|节点=A \|
  │ 动作=阵型|\[Combat\] 节点追踪器已加载: 10-1|10-1"
  │ (.cache/issue-logs/issue-458/autowsgr_2026-04-22.debug.log)
  └ 7 lines found

● Read plan.py
  │ autowsgr/combat/plan.py
  └ L250:360 (92 lines read)

● Search (grep)
  │ "当前节点 '|下一节点候选列表|节点更新: 0 → B|记录事件: \[FORMATION\] \|
  │ 节点=B \| 动作=SL|加载作战计划: 10-1"
  │ (.cache/issue-logs/issue-458/autowsgr_2026-04-22.debug.log)
  └ 48 lines found

● Read plan.py
  │ autowsgr/combat/plan.py
  └ L1:120 (120 lines read)

● Search (grep)
  │ "\[History\] 记录事件: \[FORMATION\] \| 节点=B \| 动作=SL"
  │ (.cache/issue-logs/issue-458/autowsgr_2026-04-22.debug.log)
  └ 1 file found

● Search (grep)
  │ "节点更新: 0 → A"
  │ (.cache/issue-logs/issue-458/autowsgr_2026-04-22.debug.log)
  └ 1 file found

● Search (grep)
  │ "节点更新: 0 → B"
  │ (.cache/issue-logs/issue-458/autowsgr_2026-04-22.debug.log)
  └ 1 file found

● Search (grep)
  │ "\[History\] 记录事件: \[FORMATION\] \| 节点=A \| 动作=SL"
  │ (.cache/issue-logs/issue-458/autowsgr_2026-04-22.debug.log)
  └ No matches found

我已经拿到 issue、评论、附件日志和相关代码证据，下一步会把结论整理成固定模板并写入 `copilot_answer.md`。

● Search (glob)
  │ "copilot_answer.md"
  └ No matches found

● Edit
  └ Create copilot_answer.md

● Verify occurrence counts in issue log (shell)
  │ python - <<'PY'
  │ from pathlib import Path
  │ p=Path('.cache/issue-logs/issue-458/autowsgr_2026-04-22.debug.log')
  │ text=p.read_text(encoding='utf-8', errors='ignore')
  │ for s in ['节点更新: 0 → B','节点更新: 0 → A','[History] 记录事件: …
  └ 9 lines...

● Read copilot_answer.md
  └ 100 lines read

✗ Edit
  └ Edit copilot_answer.md

● Edit
  └ Edit copilot_answer.md

● Read copilot_answer.md
  └ L18:26 (9 lines read)

● Remove temp logs and show changed files (shell)
  │ rm -rf .cache/issue-logs/issue-458 && git --no-pager status --short
  └ 2 lines...

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

结论核心是：该问题在 issue 对应环境下可由日志与代码共同证实，根因是 `NodeTracker` 仅基于静态 `next` 候选做几何判定，未接入带路条件过滤，导致 `10-1` 首分支会把应走 A 的场景误判到 B，并触发错误节点策略（含 SL）。当前主线虽改进了几何判定策略，但仍未从根本上引入带路条件过滤。


Changes   +103 -2
Requests  1 Premium (4m 32s)
Tokens    ↑ 1.2m • ↓ 11.8k • 1.1m (cached) • 6.0k (reasoning)

🔗 GitHub Action 运行记录