从 RAG 到多 Agent 协同：一个车企智能客服改造的观察与思考

前段时间和一位朋友深聊了一次。他在一家传统车企，过去一年参与并推动了客服系统的大模型改造：从最简单的知识问答起步，一路演进成由调度器统一编排、多个专业 Agent 协同的系统——用户不只是「问问题」，还能直接查数据、预约试驾、买商品，甚至在对话里控制车辆。

我自己一直在关注 AI 落地，这次交流信息量很大。征得他同意后，我把观察到的方案和我的思考整理成这篇笔记。不构成任何商业建议，细节也做了脱敏处理。

背景：一个「会背 FAQ」的客服机器人

改造前的状态很典型：客服系统基于关键词匹配和 FAQ 库，用户换个问法就答非所问，转人工率居高不下，客服团队疲于应付重复问题，体验和口碑都很难看。

管理层最初的预期是「上大模型，一步到位」。而他们团队做的第一件、也是我觉得最正确的一件事，就是把这个预期打下来：AI 项目最大的风险不是技术不行，而是想等一个完美的最终方案再动手。

他们定了一条朴素的原则：先跑起来，用业务结果说话。 V1 只做一件事——知识问答，把转人工率降下来。

架构：一个调度器 + 一群专业 Agent

随着场景变多，他们没有把系统做成一个「什么都会一点」的巨大 Prompt，而是拆成了多 Agent 协同架构：

• 核心调度器（Orchestrator）：负责意图识别和路由，决定把请求交给哪个专业 Agent，并编排跨 Agent 的任务流。
• 专业 Agent 集群：知识问答、用户问数、预约试驾、商品推荐、联网搜索、控车，各司其职。

fig. 一个调度器 + 六个专业 Agent 的协同架构

我认可这个拆法的原因在于边界清晰：每个 Agent 有自己的知识范围、工具集和安全策略，可以独立迭代、独立评估，出问题也能快速定位。下面按落地顺序聊聊每个 Agent 的做法。

知识问答：RAG 是地基，但地基是脏活累活

知识问答是整个系统的地基，技术上就是经典的 RAG：用户提问 → 检索知识库 → 大模型基于检索结果生成回答。

但真正耗时间的从来不是调模型，而是知识治理。车企各业务部门扔过来的资料千奇百怪：扫描版 PDF 要先做 OCR 且格式经常错乱；售后 SOP 是 Word 文档，得手动把步骤和规范摘出来；金融和保险政策三天两头变，还得专门做时效管理。

fig. 知识治理：把混乱的内部文档变成 AI 能消化的有序知识

防幻觉上他们定了铁律：回答必须基于检索到的真实片段，检索不到就明说不知道或转人工，绝不允许模型自由发挥。 宁可少说，不能说错。

用户问数 Agent：查不到就说「系统繁忙」，而不是编一个

「我这辆车还剩几次免费保养？」「我的积分什么时候过期？」这类问题需要查业务数据库，他们做了 Text2SQL 的问数 Agent。

这类 Agent 的核心不是准确率，是安全边界：

• 权限校验在前：用户只能查自己的数据，先过身份和权限这关，再谈生成 SQL。
• 结果校验在后：生成的 SQL 只读、带白名单，返回结果还要再过一道检查。
• 失败时诚实：超时或查询异常，一律返回「系统繁忙，请稍后再试」——绝不能让模型在拿不到数据时编一个看起来合理的答案。

最后这条我很触动。在涉及钱和权益的场景，编造比失败可怕得多——失败损失的是一次体验，编造损失的是信任。

预约试驾 Agent：多轮对话 + 业务流程编排

试驾预约是典型的多轮对话 + 流程编排场景。用户说「我想试试你们那款新的 SUV，这周六下午市中心附近有空吗」，Agent 需要：

1. 解析出车型、时间、地点等实体，缺信息就追问补齐；
2. 调用内部 DMS 系统 API，实时查询附近门店的试驾车排期；
3. 给出 2～3 个可选方案，用户确认后生成预约卡片；
4. 在 CRM 里创建线索、发短信提醒，并把线索回传到营销系统。

这里的防编造原则同样严格：门店、库存、排期全部来自 API 实时查询，模型只负责理解意图和组装流程，不掌握任何「它以为」的事实。

