出品/星动无极

近日在北京举行的2026开运航天AOE生态大会上，OpenSpace开源太空生态发布。发起方包括北京开运联合信息技术集团、东方空间技术（北京）、银河航天（北京）科技集团与北京航空航天大学。发起方给出的定位很明确：不制造卫星与火箭，做航天产业的底层连接器。

同一场活动上发布了开源计算星座的规划：首期2600颗，其中通算卫星1000颗、智算与超算卫星1000颗、边缘计算卫星500颗、量子计算卫星100颗。星座采用多层次、软件可定义的网络架构，把卫星当作在轨的"太空服务器"，融合通算、智算、超算、边缘计算与量子计算五类算力。

把五类算力放在一个星座里，是这份规划最需要解释的地方。通算与边缘计算是成熟技术，卫星上装通用服务器做预处理，已经在不少遥感星上验证；智算与超算受限于功耗、散热与抗辐射，单星算力与地面数据中心不在一个量级；量子计算卫星目前全球只有实验性质的在轨验证，把它写进100颗的规划，说明这是一个长周期蓝图而不是近期交付清单。

开源这件事在航天领域有先例，但成功的不多。立方星时代，标准化的结构与接口让高校和小公司能用低成本造星，这是开源思路最实在的一次落地；此后的开源卫星软件、开源地面站，多是社区自发，缺少商业闭环。OpenSpace想做的比这更大：不只是开源代码，而是开源标准、开源接口，再给开发者提供从开发工具到在轨验证的全流程支撑。

标准是这件事的核心价值，也是最大的难点。商业航天现在的痛点是标准繁杂、接口互不兼容、技术重复研发——每家卫星公司都要自己做电源管理、自己定义遥测协议、自己写地面软件。如果有一套被广泛接受的开源接口规范，中小公司可以少走很多重复的路，器件厂商也能按统一规格供货。

难点在于谁来为标准的维护买单，以及标准如何与现有的型号研制体系对接。航天型号的质量体系要求每个环节可追溯、可审查，开源社区的迭代节奏与型号研制的冻结节奏天然冲突。OpenSpace提出的区块链化架构，指向的正是可追溯这件事，但区块链记录的是数据流转，不是硬件的工艺一致性。

2600颗的规模需要对照现实。国内在轨的低轨通信星座目前是千帆与GW两个主体，各自规划上万颗，实际在轨数百颗量级；商业航天公司自建星座的规模通常在几十到几百颗。2600颗的首期规划，体量介于大型星座与专项星座之间，能否落地取决于资金、频率轨位与发射资源三件事，这三件事公开材料里都没有给出时间表。频率与轨位需要向国际电联申报，申报主体、使用期限与部署进度都有硬约束，开源社区这种松散组织很难直接承担。

开发者生态是另一道关。OpenSpace提出给开发者提供从开发工具到在轨验证的全流程支撑，这意味着要有人愿意把星上的计算资源开放出来给第三方使用，也要有一套安全隔离机制，防止一个开发者的程序影响整星运行。地面云的 multi-tenant 隔离做了十几年才成熟，太空环境下的容错与远程调试难度更大。

开源计算星座的商业模型也需要推敲。如果卫星是开源的、接口是开放的，算力怎么计价、数据归谁、在轨服务如何结算，都需要一套规则。地面上的云计算用了几十年才把计量、计费、SLA做成标准，太空算力的规则还在起草阶段。谁先把规则写出来并被接受，谁就占据了生态位。

产业意义在于分工。中国商业航天过去几年的竞争集中在"谁能造出整星、谁能打上去"，产业链的软件与标准环节长期薄弱。开源生态如果能把接口统一，整星公司可以专注平台与载荷，器件公司可以专注模块，软件公司可以专注应用，产业的协作成本会显著下降。

风险也很清楚。开源生态最怕两件事：一是发起方各自有私心，标准变成某家企业的产品说明书；二是社区热闹但没人用，最后只剩发布会。判断这个生态能不能成，可以看三个指标：一年内有多少家企业按这套接口交付了产品、社区里有多少非发起方的代码贡献、以及有没有真实的在轨验证任务由生态成员共同完成。

太空算力是这两年的热门方向，从谷歌的在轨TPU实验到SpaceX的百万颗AI卫星申请，路径各不相同。开源这条路线的价值不在算力规模，而在把参与门槛降下来。航天产业从来不缺宏大规划，缺的是让中小公司能按统一规则接进来的那套基础设施。判断它的成色，看代码提交和合同就够。