夜雨聆风
2026年6月25日，在第八届AI智能座舱大会上，东风研发总院智能化技术副总工程师刘俊成提出，真正的AIOS并非简单叠加大模型、升级语音或新增AI应用，而是在安卓基础上重构交互逻辑，以AI大脑为核心、意图驱动运行。行业座舱OS历经Linux功能型、Android生态型两代迭代，AIOS作为第三代原生智能系统，依托分层架构，将车辆各类能力抽象封装，联动大模型实现自然语言、Agent主动交互，突破传统座舱功能边界，覆盖车控、智驾、生活服务等跨域全链路服务。
刘俊成指出，舱驾融合核心是交互统一而非硬件绑定，受成本约束单芯片一体化尚需时日，可通过智驾能力开放、座舱感知赋能、场景一体化三大路径落地；AIOS采用分阶段端云部署架构，依托统一兼容层动态调度云端、端侧算力与多类大模型，通过MCP封装打通车端硬件与外部生态，依靠长短期记忆实现千人千面。他表示，短期内座舱将深耕出行场景挖掘价值，长期车端算力可延伸服务个人与家庭，AIOS将成为下一代智能座舱发展核心起点。
刘俊成｜东风研发总院智能化技术副总工程师
以下为演讲内容整理：
01
AIOS定义
针对AIOS，业界有许多疑问。第一，是否需要用AI将传统系统重写一遍，例如内存操作、线程调度等底层模块？我个人认为，这一方向对于AIOS而言仍显局限。其次，传统车机在集成大模型之后，是否即可称为AIOS？例如今年较为热门的claw-code，如果在车机中加装此类功能，或安装豆包等应用，是否就能作为AIOS进行发布？目前不少厂商也在就此进行宣传。第三，语音助手的简单升级，是否只需对语音助手进行少量改动，便可自称AIOS或新的智能座舱？第四，我们集成多个应用，例如将壁纸改为AI生成壁纸，或将车膜功能改为更换车衣，或集成若干AI相关功能，是否就能称之为AIOS？
关于如何看待AIOS，从我个人的理解出发，首先可以参照历史发展。结论是，AIOS必然建立在先前系统的基础之上。从发展历程来看，上一代OS，如基于Linux的安卓，并未将Linux所有系统重新编写，而是立足于Linux，利用其设备管理功能，定义相应接口，并实现应用的生命周期管理。
图源：演讲嘉宾素材
基于此，我认为AIOS同样必须建立在既有安卓系统的基础之上，重新组织和进化相关交互方式，并利用已有能力，这才是真正AIOS的核心所在。
按照这一理念，新的AIOS可分为若干层次。最底层为既有安卓系统，尽管安卓本身包含多层结构，但在新的AIOS中，它是基础层。我们需要将之前提供的各项功能，无论是应用功能还是系统功能，都封装为相应接口。
在此基础上，进行能力抽象，将音乐能力、系统能力等进行抽象，形成抽象层后提供给大模型，使其能够识别并调用这些能力。在此之上，我们再构建新的交互方式、新的用户应用，以及新的手段，从而为用户提供更优的功能。
02
智能座舱
智能座舱是人车交互的入口，但我认为其范畴不仅限于传统座舱相关的功能对话，如控制座椅、氛围灯等，智能座舱主要是交互入口。目前在实际使用中，它已开始支持与自动驾驶等驾驶域相关功能的交互。除了座舱和驾驶域，许多在线服务也属于智能座舱的交互范畴，例如下班回家时查看快递等网络服务。同时，各种场景，如上班场景、下班场景，以及与小孩出行的场景，其融合主动服务也与智能座舱相关。
此外，座舱需要不断学习和进化，实现千人千面和相应的记忆功能。这些都属于智能座舱的范畴。因此，我认为座舱本身应是一个大座舱的概念，即在车内，所有与驾驶员和乘客的交互，都应归属于座舱的范畴。
03
舱驾融合
近年来，舱驾融合这一概念提及较多，早期高通、英伟达等厂商均提出将舱驾一体集成于单颗芯片，并相继推出了相应芯片。但舱驾融合是否必须统一到硬件层面，或必须运行于同一操作系统之上，我认为其发展仍需一个过程。
座舱域与智驾域的本质区别较大，可从几个维度来看。第一是功能需求。座舱的功能可以说是无限的，且许多功能仍在探索之中，处于不断拓展的过程。而智驾域的功能是有限的，无论L3还是L4，其定义已经明确，达到相应标准即为对应等级，属于有限功能集。
二是实时性要求。座舱的多数交互面向人，延迟多一百毫秒或少一百毫秒，人难以察觉。但智驾域不同，延迟增加一百毫秒可能引发安全问题，其实时性要求很高，需求也与座舱不同。因此，功能安全等级也存在差异。座舱域对车速报警灯等少数功能有要求，多数功能则无此要求；而智驾域的功能安全要求越来越高，L3甚至可能需要进行双备份。
关于舱驾融合的概念，我认为最主要的是用户关注的交互融合，而非必须实现物理融合，例如必须运行于同一芯片上。更重要的可能是让用户与座舱进行交互，并实现统一管理，从而统一感受到智能化的升级。但后续发展也不排除，在算力提升和成本下降之后，可以实现单芯片方案。
不过我认为关键的拐点并非本质上的，而是成本层面的考量，是否采用同一硬件，主要取决于成本。我个人认为，成本至少需要下降20%至30%。因为从软件发展的角度看，我们已经投入大量精力进行解耦等工作，如果最终要整合在一起，必然需要从成本上获得相应收益，否则动力可能不足。
关于舱驾融合的交互，我认为大致可分为三个方向。其一是将驾驶能力向座舱开放，我们可以通过自然语言进行交互，例如上班较急时，可以说“我很急，开快点”，系统便会自动缩短跟车距离，防止他人插队，或在旁车道空闲时更频繁地变道。但这类请求只是以较粗粒度、自然化的方式向智驾域发出，具体执行仍需由智驾域完成，只是这些需求可以通过更自然的方式传递给驾驶域。
第二，座舱域可将自身感知能力开放给驾驶域，例如驾驶员状态监测。驾驶员打哈欠或睡着时，座舱感知到后告知智驾域，智驾域可逐步采取措施，如座椅震动、方向盘震动、氛围灯提醒，若仍无效，则靠边停车并开启双闪。座舱将相关感知信息提供给智驾域，形成较为安全且闭环的体验。
第三，将各类场景，如上车的上班场景、下班场景、出游场景等，以及泊车等，从座舱到智驾进行融合，提供较好的整体体验，并以此与用户交互，从而实现舱驾融合的方向。
图源：演讲嘉宾素材
04
AIOS架构
回到AIOS的部署问题，究竟是部署于云端还是车端。我认为可能根据发展过程分为三个阶段。第一阶段以云端为主的1.0版本，第二阶段是端云结合的2.0版本；目前1.0和2.0阶段可能并存。当端侧算力较低，例如采用8155等芯片时，主要仍以云端部署为主。目前更为主流的方式可能是端云结合。在端云结合模式下，端侧和云侧均部署相应的算力和大脑，部分任务在端侧完成，部分在云端完成。端云结合的方案需要注意记忆的同步，不能出现端侧处理的任务云端不知情的情况。
第三阶段可能以端侧为主。大脑主要涉及记忆、推理和自主学习。至于具体模型部署于端侧还是云侧，可根据场景和需求进行动态调度。该架构图大致可表示当前3.0版本的架构，其中绿色部分包括模型切换与管理，记忆管理，对话管理等，以及如何动态通过MCP/CLI接入各类功能，包括A2A之间的交互。绿色部分即为我们所定义的大脑。
图源：演讲嘉宾素材
底下蓝色部分即模型的部署。无论当前采用的是8397芯片，还是外挂AI Box的端侧算力，抑或云端大模型，对于大脑而言均兼容。大脑只需了解各模型能力差异，通过统一Adapter接口，兼容现有主流模型，根据需求动态调度相应模型。
左侧黄色部分为当前车机的各项能力，主要可划分为座舱能力、智驾能力和底盘能力。我们将这些能力封装为相应的MCP，注入大脑，使大脑知晓这些能力，并在适当时机进行调用。右侧部分更为重要的是生态能力。我们定义了标准的MCP/CLI接入方式，并兼容当前主流方案，例如OpenClaw的兼容方式，以及飞书、高德地图等已实现的MCP。这些都可以动态注入和扩展，将网络能力接入大脑，并与本地能力通过大脑进行动态调度，从而实现用户所需的场景。
由于记忆本身归属于本体，因此后续如何更好地组织和协调这些能力，以及如何实现千人千面，核心在于绿色部分的优化。这也是东风AIOS后续重点研发的工作方向。
最后，谈一下对座舱的展望。当前我们可能正处于短期到中期的阶段，主要任务是将现有场景和应用服务得更好，挖掘座舱内的场景应用，并找到座舱的新价值。长期来看，座舱芯片的价值不仅限于驾驶过程中，其算力还可为家庭和个人提供更大的价值。
AIOS当前仅是智能汽车时代的起点。我们希望让汽车更懂人，让出行更加美好。
探索更多
