1. 航天器素来谨慎为什么现在要谈生成式自主1.1 传统遥控模式的现实瓶颈前几年我参与一个深空任务软件评审老工程师问得最多的一个问题星上自主决策如果出了偏差地面上连止损的机会都没有你凭什么让我把控制权交给一个模型这个问题问得很实在。航天器从诞生起就是“地面遥控”的产物地面站把指令序列上行到星上星上按照时间表或事件条件机械执行。这种模式稳定运行了几十年可靠性极高但也逐步走到极限。以火星任务为例单程光时延5到20分钟一次完整的“发现现象-传回地面-分析决策-上传指令”闭环动辄耗费几个小时到一天。对环绕器来说这个延迟还能忍但遇到突发科学目标、尘暴来临、姿态异常这类时间敏感事件地面指挥的节奏往往跟不上。更远的木星甚至更远的深空目标光时延变成几十分钟起步传统的“地面事事拍板”模式基本不可持续。所以航天器自主性不是新概念上世纪90年代NASA的Deep Space 1任务就做过Remote Agent自主规划实验当时还闹出过名气很大、教训也很深的事件。只是那个时代的技术栈以规则引擎和约束求解为主能覆盖的状态空间有限工程界对它的信任一直没建立起来。最近两年讨论的Generative AI是另一路思路不再靠人穷举规则而是让模型从大量数据中学会“在什么情况下做什么”再通过约束机制保证输出不越界。它解决的不是“能不能让航天器自己动”的问题而是“能不能让航天器面对没见过的情况时临时生成一个还说得过去的方案”的问题。1.2 工程师真正恐惧的是什么同行之间聊起星上AI最常听到的担忧其实不是“AI会不会造反”而是三个字没法证。航天软件有一套严格的安全与可靠性工程流程从需求追踪、架构评审到覆盖率测试每一步都要求可追溯、可复现。传统软件虽然复杂但它是确定性系统同样的输入永远产生同样的输出测试人员可以对着分支覆盖表和边界条件把行为证明给你看。生成式模型本质上是概率系统温度参数一改输出就变即便温度归零也未必能从工程上说明“为什么生成的是这条路径而不是另一条”。飞行软件评审会上你要拿“模型已经训练得很好了loss很低”去回应安全性质疑是远远不够的。另一个具体恐惧是幻觉。语言模型在开放域里能编出看似合理的地面指令落到航天环境里可能就是灾难。我见过一个演示让某通用大模型生成一个卫星太阳翼展开后的姿态调整方案模型一本正经地给出了一个指向太阳的固定角度但没有考虑地影遮挡也没有考虑动量轮饱和边界输出在形式上完全正确物理上却是死的。这个例子说明一个核心矛盾生成式AI的强项是对语言的流畅控制而非对工程约束的严格维护。航天工程师的恐惧本质上是对“不可证明”和“可能幻想”的双重反感。所以要真正让航天器获得自主不能拿生成式模型直接替换传统控制器而是要把模型放进一个可验证的工程框架里。这个想法并不复杂但做起来牵扯到架构调整、验证策略、甚至团队协作方式的改变。这篇文章后面就围绕这条主线展开。2. 生成式AI正在星上扮演的四个新角色2.1 星上任务规划从查表到生成可行方案传统星上规划用的大多是查表加约束搜索沿用指令序列库遇到的状态组合超出枚举范围就无解。火星车遇到一块之前没见过的岩石、想测试一块凸起样本时地面人员往往要花一两天时间编排新指令。瓶颈不在计算速度而在建模成本把所有地形、光照、坡度、机械臂可达空间编成规则库是一项人工投入极大的工程。生成式AI进入这个场景的方式是把“生成候选计划”和“验证候选计划”拆开。模型根据当前科学目标、姿态、能源余量、通信窗口等输入输出一批候选动作序列这些候选不直接执行而是交给一个独立的验证器做约束检查。验证器里是传统的动力学模型、功耗模型和安全规则库它只负责说“哪条可行、哪条不可行”。模型负责发散验证器负责收敛最终从可行候选里挑一个评分最高的执行。这个架构从工程视角看很舒服因为可靠性边界由验证器定义而不是由一个说不清内部逻辑的神经网络定义。我在仿真里实测过一个简化版本效果让我挺意外。传统规划器在遇到两个意外约束叠加时会直接返回“无解”比如太阳翼收拢状态触发功率限制同时姿态机动窗口只剩20分钟。生成式候选生成器在这种情况下仍能产出几条突破固定模板的序列虽然大部分被验证器判死但确实存在一条“降功率-切换备份传感器-完成科学观测-再恢复对日定向”的路径是规则库里没有写的。这也是为什么越来越多团队开始研究这个方向目的不是摆脱传统控制而是给传统控制补上没见过的那部分场景。2.2 异常检测用“生成期望”代替固定阈值卫星遥测健康管理传统上靠阈值判断电压低于多少伏告警、温度高于多少度联动。问题在于真实故障往往是模式级的动量轮转速正常但电流波形与健康状态有明显差别太阳能帆板输出功率下降但幅度没超阈值这些在阈值法下标不出来等真标出来时故障往往已经扩大了。生成式模型在这里的用法是学习系统健康状态的分布然后根据当前遥测序列“生成期望的下一个观测”。比如变分自编码器或扩散模型训练时见过大量正常工况数据推理时输入一小段历史遥测重构出下一时刻“应该是什么样”把实际观测和生成期望做残差分析残差超过统计范围就触发异常。这种思路能捕捉到阈值法永远发现不了的缓慢漂移因为模型学到的是高维模式不是单个物理量的上下界。当然这个方向要落地也要踩坑。最典型的问题是训练数据绝大部分来自仿真少数来自在轨遥测仿真和真实环境的分布差异会直接让残差判定失灵。我见过一个轨控系统的异常检测原型在仿真数据上F1分数漂亮迁移到真实历史遥测马上误报率飙升。解决办法是做两件事一是大量用真实遥测做微调和域适应二是异常检测只作为“监视器”给出建议不直接触发关键动作。这个角色定位让它可以更快进入工程流程。2.3 科学数据压缩与增强在带宽有限下多看几眼这个方向是目前最容易落地、安全风险也最低的。深空通信带宽极其宝贵探测器采集了大量科学数据但下行通道只能传回一小部分。以前的做法是地面预先决定哪些数据值得传一旦决策错了科学机会就永远错过。生成式模型可以在这方面提供一种“选择性压缩”能力在星上通过轻量级生成模型对数据进行超分辨率重建、缺失值补全或者生成一个低码率版本传回地面地面用更强的模型恢复出细节。这样带宽不变传回顾有价值的信息却变多了。一个我比较看好的案例思路光谱仪采集的海量高维数据星上先用异常检测模型筛出“最有科学价值”的低概率事件只对这些数据做完整下行背景数据则用生成模型压缩后下行。相当于模型帮科学家在几万条观测里挑出了可能相关的亮点。这个模式不碰执行器不做飞行路径决策只做筛选与压缩在评审时容易讲得清。更重要的是它建立了一条“AI在星上运行”的完整工程链路为后续更高风险的应用铺路。2.4 自然语言指令接口人机交互从菜单变成对话航天器地面操控系统几十年来的交互方式是表单、命令序列和脚本门槛高操作慢。生成式AI在这里带来的改变很朴素地勤人员和未来深空任务中的宇航员可以直接用自然语言输入意图比如“把太阳翼角度调到能让发电量最高的位置但不要对星上实验造成遮挡”系统用语言模型把这个意图转译成结构化的任务规划请求再交给上文说的验证闭环去检查可行性。这个角色是最安全的一种因为模型不直接生成执行指令它生成的只是一个“意图结构体”实际执行仍然走传统指令链路。人在回路里模型可以犯错最后签字执行的仍然是地面控制人员。但它的意义不可小觑它让非轨控专家也能准确表达复杂操作意图把操作员从大量低层细节里解放出来。目前这个方向在一些地面支持系统里已经进入试点阶段我判断它比星上自主更早普遍落地。3. 信任问题怎么给“会编”的模型装上约束围栏3.1 黑盒输出与航天验证标准之间的冲突航天软件安全性的根子在于可验证性。传统标准流程要求每一行需求都追溯到代码每一段逻辑都能写出确定性行为描述。生成式模型的参数量和训练过程决定了它无法给出这种传统意义上的解释硬要解释得到的也是近似归因离“形式化证明”差了十万八千里。所以这中间的冲突本质上是范式冲突而不是工作量的冲突。你没法用加班的办法让一个GPT类模型去通过DO-178C那样的确定性验证。如果设计上默认模型输出直接参与闭环那么这个系统在可预见的未来都过不了正式审查。但如果换一个思路把模型当作候选生成器不在安全关键路径上承担最终责任冲突就迎刃而解。验证的对象变成了“验证器本身的正确性”和“生成器输出空间的覆盖范围”这两个问题都可以用传统手段证明。具体做法上我比较推崇“生成-验证-执行”三段式。模型只负责提出“可以做什么”验证器负责确认“哪个能做”执行器只做最后一步。实际系统里这个验证器可能是一个独立运行的约束求解器也可能是对动力学模型做区间仿真的模拟器。无论模型怎么折腾系统的“安全底线”由验证器锚定。这样虽然不能消除所有不确定性但把不确定性限制在了一个可接受的尺度上。3.2 约束解码与生成-验证闭环给模型加围栏第一层是输出格式约束。航天任务规划语言通常有严格语法如果让语言模型自由输出自然语言验证器还得先做一层文本解析解析错误本身就是新的故障源。更稳的办法是约束解码在生成过程中就限制模型的输出必须符合规划语言的文法模型只能在合法语法树上做选择。这有点像给一个爱自由发挥的作家发了一张严格押韵的格子纸任你怎么发挥都得在格子里。再往上走一层是语义约束。语法合法不代表物理可行所以生成器的输出还要经过规划验证器做语义检查。这个验证器需要用约束规划或形式化方法处理时间窗口、资源消耗、功率预算和安全包络。以我之前在仿真里搭的原型为例核心流程可以简写成下面这个形式def constrained_plan(goal, telemetry, generator, verifier): candidates [] for _ in range(candidate_count): plan generator.generate( goal, telemetry, grammaracquisition_dsl_grammar, temperature0.3 ) if verifier.check( plan, dynamics_modelflight_dynamics, safety_limitsconfig.safety_limits ): candidates.append(plan) return argmax(candidates, keyscience_value_score)这里生成器可以有多个候选验证器决定生死最后按科学价值评分挑一个。关键点是即使生成器在某次推理中产生了幻觉只要验证器判定不通过这个幻觉就永远不会变成星上指令系统的安全属性仍然由验证器承担。温度参数在这里值得多说一句。很多团队在星上场景会把温度设成0追求确定性输出我在实际测试中发现这样做反而更差。温度归零会让模型陷入重复的局部模式候选多样性下降验证器没得选。保持0.3左右的低温度同时增加候选数量能显著提高“至少有一个候选通过验证”的概率。这个参数取舍是个工程问题不是越大越好也不是绝对不能调。3.3 影子模式与渐进式认证信任不是一蹴而就的。工程上最有效的做法叫影子模式新算法上线后长期并排在真实系统旁边运行它的输出只进日志不碰执行器。地面人员把影子输出的建议和真实飞控的指令做比对积累运行样本统计它“如果当时真的执行了会造成什么后果”。这个过程跑上几个月甚至一年得到的不是模型在测试集上的性能指标而是它在真实任务环境中的行为充分性证据。有了这些证据认证路径就可以分成台阶。低风险的辅助功能最先上比如遥测显示优化、地面数据处理、科学数据筛选这些功能失效也不会影响飞行安全评审压力小。积累经验后再往星上非关键监视功能走如异常检测告警它介入的是“提示”层面。最后才是高风险的自主规划而且即便到这一步也要保证地面可以随时切回传统控制模式且回退路径本身经过充分测试。这种渐进式认证不只是为了过审从工程角度也是负责任的。我见过一些研究团队在仿真里把自主规划器的成功率调到95%以上就急着要上天但没人能讲清楚剩下5%的失败模式长什么样。影子模式至少能告诉你那5%在真实数据上到底是什么模样是安全性可接受的偏差还是压根不该放出来的风险。4. 已上天的实验与可复现的实操路线4.1 这些年真正飞过的自主性实验讲了一堆架构和原理来看看真实世界的进度。NASA JPL的AEGIS系统算是一个标杆已经部署在火星车上用于自主挑选岩石目标做光谱分析。火星车在移动过程中用导航相机图像识别候选岩石自主选定一个有科学价值的探测目标整个过程不需要地面逐条下发指令。AEGIS的特征提取和选目标分类器是传统机器学习方法跟“生成式”还有距离但它证明了“星上自主科学决策”这条路的可行性。欧空局的OPS-SAT是一个专门用于在轨验证的CubeSat平台过去几年开展了多项AI实验包括基于神经网络的云检测、星星地图像语义分割、异常检测等。它最大的意义在于提供了一台“可以放心折腾”的实验星让很多算法有机会在真实太空环境中拿到遥测而不是永远活在仿真里。这类实验卫星的兴起某种程度上改变了星载AI验证的节奏。回头看1999年的Deep Space 1 Remote Agent很多人只知道它是自主规划先驱却忘了它当年也出过事在飞行过程中远程代理产生了不一致的状态估计导致推进系统误判最终靠地面干预才恢复。这个事情给整个领域留下了长期阴影也直接促成了后来“生成器负责发散、验证器负责安全”的架构共识。所以当你在调研文献时看到很多系统刻意把AI放在“建议层”而非“执行层”多少都能追溯到这些早期的教训。4.2 一个“生成验证”规划管的原型实现纸上谈兵没意思我把一个简化版原型的关键思路分享一下这个东西没有用真实星载硬件但在仿真环境里跑通了完整闭环对理解工程落地很有帮助。任务场景一颗对地观测卫星需要在一个轨道圈内完成多个观测目标但目标之间有时间窗口约束、储能约束和姿态机动时间约束。传统做法是用一个序列规划器求解生成一条满足约束的观测顺序。我在原型里把规划器替换成“生成候选验证器筛选”的结构。生成器用了一个轻量级语言模型微调输入是当前剩余目标列表、卫星储能水平和姿态机动时间表输出是若干条候选观测序列。验证器是一个用区间算法写的约束检查器负责逐条判断序列是否违反时间窗口和功率边界。实测下来的几个数字单星, 12个目标场景下传统约束规划器平均求解时间在1.8秒左右生成与验证方案在4个并行候选中选出可行解的时间是0.6秒且在高冲突场景下找到解的概率明显更高。代价是生成器那几个候选里有大量会被验证器毙掉的“废案”这个现象是正常的不要以为生成器输出多准它真正的作用是给验证器提供足够多样的输入。性能瓶颈完全在验证器不在生成器这个和很多人直觉相反。代码层面需要注意的另一个细节是语料。我们不可能用通用语言模型直接生成规划序列它完全没见过这类语义。需要准备一批历史规划解或者人工标注的“废案”来做微调目标不是让它学会最优解而是让它熟悉语法和常见语义。微调后的模型精度没有特别惊艳但对候选多样性的贡献立竿见影。4.3 在仿真平台上的建议落地路径如果你想在自己项目里复现类似的管线目前开源工具有几个不错的选择。Basilisk是一个提供姿态和轨道动力学仿真的框架可以搭出比较真实的卫星控制环境适合做算法闭环测试。规划验证器可以用Google OR-Tools的CP-SAT求解器它对时间窗口和资源约束的表达能力足够。语言生成部分小尺寸的开源模型加PEFT微调在消费级显卡上就能完成实验不必一开始就上几十B参数的大模型。建议落地路径分三步。第一步做纯离线实验搜集任务历史数据生成候选训练验证器计算“验证器判断与人工判断的一致性”。第二步做在线影子实验让生成器在仿真环境里旁路运行输出保存在日志里由飞控人员在仿真事件里复盘。第三步才考虑接入闭环将验证器输出接到仿真卫星的执行层观察闭环行为。每一步都留下中间工件特别是验证器的误判案例分析这些东西到正式评审时都是关键证据。有一个坑要提前说很多团队在第一步就卡住了因为历史任务数据太干净全是成功计划缺少带约束冲突的反例。训练验证器时如果只见过正样本它会变得过度乐观把明显违例的方案也放行。解决办法是自动生成大量扰动负样本把目标时间窗口随机调乱、功率余量随机压低人为制造冲突场景喂给验证器。这个数据增强步骤是验证器可靠性的基石不能省。5. 把生成式AI送上星载系统的五个实操忠告5.1 别让模型直接触碰执行器这个建议听起来保守但它是整个工程可信度的根基。生成式模型定位为“建议引擎”而不是“决策引擎”可以大幅度降低评审难度和操作风险。实际执行必须经过验证器和传统控制链模型输出和指令之间留一道硬隔离。这条铁律我建议写进架构文档而不是靠团队自觉。有一些团队会不甘心觉得都做成这样了为什么还要多加一道验证这不是浪费算力吗我的回答是这道验证器是你给外部审查者看的行为边界也是出了问题时责任划分的锚点。没有它你没办法回答“如果这个AI犯错了怎么办”有了它你可以说“AI犯错了但验证器把它拦住了”。这个论证方式在安全性评审里几乎必须。5.2 训练数据分布永远是最大的坑星载系统的数据分布问题和互联网场景完全不同。互联网数据多到用不完太空场景数据少到珍贵。大多数使用的训练数据来自仿真仿真模型对真实环境的简化会在模型输出的决策中产生系统性偏差。最典型的例子是姿态控制仿真里忽略的太阳光压扰动在地面模型里是个小项在真实太空里经历了几个月累积后效果不可忽略。处理这个问题的工程手段是域随机化在仿真训练中加入随机扰动让模型见过各种边界情况。但域随机化治标不治本根本解法还是积累真实数据。实验卫星和已部署系统的遥测回传哪怕只用来做异常检测微调也比纯仿真数据可靠得多。所以我的建议很直接别让算法团队只看仿真数据尽早接真实遥测哪怕指标短期变差也是值得的你在消除分布偏移。5.3 资源受限下的模型裁剪实测星载处理器和地面GPU不可同日而语。抗辐射处理器性能通常只有工控机的几分之一内存以兆字节计算还要考虑功耗和热控。一个通用大模型在星上做实时推理当前基本不现实。实际可行的方向是轻量级模型加量化压缩。把视觉骨干网络替换为MobileNet类的小模型再量化到int8可以控制在几兆字节的模型体积内。我在测试中发现这样的裁剪对异常检测任务的影响可控但对任务规划这类语义复杂任务影响明显。规划任务现阶段更适合放到地面用大模型处理星上只做规则验证和低层闭环。这个“地面生成、星上验证”的混合架构可能是未来几年最现实的路线。地面有充足算力大模型可以跑得很充分生成的计划通过通信链路上行后星上传统的验证器仍然把关。这样既享受了生成式模型的灵活性又回避了星载算力的瓶颈唯一的代价是通信延迟对低延迟需求不敏感的任务完全可接受。5.4 团队与评审流程的适配最后说一个常被忽视的软性问题。一个采用生成式AI的航天项目团队构成必须从“纯飞控工程师”变成“飞控算法安全验证”三方协作。我参加过不少评审最常见的尴尬是AI工程师讲不清楚约束规划器的证明机制飞控工程师理解不了注意力机制和损失函数安全工程师夹在中间不知道从哪下手。这种沟通错位会拖垮整个项目节奏。解决方式不是培养全才而是建立一套共同的评审语言系统级的安全属性列表。评审不讨论“模型为什么输出这个”只讨论“验证器是否覆盖了所有危险情况”。这种以验证边界为核心的评审方式比各说各话高效得多。另外模型版本管理要和传统软件版本管理纳入同一流程模型参数的每一次更新都要有详尽记录否则审计时无法回答“当前飞行的到底是哪个版本”。5.5 预留回退路径是最后的体面任何自主系统都可能出现兜不住的情况最后一道善意提醒是一定要设计一条清晰、可测试的回退路径而且这条回退路径要在仿真和地面演练里反复验证。航天器的工作环境没有重来一次的按钮自主系统再强也要保证地面人员随时可以接管。甚至可以说自主性的价值不是取代地面控制而是在地面接管能力有限的时候给任务争取更多生存时间。这个定位想清楚了许多架构争论都会迎刃而解。