本文来自微信公众号： 太空与网络 ，作者：老谭
讨论中国星上计算平台，已经不能再从“有没有”开始。过去几年，中国已经完成了多轮技术验证：天智一号验证了开放架构和星载应用，天智二号D星把开放软件栈、应用上载和持续更新带入在轨试验，SpaceOS天卓具备在轨编程与任务重构能力，三体计算星座则把单星验证推进到多星组网、模型部署和协同计算。
因此，更准确的判断是：中国已经完成多轮技术验证，但尚未把这些能力变成开放、标准化、可持续运营的商业平台和开发者生态。
这个变化很重要。它意味着中国面对的主要问题，已经不是“能不能让卫星在天上运行新软件”，而是“谁能把这些能力做成别人用得起、接得上、愿意长期使用的服务”。前者是技术验证，后者才是平台产业。
中国星上计算已经有了技术样板。下一步真正困难的，是把一次次在轨试验沉淀成统一接口、公共工具和可持续运营的服务。
四个技术样板，说明中国已经走到哪一步
第一步，是让卫星从“功能固定”走向“软件定义”。2018年发射的天智一号采用开放系统架构，搭载小型云计算平台，并提出航天应用商店的思路。简单说，它不再把卫星的全部能力在发射前一次性写死，而是尝试让开发者通过软件扩展卫星功能。这已经触及星上计算平台最核心的概念：硬件提供底座，任务能力由软件持续增加。
第二步，是让星上软件具备持续更新和多方接入能力。2023年发射的天智二号D星采用开放的天智软件栈，支持应用上载与更新，并配套开发运维一体化平台。任务还包括多方算法和模型的在轨验证。对普通读者来说，可以把它理解成：卫星不仅装上了“操作系统”，还开始具备类似手机安装和更新应用的能力。
第三步，是把高可靠航天操作系统做成可重构底座。中国航天科技集团五院502所研发的SpaceOS天卓，已经具备在轨编程和重构能力，支持任务修改、任务加载和任务替换。它解决的是另一个关键问题：卫星在轨运行多年，既要能增加新功能，也必须保证原有任务不会因为一次软件更新而失控。开放不是把可靠性放在一边，而是在可靠性边界内增加灵活性。
第四步，是从一颗计算卫星走向一组协同工作的计算卫星。2025年5月，三体计算星座(即“星算”计划首发星座)首批12颗计算卫星入轨。到2026年2月，公开信息显示，首发任务已经形成组网、计算、模型部署和科学载荷在轨验证四类核心能力，实现10个人工智能模型和应用的在轨部署，并完成多星协同处理试验。星上计算由此不再只是“在一颗卫星里加一块AI板卡”，而开始向太空中的分布式计算网络演进。
把这四条线索连起来看，中国并不缺从零到一的技术样板。开放架构、星载应用、软件更新、在轨重构、模型部署和多星协同，都已经得到真实项目的验证。今天再把中国星上计算概括为“没人做”，显然已经不符合事实。
天智一号证明卫星可以由软件扩展，天智二号证明应用可以持续上载更新，SpaceOS天卓证明高可靠系统能够在轨重构，三体计算星座则证明算力可以从单星走向组网协同。
真正的差距：不是没有技术，而是还没有形成平台
技术样板不等于商业平台。一项能力在实验星上跑通，和一个外部客户能够在线申请资源、上传模型、按次付费并稳定获得结果，中间还隔着很长的工程链条。
第一，开放范围仍然有限。现有项目更多服务于科研验证、型号任务或特定合作伙伴。对高校、初创企业和普通应用开发者而言，能够公开申请的在轨计算资源仍然不多，接入流程也不像使用地面云服务那样清晰。行业需要的不只是“这颗星能运行应用”，还需要一套公开说明：谁可以申请、支持哪些模型、怎样测试、失败后如何回滚、费用如何计算。
第二，接口和工具链尚未统一。不同卫星平台、操作系统、载荷和地面系统之间仍有各自的接口与开发方式。开发者在一个平台上完成的应用，通常不能直接迁移到另一个平台。平台真正有价值的地方，是把底层差异藏起来，让用户面对相对统一的应用接口，而不是每换一颗卫星就重新做一遍适配。
第三，服务还没有形成稳定的商业闭环。星上计算最终需要回答几个朴素的问题：客户为什么付钱，按算力、任务次数还是处理结果收费，服务质量怎样保证，发生任务冲突时如何调度。技术演示关注“能不能跑”，商业平台关注“能不能反复卖、稳定交付并持续迭代”。目前，中国在后一阶段仍处于探索期。
第四，开发者生态还没有形成规模。一个成熟平台不仅需要卫星和软件，还需要文档、仿真环境、样例代码、测试工具、应用审核、安全机制和技术支持。只有把这些看似琐碎的工作补齐，星上计算才能从少数航天专家的项目，变成更多AI工程师可以参与的产业。
所以，中国需要补的不是三个“完全空白”，而是四个尚未规模化的产业环节：公共接入、统一接口、商业运营和开发者服务。
下一步，不是再发一颗孤立的实验星
欧空局OPS-SAT的启示仍然有价值：它把真实在轨资源开放给外部团队，让新算法能够在太空环境中接受检验。但对中国而言，今天更合适的动作已经不是简单复制一颗“中国版OPS-SAT”，因为天智系列和三体计算星座已经提供了更丰富的技术基础。
更现实的方向，是把现有资源中的一部分建设成持续开放的公共实验服务。例如，在不影响主任务安全的前提下，定期释放可申请的计算时段；提供统一的地面仿真环境；公开应用开发规范和审核流程；允许高校、企业提交算法；对通过安全验证的应用安排在轨运行；最后把实验数据、错误记录和适配经验沉淀为公共工具。
这样做的意义，不是多完成几项演示，而是降低整个行业第一次开展在轨验证的门槛。一家做火灾识别、海洋监测或气象模型的AI公司，不必先学会造卫星，也不必为验证一个算法单独购买整颗卫星。未来更理想的使用方式，是像申请云服务器一样，申请一段在轨算力和一次载荷数据处理机会。
中国下一阶段最缺的不是另一颗“证明能做”的卫星，而是一套让更多人“可以来做”的长期机制。
需要避免的误区
不能把“开放平台”理解为无门槛地向卫星上传任意代码。航天器的安全边界远高于普通服务器。真正可行的开放，必须建立在隔离运行、资源配额、软件审查、故障回滚和任务优先级管理之上。平台的价值，恰恰是把这些复杂约束封装起来，让外部开发者在明确边界内创新。
产业机会：把航天能力翻译成开发者能用的产品
现阶段最值得关注的机会，不是简单比较哪颗卫星的峰值算力更高，而是谁能把复杂的航天系统变成一套易用产品。这里需要一层连接星载硬件、操作系统、模型工具和任务调度的“太空边缘计算中间件”。
用更直白的话说，这层软件要做四件事：让同一个AI模型能够适配不同星载处理器；在通信不连续时安排任务和保存进度；在算力、电力和温度受限时决定先运行什么；当软件出现异常时及时隔离并恢复。它不能消除太空中的传播延迟和辐射风险，但可以通过缓存、异步调度、冗余、检查点和回滚机制，让系统在这些限制下继续可靠工作。
地面边缘计算、自动驾驶和工业控制积累的软硬件协同经验可以提供参考，但不能直接照搬。车规芯片通常没有经过完整的空间辐射环境验证，航天任务还要根据轨道、寿命和风险等级补充器件筛选、辐射评估和系统级容错设计。真正的机会在于跨行业转化，而不是把地面方案换个外壳送上天。
中国已经有天智软件栈、SpaceOS天卓、星载计算单元和三体计算星座等基础。接下来需要有人把这些技术能力进一步产品化：做统一的软件开发包，提供地面模拟器，建立模型压缩和部署工具，设计清晰的资源计费方式，并给外部开发者持续的技术支持。
三类角色，各自该做什么
行动建议·面向航天总体与平台单位
从“预留接口”升级为“预留可运营能力”。新型号除了考虑算力、电源、热控和数据通路，还应在设计阶段明确软件更新、应用隔离、资源调度和故障回滚机制。卫星入轨后无法更换硬件，但可以通过标准接口和软件更新，让后续型号复用同一套平台能力。
开放已有试验资源。可以从天智系列、计算卫星或其他合适平台中划出受控资源，建立常态化的外部应用征集与在轨验证机制。衡量成效时，不只看完成了多少技术指标，也看接入了多少开发团队、产生了多少可复用应用。
行动建议·面向商业公司与创业者
不要重复造一套封闭系统。更有价值的产品，是帮助不同卫星平台接入统一的模型部署、任务编排和结果交付流程。客户买的不是一个抽象的“软件栈”，而是更快得到火灾点、船舶、云层、灾害区域或通信异常等可直接使用的结果。
先从一个具体场景跑通。与其一开始就声称建设“太空云”，不如选择一个高时效场景，证明从任务提交、星上处理到结果交付的完整链路能够稳定运行。平台能力应从真实任务中长出来。
行动建议·面向投资者与产业组织者
判断团队是否跨过了“演示”与“产品”的分界线。除了看芯片算力和在轨试验，还要看平台是否有清晰的客户、统一接口、开发工具、可靠性方案和持续服务能力。
重视跨学科团队。星上计算平台需要航天系统工程师保证安全边界，也需要云计算和AI工程师改善开发体验，还需要懂遥感、通信或科学载荷的行业人员定义真正有价值的任务。缺少任何一类，产品都容易停在实验室里。
结语：下一场竞争，是谁把技术样板变成公共底座
中国星上计算平台已经跨过“完全没有技术基础”的阶段。天智一号、天智二号D星、SpaceOS天卓和三体计算星座表明，中国能够做开放架构、在轨更新、任务重构、模型部署和多星协同。继续把问题概括为“硬件不行”或“没人想到”，既不符合事实，也会遮住真正需要解决的难题。
下一场竞争，不只是谁把更多算力送上天，而是谁能把算力、数据、模型和任务组织成一套稳定服务。开发者能否方便接入，应用能否跨平台迁移，客户能否按结果付费，平台能否长期维护，这些问题看起来没有发射卫星那么醒目，却决定了技术样板能不能长成产业基础设施。
因此，这篇文章最终要回答的不是“中国有没有星上计算”，而是：中国如何把已经验证的星上计算能力，变成开放、标准化、可持续运营的商业平台和开发者生态。
从技术验证走向平台运营，才是中国星上计算接下来真正要跨越的鸿沟。
主要公开资料：
中国科学院软件研究所：天智一号开放架构与星载应用
中国科学院：天智二号D星开放软件栈与应用更新
中国航天科技集团：SpaceOS天卓在轨编程与重构能力
科技日报：三体计算星座组网、计算与模型部署进展