簡介面向智能汽車、AI芯片與人機(jī)交互領(lǐng)域的研發(fā)工程師、產(chǎn)品經(jīng)理及行業(yè)研究人員這份技術(shù)解析以瑞芯微RK3588芯片為核心梳理語音、視覺、手勢三類模態(tài)在智能座艙中的融合交互設(shè)計思路幫助讀者理解國產(chǎn)高性能芯片在多模態(tài)車內(nèi)Agent中的工程落地。內(nèi)容涵蓋八納米制程、八核中央處理器、高性能圖形處理器與6TOPS算力神經(jīng)網(wǎng)絡(luò)處理器等關(guān)鍵特性并講解語音識別、自然語言理解、疲勞監(jiān)測、手勢交互等模塊的技術(shù)原理與實(shí)現(xiàn)路徑。結(jié)合廣汽昊鉑GT-攀登版案例與實(shí)驗(yàn)室數(shù)據(jù)語音識別準(zhǔn)確率超95%手勢識別達(dá)96%疲勞檢測準(zhǔn)確率達(dá)97%同時討論算力瓶頸、數(shù)據(jù)隱私安全與融合算法優(yōu)化挑戰(zhàn)并展望算法演進(jìn)、硬件升級與跨場景生態(tài)融合方向。打包為一個docx文檔壓縮包僅14KB。已有60人學(xué)習(xí)/下載適合需要建立多模態(tài)座艙系統(tǒng)整體認(rèn)知的開發(fā)者與研究者。 做個多模態(tài)座艙Agent沒有想象中那么玄乎但坑確實(shí)不少。這個項(xiàng)目從需求拆分到最終在RK3588上跑通語音、視覺、手勢三條鏈路前后折騰了幾個月把這些經(jīng)驗(yàn)沉淀下來希望能給正在做智能座艙或端側(cè)多模態(tài)交互的朋友一些實(shí)際參考。1. 為什么我在智能座艙里堅(jiān)持要做多模態(tài)Agent1.1 傳統(tǒng)座艙交互的痛點(diǎn)在哪座艙交互在很長一段時間里都是“單一模態(tài)”的天下要么靠觸屏點(diǎn)按要么靠語音指令要么就是個物理按鍵。問題是真實(shí)用車場景從來不會干干凈凈只觸發(fā)一種交互。開車時眼睛要看路沒法盯著中控屏找按鈕副駕在睡覺語音播報就得收斂車內(nèi)放著音樂語音識別率直接往下掉。單一模態(tài)一旦遇到環(huán)境干擾整個交互鏈路就斷了。做多模態(tài)Agent的核心出發(fā)點(diǎn)不是“炫技”而是把交互從“人適應(yīng)機(jī)器”變成“機(jī)器適應(yīng)人”。用戶瞟一眼屏幕、抬一下手指、說半句話系統(tǒng)就能綜合這些信號判斷用戶想干什么。這個思路本質(zhì)上和現(xiàn)在大模型Agent的“感知-決策-執(zhí)行”框架是一致的只不過感知端從文本擴(kuò)展到了語音、視覺、手勢等多路信號。1.2 RK3588為什么適合干這事選型時對比過幾款主流車規(guī)和準(zhǔn)車規(guī)平臺最終定在RK3588上主要看中幾點(diǎn)。首先是它的異構(gòu)算力4顆Cortex-A76加4顆Cortex-A55大小核調(diào)度靈活內(nèi)置6 TOPS算力的NPU雖然跟云端卡沒法比但跑端側(cè)輕量化模型綽綽有余GPU是Mali-G610視頻編解碼能力強(qiáng)艙內(nèi)攝像頭畫面處理不吃力。更關(guān)鍵的是接口資源。RK3588自帶多路MIPI CSI、I2S、I2C、SPI等外設(shè)接口語音Codec比如ES8388、攝像頭Sensor、手勢雷達(dá)或紅外模組都能直接掛上去不需要額外加一堆轉(zhuǎn)接芯片對整機(jī)BOM成本控制很友好。而且它在Linux和Android下的驅(qū)動生態(tài)比較成熟快速原型驗(yàn)證階段能省下不少底層調(diào)試時間。1.3 多模態(tài)Agent到底解決什么問題這個Agent不是簡單的“指令-響應(yīng)”機(jī)器人而是一個能理解車內(nèi)場景狀態(tài)、融合多路信號、自主決策并執(zhí)行任務(wù)的智能體。比如駕駛員說“我有點(diǎn)熱”同時手朝空調(diào)出風(fēng)口方向指了一下系統(tǒng)綜合語音語義和手勢方位直接打開對應(yīng)位置的空調(diào)出風(fēng)口并調(diào)低溫度。又比如后排乘客指向車窗說“打開這個”系統(tǒng)通過語音指代消解和手勢區(qū)域識別鎖定是哪扇窗。這類場景里任何一個單模態(tài)都不足以完整表達(dá)用戶意圖必須靠融合。Agent在其中充當(dāng)?shù)氖恰按竽X”接收多模態(tài)感知模塊輸出的結(jié)構(gòu)化結(jié)果結(jié)合上下文狀態(tài)和用戶歷史偏好做推理規(guī)劃最終調(diào)用車控、內(nèi)容、座艙設(shè)置等執(zhí)行能力。注意多模態(tài)Agent的價值在于“互補(bǔ)”而不是“堆疊”。如果語音已經(jīng)能明確識別用戶意圖手勢模態(tài)就不需要強(qiáng)行參與決策否則反而增加誤判風(fēng)險。2. 系統(tǒng)整體架構(gòu)與數(shù)據(jù)流設(shè)計2.1 分層架構(gòu)與模塊劃分整個系統(tǒng)按功能拆成了四層感知層、融合層、決策層、執(zhí)行層。感知層負(fù)責(zé)采集語音、圖像、手勢原始信號通過端側(cè)模型輸出結(jié)構(gòu)化信息比如語音轉(zhuǎn)寫的文本、駕駛員注視區(qū)域、手勢類別與軌跡融合層把這些信息對齊到統(tǒng)一的時間軸和坐標(biāo)系決策層運(yùn)行Agent核心邏輯維護(hù)多輪對話狀態(tài)和任務(wù)規(guī)劃執(zhí)行層對接車控CAN信號、語音TTS、屏幕UI等。分層的好處是每層可以獨(dú)立替換和升級。比如初期手勢識別用普通RGB攝像頭后期如果要換ToF深度相機(jī)只需改感知層和融合層的坐標(biāo)轉(zhuǎn)換部分不影響決策層邏輯。這在項(xiàng)目迭代過程中幫了大忙因?yàn)樽撚布母膭宇l率遠(yuǎn)比想象中高。2.2 數(shù)據(jù)鏈路與同步機(jī)制多模態(tài)系統(tǒng)最難處理的不是單路信號質(zhì)量而是多路信號的時間同步。語音要的是音頻幀視覺要的是圖像幀手勢要的是深度點(diǎn)云或骨架關(guān)鍵點(diǎn)三者的采樣率完全不同到達(dá)時間也不一致。如果不做對齊就會出現(xiàn)“用戶已經(jīng)說完了手勢軌跡還沒傳上來”的錯位問題。我采用的方案是引入一個輕量級消息總線各路感知模塊在處理完一幀數(shù)據(jù)后附帶硬件時間戳基于RK3588的CLOCK_MONOTONIC發(fā)布到總線上。融合層維護(hù)一個滑動時間窗只把時間戳差值在150ms以內(nèi)的多模態(tài)事件歸為同一交互意圖。這個閾值來自實(shí)測自然交互中語音和手勢的起始時間差通常不會超過150ms超過這個范圍就按獨(dú)立事件處理。2.3 Agent決策框架的設(shè)計思路Agent核心沒有一上來就上大語言模型因?yàn)檐嚈C(jī)端NPU跑7B以上的LLM還是吃力而且推理延遲不可控。實(shí)際采用的是一個“規(guī)則基座輕量模型”的混合框架意圖分類用一個小型BERT模型識別槽位提取用規(guī)則和關(guān)鍵詞模板對話管理用有限狀態(tài)機(jī)加上下文緩存。只有當(dāng)遇到復(fù)雜語義或多輪指代場景時才通過API網(wǎng)關(guān)請求云端大模型兜底。這種架構(gòu)的好處是絕大多數(shù)高頻指令在端側(cè)100ms內(nèi)就能完成“識別-決策-執(zhí)行”閉環(huán)只有少數(shù)復(fù)雜請求才產(chǎn)生網(wǎng)絡(luò)依賴系統(tǒng)整體魯棒性高很多。后面有了更高算力的平臺或量化技術(shù)更成熟再逐步把端側(cè)模型替換成更大的LLM也不會推翻現(xiàn)有架構(gòu)。3. 語音、視覺、手勢三條感知鏈路實(shí)戰(zhàn)3.1 語音鏈路喚醒、識別與語義理解語音部分用的是“本地喚醒本地識別為主、云端識別兜底”的策略。硬件上通過I2S接口接入ES8388 Codec雙麥克風(fēng)陣列做波束成形實(shí)測在車速60km/h、音樂音量中等的情況下喚醒率還能保持在95%以上。這里有個經(jīng)驗(yàn)麥克風(fēng)開孔位置和朝向比算法更影響喚醒率前期結(jié)構(gòu)設(shè)計一定要介入不然后面調(diào)算法事倍功半。喚醒詞觸發(fā)后語音進(jìn)入識別和語義理解流程。端側(cè)識別模型在RK3588上用NPU加速一段2秒的語音轉(zhuǎn)文本大概耗時80ms加上意圖解析整體延遲控制在200ms以內(nèi)。語義部分維護(hù)一個“意圖-槽位”模板庫覆蓋空調(diào)、車窗、導(dǎo)航、音樂、座椅等高頻場景。對于極端嘈雜環(huán)境識別失敗的情況系統(tǒng)會主動發(fā)一句“剛才沒聽清您再說一遍嗎”而不是靜默等待。實(shí)操心得ES8388在RK3588上調(diào)試時最容易遇到的是“錄音有雜音”和“播放無聲”兩類問題。前者多半是MIC偏置電壓沒配好后者要重點(diǎn)查I2S的MCLK和BCLK比例是否匹配。別一上來就懷疑芯片壞了。3.2 視覺鏈路駕駛員與艙內(nèi)感知視覺感知主要覆蓋兩個方向駕駛員狀態(tài)和艙內(nèi)環(huán)境。駕駛員狀態(tài)包括疲勞檢測閉眼、打哈欠、分心檢測視線偏移、玩手機(jī)艙內(nèi)環(huán)境包括乘客數(shù)量、乘員位置、艙內(nèi)光照等。這些信息一方面用于安全提醒另一方面為多模態(tài)Agent提供“場景上下文”。視覺鏈路使用一顆800萬像素的IR攝像頭部署在儀表盤上方通過MIPI CSI接口接入RK3588。目標(biāo)檢測模型用的是輕量化YOLOv8n輸入分辨率640x640在NPU上單幀推理時間約35ms。姿態(tài)估計用了一個簡化的關(guān)鍵點(diǎn)模型輸出眼睛縱橫比EAR和嘴部縱橫比MAR用來判斷疲勞和哈欠狀態(tài)。在RK3588上部署YOLOv8的流程這里說一下關(guān)鍵點(diǎn)。先把PyTorch模型導(dǎo)出為ONNX再用RKNN-Toolkit2轉(zhuǎn)成RKNN格式。轉(zhuǎn)換時最容易踩坑的是算子的兼容性比如Focus層和部分上采樣算子在NPU上不支持或效率低。解決辦法是調(diào)整模型結(jié)構(gòu)把Focus改成常規(guī)Conv加切片或者把不支持的算子放到CPU上執(zhí)行。實(shí)測下來合理進(jìn)行算子分配后整體幀率能提升30%以上。3.3 手勢鏈路靜態(tài)與動態(tài)手勢識別手勢方案我對比過三種RGB攝像頭純視覺方案、ToF深度相機(jī)方案、毫米波雷達(dá)方案。純視覺成本最低但受光照影響大夜間體驗(yàn)差雷達(dá)穩(wěn)定但無法識別精細(xì)手勢ToF深度相機(jī)在夜間也能穩(wěn)定工作且能輸出深度信息最終選了ToF為主、RGB為輔的融合方案。手勢識別模型分兩個階段先檢測手部區(qū)域并輸出21個關(guān)鍵點(diǎn)再用關(guān)鍵點(diǎn)序列分類靜態(tài)手勢OK、握拳、比心等和動態(tài)手勢揮手、滑動、指向等。在RK3588 NPU上手部檢測約25ms關(guān)鍵點(diǎn)檢測約18ms動態(tài)手勢分類用LSTM輕量模型32幀的序列分類約15ms。整條鏈路60ms左右能出結(jié)果基本滿足實(shí)時交互的要求。動態(tài)手勢識別有個容易被忽略的細(xì)節(jié)起始幀和結(jié)束幀的判定。如果在靜止?fàn)顟B(tài)不斷提取關(guān)鍵點(diǎn)序列模型會把“手放在那不動”也當(dāng)成一個動態(tài)手勢類別。我用的是一個簡單的運(yùn)動能量閾值關(guān)鍵點(diǎn)位移超過設(shè)定閾值才激活序列記錄連續(xù)5幀位移小于閾值則結(jié)束當(dāng)前手勢必要時搭配PWM風(fēng)扇給RK3588散熱效果更穩(wěn)定。4. 多模態(tài)融合從傳感器到意圖4.1 融合時機(jī)與置信度綜合多模態(tài)融合按層級分有數(shù)據(jù)級融合、特征級融合和決策級融合。數(shù)據(jù)級融合對時間同步要求極高實(shí)現(xiàn)復(fù)雜特征級融合需要把不同模態(tài)的特征向量拼接中間表征空間設(shè)計比較頭疼決策級融合是每個模態(tài)獨(dú)立產(chǎn)出結(jié)果再由上層綜合判斷。座艙場景下我選的是決策級融合為主因?yàn)槟K之間解耦清楚出現(xiàn)問題好定位。每個模態(tài)模塊在處理完一幀輸入后除了輸出識別結(jié)果還輸出一個置信度分?jǐn)?shù)。比如語音模塊除了輸出文本還有聲學(xué)置信度視覺模塊除了輸出手勢類別還有檢測框得分。融合層對同一交互窗口內(nèi)的各模態(tài)結(jié)果做加權(quán)投票權(quán)重不是寫死的而是根據(jù)場景動態(tài)調(diào)整白天視覺權(quán)重高夜間或逆光時語音權(quán)重提高強(qiáng)噪聲環(huán)境下視覺權(quán)重提高。4.2 上下文記憶與槽位管理Agent的決策質(zhì)量很大程度取決于上下文記憶能力。用戶說“打開空調(diào)”接著又說“再調(diào)低兩度”如果不記憶上一輪提到的“空調(diào)”對象“調(diào)低兩度”就無從落地。這里的槽位管理借鑒了對話式AI的經(jīng)典思路維護(hù)一個當(dāng)前任務(wù)槽位表包含操作對象、動作類型、參數(shù)值、狀態(tài)等字段。每次新意圖進(jìn)入時先檢查槽位表中是否有未閉合的任務(wù)與其關(guān)聯(lián)。比如上一條指令是“打開空調(diào)”槽位表中對象空調(diào)、動作打開。下一條“調(diào)低兩度”到來的瞬間Agent發(fā)現(xiàn)空調(diào)槽位存在且用戶沒有否定語境就把“調(diào)低兩度”作為補(bǔ)充參數(shù)合并進(jìn)去最終執(zhí)行“空調(diào)溫度調(diào)低兩度”。這個邏輯聽起來簡單但融合了語音的指代消解哪些詞該替換、哪些詞該保留需要仔細(xì)設(shè)計。槽位管理還要考慮“時效性”。用戶說“打開天窗”過了五分鐘又說“算了關(guān)掉”這里的“算了”應(yīng)該關(guān)聯(lián)到五分鐘前的天窗指令。但如果超過一個會話周期設(shè)定為10分鐘無交互槽位表就會清空避免跨場景的錯誤關(guān)聯(lián)。4.3 沖突消解與回退策略多模態(tài)之間產(chǎn)生沖突非常常見。用戶嘴上說“我沒事”但視覺檢測出頻繁揉眼睛、打哈欠這時該信誰如果盲目執(zhí)行“我沒事”而忽略疲勞狀態(tài)安全風(fēng)險很大反過來如果武斷判定疲勞并強(qiáng)提醒又可能誤報。我的處理原則是“安全優(yōu)先、默認(rèn)不打擾”。疲勞檢測這類涉及行車安全的信號優(yōu)先級最高只要視覺模型連續(xù)輸出高風(fēng)險狀態(tài)超過5幀就進(jìn)入安全提醒流程語音的“沒事”可以短暫推遲提醒但不能取消提醒。娛樂場景的沖突則采用“多數(shù)決策置信度加權(quán)”比如用戶嘴上說“打開音樂”手勢卻指向“關(guān)閉車窗”兩個結(jié)果置信度接近Agent會主動詢問一句“您是想聽音樂還是關(guān)車窗”用一次澄清代替猜測。這個澄清策略在實(shí)踐中非常實(shí)用。與其追求一次交互就完全懂用戶不如在關(guān)鍵沖突點(diǎn)主動確認(rèn)換來的是整體交互成功率的提升用戶也不會覺得系統(tǒng)很“蠢”。5. 部署落地與性能優(yōu)化5.1 算力分配與NPU調(diào)度RK3588的NPU雖然性能不錯但多路模型同時上板后算力分配就成了大問題。語音喚醒模型、YOLOv8目標(biāo)檢測、手部關(guān)鍵點(diǎn)模型如果同時搶占NPU單個模型時延都會明顯上升。我的做法是給不同模型設(shè)置不同的NPU核心分配和優(yōu)先級。RK3588 NPU是三核架構(gòu)可以按模型配置單獨(dú)使用一個核心或多個核心。實(shí)際配置里語音喚醒長期占據(jù)一個核心保證隨時響應(yīng)視覺檢測和手勢關(guān)鍵點(diǎn)共享另外兩個核心且視覺檢測優(yōu)先級更高因?yàn)樯婕靶熊嚢踩討B(tài)手勢分類這類低頻任務(wù)直接跑CPU因?yàn)?2幀序列的分類計算量不大CPU完全扛得住。5.2 功耗、散熱與穩(wěn)定性座艙環(huán)境對功耗和散熱很敏感。RK3588滿負(fù)載運(yùn)行時機(jī)身溫度會明顯上升如果散熱設(shè)計不到位NPU會觸發(fā)降頻推理延遲直接翻倍體感就是“車機(jī)突然變卡”。我們做了兩件事一是結(jié)構(gòu)上增加了均熱板和導(dǎo)熱硅脂并預(yù)留PWM風(fēng)扇接口二是軟件層做了動態(tài)頻率調(diào)節(jié)策略根據(jù)NPU負(fù)載率動態(tài)調(diào)整運(yùn)行頻率避免一直滿頻空轉(zhuǎn)。在RK3588上接PWM風(fēng)扇時有個細(xì)節(jié)值得提一下風(fēng)扇轉(zhuǎn)速可以通過讀取PWM占空比或直接讀取風(fēng)扇的轉(zhuǎn)速反饋引腳來監(jiān)控但不同風(fēng)扇的反饋信號電平標(biāo)準(zhǔn)不一樣有的需要上拉電阻有的需要電平轉(zhuǎn)換接反了輕則讀不到轉(zhuǎn)速重則燒引腳。測試時先用萬用表確認(rèn)信號電平再接入主控能省很多排查時間。5.3 端側(cè)推理優(yōu)化小技巧端側(cè)模型優(yōu)化是個持續(xù)的過程幾個效果顯著的手段分享給大家。第一是量化RK3588的NPU對INT8量化支持得很好模型從FP16轉(zhuǎn)到INT8后體積縮小一半推理速度提升約40%精度損失在可控范圍內(nèi)。第二是輸入分辨率動態(tài)調(diào)整白天光線好時用640x640檢測夜間或暗光環(huán)境降到416x416減少無效計算。第三個技巧是模型并行和流水線設(shè)計。把感知處理拆成“采集-預(yù)處理-推理-后處理”四個階段用多線程流水線方式讓NPU推理和CPU后處理重疊執(zhí)行。實(shí)測整體吞吐提升明顯端到端延遲反而更低。這個思路和CPU流水線設(shè)計一致但在端側(cè)AI落地中很多人容易忽略。6. 測試方法與常見問題排查6.1 智能座艙多模態(tài)測試怎么做實(shí)驗(yàn)室環(huán)境和真實(shí)座艙環(huán)境差異很大。光線、振動、噪聲、人的坐姿每一項(xiàng)都可能讓模型表現(xiàn)明顯退化。我的測試分三層首先是單元測試單獨(dú)驗(yàn)證每個模態(tài)的識別準(zhǔn)確率其次是集成測試驗(yàn)證融合邏輯和Agent決策鏈路最后是實(shí)車路測覆蓋白天、夜晚、隧道、高速、顛簸路面等場景。自動化測試方面錄制了一套標(biāo)準(zhǔn)的語音指令集和手勢動作集包括正常語速、快速語速、方言口音、兒童聲音等變體以及不同光照、不同角度下的手勢視頻。每次模型更新后自動回放這套測試集對比各項(xiàng)指標(biāo)變化。這里強(qiáng)烈建議把基線指標(biāo)沉淀成文檔不然后續(xù)優(yōu)化時很難判斷改動是變好還是變壞。6.2 我在RK3588上踩過的坑說幾個印象深刻的坑。第一個是I2S音頻的延遲問題。系統(tǒng)啟動后第一次播放TTS正常但第二次會出現(xiàn)卡頓或延遲排查了很久發(fā)現(xiàn)是Audio HAL層沒正確釋放ALSA buffer導(dǎo)致后續(xù)請求排隊(duì)。加上一個buffer釋放和重建邏輯后解決。第二個是NPU模型轉(zhuǎn)換時的“delayline”錯誤。英文提示類似“cant find suitable delayline”看著像是RKNN內(nèi)部的某種流水線問題。網(wǎng)上資料很少后面發(fā)現(xiàn)是模型里某些算子的輸入張量維度與NPU的流水線約束不匹配把算子拆分或補(bǔ)一個Reshape后解決。遇到這類底層報錯不要硬猜先檢查模型結(jié)構(gòu)再檢查量化方式和輸入分辨率通常能定位到。第三個是Camera接入時的CSI信號完整性問題。MIPI CSI走線過長或阻抗控制不好會出現(xiàn)圖像花屏或偶爾丟幀。前期PCB Layout時就要按阻抗要求走線并用眼圖測試驗(yàn)證信號質(zhì)量不要等整機(jī)測試再排查。6.3 問題速查表問題現(xiàn)象可能原因排查與解決方法語音喚醒率突然下降MIC孔堵塞/麥克風(fēng)偏置異常檢查MIC開孔位置增大偏置電壓至1.8V~2.8V并確認(rèn)Codec配置錄音中有持續(xù)底噪I2S時鐘配置錯誤或電源紋波用示波器查MCLK/BCLK波形確認(rèn)I2S主從模式是否匹配播放TTS無聲ES8388輸出通道未初始化檢查DAC輸出通道使能、音量寄存器優(yōu)先排除ALSA mixer配置攝像頭圖像花屏CSI走線過長或信號串?dāng)_改善Layout阻抗匹配檢查MIPI差分對是否有干擾源YOLOv8轉(zhuǎn)RKNN失敗存在不支持的算子調(diào)整模型結(jié)構(gòu)替換Focus/部分上采樣算子或轉(zhuǎn)成ONNX時簡化圖結(jié)構(gòu)NPU推理偶發(fā)變慢溫度觸發(fā)降頻檢查散熱方案設(shè)置合理的動態(tài)調(diào)頻策略必要時加PWM風(fēng)扇手勢識別亂觸發(fā)靜止?fàn)顟B(tài)被分類為手勢增加運(yùn)動能量閾值激活起始/結(jié)束檢測邏輯多模態(tài)沖突誤判融合權(quán)重設(shè)置不當(dāng)按場景動態(tài)調(diào)整模態(tài)權(quán)重沖突時優(yōu)先安全信號并主動澄清7. 一點(diǎn)個人體會做完這個項(xiàng)目最大的感受是端側(cè)多模態(tài)Agent的難點(diǎn)不在于單個模型有多聰明而在于如何讓多路信號在真實(shí)、嘈雜、不可控的環(huán)境里穩(wěn)定協(xié)同。算法固然重要但結(jié)構(gòu)設(shè)計、時間同步、算力調(diào)度、散熱這些“看不見”的環(huán)節(jié)才是決定系統(tǒng)能不能落地量產(chǎn)的關(guān)鍵。如果讓我重新來一次我會更早地把測試場景定義清楚更早地介入硬件結(jié)構(gòu)設(shè)計而不是等算法跑通了再回頭調(diào)硬件。多模態(tài)交互是一個系統(tǒng)級的工程問題任何一個環(huán)節(jié)掉鏈子用戶的體感都是“這車機(jī)有點(diǎn)蠢”。另外建議大家在做端側(cè)Agent時不要把全部希望寄托在云端大模型上。端側(cè)快、穩(wěn)、可控云端強(qiáng)、廣、可擴(kuò)展兩者結(jié)合才是最優(yōu)解。先把端側(cè)能做的事做到極致再讓云端解決那些真正復(fù)雜的推理這個方向大概率是智能座艙接下來幾年的主流打法。本文還有配套的精品資源點(diǎn)擊獲取