1. 当"智能体"变成"智障体"：我在三家车企看到的真实落地现场

去年下半年到今年年初，我因为做AI产品咨询的关系，先后跑了三家主机厂和两家Tier1供应商的数字化部门。聊的话题都差不多：你们那个"汽车AI Agent"到底跑成什么样了？结果听到的答案惊人地一致——演示的时候像模像样，真到了业务流里，基本就是个"套壳对话机器人"。

这话不是我在黑谁。你去看现在市面上打着"汽车AI Agent"旗号的产品，十有八九是这么个结构：前端一个对话框，后端接一个大模型API，中间塞几段提示词模板，再挂几个写死的函数调用。用户问"帮我预约明天下午的保养"，它能回你一句"好的，已为您预约"，但后台的工单系统根本没动，因为那个"预约"动作压根没接进去。这就是典型的套壳对话机器人，跟业务智能之间隔着十万八千里。

我写这篇东西，不是要唱衰汽车AI。恰恰相反，我觉得这个方向是对的，只是现在被太多"伪Agent"给带偏了。这篇文章适合三类人看：一是车企里负责AI落地的产品和研发，二是给车企做AI方案的乙方同学，三是想搞清楚"AI Agent到底是不是智商税"的技术管理者。我会把我在现场看到的翻车案例、翻车的根因、以及真正能跑通业务智能的Agent该长什么样，一层一层拆开讲。

先给个结论垫底：90%的汽车AI Agent翻车，不是因为模型不够强，而是因为架构上就没把它当"业务系统"来设计，只当成了一个"聊天窗口"。这个认知偏差，是所有问题的源头。

2. 拆开一个"套壳Agent"的骨架：它到底缺了什么

2.1 套壳架构的三层皮：对话框、提示词、假函数

我把现场看到的套壳Agent拆解了一下，基本逃不出这三层结构。

最外面一层是对话框。用户在车机或者App里看到一个聊天界面，输入自然语言，Agent返回自然语言。这一层做得最花哨，有的还加了语音、加了数字人、加了情绪识别，但本质上就是个输入输出通道。

中间一层是提示词模板。开发者把业务规则写成一段一段的prompt，比如"如果用户问保养，就引导他提供车型和里程；如果用户问充电，就告诉他最近的充电桩"。这些提示词往往有几百行，堆在一个配置文件里，改一次要重新部署。

最里面一层是假函数调用。这是最要命的地方。很多Agent号称"能调用工具"，但你去看它的实现，所谓的工具调用就是把用户的话转成一个JSON，然后……然后就没有然后了。那个JSON要么被丢弃，要么被写进一个日志表，真正的业务系统（DMS、CRM、工单、车控）根本没被触发。

提示：判断一个汽车AI Agent是不是套壳，最快的办法就是问一句"你刚才说帮我预约了，工单号是多少？"如果它答不上来，或者给一个查不到的假号，那就是套壳无疑。

2.2 业务智能的三个硬指标：可执行、可追溯、可回滚

那什么叫业务智能？我给它定了三个硬指标，缺一个都不算。

可执行，意思是Agent的每一个"动作"都必须真实落到业务系统里。用户说"把空调调到24度"，车控接口就得真的被调用，而不是回一句"已为您调节"。这个"执行"必须是幂等的、有超时处理的、有失败重试的。

可追溯，意思是每一步决策都要留痕。Agent为什么选择调用这个接口而不是那个？它读了哪些上下文？中间有没有人工确认？这些都要能查。车企的业务流很多涉及安全和合规，没有追溯能力的Agent，业务部门根本不敢让它上线。

可回滚，意思是执行错了能撤销。比如Agent误判用户意图，把"取消订单"理解成了"确认订单"，那必须有一个补偿机制把状态改回去。套壳Agent完全没有这个概念，因为它压根没改过状态。

这三个指标听起来简单，但真做起来，工作量比接一个大模型API大十倍不止。这也是为什么很多团队选择"套壳"——因为套壳快啊，两周就能出Demo，而真做业务智能，三个月起步。

2.3 一个真实翻车案例：预约保养为什么变成了"复读机"

我印象最深的一个案例，是某车企的"智能保养助手"。演示的时候，产品经理对着大屏说"我车该保养了"，Agent流畅地回了一串，还"帮"用户选好了最近的门店和时间。台下掌声一片。

结果上线两周，客服投诉爆了。用户说"我明明跟它说了要预约，它就一直重复问我'您确定要预约吗'，问了五遍，最后也没约上"。

我去看了日志，问题出在状态管理上。这个Agent没有会话状态机，每一轮对话都是独立的。用户说"确定"，Agent收到的是一个孤立的"确定"两个字，它不知道这是在确认上一轮的预约意图，于是又走了一遍"您确定要预约吗"的流程。这就是典型的无状态套壳——它把多轮对话当成了单轮问答的拼接。

