汽車的「OpenClaw 時刻」，到了？

新造車觀察

10min read

汽車的「OpenClaw 時刻」，到了？

靖宇2026/04/28

摘要

摘要：更聰明的智能助手，和真正的「AI 控車」。

汽車的「OpenClaw 時刻」，到了？

摘要：更聰明的智能助手，和真正的「AI 控車」。

極客一問：你覺得現在車上的「AI 助手」智能化程度如何？

頭圖來源：極客公園

作者｜靖宇

走完 2026 北京車展的十幾個展館，我最大的感受是，車企的高管，肯定是用上「小龍蝦」了——今年，如果你的新車沒搭個大模型，你都不好意思開發布會。

火山引擎帶著豆包宣布搭載超 700 萬輛車；騰訊發布出行全場景智能體開放平臺；科大訊飛推星火智能座艙；面壁智能展示端側 Agent 框架 EmbodiedClaw，連奔馳新一代 S 級都在后排塞了一顆端側多模態大模型 VLM。

更不用說華為的鴻蒙座艙 HarmonySpace 6、寶馬與阿里聯合定制的 AI 大模型——放眼望去，整個車展彌漫著一種「不 AI，就出局」的緊迫感。

但如果你真的坐進這些車里，一輛一輛試過去，會發現一個略顯尷尬的事實。

絕大多數所謂的「AI 座艙」，本質上還是一個更智能、會聊天的語音助手。

它們可以幫你規劃出去某個景點的打卡和網紅餐廳路線，搭載了大模型能力，也能和你閑聊非常多話題，并且情緒價值給足。但是，在真正「控車」環節，能力依然欠奉——至少在 Q4 之前，真正的 Agent 控車的量產車，可能還送不到消費者手里。

這就是 2026 年汽車 AI 最核心的一個斷層：人人都在講 Agent 上車，但從 Chatbot 到 Agent，中間差的東西，比大多數人想象的要多得多。

人人都在講 Agent，但 90% 還是 Chatbot

兩年多之前，大模型上車就已經是車企共識，在 2026 年已經不是什么新聞了——它現在是基礎設施，而不是時髦的噱頭。

豆包（火山引擎）、通義（阿里）、星火（科大訊飛）、騰訊混元、面壁 MiniCPM……幾乎所有主流大模型都在搶汽車的入口。你甚至能在車展的展臺上，看到同一家車企，不同產品接入了不同的模型廠商的產品。

真正的問題是：接了大模型之后，體驗變了多少？

訊飛也在做星火智能座艙方案｜圖片來源：極客公園

我在車展期間跟科大訊飛的人聊，他們的星火大模型（星火智能座艙）也在做上車方案。一個很有代表性的細節是，他們告訴我，目前星火上車做車控的思路，是大模型生成指令之后，映射到之前傳統語音助手的控車路線上。換句話說，AI 的「腦子」是新的，但「手腳」還是舊的。

這不是訊飛一家的做法。目前行業里絕大多數「大模型上車」的合作模式，都是車企調用一個云端大模型 API，替換掉原來的語音引擎。對話更自然了，知識更豐富了，情緒識別更好了——但你說一句，它答一句，這還是 Chatbot 的邏輯。

真正的 Agent 上車應該是什么樣的？

火山引擎在這次車展發布會上用了一個很準確的表述：從「回合制問答」到「感知-推理-執行-記憶-學習」的一體化閉環。翻譯成人話就是，它不只是回答你的問題，而是能主動感知環境、理解你的意圖、拆解任務、調用車上的各種能力把事情辦完，而且還能記住你的習慣，下次做得更好。

有一個很簡單的判斷標準，你對車說「我有點悶」。Chatbot 會問你「要不要開窗」；而一個真正的 Agent，應該能結合當前溫度、濕度、車速、你的歷史偏好、后排有沒有人在睡覺，自動做出一套組合調節——可能是開一條縫的車窗加上調低空調兩度再打開座椅通風。

這個差距看起來不大，但背后涉及的工程復雜度，是完全不同量級的。

從 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，但真正落地的幾乎沒有。

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 上車的能力，給消費者帶來跨時代的體驗，汽車行業無疑會再次迎來猛烈的進化。

畢竟，在中國這個神器的市場上，即便是大爺大媽，都是會拿著電腦讓人幫忙裝「小龍蝦」的。

人工智能智能汽車新能源車AI