2026年3月18日,在第七届软件定义汽车论坛上,上汽大乘用车智能化软件中心高级总监&零束科技CTO孟超指出,当前AI在汽车领域的应用多停留在“AI哨兵”、“AI宠物识别”、“AI闲聊”等噱头型功能,实际用户使用率与购车吸引力有限,真正高频功能如语音交互、导航规划等尚未被AI深度赋能。他谈到,以特斯拉Grok与FSD结合、OpenClaw开源框架为代表,AI正从信息智能向物理智能融合演进,汽车行业应借鉴其智能框架范式,构建具备“意图理解、物理执行、主动服务、记忆反思及拟人表达能力”的下一代架构。
孟超进一步提出,AGI驱动下的AIOA汽车架构需从模型范式、应用框架、软件系统、硬件底座、安全与生态五方面系统性重构。他强调,应用层面,传统指令式APP开发将被基于agent范式取代,未来智能座舱需围绕agent框架构建,并结合端云协同规划器与技能封装机制实现类AGI产品体验。模型层面,针对频域特性、数据分布与 ViT 特征等维度差异,将信息理解类语言模型与物理 AI 世界模型进行深度融合;依托大小模型协同机制与多模态权重分配策略,探索统一具身智能范式框架,并实现其在汽车、IoT 等智能终端的落地适配。软件层面,SOA服务中间件平台逐步发展成AIOS 框架,支撑AGI模型对于数据、存储、推理高效协同。硬件层面,现有中央计算架构面临内存墙等瓶颈,面向AGI时代则需向更高带宽、灵活调度方向演进。同时,AI安全、权限管理与智能体生态的构建是落地关键。最后,汽车作为智能终端,必须从当前SOA架构进化到AIOA技术架构,实现助理、司机、工程师三重智能体角色的融合。作为汽车行业从业者,他也呼吁大家聚焦Native AI真正赋能汽车的产品及服务,进而共同驱动整个行业实现良性、正向的发展。
孟超|上汽大乘用车智能化软件中心高级总监&零束科技CTO
以下为演讲内容整理:
当前,AI的应用领域主要分为两部分,一是赋能产品,二是驱动工业效能。今天我主要聚焦于AI赋能产品,以及何种架构能够满足当前AI产品的需求跟大家做个分享。
产品总会询问研发部门,能否开发出“独特唯一最”的产品?我们一直在思索,这样的产品是否真的存在?有这样一组数据表明,当前市场上各类以AI为卖点的产品,如AI哨兵、AI香氛,以及AI宠物模式等,在用户体验率和汽车销量中所占的影响因素比例其实较低。相反,我们日常频繁使用的功能,如语音交互、地图导航、车控等,尚未采用AI技术进行开发。
我们自身也有深刻体会,曾开发了两个场景功能,其中之一便是AI哨兵。当有人破坏或刮划车辆,或有宠物靠近车辆时,AI会主动进行防御,这一功能也被一些人包装为AI防御系统。后续测试发现,收集到的多为误触发的行人照片及周边经过的宠物影像。我们曾安排一名演员实际刮划车辆进行测试,结果当AI发出警报时,该演员已跑出10米开外。这是当前“+AI产品”所面临的困境之一。
去年讨论时,有人提出让AI识别宠物表情并感知其变化,产品经理据此开发了AI宠物情绪识别功能。然而,在与团队成员探讨时,大家提出疑问:宠物种类繁多,形态各异,甚至听说美国还有人饲养鳄鱼作为宠物,在此情况下,我们该如何准确判断宠物情绪状态?AI是否真正能满足这些需求还是一个问题。
后来,我们团队内部经过激烈探讨发现,当前我们臆想、虚构出来的诸多场景,更多只是自我感动,进而感动老板,最终试图感动客户。然而,这些并非AI真正能带来的独具特色、独一无二的产品。我们虽每日谈论AI,但AI原生产品究竟是什么,目前仍不明确。
在此,分享一个特斯拉Grok与FSD结合的应用场景。车辆驶至drive through点餐窗口,乘客点了一份麦当劳,随后车辆自动降下车窗、完成点餐后又自动升起车窗,并自动驶离。我们将这一过程进行切片分析,发现其背后蕴含两个逻辑:一是Grok所基于的信息交互大语言模型,二是特斯拉FSD本身的世界模型,二者在此场景中协同工作。
图源:演讲嘉宾素材
在该场景中,AI在整体模型范式上相较于过往软件开发实现了代际迭代与转变。整个架构由Grok的认知脑与世界模型,以及模型最终生成的FSD模型共同构建而成。在此架构中,Grok负责生成导航任务,涵盖长链路规划、基础支付、点餐等操作,并搭建起整体base语言框架;而FSD则完成路径规划、自动驾驶漫游以及最终驶离等任务。这或许是当前能直观感受到的、较具代表性的应用场景,即AI真正将Information AI与Physical AI进行了初步融合。
另一个较为引人注目的现象是“OpenClaw养龙虾”项目,这已成为众多普通人,包括软件从业者广泛采用的范式。其整体架构涵盖主结构体、感知结构体,以及搜索与处理结构体。OpenClaw目前所扮演的角色并非模型,亦非基础操作系统,而更倾向于是一个本地部署引擎与网关相结合所构建的智能体框架范式。
那么,这一框架能否应用于当前的汽车行业呢?我用Gemini和DeepSeek对OpenClaw技术框架进行了分解,发现其主要包括以下几个部分:一是本地部署模式,确保数据不出端;二是用户交互功能,目前我们已看到如QQ、飞书等应用已实现此类交互;三是记忆系统与模型推理能力;四是模型调用方面。半年前大家可能还依赖MCP进行整体调用,而目前已经能够实现skills技能的封装;当然,还有安全保障机制。关于汽车行业是否需要“养龙虾”尚且存疑,但我认为,这种范式框架值得汽车行业参考借鉴。
图源:演讲嘉宾素材
不过,以上两个现象级应用尚不能被视为所谓的杀手级产品。那么,基于当前AGI所能提供的能力基础,是否会催生出一款现象级应用呢?我们将过去传统基于SOA架构及小模型的开发方式,与当下情况进行对比,总结出以下四个方面的差异。
其一,AGI与过往的不同之处在于意图识别与多模态感知交互能力的提升;其二,基于场景认知,AGI能够提供主动服务;其三,AGI具备决策规划、记忆与反思的能力;其四,在输出方面,AGI可实现拟人化的倾听与表达。这也是当前智能座舱围绕这四个核心要点进行开发的方向。
迄今为止,仍未出现一款AI原生的现象级产品应用。但我们仍需持续推进相关工作。在这样的范式下,何种架构能够满足AGI在车端的部署需求?整体架构框架原则上应涵盖应用框架、模型范式、软件、硬件及生态。之所以将模型范式置于首位,是因为在应用尚不成熟、产品尚未成型之际,我们可观察模型驱动所带来的变革。
首先探讨的范式变革是,同样的具身范式能否在多终端实现共享,以及这样的模型框架能否直接垂直应用于汽车端?我将整体架构的左半部分理解为基于数字信息的AI,它更侧重于交互与信息收集,相较于物理系统而言,其响应速度较慢。而右半部分则更多涉及物理层面,无论是我们提及的快速小比例VLA,还是目前路线尚未明确的世界模型。
图源:演讲嘉宾素材
本质上,左侧模型聚焦于语言类交互,其主要任务是预测下一个单词、下一个标记,更侧重于对文本序列的预测处理;而右侧模型则致力于预测下一帧画面、下一个场景,以及背后的物理逻辑,例如球落在地上会弹起、钢球落在地上会静止,在智能辅助驾驶场景中会规划绕过障碍物等,本质上是对物理世界下一帧状态的预测。
目前,这两种模型范式在汽车行业的应用已逐渐显现雏形,并且可将其迁移至具身智能领域。不过,具体的应用对象以及最终的AI工程实现存在差异,我们也在探索这两种范式能否保持一致。
在此范式下,向上延伸至应用层面会发生哪些变化?向下涉及我们常说的framework、操作系统,乃至最底层的硬件,又会产生怎样的变革?
以智能座舱为例,当前市面上常见的智能座舱底层操作系统多采用QNX+安卓或Linux+安卓的组合,在此基础上搭建一层框架,如Android framework,再向上进行功能模块化开发,涵盖语音交互、音效、地图、舱驾融合等,形成现有的系统框架。
然而,从指令式APP开发模式来看,下一代智能座舱必将被一种新的范式所改变,即基于agent的范式。这两种范式存在显著差异:左侧代表指令式应用视角,右侧则代表agent视角。
对这两种范式进行具象化阐述。该框架主要包含两部分内容,右侧是SOA服务,即五年前提出的将车辆所有信息封装为服务的理念;左侧是整个系统的多端输入部分,针对当前多样化的模态输入,可能涉及文本、视频、图片或语音。这些输入通过模型智能体进行驱动,最终构建出这样一套框架体系。
半年前我们还在通过调用function call并运用底层MCP来进行驱动,时至今日,我们已能够将其封装为一些skill,使框架具备基于技能的框架能力,这极大地提升了系统效率。虽然“龙虾汽车”不一定采用此框架,但我们可以参考这样的设计思路。
图源:演讲嘉宾素材
其中较为复杂的部分在于planner。就目前这一代产品而言,planner仍主要在云端完成。预计未来1-2年内,将实现端云协同,即端侧规划器与云侧prompt规划器共同协作开发。AGI带来的架构变革,是应用架构全新范式的转变。我们不能再沿用过去开发应用和APP的方式,而需采用全新范式,使大模型具备执行能力与规划能力。
还有一个典型变化体现在软件方面。过去我们采用服务组件式开发,基于AUTOSAR AP进行开发,在其上封装SOA服务,供所有应用调用。时至今日,原有的开发范式是否仍适用?我们是应在原有基础上进行小幅调整,还是开展颠覆式设计?我们认为,现阶段两者可并存,但最终,随着AGI的发展,右侧的新范式将推动左侧旧范式的变革。
当前,各企业纷纷宣称要打造AIOS。现阶段而言,AIOS更像是架构在基础Linux、Android以及AUTOSAR等系统之上的一套中间件框架。其核心作用主要体现在两个方面:一是向上提供基础的agent框架;二是向下提供系统层面的框架。本质上,系统层面的框架更侧重于挖掘底层资源、提升底层性能。解决模型对于数据搬运、框架推理外围提效。同时,在底层必须确保安全性,如此一套框架方能满足当今汽车行业的需求。
另外是硬件架构,目前业内已达成高度共识,电子架构已完全趋同,即采用HPC加区域控制的架构模式。这种架构主要通过集成控制器和硬件集成实现成本降低,同时通过打破传统软件的封闭性,采用平台式的分层分块解耦方式,提高了系统迭代效率。然而,它并未完全满足AGI对电子架构的需求。在部署模型时,我们面临诸多痛点,除算力不足外,内存墙和内存瓶颈问题尤为突出,内存带宽的影响也不容忽视。这一代电子架构的核心——中央域控制器,首先要解决的是内存问题,包括突破内存墙限制、降低延迟,以支持大模型的数据通信需求。
图源:演讲嘉宾素材
如果目前无法实现one chip,那么在多个芯片间的数据搬运与通信方面,PCIe可作为一种可行选择,借此达成资源的灵活调度以及原始数据的相互传递。此外,采用独立SoC、UFS和DDR的模式也可纳入考量,即部分采用SSD这种共享存储方式来替代原有方案。最终实现“一个芯片打天下”无疑是最佳方案,但就现阶段而言,硬件架构将以这样的范式转变。
另一个较为重要的方面是安全,此安全有别于五年前所提及的信息安全以及数据安全等,更确切的范式是AI安全。它涵盖权限管理、数据泄露以及提示词恶意注入等问题。需要解决的关键问题有两个:一是AI生成内容看似合理实则错误的情况;二是AI不受限制地调用和控制执行体。
针对这两个问题,可通过采用最小权限原则机制、意图网关的人类二次验证以及基础沙盒机制等手段,对AI进行初步管控。这些措施能否真正解决问题,仍有待行业进一步探索。目前,尽管法规在语料安全、模型安全措施及评估等方面给出了一些基本建议,但相关建设仍处于推进过程中。
图源:演讲嘉宾素材
另一个关键要素是生态。目前,从业者每日所关注的生态,本质上仍是基于现有APP应用的生态。若要构建基于agent的全新生态,首先需解决平台接入问题,其次是基于上层架构的支持设计问题,再者是安全管控问题。只有筑牢这三方面的护城河,才有可能实现整个系统的变革与融合。因此,构建智能体生态是一个全新的开发过程。
总体而言,模型厂商与开发公司应聚焦于模型本身,智能体框架应专注于智能体相关技术,而每一个真正的终端制造者,不仅限于汽车行业,还包括具身智能设备、低空飞行器、移动桩端等领域的制造者,都必然需要构建这样一套框架,以满足当前产品落地应用的需求。
下图的框架图最底层为安全底座,涵盖硬件层相关内容,如我们提及的AI Box,以及智能座舱,还包括未来可能实现舱驾一体的大型HPC平台。在典型操作系统、模型与推理框架方面,agent框架可参考OpenClaw以及Agent Skill等框架。
至于框架最上层的应用,智能体最终可扮演三个角色:一是助理,如同用户的私人秘书,提供各类协助;二是司机,负责解决用户从A点到B点的运输问题;三是工程师,能够处理用户在整个产品使用过程中遇到的所有问题,包括故障诊断、解答疑问等。
过去谈及面向服务的SOA,往往仅聚焦于服务层面。而当进入AI或AGI时代,我们需从整体视角审视问题,既要关注纵向层面的安全保障,思考何种硬件能够满足AGI的需求,探究软件架构会发生怎样的变革,明确模型范式如何决定agent框架的设计以及底层操作系统的支撑方式,还要关注应用与生态的垂直整合。同时,我们也不能忽视横向层面的生态协同共建,这对于推动整个行业的持续发展至关重要。在目前尚无完整标准、仍以单点应用为主的阶段,我们仍需积极开展探索。
图源:演讲嘉宾素材
作为智能终端的制造者与设计者,我们的首要任务是设计一套能够满足AGI需求的架构,以支撑模型的演进迭代和智能体的发展,进而共同驱动整个行业实现良性、正向的发展。
(以上内容来自上汽大乘用车智能化软件中心高级总监&零束科技CTO孟超于2026年3月18-19日在第七届软件定义汽车论坛发表的《SOA到AIOA,AGI驱动汽车架构范式演进》主题演讲。)