最近小半年我集中干了一件事把市面上能摸到的车企Agent挨个拆了一遍。从车展Demo到量产车机从官方宣传片到实际装车的APK前前后后覆盖了几十家——新势力、传统厂商、合资品牌都有有些是借朋友的车实测有些是拿工程机刷机跑还有一些是直接抓接口看请求。拆完的感受放在开头绝大多数所谓Agent本质还是套壳对话真正能完成“感知-决策-执行-闭环”的一只手数得过来而那些硬着头皮上Agent的车企落地的坑一个比一个深。这个系列前几篇聊过座舱芯片、大模型上车、语音交互的底层逻辑这篇集中说Agent。我会把识别套壳的方法、实测踩到的坑、以及我眼中真Agent和假Agent的分水岭一次性讲透。不管你是在车企做产品还是准备选型供应商或者只是好奇车机里的AI到底几斤几两这篇应该都能给你一些参考。1. 车企Agent扎堆背后的真实驱动力为什么突然都在讲Agent1.1 座舱军备竞赛从“语音助手”卷到“智能体”其实是没得卷了过去五六年智能座舱的核心卖点是语音助手。最开始能听懂“打开空调”后来能听懂“我有点冷”再后来能连续对话、能区分主副驾。到了大模型上车之后各家发现传统的“规则槽位填充”那套已经撑不住用户预期了——用户开始对着车机问“前面那家火锅店评分怎么样”“帮我规划一条避开拥堵的路线”这些根本不是预先定义好的意图能覆盖的。这个时候Agent的概念被推了上来。车企话术里Agent 能理解复杂指令 能主动执行任务 能跨App协同。听起来很性感资本和用户都买账所以几乎一夜之间所有发布会PPT上都开始写“xxx智能体”“xxx Agent”好像没有Agent就不配叫智能座舱。但说实话这个转型是市场逼出来的不是技术准备好了。大多数团队根本来不及重构技术栈就把原来的对话系统改了个名字。我拆下来的实际情况是不少车型的Agent入口就是一个大模型聊天框能聊但聊完就完了。你让它“打开车窗”它回答一句“好的为您打开车窗”然后车窗纹丝不动。这种属于最粗糙的套壳稍微好一点的是接了车控指令但只能听懂十几种固定说法换个说法就死再好一点的能调用几个生态App但链路又长又脆稍微网络抖动就失败。1.2 供应商方案的大水漫灌让“真假Agent”更难分辨另一个推动因素是供应商。大模型厂商、语音方案商、地图厂商、甚至手机厂商都在给车企递Agent方案一套Demo打天下。供应商给的方案往往长这样一个大模型API 一套对话管理 几个预置工具查天气、放音乐、开空调。Demo跑起来确实像模像样因为演示环境是提前调好参数的换到量产车上麦克风阵列、网络环境、车控接口权限、算力平台全变了效果直接断崖式下跌。这里面有个很关键的信息差车企采购Agent方案很多时候买到的不是“智能体”而是一套“会说话的前端”。真正让Agent动起来的那套任务规划、工具调用、执行反馈、安全兜底供应商要么没做要么做得很浅。我拆过某款头部新势力的车机宣传里说“全场景智能体”实际抓包发现它的大部分对话回复都是LLM直接生成的文本能真正触达车控服务的只有四个API——空调、车窗、座椅、音乐还全是单向指令没有状态回读。所以这次拆解我给自己定了一条底线不看你宣传怎么说只看用户在车里实际能干什么。下面我详细讲讲怎么快速识别一套Agent是不是套壳以及拆了这么多家之后总结出来的共性坑。2. 手把手教你识别套壳Agent上车三连问 接口抓包验证2.1 上车前的三连问测试几乎能筛掉一半套壳货识别套壳Agent不需要很深的技术背景坐进车里做三个测试就能判断个大概。第一个是“连续变通测试”。正常说“我饿了”看它是真去搜附近餐厅并给出可执行的导航建议还是只回一句“好的为您搜索附近的餐厅”然后没有下文。再比如“空调太冷了”和“把温度调到22度”和“风量小一点”这三句话说的是同一个方向但表达方式完全不同。真Agent应该能把三句话都映射到温度/风量调节这个动作套壳的只能命中其中一种说法其余回复一堆废话。第二个是“指代消解测试”。说“导航去市中心那个商场就是上次去过的那个”然后紧接着说“换一条不堵的路”。这句话里有两个指代一个指代“那个商场”一个指代“那条路”。能正确理解并连续执行两个动作的说明它有真正的会话记忆和任务推理能力如果答非所问或者直接重新问一遍“请问您要去哪里”基本可以判定是套了对话模板。第三个是“跨域协同测试”。说“先导航到公司然后给老婆发条消息说我晚点到家”。这是一个多步任务涉及导航和通讯两个域。真Agent会拆解成两个子任务并依次执行套壳的通常只能识别出“导航”这个关键词后面的“发消息”直接被吞掉。我在实测中这三连问筛下来能全过的产品不超过五家。大部分在第一问就露馅了——不是回复内容不对而是说了等于没说回复完了没有动作。2.2 抓包看请求坐实“套壳”的铁证语言测试有主观成分抓包看接口是铁证。方法不复杂准备一个Wi-Fi热点把车机连上去用抓包工具比如Burp或Charles看车机和服务端之间的HTTP/WebSocket流量。重点看两类请求一类是纯文本生成请求特征是很明显的LLM API调用请求体是用户说的话响应体是一段自然语言。这类请求占大头的话说明系统就是“语音识别 大模型聊天”完全没有执行逻辑。另一类是工具调用请求特征是有结构化的指令参数比如{action: set_temperature, value: 22, target: driver}或者调用第三方服务的API签名。真Agent在用户说完话之后会产生一个从自然语言到结构化指令的转换过程然后带着这个指令去请求服务端。如果你抓到的流量全是第一类几乎没有第二类那不用再怀疑了就是套壳对话。我拆某合资品牌的一款量产车时连续对话十分钟抓到二十多个请求清一色是LLM文本生成连一个车控指令都没有。它的语音助手确实“听懂”了我说“打开座椅加热”回复也像模像样但座椅加热图标纹丝不动。这种车机你让用户怎么信任2.3 套壳Agent的五个典型特征对照自查拆了这么多我整理出一张特征对照表基本可以拿来当判断清单特征维度套壳对话Agent真Agent任务成功率靠话术圆场说“好的”但不动有明确执行结果成功/失败可感知多轮记忆只记最近一两轮指代混乱能维护会话状态与任务上下文工具调用没有或只有静态预设的几个有结构化工具接口支持动态组合失败处理复读“没听清”“请重试”无兜底能解释原因能降级或建议替代方案数据闭环无执行日志无结果反馈有执行日志、结果回读与效果评估这套表不光适用于车企任何号称Agent的产品都可以对照着看。我见过很多团队拿着一个“能连续对话”的聊天框跟老板汇报说做出了Agent其实连工具的边都没沾上。对话是入口不是Agent本身。Agent的核心是任务能不能闭环。注意抓包测试需要在合法的前提下进行优先使用自己拥有或经授权的车辆与网络环境避免触碰第三方隐私与安全边界。3. 落地全是坑我从实测里总结出的六个高频故障链路3.1 坑一意图识别“薛定谔的准确”——同一句话十次有八次能行两次不行这应该是我在所有车里遇到频率最高的坑。用户说“副驾座椅通风打开”Agent有时候能正确执行有时候回复“抱歉我还不会这个操作”有时候打开的是主驾座椅通风。同一个说法在不同时间、不同轮次、不同上下文下表现完全不稳定。定位链路走下来问题出在三个环节叠加。第一语音识别在行车噪声下把“副驾”听成了“副驾驶”或“副座”做了归一化但映射表不全第二意图分类器对“座椅通风”这种低频说法训练数据不足掉到了“座椅调节”这个粗粒度意图里第三槽位填充没做跨词性校验“副驾”这个槽位和目标区域映射错乱。给团队的修复建议也明确了这类问题不是换个大模型就能解决的。语音识别侧要做领域词典增强把座舱词条座椅/空调/车窗/导航等单独做热词加权意图侧要建“场景化评测集”专门收集车主口语化表达比如“我背上都是汗”这种隐性意图执行侧要加状态回读确认执行对象是不是用户指定的那个区域不是就主动纠错。3.2 坑二上下文一多就乱会话记忆变成“金鱼记忆”多轮对话是Agent的基本功但我在实测中发现很多车机Agent的上下文管理极其脆弱。用户连续说了三四个指令之后再问“刚才那个导航路线换成不走高速的”系统要么忘了刚才规划的是什么路线要么把“刚才”理解成上一个动作直接执行了完全无关的指令。这背后的技术原因比想象中复杂。很多车载Agent为了控制时延会把大模型的上下文窗口压缩到很短只保留最近一两轮对话一旦涉及跨轮指代就信息不足还有的是因为对话状态和任务状态分离——对话历史存在前端任务执行状态存在后端两者没有同步导致“对话记得的事”和“系统实际在做的事”对不上。这个坑的修复难度最大因为它牵扯到底层架构。我的建议是不要想着把全部历史都塞给LLM而是抽取出结构化的“会话状态”包括已完成的动作、未完成的指代对象、当前活跃的意图。每次对话时把结构化状态作为上下文的一部分输入模型同时定期做状态校验发现状态和实际不符就主动询问用户。这套方案能解决大部分上下文混乱代价是架构要提前设计后期很难补。3.3 坑三车控API七零八落Agent有手却使不上劲有个现象很有意思很多Agent产品Demo里控制空调、车窗、座椅都行云流水一到量产车上能控制的设备就少得可怜。原因不在Agent本身而在车控服务层。传统车机里的车控功能是各个供应商各自开发的空调是一个模块车窗是另一个模块座椅又是一个模块它们的接口协议、参数格式、调用方式完全不一样。Agent想统一调用需要一层“工具网关”把这些接口包成标准化的Tool。但很多车企没有这层网关或者只有部分车型有Agent要新增一个车控能力就得走一遍商务合同和开发排期根本谈不上“动态扩展”。我拆的一款传统厂商的车型就是典型宣传支持全车控制实际只接上了车窗和空调两个Tool氛围灯、座椅、天窗、后备箱全没接。我问厂家的人对方也很无奈“Tool接口是今年才提的需求底层那些BSP代码还是三年前的得一个一个适配。”所以选Agent方案之前先看清楚车控服务层有没有统一网关否则Agent的能力天花板一开始就被焊死了。3.4 坑四安全与误操作风险敢放权才是真问题真Agent和套壳对话之间隔着一道巨大的安全鸿沟。套壳对话只说话不做事天然没有安全责任真Agent要执行物理动作就绕不开误操作、异常状态、不可逆操作这三个问题。我在实测中遇到过几个真实场景说“把窗户开小一点”系统直接降了一半车窗但用户本意可能只是开一条缝说“帮我找一下附近充电站”Agent直接开始导航但车上还有小孩在睡觉用户根本不想启动导航还有一次喊“关闭所有车窗”系统只关了右后窗因为左前窗本身开了条缝且传感器状态没更新到执行模块。这些坑的本质是Agent缺少物理世界的状态建模和安全兜底。真Agent应该在执行通断类动作前先读取车辆当前状态判断动作是否合理在涉及安全的关键操作如驾驶中调座椅、儿童在场时开窗前增加二次确认或限制条件在执行完动作后还要回读状态确认结果否则用户看到的永远和系统以为的不一样。这个领域的行业共识在逐步形成但目前没有成熟标准。我给团队的实操建议是先列“可执行指令白名单”把每一个指令的安全等级、影响范围、确认门槛定义清楚再谈开放更多能力。宁可少开放不能乱执行。3.5 坑五多模态输入断层车外世界完全感知不到Agent这个概念天然带有“感知”属性。如果Agent只能听声音那它就和语音助手没有本质区别。真正的车载Agent应该能结合视觉、位置、驾驶状态、时间等多模态信息来理解上下文。但我拆下来的情况是车内摄像头普遍没接、车外感知数据比如前方拥堵、周边POI没有进入Agent的决策输入、导航系统的实时路况和Agent之间是两条平行的数据管道。最典型的场景是——用户说“前面那个商场”本意是结合前挡风玻璃看到的建筑来指代目的地但没有任何一个Agent能处理这种“视觉指代”因为视觉信息根本没进到模型输入里。多模态不是炫技恰恰是车载Agent区别于手机Agent的关键。车里的场景高度依赖位置、视线、手势和上下文想把Agent做到可用必须在数据层面打通车载传感器和座舱交互。现在多数车企还在为“能不能看见”发愁谈“看懂了”确实有点远。3.6 坑六时延和算力墙云端Agent在弱网下直接躺尸最后说一个最容易测量也最影响体验的坑时延。云端大模型API在信号好的时候首包响应大约1到2秒但车在移动过程中网络环境波动很大地下车库、隧道、郊区、高速上弱网断网是常态。一旦网络恶化云端Agent的响应时间直接飙到5秒以上用户喊完指令盯着屏幕干瞪眼。有些车企想走端侧模型路线但座舱的算力平台大致分布在几十TOPS这个区间还得同时跑仪表、中控、辅助驾驶的多块屏幕留给大模型的内存和算力并不宽裕。实测下来端侧7B级别的模型能勉强跑但推理速度和效果都跟云端有差距13B级别的模型几乎不可能流畅运行。这个坑没有完美解只能做策略组合高频、低延迟、安全要求高的指令如车窗、空调走端侧规则引擎追求毫秒级响应复杂的开放式问答和跨域任务走云端大模型允许1到3秒延迟弱网时降级到纯规则对话保证基本可用。分层调度是当前最务实的做法但很考验架构设计能力不是所有团队都愿意花这个功夫。4. 分水岭到底在哪真Agent和套壳对话的底层架构差异4.1 一个真Agent至少要有五层缺一不可我在上面反复说了“套壳”和“真Agent”现在把技术架构摊开来说清楚。我自己拆解和设计Agent系统时习惯分成五层感知输入层负责语音、视觉、位置、车辆状态、用户画像等多源信息接入是Agent对物理世界的“眼睛和耳朵”。意图与规划层把用户模糊的自然语言目标转换成可执行的任务序列。这是LLM的核心用武之地也是决定Agent聪明程度的关键。工具执行层通过Function Calling或MCP协议调用车控API、第三方服务、导航引擎等真实工具拿到结构化的执行结果。状态与记忆层维护多轮会话状态、任务执行状态和用户偏好让Agent“记得住”且“分得清”。安全与兜底层校验执行动作是否安全、权限是否足够、失败时是否降级、结果是否合理。套壳对话的典型架构是把感知输入层砍到只剩语音把意图与规划层换成一个直接生成文本的LLM工具执行层几乎没有状态记忆层只靠对话历史硬顶安全兜底层完全没有。看起来每一层都沾点边实际上只有中间那张嘴在干活。从这个角度看判断一套Agent是不是真的不用听厂商吹牛直接看它有没有“工具执行层”和“安全兜底层”。没有工具执行层的叫ChatGPT车载版没有安全兜底层的叫“闯祸机器”两个都没有的顶多算一个会说话的皮肤。4.2 Function Calling不是银弹你调得动工具不代表调得好现在很多供应商开口闭口Function Calling好像上了这个就是Agent了。我的看法是Function Calling只是Agent的及格线不是天花板。它在技术上解决的是“模型输出结构化工具调用参数”的问题但落地之后还有三道坎。第一道坎是工具描述的质量。模型要正确调用工具就得清楚每个工具的入参、出参、边界条件和副作用。我见过有些团队的Tool定义写得非常潦草比如adjust_temperature(temp: int)既没说单位是摄氏度还是华氏度也没说范围和多目标区域支持模型能不调错吗第二道坎是工具之间的组合编排真实任务往往需要多个工具按顺序调用中间还可能有条件分支和异常分支这不是单次Function Calling能解决的得有任务编排引擎。第三道坎是结果反馈的闭环调用完工具之后要把执行结果解析成用户能理解的反馈如果失败了要能解释原因、给替代方案。所以不要被“支持Function Calling”这句话骗了。真Agent的功夫都在Function Calling之外——工具建模、任务编排、状态管理、反馈闭环这里面每一个都是深水区。4.3 数据闭环是区分真假Agent的最终标尺我还有一个判断标准可能比较主观但拆了这么多家之后越来越笃定看数据闭环。套壳对话的产出就是文本用户说了什么、模型回了什么这个循环里产生的数据只有对话日志。真Agent的产出是动作——用户指令、意图解析结果、工具调用参数、执行结果、用户满意度反馈这组数据形成一条完整的闭环。有了这个闭环系统才能持续优化哪个意图经常转错、哪个工具调用经常失败、哪个场景用户最满意全部可以被量化复盘。反过来没有数据闭环的Agent迭代基本靠拍脑袋。今天觉得某个说法命中率低让标注团队去补样本明天觉得回复太啰嗦给Prompt加一句“请简洁”。这种迭代方式不是不行但效率极低而且永远发现不了深层问题——因为你看不到执行层面的失败率。所以我做Agent选型或者内部分析时一定会问三个问题你们有没有工具调用的全量日志有没有执行失败率的数据看板有没有基于失败日志做回归测试的流程这三个问题问下来真假立判。5. 避开这些坑的实操路径我给正在做Agent的团队几条建议5.1 从“高频低风险”场景切入别一上来就画全场景大饼和很多团队聊完我发现一个通病总想第一个版本就覆盖所有座舱场景把PPT上的“全场景智能体”一步到位实现。结果就是每个场景都浅尝辄止用户随便换个说法就崩最后连最基本的“打开空调”都被用户骂不好用。务实的做法是选三个“高频低风险”场景做深做透。我推荐起步优先做空调和座椅调节、导航和POI检索、媒体控制。这三个场景的特点是用户高频使用、物理动作简单、出错代价较低导航走错路可以重新规划空调调错温度可以再调。等这三个场景跑顺了积累了工具调用的数据闭环和用户习惯数据再逐步扩展到车窗、天窗、后备箱、预约充电这些中频场景。每一个场景的打磨标准也简单找二十个真实用户做测试收集他们的自然表达整理成回归集每条表达在三个环境安静、高速噪声、空调风量最大下各测五遍成功率低于90%就继续优化调工具描述、调Prompt、调槽位映射直到过了门槛再上线。慢是慢点但每上一个大场景用户是真的能用起来的。5.2 架构上先把“工具网关”和“安全白名单”定下来我在前面说过很多Agent落地受阻卡在车控服务没有统一网关。这事必须在项目早期解决越晚代价越大。工具网关要做的事是把车内所有可执行能力封装成统一的Tool接口定义好统一的鉴权、参数校验、速率限制、异常返回格式同时提供沙箱环境供Agent在测试时安全调用。安全白名单是另一条必须前置的线。每一类可执行动作都要定义安全等级和执行策略。以车窗为例调节车窗属于中等敏感操作涉及乘员安全建议在行车过程中禁止执行或降级为语音提示座椅调节如果车辆在行进中应该限制调节幅度或要求二次确认而空调温度、音量这类低风险操作可以放开直接执行。这个白名单不光是给Agent用的也是给用户安全兜底的最后一道闸。5.3 用“回归测试集 对抗样本库”当验收标准很多Agent项目验收的时候演示Demo一切顺利一到用户手里问题百出。根源是验收标准不对——Demo只能证明“精心准备的输入能被正确处理”证明不了“真实世界的长尾输入也能正确处理”。我建议建两套测试资产把Agent在实验室里榨干再上线。第一套是回归测试集来自真实用户语料的积累按场景分类每个场景至少500条覆盖标准说法、口语说法、方言说法、噪声环境说法、指代说法、否定说法。第二套是对抗样本库主动构造难例比如“语法错乱的句子”、“故意省略主语的指令”、“前后矛盾的指令”、“包含安全风险的操作”、“跨域复合任务”。每次Agent更新迭代后跑一遍这两套测试集把成功率、失败原因、回归问题全部记录下来。这套方法不是我的原创是行业内做对话系统常用的思路。但在车载Agent这个领域真正执行的团队少之又少。多数团队还是靠几个产品和开发口头评估“感觉差不多”结果上线之后被真实用户教育。所以我把这个建议放在这篇文章的最后因为它才是“落地不全是坑”的护城河。我拆了这几十家Agent之后最深的体会是Agent这个词正在被严重透支。用户被宣传吊高了预期坐进车里试了一次发现全是“嘴上功夫”反过来对整个智能座舱都失去信任。做Agent这件事宁可把场景缩窄一点、把成功率做扎实一点也不要拿着一个大模型聊天框去碰瓷“智能体”。工具调用、状态记忆、安全兜底、数据闭环这几样没有任何一样是可以靠改PPT糊弄过去的。
