去年开始我给国内几家车企和头部Tier 1做过AI Agent相关的技术尽调和项目评审前前后后看了四十多个号称“汽车AI Agent”的交付物和Demo。结论挺扎心的这里面超过九成本质上是套了一层大模型外壳的对话机器人跟“业务智能”四个字基本不沾边。标题里的“大面积翻车”不是夸张是我在评审单上一个一个勾出来的真实结果。这篇是这个系列的第四篇我不打算继续停留在概念讨论。这篇文章会讲清楚三件事我判断一个汽车AI Agent是不是套壳的具体标准是什么真正的汽车业务智能应该长成什么样以及如果你想做——或者你正在采购——一个真正能下地干活的汽车AI Agent应该怎么下手。1. “90%翻车”这个数字是怎么得出来的先交代一下我的取样方法免得被说拍脑袋。过去十个月我重点看了三类东西车企自己做的座舱AI项目、供应商投标时提交的Agent方案、以及已经量产装车的语音助手和售后客服系统。研究方法也很朴素——把它们的“人机交互演示”和“真实业务系统操作”分开来看再要求对方提供系统接口调用日志和业务系统改动记录。1.1 我用一个土办法做筛选大多数供应商在讲PPT的时候都是同一套话术我们的AI Agent能听懂用户意图、能调用工具、能做多轮对话。真正动手验证的时候我一般只提三个要求给我看这条对话背后到底调用了哪个业务系统的哪个API参数是什么如果API调用失败Agent能不能感知到并且触发补偿动作这个Agent完成一次任务之后业务系统里的数据发生了什么变化就这三条能挡住绝大部分“伪Agent”。原因后面细讲但先记住一个核心结论Agent和聊天机器人的分界线是它能不能改变业务系统的状态。我见过最典型的一个项目某车企的售后部门采购了一套“AI Agent”宣传是能处理用户保养咨询和预约。实际拆开来看它确实接了知识库用的是某个大模型厂商的Embedding接口和向量数据库回答保养周期、机油型号这类问题有模有样。但用户如果说“帮我预约明天下午的保养”它只会回复一段话“好的建议您拨打400电话或通过App预约。”这算哪门子Agent1.2 四十多个项目里的三种典型“伪Agent”筛完之后我发现大面积翻车的项目基本都能归进三类第一类叫“知识库问答伪Agent”。占的比例最高六成以上。这类产品就是把汽车手册、售后政策、FAQ切块塞进向量数据库外面套一个对话界面。用户问什么它答什么答不出来就“建议联系人工”。全程没有意图识别之外的动作纯粹是一个更聪明的FAQ。第二类叫“意图识别伪Agent”。比第一类稍微进了一步它能识别“我要充电”“我要保养”“我要找附近的4S店”但识别完之后只是把结果推给用户或者弹一个H5页面。它依然没有连接任何业务系统所有的“服务”都是跳转链接。第三类叫“低代码编排伪Agent”也是我觉得最坑的。它用了一些Agent框架里面定义了节点、有状态流转、有工具调用的架子但工具那一栏空空如也。像样的接了个天气查询或日历然后就没有然后了。Demo阶段看起来很唬人因为流程图画得很漂亮一问到“调用你们的订单系统了吗”“接到DMS经销商管理系统了吗”对方就开始含糊其辞。这三类项目全算上我评估样本里的对话机器人率大概在85%~90%之间跟标题里的数字吻合。2. 套壳对话机器人的技术底子决定了它干不了活要理解为什么这么多项目翻车得先看清楚套壳对话机器人的技术路线。它不是某一个供应商偷懒而是大多数团队在“用最快的速度拿出一个AI Demo”这个KPI下必然会走的路。2.1 标配技术栈LLM加向量数据库加提示词套壳对话机器人九成是同一套架构大模型API或者开源模型私有化部署向量数据库存知识切片一个提示词模板负责约束回答风格前端套一个对话框这套架构做“懂车帝式问答”和“汽车手册查询”是够用的这也是为什么这么多团队选它切入。我对这种架构本身没有意见它确实解决了一类问题——用户获取车辆知识、政策信息的成本降低了很多。但问题在于这套架构的一切能力都围绕“生成内容”而不是“完成任务”。大模型负责生成知识库负责找素材唯一的输出通道是文字。它没有手没有脚连“给用户创建一个工单”这种最简单的动作都要靠人去手动完成。因此当用户的需求从“问一下”变成“办一下”的时候这套架构就崩了。我问过很多做这类产品的团队同一个问题用户让你预约保养你们的完成率是多少答案通常非常模糊或者说“系统会把用户需求记录下来由人工跟进”。这里有个冰冷的事实一个只能“记录用户需求”的系统不叫业务智能。用我前文的判断标准——业务系统状态根本没有发生改变一切都停留在对话层。2.2 三个致命短板无状态、无动作、无感知把套壳对话机器人的弱点拆开来看主要是三个第一个是无状态。它对上下文的理解基本停留在单次对话内最多保留几轮“记忆”。它不关心用户这辆车是首保还是十万公里大保不关心用户是刚下订单还是已经提车三年更不关心用户上一通电话投诉过什么。各家座舱里的“记忆”其实是个性化话术不是业务状态。真正的状态在DMS系统里、在CRM系统里、在车联网平台里套壳机器人全都看不到。第二个是无动作。它没有能力去调用DMS创建预约工单没有权限去修改CRM里的用户标签不能通知仓库备货更不能触发OTA升级任务。因为所有这些动作都需要API对接、需要权限体系、需要数据同步——而这些套壳架构一开始就没有设计进去。第三个是无感知。它运行在一个“真空”环境里。用户说“保养做完了”它接一句“好的”可系统里根本没有保养工单这回事所以无法校验用户说的是不是真的。任务执行是成功还是失败它不知道也没办法基于结果做下一步推理。一个没有反馈信号的系统是不可能变聪明的。2.3 套壳不是原罪但要清楚自己的边界我得说句公道话套壳对话机器人也并不是全无价值。我见过做得不错的案例——某个新势力品牌的售后知识助手把车辆故障码查询、保养周期提醒、OTA升级说明整合得很好用户主动满意度数据很漂亮。它的问题不是“没用”而是“被当成Agent来卖”。当企业为“对话机器人”付了“业务智能”的钱当项目验收写的是“AI Agent落地”实际上线的是老式FAQ这才是争议的核心。我认为这个责任不能完全算在供应商头上采购方的认知错位、项目验收指标定得稀烂同样跑不掉。这个话题放到后文专门讲。3. 汽车行业真正的“业务智能”Agent应该分成四个层级想避免套壳先得建立标尺。这几年我做咨询和评审一直在用一套自己归纳的四层成熟度模型来给汽车AI Agent定位。很多项目翻车本质是把第二层的活包装成了第三层甚至第四层来卖。四层模型如下表层级名称核心能力典型示例L0语音指令单意图、固定命令传统的“打开天窗”“调到25度”L1对话式问答多轮对话、知识检索车辆手册问答、政策咨询L2单域任务Agent在单一业务域内闭环执行保养预约、充电推荐、工单创建L3跨域业务Agent编排多个业务系统完成任务故障诊断配件库存售后派单客户通知L4自主业务智能持续优化业务目标根据维保数据主动触达用户并动态调配产能3.1 L2第一个值得认真做的分水岭我见过的大量“翻车”项目其实只想做L2——比如把售后场景里的预约这个动作做闭环。但问题是他们做出来的东西停在L1加一个表单收集。一个真正的L2保养预约Agent应该长这样用户说“我这周六想去做保养”Agent理解并提取用户信息车牌、车型、保养类型Agent向DMS系统查询用户车辆当前的保养记录和里程数Agent给出符合条件的4S店列表附上各店本周六的空闲工位用户选择A店Agent调用DMS的预约API真实创建一个预约工单工单审核通过Agent把预约信息与到店指引推给用户如果门店产能满了Agent提供备选方案或者自动进入等待队列整套动作下来业务系统里多了一条真实的预约工单4S店服务顾问能看到接车时有准备。这才是我说的“业务智能”。它完成的不只是对话而是把对话直接变成了业务动作。3.2 从L2到L3的跨越考验的是编排能力做L2考验的是接口打通和数据质量做L3才是真正考验Agent能力的地方。我举一个L3的实际场景用户在高速上车胎报警。L2级别的Agent能查到故障码并告诉用户“轮胎气压异常”但也就到此为止了。L3级别的Agent会把这件事当成一个任务来编排结合车联网数据判断胎压数值、车速和轮胎温度判定是否为爆胎风险决定是引导用户安全靠边还是可以低速行驶到服务区同时查询沿途服务区的轮胎维修点和备胎库存如果风险较高直接向品牌道路救援系统创建救援工单把救援车辆的位置实时同步给用户L3与L2的本质区别在于它不再是一个“助手”而是站在用户的处境里把多个后台系统按任务需要编排起来。要做到这一点Agent必须具备业务视角——理解“高速爆胎”这个场景涉及车况、安全、维修、位置、救援等多个域而不是把每个域当作孤立问答。3.3 L4现阶段最容易被吹牛的层级L4自主业务智能当前没有多少真正量产案例。它意味着AI不只是被动响应而是主动制定策略并达成业务目标。比如系统根据几万名用户的维保数据、配件库存和门店产能自动给潜在保养客户排定优先级通过企微和App触达并根据用户的回复自适应调整话术和时间。这种能力目前绝大部分车企都还不具备。但凡是跟我说自家已经做到L4的供应商我基本会礼貌地请他出示效果数据然后大部分人就聊不下去了。原因很简单L4需要极其扎实的L2和L3基础基础数据一团糟谈什么自主决策。4. 一套能直接落地的鉴别方法给汽车AI Agent做“体检”怎样在采购、立项、验收时不被人糊弄我给你一套我自己用的鉴别方法不需要多高的技术门槛按下面这五步走就能看出一个所谓“汽车AI Agent”的真实成色。4.1 第一个指标动作闭环率问对方一个问题“你们的Agent完成的动作里有多少比例是真正写入业务系统的不是对话回答而是创建了订单、更新了工单、修改了配置这种级别的动作占比多少”我把这个指标称为“动作闭环率”。套壳机器人的动作闭环率是0因为它的所有输出都以文字结束。一个及格的单域Agent动作闭环率至少应该在70%以上。低于这个数你需要质疑它是否只是一个包装精致的导流工具。4.2 第二个指标系统连接数让乙方列一张接口清单写明Agent生产环境里真实连接了多少个业务系统每个系统调用哪些API平均日调用量是多少。我见过相当气派的PPT画了十几个系统连接包括CRM、DMS、车联网、MES一问生产环境连接数支支吾吾说“目前正在联调中”。其实这不一定说明对方用了欺骗手段也可能是整个项目还停留在POC阶段。但无论如何一个没有在生产环境连上三个以上核心业务系统的Agent不给它标“业务智能”这四个字。4.3 第三个指标异常处理能力这个指标最能看出一个Agent是真业务智能还是只是单纯的对话模板。测试方法很简单故意给出一个系统无法完成的需求或者中断一个正常的执行流程。好的Agent会说你要预约的这家店今天已满能不能接受隔壁区的另一家店或者改到周六上午同时把改期这个动作带着用户的授权直接执行掉。差的Agent只会说非常抱歉我暂时无法处理您的需求请尝试联系人工客服。异常处理能力我认为是业务智能最硬的门槛。真实业务环境里充满意外系统宕机、库存不足、权限不足、用户反悔、重复下单。能不能识别这些异常并做出合理决策直接决定了Agent能不能从Demo走向实际生产。4.4 第四个指标状态记忆与跨人跨设备连续性一个真正业务化的Agent必须能在不同会话间保持业务状态的连续。比如用户上午在手机上跟Agent聊了维保方案下午在车上跟同一个Agent确认预约Agent不需要用户重头说起。套壳机器人的做法是换一个会话就“失忆”只靠对话里追问。真正业务智能的做法是把会话状态写到业务存储比如订单状态、用户的决策进度这样跨渠道、跨时间都能接得上。这一条很多产品连及格线都没有。4.5 第五个指标业务效果反馈最后一条依然是老生常谈——看数据。Agent上线后有没有带来可衡量的业务指标变化比如预约成功的转化率、客服工单平均处理时长、用户一次性解决率、门店产能利用率。有一点需要注意有些项目确实提升了“用户对话时长”和“消息数”但这些指标对业务来说毫无意义。用户聊得越多不代表任务完成得越好。一个好的业务Agent追求的不是让用户聊更久而是让用户尽快完成目标然后离开。评估这件事时用“任务完成效率”会比“对话轮数”健康得多。4.6 随身两招不用看技术文档也能测如果你没有条件去查接口文档和后台日志那就带上两个测试用例去现场的Demo机测试一提出一个需要修改业务数据的需求。比如“我要把预约从明天改到后天”看它能不能在系统里真正完成一次修改并给出新的确认信息还是只回一句“好的我已记录您的需求”。测试二恶意打断流程。在它执行某个多步任务时突然说“算了不办了换一个方案”看它能不能真正地撤销之前已经创建的动作还是道歉之后留下一堆脏数据。这两个测试能过滤掉大半靠PPT吃饭的项目。动作修改不了、操作撤不掉的Agent任凭它说得再漂亮也是套壳。5. 回到现实为什么车企集体踩进了同一个深坑技术鉴别这套方法说穿了并不复杂但我接触的车企项目里真正按这套标准去验收的还是极少数。问题出在技术之外。5.1 立项时的KPI就错了大多车企内部立项时依然沿用“建设XX系统”的老思路验收标准天然偏向“有没有”而非“用起来怎么样”。项目验收看的是系统开了发布会、功能清单勾完了、第三方检测报告出了这套体系对“业务效果”的约束力极为有限。这直接导致乙方交付策略走向“看起来全面”而不是“用起来好用”。对乙方来说把功能列表做得越长越好每页Demo都确保有AI在说话但没人真的要求“线上跑通一个月看转化率变化”。还有一个现实因素AI项目的预算通常是“创新预算”而不是“业务预算”意味着项目负责人更关心的是汇报材料里能不能展现AI元素对业务结果本身反而没有特别强的KPI压力。5.2 供应商商业模式的错位很多做汽车AI Agent的供应商本质上是项目制的外包公司。它的商业模式决定了它没有动力陪客户做长期的业务打磨。外包公司按人天收费用一个开发周期交付完拿到验收款项目就结束了。至于Agent在真实业务环境里跑得好不好跟它的下季度营收没有直接关系。真正做业务智能的公司应该靠什么赚钱要么按效果分成比如通过Agent带来的每笔预约订单抽成要么按订阅付费加持续优化服务。可惜目前国内主流的汽车AI Agent采购模式还是“一次性开发费用”这种商业模式天然激励“交付漂亮Demo然后离场”。5.3 IT部门与业务部门之间的断层我在多家车企里都观察到同一个现象采购AI Agent的往往是IT或数字化部门而真正使用这个系统的业务人员售后顾问、客服坐席、门店经理很少参与需求定义和验收。IT部门偏好“技术架构先进”业务部门苛求“直接解决问题”这两个在项目里总是错位。最后交付出来的Agent技术上用了最新的框架、有漂亮的编排图可它连门店的营业时间段这种基础业务规则都不知道。就是因为这个需求从来没有人去问过门店店长。我做过一次挺有意思的试验把一套“语音助手Agent”的Demo拿给某4S店服务顾问用对方礼貌地听完跟我说“这个还不如我直接把电话给用户。”他不需要AI替他念说明书他需要的是AI能把预约单处理好、把用户到店前的准备工作做掉这些恰恰是大部分Agent系统最弱的部分。6. 作为从业者我的落地建议翻车之后怎么走讲了这么多行业问题还是得回到建设性话题上。如果你现在正负责车企业务里的AI Agent项目想避开“九成翻车”的魔咒从我个人的实践经验出发我会给你这几条建议。6.1 场景选择的四条铁律场景是决定成败的第一要素。我用一个简单的过滤器来评估值得做的场景四个条件缺一不可动作可闭环该场景里存在明确的业务动作比如创建工单、改预约、下订单而不是纯粹的“给答案”数据可触达你在这个场景里能拿到打通业务系统所需的数据权限和接口频次足够高低频场景做出来很难积累数据、迭代优化尽量选月活足够高的容错有空间初期Agent一定会犯错选那些错了能补救、不会直接造成致命影响的场景按这个标准我最推荐的切入点是售后维保预约、充电服务导流和维修进度主动通知。这三个场景动作明确、用户求强、容错空间也比较大。6.2 架构上的三个关键决定如果还有机会重新设计一个汽车AI Agent的技术架构我建议把下面这三个决定做好第一Agent必须面向API设计不是面向对话设计。你把业务系统的能力梳理得越清楚Agent的手脚就越灵活。我自己做项目时习惯先把候选场景相关的API全部列出来用OpenAPI规范管理然后再去设计Agent的思考流程顺序不能倒。第二状态和业务上下文要放在Agent框架之外。我目前比较推崇的做法是把多轮对话中的业务状态持久化在订单系统或状态机里而不要全部依赖Agent框架本身带的短期记忆。为什么生产环境的业务连续性要求跨会话不丢状态而不是只有“这一轮聊得顺”。第三并发和可靠性需要专门的工程投入。很多团队做Demo时毫不在意并发一到上线就翻车。汽车售后场景天然有集中峰值的特征比如OTA升级公告发出后客服入口瞬间涌入大流量。在这个点上对话入口的并发架构跟业务接口的限流降级要放在一起设计否则一个热点就能把整套系统打崩。语言和中间件层面我偏向用轻量级网关比如Rust写的高并发服务做接入层把大模型推理和业务编排交给FastAPI加LangGraph这类成熟框架。这样各司其职既不用神话某一门语言也不用在一个框架里塞下所有事情。6.3 组织保障比技术方案更关键也许是最重要的一点让业务人员从一开始就进项目组。不要让IT部门隔着一个需求文档去猜业务场景。实际操作中我建议项目组固定吃进三类人懂Agent技术的产品经理、懂后端系统整合的工程师、以及一线业务运营骨干。验收标准里一定要写清楚“业务指标”而不是“技术指标”。与其要求“支持1000个意图”不如要求“预约转化率提升10%”。另外给Agent系统留出两个月的“训练运营期”。所有业务智能都不是一次性交付就能成的上线之后要有人根据对话日志持续做Badcase分析、规则调整和模型微调。会翻车的项目里十有八九是因为交付之后没有人接后续优化这摊子事。最后再说说我的判断回头看汽车AI Agent这个赛道我认为“翻车”其实是一次很及时的洗牌。套壳对话机器人能拿预算的时间窗口正在收窄企业方正在快速建立起“能不能办事”的鉴别能力。比起嘲讽谁在裸泳我更关注下一批真正能改变业务状态的Agent什么时候出来。从我的经验看有两条路会走通一类是深耕单点场景闭环的Agent比如售后预约做到了区域网络的产能智能调度体量不大但场场都是真金白银的降本另一类是跨域编排的出险、救援、维修这类复杂任务Agent背后的系统性工程更难复制护城河也更深。至于那些至今仍然把“能对话”当成核心卖点的产品——我建议直接把PPT第一页改掉换成一句更诚实的话这是一个带AI客服功能的FAQ系统。这不丢人但别冒充业务智能。