实战：找最好的攻击位 / 掩体位

把前面三节合起来做两个实际查询。这两个查询可以直接抄进项目。

查询 A：远程兵的攻击位

目标：与目标保持 10~20m，有视线，偏好在 NavMesh 上且不挤队友。

EnvQuery ATK_Position
├ 生成器：Circle(Querier, R=20m, Spacing=0.8m, MaxPoints=200)
├ 导航过滤：仅 NavMesh
├ 测试：
│   ├ [过滤] 距离目标 8~22m
│   ├ [过滤] Trace 到目标无阻挡（可看到）
│   ├ [权重 3] 与队友距离远（避免挤一起）
│   └ [权重 1] 离查询者近
└ 排序：总分最高

用法：AI 每 2 秒"重新评估站位"时跑一次，结果写黑板 DesiredPosition，行为树移动过去。

查询 B：掩体位（挨打时）

目标：快速躲到一个挡住敌人的地方。

EnvQuery CVR_Position
├ 生成器：Circle(Querier, R=10m, Spacing=1m, MaxPoints=100)
├ 测试：
│   ├ [过滤] Trace 到目标被阻挡（挡住 = 掩体有效）
│   ├ [权重 2] 距离近（赶紧躲）
│   └ [权重 1] 点位中点到目标连线的角度（贴掩体边探身打）
└ 排序：总分最高

注意两个查询的差异：攻击位要"看得见"，掩体位要"看不见"。同一套生成器 + 不同测试组合就服务两种战术——这就是 EQS 的复用价值。

接入行为树

缓存策略：不要每帧查。攻击位每 2~3 秒重查一次就足够智能了（每次查询都是一次小规模空间运算）。

调参的验证方法

把 EQS 查询的"调试绘制"打开（编辑器里 Run with Debug），看 AI 站位选择是否符合预期： - 全是红点 → 过滤太严，放宽必要条件； - 全是绿点（找不到规律）→ 权重区分度不够，拉开权重差距； - AI 站到墙后打不到人 → 视线测试方向反了，检查 Test 的"从 / 到"情境。