多智能体强化学习在卫星调度中的应用：从STK联调到参数调优

简介基于Python与STK11的多智能体强化学习卫星调度实验是面向人工智能、通信工程、自动化、电子信息等专业学生、教师及科研工作者的完整实践项目。其针对卫星任务规划中的多智能体协作、资源调度等关键问题提供了一套可运行的算法工程与仿真环境。压缩包共203个文件涵盖Python源码、STK场景文件(sa/sn/sc等)、实验数据csv、训练模型pth以及设计报告docx等整体约79.62MB目录结构清晰便于对照学习与二次开发。目前已有151人学习使用。除完整源码外资料中还包含多组不同数据规模的CSV观测数据、不同训练阶段的模型权重、STK仿真快照及配套文档可帮助读者理解从数据处理、模型训练到STK联调的全流程。由于代码经过严格测试、功能完善既适合新手入门进阶也能直接用于毕业设计、课程设计或项目初期演示。1. 从“一颗星”到“一群星”卫星调度为什么需要多智能体强化学习单星调度的日子已经过去了。低轨星座、对地观测网络、中继卫星协同调度对象从单颗卫星变成一个随时变化的系统卫星资源有可见时间窗约束、存储与能量约束地面站和中继链路又在动态竞争同一个任务。用规则或数学规划做小规模场景还可以一旦任务数量过百、卫星数量过十求解时间就不可控而强化学习的价值恰好在这里——它不追求全局最优解而是把调度过程变成“与环境交互中学习策略”的过程用训练好的策略网络在毫秒级输出动作天然适合这种每时每刻都在变化的场景。标题里出现 python 与 stk11 的组合是有原因的STK11AGI Systems Tool Kit 的第 11 版负责高精度轨道预报与可见性计算python 负责把 STK 算出来的几何关系变成多智能体强化学习可以理解的观测与奖励。STK 解决“卫星什么时候能看到目标”的问题强化学习解决“看到了之后该不该拍、拍了存在哪、什么时候下传”的决策问题。两个问题叠加就是一套完整的卫星调度实验环境。这篇文章不打算复述某个开源项目的目录结构而是顺着“把环境搭起来、把算法跑通、把参数调好”这条主线讲清楚一套可复现的多智能体卫星调度实验该怎么做。适合正在做强化学习课程设计、需要交实验报告的研究生也适合刚接触 STK 二次开发的工程师——文章里的每段代码都对应一个可验证的环节。2. python 与 STK 联调先让仿真环境和强化学习环境对上话2.1 用 STK11 的 Connect 接口把轨道计算变成 Python 函数STK11 本身是一个庞大的航天仿真软件支持轨道预报、覆盖分析、可见性计算、链路分析等功能。卫星调度实验里最常用到的能力是“计算卫星对地面目标的可见时间窗口”。这个计算背后涉及轨道外推、地影判断、传感器视场约束这些是 STK 的看家本领没必要在 python 里重新实现。难点在于如何让 python 进程和 STK 进程之间建立起稳定、低延迟的通信。STK 提供了多种 python 对接方式最常见的两种是 COM 接口和 Connect 命令接口。COM 接口适合在 Windows 上做对象级操作可以直接读取卫星的轨道参数、传感器指向但稳定性受限于 STK 的 GUI 状态。Connect 接口是文本命令流python 通过 TCP 端口发送命令、接收返回适合批处理场景。在调度实验里环境与策略网络会频繁交互Connect 接口的轻量特性更合适。import socket STK_HOST localhost STK_PORT 5001 # 默认 Connect 端口 def send_command(cmd: str, timeout: float 10.0) - str: 向 STK Connect 端口发送命令并接收回显 with socket.create_connection((STK_HOST, STK_PORT), timeouttimeout) as sock: sock.sendall(f{cmd}\n.encode(utf-8)) recv_data [] while True: chunk sock.recv(4096).decode(utf-8) recv_data.append(chunk) if END in chunk: break return .join(recv_data) # 示例请求一个可见性计算窗口的起始时间 resp send_command(GetAccess /Satellite/SAT1 /Target/TARGET1) print(resp)代码说明send_command函数封装了 socket 通信的完整流程每次调用都会建立连接、发送命令、等待以END结尾的完整响应后关闭。GetAccess是 Connect 命令中查询可见性的核心指令它会返回两对象之间的可见时间窗口列表。注意 timeout 参数要设置合理长周期的可见性计算有时会超过 5 秒取 10 秒比较安全如果场景里卫星数量多建议改用持久化连接而不是每次重连。2.2 用 gymnasium 封装 STK把轨道预报包装成强化学习标准接口连接 STK 只是打通了通信链路要让多智能体强化学习算法能用上这个环境还需要一层标准封装。OpenAI Gym 与其继承者 gymnasium 是强化学习领域事实上的环境接口标准它定义了reset()和step()两个核心方法reset()负责把环境恢复到初始状态并返回初始观测step(action)接收智能体的动作、推进仿真一步并返回新观测、奖励、终止标志和额外信息。任何一个强化学习算法库无论是 Stable-Baselines3、Ray RLlib 还是自研的 PPO 实现都可以直接驱动这个接口。import gymnasium as gym import numpy as np class STKSatelliteEnv(gym.Env): 将 STK 仿真封装为 gymnasium 环境 def __init__(self, stk_conn, satellite_ids, target_ids): super().__init__() self.conn stk_conn self.satellites satellite_ids self.targets target_ids self.action_space gym.spaces.Discrete(3) # 0不动作 1成像 2下传 self.observation_space gym.spaces.Box(low0, high1, shape(len(satellite_ids), 6)) def reset(self, seedNone): 重置场景到初始时刻返回初始观测 self.conn.send_command(SetEpoch / * 1 Jan 2024 00:00:00.000) return self._get_observation(), {} def step(self, actions): 执行动作推进一个决策步长返回 (观测, 奖励, 终止, 截断, 信息) rewards [] for sat_idx, action in enumerate(actions): if action 1: rewards.append(self._execute_imaging(sat_idx)) elif action 2: rewards.append(self._execute_downlink(sat_idx)) else: rewards.append(0.0) self.conn.send_command(Animate * Time 10) # 推进 10 秒 done self._check_episode_end() return self._get_observation(), float(np.mean(rewards)), done, False, {}封装逻辑说明action_space定义每个智能体可选的动作种类这里是三个离散动作observation_space的形状由卫星数和每个卫星的特征维度决定特征可以包括目标可见标志、存储占用率、电量剩余比例等。step里先执行各智能体的动作再统一推进仿真时间最后返回平均奖励作为全局奖励。这种封装方式把 STK 完全隔离在环境内部上层算法只看到标准的 gymnasium 接口后续替换算法时环境代码完全不用动。2.3 环境安装与验证跑通第一个 CartPole 式的最小闭环环境封装完成后建议先做一个最小可行性验证再正式进入多智能体训练。常见做法是暂时把 STK 的可见性计算替换成随机数据用这个简化版环境跑通算法逻辑确认状态流转、奖励计算、回合结束这三个环节没有问题再接入真实 STK 数据。这样做的原因是 STK 的逐秒推进非常耗时如果算法和环境接口存在 bug排错成本会翻倍。# 创建虚拟环境并安装依赖 python -m venv satrl_env source satrl_env/bin/activate # Windows 下为 satrl_env\Scripts\activate pip install gymnasium numpy stable-baselines3 # 验证 gymnasium 环境注册与随机策略运行 python -c from gymnasium.utils.env_checker import check_env env STKSatelliteEnv(stk_connconn, satellite_ids[SAT1], target_ids[T1]) check_env(env) # 官方环境合规性检查 obs, _ env.reset() for _ in range(10): actions [env.action_space.sample()] obs, reward, done, truncated, info env.step(actions) if done: break print(环境闭环验证通过) 参数说明check_env是 gymnasium 提供的环境检查工具会验证action_space与step返回值的类型是否合规、reset是否返回二元组等细节。概率上新手最容易犯的两个错误是reset返回值格式不对新版要求(obs, info)二元组以及observation_space与真实观测形状不一致。这两个问题靠肉眼很难发现用check_env可以一次性扫出来。3. 多智能体强化学习如何作用于卫星调度从问题建模到算法选择3.1 把卫星调度问题映射成 MARL 的标准范式多智能体强化学习并不是把单智能体算法复制多份那么简单。单智能体中agent 只需要考虑自己的动作如何影响环境而多智能体面临的核心问题是非平稳性——每个智能体的策略都在变化导致其他智能体眼中的环境转移函数也在变化。在卫星调度场景中这种非平稳性体现在卫星 A 决定对某个目标成像会占用存储和能源可能影响卫星 B 通过星间链路获取数据地面上传调度指令的窗口是共享资源多颗卫星同时申请下传时存在竞争。要把问题形式化成 MARL需要明确三件事智能体划分、状态空间定义、奖励分配方式。智能体划分有两种常见做法。第一种是以单颗卫星为一个智能体适合卫星数量少、每颗卫星独立决策的场景第二种是以“卫星-任务对”为一个智能体适合任务量大于卫星数量、需要精细分配的场景。卫星调度实验里前者更常见因为它更接近物理实体的边界——每颗卫星有自己的存储、能量和传感器决策天然解耦。缺点是卫星之间的协同信息需要靠观测或共享奖励来传递训练难度会增加。状态空间按“局部可观测”来设计。每颗卫星的观测包括当前时刻、目标可见性标志、存储占用比例、电量比例、已执行任务数量、当前指向角。这些信息通过 STK 的场景查询接口逐项获取组装成一个实值向量。如果采用集中训练分布式执行的架构CTDE还需要考虑是否加入全局状态——比如所有卫星的存储占用总和——用于训练阶段的 critic 网络。奖励设计是调度实验中最关键的环节。常见的分解方式是完成一次有效成像给予正奖励成像数据成功下传再给予额外奖励任务逾期取消则给予负奖励存储溢出或电量耗尽给予较大的负向惩罚。注意多智能体场景下奖励分配有“全局奖励”和“个体奖励”两种选择。全局奖励是整支星座的总收益个体奖励只反映单颗卫星的表现。实际经验是二者结合效果更好可以写成reward_i alpha * r_local_i beta * r_global其中alpha和beta是权重系数。只在个体奖励下训练卫星容易陷入自私策略比如抢占最容易成像的目标而不顾整体收益只在全局奖励下训练又面临信用分配问题——某颗卫星做了错误决策全局奖励下降时它并不知道是自己导致的。折中方案是让alpha取 0.7、beta取 0.3配合经验池的随机采样训练效果通常比较稳定。3.2 从 IQL 到 MAPPO卫星调度该选哪个算法明确了问题建模方式之后算法选择是下一个决策点。热词里提到了 IQL 离线强化学习和 MAPPO 等算法这两者在卫星调度实验中正好代表了两种不同的技术路线。IQLIndependent Q-Learning是最简单直接的多智能体改造方式——每个智能体独立维护一个 Q 网络只用自己的观测和奖励做训练完全忽略其他智能体的存在。这个方案实现简单、调试容易适合快速验证问题建模是否正确但非平稳性问题会导致训练后期震荡。在卫星数量不超过 5 颗、任务冲突不激烈的小规模实验中IQL 已经能得到可用的策略。如果实验规模更大比如卫星数量超过 10 颗、目标点超过 50 个我会直接选择 MAPPOMulti-Agent Proximal Policy Optimization。MAPPO 是 PPO 在多智能体场景下的扩展核心思想是集中训练、分布执行训练时 critic 网络可以看到所有智能体的观测和动作actor 网络只能看到自己的观测。这样既缓解了非平稳性问题又不牺牲执行阶段的独立性。import torch import torch.nn as nn import torch.optim as optim class MAPPOActor(nn.Module): 每个智能体的策略网络局部观测 - 动作概率分布 def __init__(self, obs_dim, action_dim, hidden_dim128): super().__init__() self.net nn.Sequential( nn.Linear(obs_dim, hidden_dim), nn.ReLU(), nn.Linear(hidden_dim, hidden_dim), nn.ReLU(), nn.Linear(hidden_dim, action_dim), nn.Softmax(dim-1) ) def forward(self, obs): return self.net(obs) class MAPPOCritic(nn.Module): 集中式价值网络全局状态 - 状态价值 def __init__(self, global_obs_dim, hidden_dim128): super().__init__() self.net nn.Sequential( nn.Linear(global_obs_dim, hidden_dim), nn.ReLU(), nn.Linear(hidden_dim, hidden_dim), nn.ReLU(), nn.Linear(hidden_dim, 1) ) def forward(self, global_state): return self.net(global_state)网络结构说明actor 网络的输出层用Softmax激活得到每个离散动作的选择概率critic 网络的输入是全局状态所有卫星观测的拼接输出是一个标量价值估计。MAPPO 的更新方式与单智能体 PPO 相同都是最大化带裁剪的替代目标函数区别在于计算优势函数时使用集中式 critic 的估值。实际训练时每轮收集 2048 步经验用 4 个 epoch 更新策略裁剪系数取 0.2这个配置在多数调度场景下都能稳定收敛。3.3 训练框架选择自研还是用 RLlib算法确定之后要选训练框架。如果坚持“纯 python 手写”代码量会很大——PPO 本身要处理优势估计、GAE、经验回放、学习率调度等细节加上多智能体的经验收集与分发至少要多写几百行。行业内的常见做法是使用 Ray RLlib 或 Stable-Baselines3 搭配多环境并行。RLlib 对多智能体的支持更原生内置了 MAPPO、QMIX、VDN 等算法还提供了多进程采样、参数共享、经验重放等现成模块。但 RLlib 的学习曲线比较陡它的配置系统非常灵活反而容易让人迷失。如果是课程设计或中期检查这类的节点我更推荐用 Stable-Baselines3 里的 PPO 配合自定义多智能体包装器。SB3 的 PPO 实现质量高文档清晰调试时打印的训练指标更直观。下方代码展示了如何用 SB3 训练一个多智能体环境from stable_baselines3 import PPO from stable_baselines3.common.vec_env import DummyVecEnv, SubprocVecEnv def make_env(rank: int): def _init(): env STKSatelliteEnv(stk_connconn, satellite_ids[fSAT{i} for i in range(6)], target_ids[T1, T2, T3]) return env return _init # 多进程并行采样6 颗卫星共用一份策略参数共享 # 每颗卫星通过 env_index 区分自己的观测入口 vec_env SubprocVecEnv([make_env(i) for i in range(4)]) model PPO( MlpPolicy, vec_env, learning_rate3e-4, n_steps2048, batch_size256, gamma0.99, gae_lambda0.95, clip_range0.2, ent_coef0.01, verbose1 ) model.learn(total_timesteps200_000) model.save(satellite_mappo_model)配置说明n_steps2048表示每次收集 2048 步经验后更新一次策略配合 4 个并行环境实际采样量为 8192 步batch_size256表示每次梯度更新从中抽取 256 条样本ent_coef0.01是熵正则系数调大可以增加探索程度调小则更偏向利用已学到的策略。卫星调度场景中动作空间较小熵系数设太小容易过早收敛到次优策略0.01 是一个经验上比较平衡的起点。4. 训练中的关键参数与常见陷阱从震荡到收敛的调参路径4.1 影响多智能体训练效果的三个核心参数reward scaling、entropy、clip range多智能体卫星调度实验跑到一半最常遇到的现象是训练曲线上来就冲得很高然后在某个点附近剧烈震荡最后 loss 不降、reward 不涨。这种情况大概率不是算法代码的问题而是参数配置不当。奖励的尺度问题排在第一位。STK 环境里一次成像的奖励如果直接设为 100下传奖励设为 200这种量级差异会撑爆 PPO 的梯度更新导致策略在几个 epoch 内发生剧烈变化。常见做法是在环境返回值上做缩放把奖励控制在 [-1, 1] 区间内。# 奖励缩放将原始奖励压缩到 [-1, 1]避免梯度爆炸 def normalize_reward(reward, scale100.0): 原始奖励除以 scale保证量级在 [-1, 1] 附近 return max(-1.0, min(1.0, reward / scale)) # 实际调用时 raw_reward self._execute_imaging(sat_idx) # 假设返回 150 scaled_reward normalize_reward(raw_reward, scale100.0) # - 1.0参数说明scale的选择有讲究。取太小会把奖励压缩得过平智能体无法区分好动作和差动作取太大会失去归一化的意义。建议先跑一轮评估统计原始奖励的最大值再取最大值的 1.5 倍作为scale的初始值。如果训练过程中发现策略收敛到“什么都不做”多半是负奖励惩罚过重需要把scale调大。entropy 系数在多智能体场景下需要比单智能体调得更高。原因是多智能体环境的非平稳性天然会让策略输出变得尖锐——某个智能体发现一个动作在当前回合获得了高奖励会立刻加大选择这个动作的概率这个动作在下一回合可能因为其他智能体策略变化而变得低效。ent_coef取 0.01 甚至 0.02能有效避免这种过早的确定性。clip range 则控制每次更新的幅度上限0.2 是 PPO 论文的标准配置但在奖励信号较为稀疏的卫星调度场景可以尝试降低到 0.1以提升训练的稳定性。4.2 样本效率低试试 IQL 预热加 MAPPO 微调的两阶段训练卫星调度环境的交互成本很高。STK 每推进一次观测需要重新做轨道外推和可见性计算复杂场景下这一步可能耗时 10 毫秒以上。如果每轮训练需要 2048 步经验实际采一条 rollout 就需要几十秒。这让 MAPPO 这类 on-policy 算法的样本效率问题被放大——每次策略更新后旧的采样数据全部作废必须重新采样。对应策略是两阶段训练先用离线数据预训练价值网络再切到在线交互微调。从热词里提到的 IQL 离线强化学习出发这个方案的实现是先用随机策略或规则策略在 STK 环境中采样一批历史轨迹存成离线数据集然后用 IQL 在离线数据上预训练每个智能体的 Q 网络最后把 Q 网络输出的 Q 值作为特征拼接到 MAPPO 的观测中继续用在线交互微调策略。这种做法的效果在任务密集度过高、单次 rollout 中冲突频繁的场景下优势明显——预训练阶段学会了大部分调度经验在线阶段只需要微调边界情况。# 两阶段训练伪代码IQL 预热 MAPPO 精调 # 阶段一IQL 离线预训练 from iql import IQLAgent # 假设自研的 IQL 实现 offline_data load_offline_trajectories(satellite_trajectories.h5) iql_agent IQLAgent(state_dim12, action_dim3) for epoch in range(50): q_loss iql_agent.train_on_batch(offline_data.sample(256)) print(fEpoch {epoch}, Q-loss: {q_loss:.4f}) # 阶段二将 Q 网络输出作为额外观测维度接入 MAPPO from mappo import MAPPOAgent mappo_agent MAPPOAgent( state_dim12 3, # 原始观测 Q 值 action_dim3 ) mappo_agent.train_with_env(env, total_steps100_000)阶段划分的逻辑是IQL 只依赖离线数据不与环境交互学到的 Q 值即使不精确也包含了“哪个动作在哪个状态下大概率更好”的先验信息。把 Q 值直接作为观测的一部分传入 MAPPO相当于给策略网络额外提供了一条信息通道。这个设计在丁健等团队的卫星调度研究中被验证过其价值在于缓解了 on-policy 算法冷启动阶段的盲目探索问题。4.3 卡在局部最优检查智能体是否吞掉了共享资源训练一段时间后 reward 曲线持平不再增长需要检查的不是网络结构而是环境建模是否出现了资源竞争失衡。卫星调度场景里最容易被忽略的是存储资源的共享约束。如果所有卫星使用同一个地面站下传数据那么下传窗口变成了共享资源某颗卫星频繁占用下传窗口其他卫星的存储就会溢出表现为“个别卫星 reward 很高整体 reward 很低”。排查方法是把每个智能体的个体 reward 拆出来曲线对比。如果 A 卫星的 reward 持续上升而 B 卫星持续下降说明策略进入了自私模式。常规解法有两种一是把环境设计成“下传窗口轮询”——同一时刻只允许一颗卫星下传且按卫星编号轮转二是在共享资源被占用时给予负向惩罚让智能体学会避让。建议两种都做前者保证环境层面的公平性后者提供策略层面的负反馈信号。5. 验证实验效果用最简单的基线方法判断训练是否真的有效5.1 对照实验用随机调度和贪心调度量化提升幅度强化学习实验报告里最容易被质疑的一点是训练曲线上升是否只是环境随机性的统计波动。要回答这个问题需要跑对照实验。基线方法越简单越好随机调度——每颗卫星在每个决策时刻均匀随机选择一个动作贪心调度——只要有可见目标且存储足够就去成像只要存储超过 80% 就尝试下传。这两条基线不需要任何学习过程直接在同一环境下跑 100 个训练回合统计平均奖励和任务完成率。import numpy as np def evaluate_policy(env, policy, episodes100): 对给定策略运行多个回合返回平均奖励与完成率 total_rewards, completion_rates [], [] for _ in range(episodes): obs, _ env.reset() done False ep_reward, completed 0.0, 0 while not done: actions policy(obs) # 策略函数输入观测输出动作列表 obs, reward, done, truncated, info env.step(actions) ep_reward reward if info.get(task_completed, 0) 0: completed 1 total_rewards.append(ep_reward) completion_rates.append(completed / env.num_tasks) return np.mean(total_rewards), np.mean(completion_rates) # 三组策略对比 random_reward, random_completion evaluate_policy(env, lambda obs: [env.action_space.sample() for _ in range(6)]) greedy_reward, greedy_completion evaluate_policy(env, greedy_policy) trained_reward, trained_completion evaluate_policy(env, trained_model_policy) print(fRandom: reward{random_reward:.2f}, completion{random_completion:.2%}) print(fGreedy: reward{greedy_reward:.2f}, completion{greedy_completion:.2%}) print(fTrained: reward{trained_reward:.2f}, completion{trained_completion:.2%})评估结果的使用方式重点对比 trained 相对 greedy 的提升幅度。通常 5% 到 15% 的任务完成率提升说明策略学到的是有效信息如果负于 greedy则优先检查奖励设计是否合理——可能成像的消耗没有被计入负奖励导致策略倾向于“不管有没有价值都拍”。随机策略的数值不用于判断优劣只用于确认环境本身没有正负失衡。5.2 看 STK 里的实际调度结果不只是看 reward 曲线数值指标之外实验验证还有最后一道工序就是在 STK 的二维或三维可视化窗口中观察训练后的策略产出的调度方案是否物理合理。打开 STK 窗口逐颗卫星检查动作发生时刻是否落在 STK 计算的可见时间窗内——如果策略模型输出了成像动作但此时 STK 判定不可见说明环境接口的观测延迟或状态同步出现了偏差再检查重复成像的次数——如果同一目标被多颗卫星重复成像且没有合并逻辑训练过程实际上是在做无用功只会浪费存储。一个我自己常做的经验性检查是把所有成像动作按时间轴画成甘特图。正常收敛的策略成像动作应该集中在可见窗口的中段而不是窗口边缘。因为可见窗口边缘往往对应较低仰角成像质量差而环境没有显式地把仰角因素放进观测如果策略学到的分布仍然偏向中段说明策略自发学习到了窗口的统计规律。如果甘特图显示出明显的边缘集中优先怀疑是奖励函数的时序偏差——比如奖励没有扣除等待时间需要加入与窗口中心的距离惩罚项来修正。5.3 参数建议速查验证环节结束后把常用的参数整理成一张速查表方便复跑时对照。下表综合了多轮实验的典型配置适用于 6 颗卫星、20 个目标点的中等规模实验场景。参数推荐值说明actor 隐藏层维度128卫星数量少时 64 足够超过 10 颗建议 256critic 隐藏层维度128需拼接全部智能体观测维度跟不上容易欠拟合学习率3e-4训练不稳定时优先降为 1e-4gamma0.99调度属于长程回报问题不宜低于 0.95GAE lambda0.95稀疏奖励下推荐 0.95密集奖励可降至 0.9clip range0.2奖励抖动大时降为 0.1并行环境数4机器内存允许时可加到 8提升采样速度单次经验收集步数2048过小导致策略更新噪声大过大则训练周期长奖励 scale原始最大奖励的 1.5 倍保证归一化后范围为 [-1, 1]参数含义的最后一条补充表中的 “奖励 scale” 不是超参数里可以自动搜索出来的部件它直接影响 PPO 内部优势估计的数值稳定性。如果调了一圈学习率、clip range 都没改善回头检查一下这个值它往往才是根因。做实验记录时把视角从“调参记录”切换成“奖励量级分析”会更容易定位到问题。本文还有配套的精品资源点击获取