企业官网建设流程全解析

前面两篇讲了分布式和批量实验。这篇讲一个更远的方向：把 AFSIM 从"人操控的推演工具"变成"AI 智能体的训练环境"。

我在接 wsf_external_control 做 TCP 控制的时候，脑子里一直有一个念头——这套指令接口，如果发指令的不再是我（或者 Java 规则引擎），而是一个训练好的神经网络，会怎样？

一、lock-step 时间协议：AI 怎么"看见"和"出手"

AFSIM 要让 AI 接入，第一步是把时间控制权交出去。你不能让引擎自己跑——AI 需要"看一眼 → 想一下 → 做一个动作"的循环，每一步之间引擎必须暂停。

AFSIM 2.9 的SetTimeParameters+PauseAndRequestAdvance就是干这个的。它的锁步（lock-step）协议工作方式是这样的：

1. 外部调用SetTimeParameters，设定步长（比如 1 秒）和起始时间
2. AFSIM 引擎推进到下一个步长节点，自动暂停
3. 暂停期间，外部 AI 通过 wsf_external_control 读取当前 Track 列表（观察）
4. AI 根据态势推理，生成动作（下 FlyToEvent 或 FireWeaponEvent）
5. AI 调用Resume()让引擎继续
6. 引擎执行动作，推进到下一个步长节点，再次暂停
7. 循环

这就是一个标准的 RL 循环：

# AI 训练主循环（Python 伪代码）env=AFSIMEnv(scenario='batch/engagement.txt',step_interval=1.0)obs=env.reset()# 加载想定，引擎暂停在 t=0forstepinrange(max_steps):action=agent.select_action(obs)# 神经网络推理obs,reward,done,info=env.step(action)# 下发动作 → 引擎推进 → 返回新状态agent.store_transition(obs,action,reward,next_obs,done)ifdone:breakagent.learn()# 从经验回放中更新策略

备注：这个循环我跑通过，但说实话，效率是个大问题。AFSIM 引擎本身是 C++，但通过 TCP 和 Python 通信，每一步都有一个 RTT 的延迟——在我的机器上大约 5–15ms。如果训练需要几百万步，这个延迟累加起来很可观。有人用共享内存（mmap）代替 TCP 来做跨进程通信，延迟能降到 1ms 以内，但需要改 wsf_external_control 的通信层。

二、Gym 环境封装：observation 空间怎么设计

把 AFSIM 包成 Gym 环境，最难的不是接口，是 observation 和 reward 的设计。

observation 空间。你不能把整个 Track 列表拍扁成一维向量塞给神经网络——Track 数量是变化的（探测到新目标会增加、目标被摧毁会减少），固定长度的向量装不下。有几个做法：

• 栅格特征图（Grid-based）。把战场切成网格，每个格子编码"是否有我方/敌方/中立单位"“单位类型”“速度方向”。这种表示是固定尺寸的，CNN 可以直接处理。代价是丢失精度——两个在同一格子里的单位对模型来说无法区分。
• 实体列表（Entity List）。把每个 Track 编码为一个定长向量（类型 one-hot、归一化位置、速度），整个 observation 是变长列表。需要 Transformer 或 GNN 这类能处理变长输入的模型。表示精度最高，但模型复杂度也最高。
• 混合表示。全局特征用几个标量（己方存活数量、弹药库存、时间），局部关系用注意力机制（哪些目标在射程内、哪些友军能支援）。在实践中性价比较高。

我在实验里用的是一个简化版：把 observation 做成 12 个浮点数——UAV_01 的位置(2)、Enemy_Ship 的位置(2)、UAV 的传感器状态(1)、武器库存(1)、相对距离(1)、相对航向(1)、时间剩余(1)、以及 3 个二值特征（目标是否在射程内、是否已开火、是否已命中）。12 个浮点数，MLP 就能处理，训练很快。