修复方案其实不复杂：引入一个显式的会话状态对象，记录当前处于"意图识别""信息补全""确认""执行"哪个阶段，每一轮对话都带着状态走。但就这么个改动，那个团队做了将近一个月，因为他们原来的架构里根本没有"状态"这个概念。

3. 为什么套壳方案在汽车场景里特别容易露馅

3.1 汽车业务的强约束：安全、实时、多系统耦合

汽车这个场景，跟你在电脑上问ChatGPT完全不是一回事。它有三个特别硬的约束。

安全约束。车控相关的指令，比如解锁、启动、调空调，误执行一次可能就是事故。套壳Agent那种"猜意图"的做法，在安全场景里是致命的。你不能让一个概率模型去决定要不要解锁车门。

实时约束。用户在车里说一句话，期望的响应时间是毫秒级到秒级。套壳Agent往往要串好几个大模型调用，延迟动辄三五秒，用户体验直接崩掉。

多系统耦合。一个"帮我找充电桩"的需求，背后要串导航系统、充电桩数据库、支付系统、用户偏好系统。套壳Agent通常只接了其中一个，剩下的靠"编"，编出来的结果用户一验证就穿帮。

3.2 对话机器人的能力天花板在哪里

我不是说对话机器人没用。作为入口，对话是很自然的交互方式。但对话机器人有它的能力天花板。

它能做的是：理解意图、抽取槽位、生成回复。它做不了的是：维护跨会话的长期状态、协调多个后端系统的调用顺序、处理调用失败后的补偿、在安全边界内做决策。

很多团队把"对话能力强"等同于"业务能力强"，这是根本性的误判。一个模型可以把保养流程讲得头头是道，但它不一定能真的把工单建出来。说和做，是两套完全不同的能力。

3.3 用户预期与产品现实的落差从哪来

落差主要来自演示环节。演示的时候，产品经理会挑最顺的路径走，Agent表现完美。但真实用户不会按剧本说话，他们会说方言、会打断、会一次说三件事、会在中途改主意。

套壳Agent没有处理这些"意外"的能力，因为它所有的分支都是写死的。一旦用户的话超出了预设的几条路径，它就开始胡言乱语，或者陷入复读。用户第一次觉得新鲜，第二次觉得还行，第三次就直接卸载了。

4. 真正能跑通业务智能的Agent，架构上要做对哪几件事

4.1 把"工具调用"做成真正的一等公民

真Agent和套壳Agent最大的区别，就在工具调用这一层。套壳的工具调用是装饰，真Agent的工具调用是核心。

具体怎么做？我的经验是，先把业务能力抽象成一组原子工具。比如"查询车辆状态""创建保养工单""查询门店空闲时段""锁定预约时段""取消工单"，每个工具都有明确的输入输出schema、超时时间、重试策略、幂等键。

然后，Agent的职责变成"编排这些工具"，而不是"生成一段话"。大模型在这里的作用是决策——根据用户意图和当前状态，决定下一步调用哪个工具、传什么参数。这个决策过程要可解释、可干预。

我见过做得比较好的一个实现，是把工具调用做成了类似工作流引擎的东西：每个工具是一个节点，节点之间有条件和顺序，大模型负责在关键分叉点做选择。这样既保留了大模型的灵活性，又有工作流的可控性。

4.2 状态机与会话记忆：别让Agent"失忆"

前面说的"复读机"问题，根因就是没有状态机。真Agent必须有一个显式的会话状态，至少包含：当前意图、已收集的槽位、待确认的信息、已执行的工具、执行结果。

这个状态要持久化，不能只放在内存里。因为用户可能中途去干别的事，过十分钟回来接着说，Agent得记得之前聊到哪了。

会话记忆还分短期和长期。短期是当前这通对话的上下文，长期是这个用户的历史偏好——比如他常去的门店、他习惯的保养周期。长期记忆要单独存，而且要能更新和遗忘，不能无限堆积。

4.3 人在回路：哪些决策必须交还给人类

汽车场景里，有些决策是绝对不能交给Agent自动执行的。比如涉及金额超过一定阈值的、涉及车辆安全控制的、涉及用户隐私数据导出的。

这些场景要设计人在回路机制：Agent把决策建议和依据呈现给用户或客服，由人来点确认。这个确认动作本身也要被记录，作为追溯的一部分。

我在一个项目里看到过很聪明的做法：Agent把"建议预约XX门店XX时间"做成一张卡片，用户点"确认"才真正执行。这个卡片既是交互，也是审计凭证。

4.4 评测体系：怎么量化一个Agent到底"智能"在哪

