企业官网建设流程全解析

去年开始，我给国内几家车企和头部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预约。”这算哪门子Agent？

1.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定位。很多项目翻车，本质是把第二层的活，包装成了第三层甚至第四层来卖。

四层模型如下表：

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系统。这不丢人，但别冒充业务智能。