更聪明的智能助手，和真正的「AI 控车」。
作者｜靖宇
走完 2026 北京车展的十几个展馆，我最大的感受是，车企的高管，肯定是用上「小龙虾」了——今年，如果你的新车没搭个大模型，你都不好意思开发布会。
火山引擎带着豆包宣布搭载超 700 万辆车；腾讯发布出行全场景智能体开放平台；科大讯飞推星火智能座舱；面壁智能展示端侧 Agent 框架 EmbodiedClaw，连奔驰新一代 S 级都在后排塞了一颗端侧多模态大模型 VLM。
更不用说华为的鸿蒙座舱 HarmonySpace 6、宝马与阿里联合定制的 AI 大模型——放眼望去，整个车展弥漫着一种「不 AI，就出局」的紧迫感。
但如果你真的坐进这些车里，一辆一辆试过去，会发现一个略显尴尬的事实。
绝大多数所谓的「AI 座舱」，本质上还是一个更智能、会聊天的语音助手。
它们可以帮你规划出去某个景点的打卡和网红餐厅路线，搭载了大模型能力，也能和你闲聊非常多话题，并且情绪价值给足。但是，在真正「控车」环节，能力依然欠奉——至少在 Q4 之前，真正的 Agent 控车的量产车，可能还送不到消费者手里。
这就是 2026 年汽车 AI 最核心的一个断层：人人都在讲 Agent 上车，但从 Chatbot 到 Agent，中间差的东西，比大多数人想象的要多得多。
01
人人都在讲 Agent，但 90% 还是 Chatbot
两年多之前，大模型上车就已经是车企共识，在 2026 年已经不是什么新闻了——它现在是基础设施，而不是时髦的噱头。
豆包（火山引擎）、通义（阿里）、星火（科大讯飞）、腾讯混元、面壁 MiniCPM……几乎所有主流大模型都在抢汽车的入口。你甚至能在车展的展台上，看到同一家车企，不同产品接入了不同的模型厂商的产品。
真正的问题是：接了大模型之后，体验变了多少？
讯飞也在做星火智能座舱方案｜图片来源：极客公园
我在车展期间跟科大讯飞的人聊，他们的星火大模型（星火智能座舱）也在做上车方案。一个很有代表性的细节是，他们告诉我，目前星火上车做车控的思路，是大模型生成指令之后，映射到之前传统语音助手的控车路线上。换句话说，AI 的「脑子」是新的，但「手脚」还是旧的。
这不是讯飞一家的做法。目前行业里绝大多数「大模型上车」的合作模式，都是车企调用一个云端大模型 API，替换掉原来的语音引擎。 对话更自然了，知识更丰富了，情绪识别更好了——但你说一句，它答一句，这还是 Chatbot 的逻辑。
真正的 Agent 上车应该是什么样的？
火山引擎在这次车展发布会上用了一个很准确的表述：从「回合制问答」到「感知-推理-执行-记忆-学习」的一体化闭环。翻译成人话就是，它不只是回答你的问题，而是能主动感知环境、理解你的意图、拆解任务、调用车上的各种能力把事情办完，而且还能记住你的习惯，下次做得更好。
有一个很简单的判断标准，你对车说「我有点闷」。Chatbot 会问你「要不要开窗」；而一个真正的 Agent，应该能结合当前温度、湿度、车速、你的历史偏好、后排有没有人在睡觉，自动做出一套组合调节——可能是开一条缝的车窗加上调低空调两度再打开座椅通风。
这个差距看起来不大，但背后涉及的工程复杂度，是完全不同量级的。
02
从 Chatbot 到 Agent，差的不是模型，是「底座」
为什么，从「能聊天」到真正「能办事」这么难？
很多人的第一反应是模型不够强。但其实，以目前豆包、通义、星火这些大模型的能力，理解「我有点闷」这句话的含义，并不是什么难事。真正的瓶颈在另一个地方：大模型再聪明，如果车企不把底层能力开放出来，它也只能陪你聊天。
这就像你请了一个特别聪明的助理，但你不给他公司的系统权限，不让他调动任何资源。他再聪明，也只能坐在那跟你对话。
Agent 上车，最大的挑战就是这个。
一辆车的底层有几千个硬件接口——空调、车窗、座椅、氛围灯、通风、导航、行车信号……这些东西原本是为「按钮」和「触屏」设计的，不是为 AI 设计的。你突然让一个大模型来操作这些东西，它连信号都拿不到，更别说安全地控制了。
而且，车控不是小事。如果你只是简单地把接口暴露给 AI，让它直接调用，一旦产生安全问题，结果就可能很严重。
所以 Agent 上车的核心难题不是「大模型能不能理解我的话」，而是「理解之后，怎么安全地、精确地、在对的时机帮我把事办了」。
火山引擎和荣威合作的新产品序列「家越 07」｜图片来源：极客公园
在这次车展前后，我深入了解了火山引擎和荣威合作的一套方案，叫 CPP 架构。这可能是目前行业里对「Agent 上车」想得最深、做得最重的一个案例。
CPP 是三个词的缩写：Context、Planner、Pixel。但它不是一个 Agent——它是一个 Agent 的「操作系统」，业内叫 runtime。
先说 Context。
大多数车载 AI 的「上下文」就是你跟它聊天的记录。但 CPP 的 Context 做了一件很激进的事——它把上下文泛化了。不只是对话，而是把车内外的所有信息都当作 AI 的「感知输入」：9 到 13 路外部摄像头、2 到 3 路内部摄像头、车辆的所有传感器信号、用户的长期记忆，甚至豆包 App 上的个人偏好数据。
这个「泛化」听起来简单，做起来极难。因为这些摄像头和传感器，原本是为自动驾驶、360 度倒车影像、行人检测这些功能设计的。你突然要让座舱 AI 调用它们来判断「后排的小朋友是不是睡着了」，就需要在底层重新打通信号通道。荣威能做到这一步，靠的是七年三代电子电器架构的积累——这不是短期能补的功课。
再说 Planner。
荣威的 CPP 架构｜图片来源：荣威汽车
这是 CPP 最核心的一层。它不是一个单一的大模型，而是一个多模型协作的「任务规划器」。简单的指令（开车窗）走一个轻量快速模型，毫秒级响应；复杂的任务（帮我规划明天的行程）走一个深度思考模型，允许异步处理；环境感知（后排有没有人）走视觉模型。
这里有一个很精巧的设计叫 pre-tool 和 post-tool。比如你说：「北京鸟巢旁边那个什么会议中心附近的星巴克，帮我导过去。」这个请求很复杂，AI 需要先理解「鸟巢旁边的会议中心」是水立方还是国家会议中心，然后搜索附近的星巴克，再设定导航。
如果等它全部算完再回答你，可能要好几秒——在车里，几秒的沉默就会让人觉得它死机了。所以 pre-tool 机制会让 AI 先快速回一句「你说的是水立方吧？我现在帮你找附近的星巴克」——这段话说出来的 3 秒钟里，后台另一个并行任务已经在疯狂计算了。算完之后，post-tool 把结果汇总，接上前面的话继续说。用户感受到的是一段连贯的对话，背后其实是两三个模型在并行工作。
最后是 Pixel——像素级执行。
这才是整套架构里最「重」的一层，也是最需要主机厂自己来做的一层。荣威的做法是把底层两三千个硬件接口，封装成七八百个安全的「服务层」接口。AI 不直接操作底层硬件，而是调用这个服务层。 就像你开着车去按 P 档，它按不下去——不是因为有人告诉你「不能按」，而是在架构层面就锁死了。
这就是他们内部说的「黑区、灰区、彩区」设计。彩区，AI 可以尽情发挥；灰区，有条件地执行；黑区，比如行驶中的关键安全操作，无论 AI 多聪明都碰不到。
荣威和火山引擎+豆包的开发强度超出了行业预期。 荣威的服务层封装已经迭代到第三代，光第三代的研发周期就超过两年半。火山引擎的联合开发团队高峰期近 200 人。而且这不是火山单方面做的——CPP 的每一层都需要车企和大模型厂商一起定义，因为车载场景的需求（延迟敏感、安全要求、多人多角色交互）和手机、电脑上的 AI 完全不同。
但原生方案的门槛极高。你需要车企愿意把底层架构打开，需要大模型厂商深入理解车载场景，需要双方投入两年以上的联合开发——其中每一项都难度极大，意愿极低。这也是为什么整个行业都在喊 Agent，但真正落地的几乎没有。
03
MaaS 大战，烧到了汽车上
技术问题之外，Agent 上车，还有另一个看不见的战场——云服务市场的争夺。
汽车座舱正在成为 MaaS 的新战场。不夸张地说，这可能是继公有云之后，中国科技巨头们最激烈的一次 B 端抢滩。
目前至少有四条路线在同时跑。
火山引擎和豆包走的是「C 端撬 B 端」的路线。豆包 App 日活已经突破 3 亿，这意味着字节在自然语言交互、情绪识别、个人偏好学习上积累了海量的用户数据。火山引擎把这套能力打包，推到汽车端，目前搭载量超 700 万辆，覆盖 50 多个品牌、145 个车型——这个数字是行业第一。
豆包座舱助手能实现的能力｜图片来源：极客公园
更重要的是，火山这次发布的「豆包座舱助手」，直接与手机端的豆包 App 打通。这意味着你在手机上训练出来的个人偏好——你喜欢被安慰还是喜欢听干货、你的说话风格、你常问的问题类型——上车就能无缝继承。这是其他家做不到的，因为没有人同时拥有一个 3 亿日活的 C 端 AI 应用，和一套 B 端的汽车云服务。
阿里云走的是传统 B 端强客户关系的路线。
宝马在中国选了阿里联合定制 AI 大模型，这是一个标志性事件。阿里云在汽车行业经营多年，客户基盘扎实，而且在训练基础设施、数据中台方面有深厚积累。
腾讯则选了一条完全不同的路。在车展前一天的 TIMEDAY 大会上，腾讯发布了出行全场景智能体开放平台。他们的逻辑不是「卖模型」，而是「做底座」——不绑定生态，而是开放能力，让车企在腾讯的平台上自己搭。目前腾讯产品的座舱搭载量超 1800 万辆，在头部车企中渗透率超过 80%。连特斯拉在中国市场，都选了腾讯来做微信互联和目的地服务。微信支付、小程序、腾讯地图——这些生态资源是腾讯的独家护城河。
华为最特殊，走的是最接近 Tier 1 的路线。鸿蒙座舱加乾崑智驾，深度绑定车企，从芯片到操作系统到应用层全部自研。
在这个格局里，火山引擎的位置很微妙。
极客公园在车展期间参加了火山引擎的媒体群访。火山引擎高管在被问到「是否想做华为那样的大模型上车 Tier 1」时，明确说了「不想」。但你看他们实际在推的东西——「豆包座舱助手」是完整的产品级交付，跟豆包 App 互联互通，年内量产——这已经远远超出了一个「API 供应商」的边界。
嘴上说不做 Tier 1，身体很诚实。
更有意思的是他在群访中对整个行业的评价——一句很轻描淡写的话：「人才密度较低。」翻译一下，就是火山和字节，觉得自己在这个赛道上是「降维打击」。
这种自信不是没有道理的。
字节系有两个别人没有的东西：一个是豆包 App 积累的海量交互数据和情绪模型（3 亿日活不是白来的），另一个是今日头条和抖音体系沉淀的，内容数据和信息清洗能力。这些资产用在车载场景里——比如让 AI 带你做冥想，它从网上学来冥想的流程、话术、配乐，然后结合车内的氛围灯和座椅调节——这种跨域能力不是传统汽车供应商能复制的。
但火山也有自己的短板。
火山引擎在北京车展的展台｜图片来源：极客公园
700 万辆搭载量虽然是「第一」，但其中大部分是标准 API 接入，真正做到 CPP 级别深度合作的标杆客户，还在打造中。数据好看，但深度还不够。 这也是为什么火山高管在群访中反复强调「ToC 的用户体验」和「社会价值」，而对短期商业闭环的问题打了很多太极。
这场 MaaS 大战的本质，其实不是谁的模型更强——真正的胜负手是谁能把「服务闭环」做得更深。 火山的优势是 C 端生态和内容数据，阿里的优势是 B 端客户关系和云基础设施，腾讯的优势是社交生态和支付。
谁能赢？现在下结论还太早。但有一点可以确定：Agent 上车这件事，正在把汽车产业的竞争维度从「硬件制造」拉，向「软件生态」。
而在这个新战场上，传统车企的话语权，可能比他们想象的要小。
尽管车展上 Agent 上车的声量震天响，冷静看，目前真正的 AI 原生架构，在行业里几乎没有量产交付的案例。即便是合作了一年半的荣威和火山，也才走到 CPP 的 runtime 层，真正能控车、能主动服务、能持续学习的智能助手，预计最快也要到今年年底才能跟用户见面。
但这恰恰说明了一件事：大家终于不再满足，只是给车里塞一个聊天机器人了。
从 Chatbot 到 Agent，从「接 API」到「建 runtime」，从「语音助手」到「整车大脑」——这条路确实很长。但至少在这一届北京车展上，我们已经看到了行业转变的信号，而一旦 Agent 上车的能力，给消费者带来跨时代的体验，汽车行业无疑会再次迎来猛烈的进化。
毕竟，在中国这个神器的市场上，即便是大爷大妈，都是会拿着电脑让人帮忙装「小龙虾」的。
*头图来源：极客公园
本文为极客公园原创文章，转载请联系极客君微信 geekparkGO