没有评测，就没法迭代。套壳Agent通常没有评测体系，因为它的成功标准就是"演示时没崩"。

真Agent需要一套离线+在线的评测。离线评测用构造的对话数据集，测意图识别准确率、槽位填充准确率、工具调用正确率、任务完成率。在线评测看真实用户的完成率、平均轮次、放弃率、投诉率。

我建议至少盯住两个指标：任务完成率和平均交互轮次。完成率低说明能力不够，轮次高说明交互设计有问题。这两个指标一起看，基本能判断一个Agent是真智能还是假智能。

5. 从套壳到业务智能，团队要跨过的三道坎

5.1 组织坎：AI团队和业务团队谁说了算

我观察到一个规律：套壳Agent往往诞生在"AI团队主导、业务团队配合"的组织里。AI团队想快速出成果，业务团队没动力深度参与，结果就是AI团队自己拍脑袋定义业务流，做出来的东西业务部门不认。

真Agent必须业务团队主导、AI团队赋能。业务团队最清楚流程里的坑在哪、哪些环节不能自动化、用户最常卡在哪一步。AI团队的价值是把这些业务知识翻译成Agent能执行的逻辑。

这个组织调整说起来容易，做起来难。我的建议是，至少在项目初期，让业务团队的人全职参与，而不是"抽空支持"。

5.2 数据坎：业务系统的接口不是为Agent设计的

车企的业务系统，很多是十年前建的，接口设计的时候压根没考虑过会被AI调用。有的接口没有幂等性，调两次就建两个工单；有的接口返回的是HTML，得解析；有的接口权限控制很粗，Agent一调就是全权限。

这些都得在Agent落地前解决。要么改造后端接口，要么在Agent和业务系统之间加一层适配层，把脏活累活都封装在适配层里。适配层还要负责限流、熔断、降级，防止Agent把业务系统打挂。

5.3 认知坎：别把"能聊天"当成"能干活"

最后一道坎是认知。很多决策者看到Agent能流畅对话，就以为它什么都能干。这个预期一旦建立，后面必然失望。

正确的认知是：对话只是交互形式，业务智能才是目标。一个Agent哪怕对话不那么流畅，但能把保养预约真正跑通，它就是有价值的；反过来，一个Agent对话再流畅，业务动作一个都落不了地，它就是玩具。

6. 给正在做汽车AI Agent的团队的一份自查清单

6.1 架构自查：你的Agent有没有这五个组件

我把真Agent的最小架构总结成五个组件，你可以对照自查：

五个组件里，套壳Agent通常只有第一个，而且做得很浅。如果你的Agent缺了后四个，那它离业务智能还有很远。

6.2 场景自查：这三个问题答不上来就别上线

上线前，问自己三个问题：

1. 用户说"帮我做X"，X真的被执行了吗？拿工单号、拿执行日志来证明，别拿"Agent说已执行"来证明。
2. 执行到一半失败了，会发生什么？有没有重试？有没有回滚？用户会看到什么？
3. 用户中途改主意了，Agent能跟上吗？比如先说预约，后说取消，再问能不能改时间，Agent的状态能正确流转吗？

这三个问题答不上来，说明你的Agent还没准备好面对真实业务。

6.3 指标自查：用数据说话，别用感觉说话

最后，建立一套指标。我建议至少跟踪这几个：

• 任务完成率：用户发起的需求，最终被真正完成的比例。
• 平均交互轮次：完成一个任务平均要几轮对话。
• 工具调用成功率：Agent发起的业务接口调用，成功返回的比例。
• 人工介入率：需要转人工的比例。
• 用户放弃率：用户中途不聊了的比例。

这些指标每周看一次，比任何演示都有说服力。

7. 我对汽车AI Agent这件事的真实看法

跑了这么多项目，我最大的感受是：汽车AI Agent这件事，方向没错，但节奏错了。太多团队被"大模型很火"这个氛围推着走，急着出Demo、急着开发布会，结果做出来的东西经不起业务检验。

我个人的经验是，与其做一个"什么都能聊"的套壳Agent，不如做一个"只能干三件事但件件干成"的真Agent。前者是面子，后者是里子。车企这种重业务、重安全的场景，里子比面子重要得多。

还有一个体会：Agent的智能，不在模型里，在架构里。模型只是决策的一个环节，真正让Agent"智能"起来的，是状态管理、工具编排、执行补偿这些看起来不酷但极其重要的工程能力。谁把这些做扎实了，谁就能从这波"套壳翻车"里跑出来。

最后分享一个小技巧：如果你不确定自己的Agent是不是套壳，就把它放到真实用户手里跑一周，然后看客服投诉。投诉里出现"它一直重复""它说做了但没做""它听不懂我改主意"这三类，基本就确诊了。诊断清楚了，才知道往哪修。