出品/星动无极
椭圆时空科技发布太空智能体平台AethraZ 1.0。平台依托该公司的星池计划低轨星座，星座规划112颗通导遥算一体化卫星，分四期建设，分别为12颗、28颗、56颗和112颗。按披露的对应关系，星座规模与广域信息服务的响应时间挂钩：12颗约3.6小时，28颗约26分钟，56颗约15分钟，112颗约8.8分钟。
星上部分的技术路径已经写进了发布材料。卫星端通过模型量化压缩，把大模型做轻量化适配后部署在轨推理；星上智能体自主规划观测任务、生成信息、端到端回传。传统遥感卫星的作业流程是地面下任务、卫星拍数据、数据传回地面再处理，一轮周期以小时计。星上智能体把任务规划和数据处理都搬上天，从看见目标到产出结果的时间被压到星座覆盖周期之内。
地面部分承担另一端的负载。地面智能体做大规模计算与业务规划，支持客户私有化部署。星地分工的逻辑是星上算力受功耗和散热约束，适合跑轻量化的实时推理；大模型训练和批量数据生产留在地面。两端以智能体接口衔接，星上的观测结果直接变成地面的业务输入，中间省掉人工判读的环节。
星端开放操作系统是这个平台里商业设计最重的一块。客户和第三方的行业应用与算法可以上载到卫星端运行，地面算法市场已经上架65个能力，按GPU秒或按量计费。这个结构把卫星从专用的观测设备变成了开放的计算载体，遥感应用的开发者不再需要整星研制能力，往平台上写算法就能分到算力结算。卫星算力的计费单位向云服务看齐，商业模式上是把星上GPU做成了轨道上的算力实例。
星池计划的112颗星是通导遥算一体化设计，一颗卫星同时承担通信、导航、遥感和在轨计算，四期分别为12颗、28颗、56颗和112颗。四期的建设节奏对应商业化的台阶：12颗星做完验证，28颗星形成区域服务能力，56颗和112颗支撑全国及海外覆盖。响应时间从小时级压到分钟级，是星座运营方对客户讲的最直接的采购理由，灾害监测、应急调度这类场景对时效的付费意愿最高。
这个方向的热度来自需求端的变化。SpaceX今年1月申请部署百万颗卫星构建太空数据中心，马斯克给出的理由是算力需求扩张对地面电力和水资源的消耗压力；谷歌、英伟达、亚马逊等巨头都已入场布局。太空计算的价值被各方共同认定的部分，是通过增强卫星的数据处理能力，缩短从获取数据到形成可用结果的时间。椭圆时空的智能体框架相当于在这条共识路线上往前多走了一步，把调度和任务生成也搬上了天。
国内星上算力这条线今年明显提速。之江实验室与国星宇航的三体计算星座去年5月发射12颗算力卫星组网，卫星互联后具备每秒5千万亿次的计算能力，地卫二与东方星链的太空之弦星座规划超1000颗，谷歌的星上TPU在10月底完成了在轨模型推理的地面验证——地面站上行提示词，卫星上的数据中心级TPU运行Gemma 4模型并回传结果。椭圆时空的AethraZ把智能体框架加到这条线上，差异点不在算力规模，在任务自主规划——卫星自己决定看什么、怎么算、回传什么，这对星座调度软件的要求高于对芯片的要求。
星上算力的技术约束各家面对的是同一组问题。计算设备要适应空间辐射环境，在有限的供电和散热条件下长期工作；功耗管理、容错设计和星间连接能力决定系统可用性。星上处理能减少下传数据量，前提是模型足够轻、在轨环境下的推理精度足够稳。椭圆时空用模型量化压缩解决轻量化，端到端回传解决时效，这两个选择在工程上互为条件。
商业化路径上，这个平台面对的问题与所有星上算力玩家相同：星座在轨数量与算法生态的匹配。算法市场上架65个能力是起点，应用开发者是否愿意为一个在建星座投入开发，取决于星座部署进度和客户订单的真实性。按GPU秒计费的模型要在卫星数量够多、调用频次够高的前提下才成立，四期建设的资金和时间表是这套商业逻辑的硬约束。
星上智能体这个方向的技术风险也摆在明处。模型在轨运行的可靠性、辐射环境下的故障恢复、多星协同的调度一致性，都是没有长周期验证记录的环节。椭圆时空把开放操作系统和算法市场放在第一期就推出来，等于把生态建设的周期压进了星座建设周期。112颗星全部入轨那天，平台上跑着多少个第三方算法、结算收入有多少，是这个模式成立与否的最终判据。