这个场景上线后效果最直接——预约流程从「留电话等回访」变成一句话完成，线索转化效率明显提升。

控车 Agent：权限分级、二次确认、留痕熔断

控车是所有 Agent 里安全等级最高的，涉及车辆安全，设计原则是极其严格的权限控制：

• 身份与授权：必须通过 VIN 码绑定关系验证车主身份；开车门这类敏感操作需要用户再次确认；部分操作还要求用户处在车辆附近（GPS 电子围栏）。
• 意图与参数提取：识别控车类型（温度、车门、车窗、座椅加热等）和参数（目标温度、开/关、前/后），指令不全就追问——「打开空调」必须问清目标温度。
• 对接 TSP 平台 API：自然语言转成标准调用，比如「温度调到 24 度」→ { "action": "set_temperature", "value": 24, "vin": "xxx" }，然后根据 API 响应如实反馈执行结果。
• 安全机制：API 失败必须如实告知，不允许虚假执行（绝不能说「已完成」）；所有操作记录日志可追溯；连续失败或异常请求时熔断，暂停控车功能并转人工。

fig. 控车操作的多重防线：身份验证、二次确认、电子围栏、留痕熔断

上线后，高频的 App 控车操作（出发前调温度、开后备箱）很自然地融入了对话场景。

商品推荐 Agent：从「答问题」到「懂场景」

推荐 Agent 做的是场景理解：用户抱怨「夏天车里太晒」，系统不是去搜「晒」这个关键词，而是把场景映射到商品类目标签——["遮阳用品", "隔热服务", "车内降温"]，再从商城 API 拉取真实商品卡片。

推荐分两种：被动推荐（回答完问题后顺带推荐相关商品）和主动推荐（在特定业务场景触发，比如保养到期提醒时推荐套餐）。所有推荐都接效果追踪：点击率、转化率、A/B 测试，用数据决定推荐策略的去留。

联网搜索 Agent：有边界地使用外部信息

知识库覆盖不了的问题（比如行业新闻、竞品对比），他们加了联网搜索 Agent，用置信度阈值触发：知识库置信度不够时才走搜索，搜索结果做可信度评估和内容审核，回答时逐条标注来源链接，并明确告知「以下信息来自互联网」，提醒用户以官方口径为准。

闭环之后：系统长出了「办事」能力

这些 Agent 协同起来，系统就从「客服」变成了「办事入口」：

fig. 四个已经跑通的闭环场景

他们踩过的坑，给我的两个启发

聊起复盘，朋友说了一句我很认同的话：这个项目最宝贵的不是做对了什么，而是做错了什么。

启发一：不要等「最终方案」，先跑起来。 项目刚开始时他们特别焦虑，总想看清全局、找到一个一步到位的方案再开始——「要不要再等等，下个季度可能有更好的模型？」结果项目差点在无休止的调研和规划里被拖死。后来的做法是不再纠结终局，V1 目标非常纯粹：就做知识问答，把转人工率降下来。正是 V1 的数据给了团队向管理层要资源的底气，去做预约试驾这种更复杂的任务。后续每个版本，都是用上一个版本的成绩，换下一个版本的门票。

启发二：别以为 AI 是神仙，主要工作其实是「喂数据」。 项目里最耗时间、最痛苦的工作根本不是调模型，而是处理各业务部门扔过来的、乱七八糟的内部文档。AI 不是神仙，你喂给它垃圾，它只能吐出更精致的垃圾。但这个过程有个意想不到的好处：为了让 AI「吃懂」资料，他们反过来逼着业务部门把知识库整理得井井有条——一个 AI 项目，意外成了推动整个公司知识管理进步的催化剂。

我的一点思考

从结果看，改造后转人工率下降超过一半，CSAT 和 NPS 都有明显提升，试驾线索的转化链路从「天级」压缩到了「分钟级」。

但围观完整过程后，我最大的感受是：这类项目里，技术选型只占三成，剩下七成是知识治理、流程重塑和安全边界。 模型会一年一换，但这七成功夫，才是系统真正能跑起来的原因。

这也回应了很多人的疑问：为什么同样的大模型，有的团队能做出东西，有的只能做出 Demo？差距不在模型，在于愿不愿意俯下身子，去啃知识治理、流程打通这些「不性感」的硬骨头。