reward 设计。这是最不好拍脑袋的。太稀疏（只在终局给 reward + 击沉 = +100 / 己方被击沉 = -100），模型学几千回合都不知道方向。太密集（每秒给一个存活奖励），会让智能体躲在一边不接敌。

我的做法：基础 reward 是 0；每探测到一个敌方 Track 给 +0.1（鼓励搜索）；首次进入武器射程给 +1（鼓励抵近）；每次有效命中给 +5；击沉目标给 +20；己方被击中给 -10。中间反馈密度够了，又不至于让模型只盯着局部小奖励忘了大局。

三、多智能体对抗训练：红蓝双方一起学

单智能体是对着"规则对手"学（比如 Enemy_Ship 按预设航线运动、按固定交战规则开火）。这种训练的模型拿出来打真人（或另一个 AI），基本是一碰就碎——因为它只学会了对付那一种"傻"对手。

更好的做法是自我博弈（Self-Play）。红蓝双方各跑一个策略网络、同一个环境里对抗。每次红方赢了，红方网络加强这局的行为；蓝方赢了同理。反复对抗之下，双方的策略会互相逼迫着进化——跟 AlphaGo 那套 self-play 一个思路。

# 自我博弈架构red_agent=PPOAgent(obs_dim=12,action_dim=5)blue_agent=PPOAgent(obs_dim=12,action_dim=5)forepisodeinrange(100000):obs=env.reset()done=Falsewhilenotdone:# 红方决策red_obs=extract_red_obs(obs)red_action=red_agent.select_action(red_obs)env.send_command('red',red_action)# 蓝方决策blue_obs=extract_blue_obs(obs)blue_action=blue_agent.select_action(blue_obs)env.send_command('blue',blue_action)# 推进obs,rewards,done,info=env.step()red_agent.store(red_obs,red_action,rewards['red'],done)blue_agent.store(blue_obs,blue_action,rewards['blue'],done)red_agent.learn()blue_agent.learn()

工程上有两个实际困难：第一，PPO 的训练需要大量 rollout，几千甚至几万局。AFSIM 单局仿真虽然快（3600 秒想定 ≈ 2 秒跑完），但 self-play 要同时跑红蓝两个智能体、加上神经网络推理，每局大概 3–5 秒。训练一个像样的策略需要 50–100 小时。多机并行（每台机器一个 warlock 实例 + 一个本地 Agent 进程）可以把时间压到几小时。

第二，策略收敛后怎么评估。不能只看"红方胜率"——因为蓝方也在变强，胜率可能是 50% 上下波动（说明双方势均力敌）。更靠谱的做法是定期把训练中的红方 Agent 拿出来跟几个"固定基线对手"打（比如"原地不动"基线、"随机行动"基线、"上一个训练版本的蓝方"基线），看它在各基线上的得分趋势。

四、从仿真策略到真实系统：迁移的工程桥接

训练出来的策略不能说"能用在真实指挥系统里"——仿真和真实之间有本质差距。但有几件事是可以做的，而且工程价值不低：

• 策略作为决策辅助。不直接让 AI 操控系统，而是把策略的"推荐行动"显示在态势界面上，操作员决定采纳还是否决。实质上就是 Maven Smart System 在做的事。
• 想定参数优化。策略训练过程中发现的"最优参数组合"（比如"在雷达发现目标后延迟 3 秒再开火存活率最高"），可以反向写入 DoDAF 的 OV-6c 作战规则和 StdV-1 标准配置。
• 对抗训练数据生成。用训练好的 AI 生成"高质量对抗样例"——什么样的态势下该做什么样的决策——然后拿这些样例去训练更通用的决策模型。这就是"仿真生成数据驱动真实模型"的路径。

这一块作者研究还在早期阶段，但方向是明确的。AFSIM 的 lock-step 协议和 wsf_external_control 已经提供了"把仿真变成 RL 环境"的基本条件。剩下的就是算法侧的工作——更大的模型、更高效的并行训练、更好的 Sim-to-Real 迁移方法。