很多大模型客服项目做到一定阶段，都会遇到类似讨论：

“知识回答不准，要不要微调？”

“已经做了RAG，还有必要上Agent吗？”

“Agent是不是比RAG更高级？”

如果从技术名词出发，很容易把RAG、Fine-tuning和Agent理解成三条相互竞争的路线。但放进真实客服系统，这种比较并不准确。

比如，客服回答产品政策时总引用旧版本资料，首先应该检查知识来源和检索链，而不是重新训练模型；如果模型已经拿到了正确上下文，却长期无法稳定完成某种分类或固定格式任务，问题才可能进入模型行为层；如果客户说“帮我把明天下午的预约改到周五上午”，即使知识检索完全正确，系统仍然需要查询预约数据、判断可选时段、调用接口并返回结果。

这三个问题分别发生在知识层、模型层和任务执行层。

因此，大模型客服真正需要解决的不是“RAG、微调、Agent三选一”，而是先判断系统当前失败在哪里，再决定应该调整哪一层。

一、先把三种技术放回客服架构：知识、模型和执行是三个不同问题

可以先看一个简化的大模型客服架构：

用户问题
   ↓
Agent / Workflow
   ↓
意图判断、任务状态
   ↓
        LLM
       ↙   ↘
   RAG     Tools / API
    ↓          ↓
企业知识库   CRM / 订单 / 预约 /
            工单 / 会员系统

微调与这条在线运行链路的位置不同。它直接作用于模型本身，通过训练数据调整模型参数，使模型在特定任务上的输出行为发生变化。

因此，三种技术可以先做一个最基本的区分：

RAG解决“回答时应该参考什么”，微调解决“模型应该怎样表现”，Agent解决“理解以后下一步应该做什么”。

它们既不是三个版本的聊天机器人，也不是从低到高的升级关系。

一个客服Agent完全可以调用RAG知识库回答产品政策，再调用订单API查询实时数据；如果某个长期稳定的分类任务仍然表现不稳定，也可以在经过评测后进一步考虑模型微调。

生产环境里更常见的情况，本来就是组合，而不是三选一。

---

二、回答总是过期、缺少企业私有知识：先检查RAG

客服系统中的大量知识有两个明显特点：一是属于企业私有数据，二是会持续变化。

产品说明、促销政策、售后规则、服务流程、门店信息和活动安排都可能更新。如果要求模型依靠训练参数长期记住这些内容，一旦规则变化，维护和验证都会变得困难。

RAG的核心思路不是让模型把所有企业资料“背下来”，而是在客户提问时检索当前问题所需的知识，再将结果放入模型上下文。

一个基础链路通常是：

企业文档
   ↓
解析与切片
   ↓
索引
   ↓
用户问题
   ↓
召回相关知识
   ↓
加入模型上下文
   ↓
生成回答

真正影响客服RAG效果的，也不是“有没有向量数据库”，而是检索出来的内容是否足以支撑当前回答。

1. 知识源错误，RAG不会自动帮企业纠正

假设知识库里同时存在今年和去年的售后政策，如果两个版本都处于有效检索范围内，系统就可能把旧规则召回。

这时即使模型本身能力很强，也可能基于错误上下文生成错误答案。

因此，客服知识库不能只是“把PDF上传进去”，还要管理知识来源、有效状态、更新时间、权限和版本边界。

回答出现事实错误时，首先要分清：

• 知识本身是否正确；

• 当前版本是否有效；

• 检索是否召回了正确内容；

• 模型是否真正使用了召回结果。

否则很容易把知识问题误诊成模型问题。

2. Chunk不是越小越精准

切片过小，会把一条完整规则拆散；切片过大，则可能把大量无关信息一起带入上下文。

例如一段退换货政策可能同时包含：

适用商品 → 时间限制 → 特殊商品例外 → 所需材料。

如果系统只召回了“七天内可申请”这一句话，却没有召回后面的例外条件，模型仍然可能给出不完整答案。

所以客服RAG不能只测试“是否命中文档”，还要测试：

召回结果是否包含完成回答所需的完整条件。

3. 找到规则，不代表知道客户当前发生了什么

这是RAG非常重要的一条能力边界。

客户问：

“我的订单为什么还没到？”

RAG可以告诉模型企业规定的物流异常处理规则，却不知道这个客户的真实订单现在到了哪里。

客户说：

“帮我把预约改到周五上午。”

RAG可以找到预约变更规则，却不会天然修改后台预约记录。

到了这里，系统缺少的已经不是知识，而是业务数据和执行能力。

因此，如果客服当前的问题主要是“企业资料模型不知道”“答案总引用旧规则”“知识没有依据”，优先应该处理知识治理和RAG链路，而不是直接进入微调或Agent改造。

---

三、知识变化频繁时，不要首先想到微调

微调经常被理解成“把公司的资料训练进大模型”。

但对客服系统来说，这通常不是它最适合解决的问题。

RAG和微调最重要的区别，可以概括成：

RAG改变模型回答时拿到的上下文，微调改变模型本身的行为。

假设企业今天把退货期限从15天改成7天。

使用RAG时，企业可以更新知识并重新建立相应索引。

如果这类经常变化的业务规则主要通过训练样本固化进模型参数，那么规则变化之后，不仅要重新训练或调整模型，还要重新验证旧知识是否仍然影响输出。

因此，价格、库存、政策、活动、门店信息等持续变化的客服知识，通常应该优先留在知识和业务数据层管理。

什么情况下才值得考虑微调？

微调更适合的是另一类问题：

模型已经拿到了正确的信息，但在一个稳定、重复的任务上，输出行为长期不够稳定。

例如，企业要求模型把投诉稳定分类到固定的20个业务标签中，经过Prompt、结构化输出和模型选择优化后，仍然频繁出现越界标签。

又比如，一个长期稳定的任务要求模型严格按照固定格式抽取字段、使用特定领域表达，通用模型持续难以达到要求。

这时，问题才可能真正落在模型行为层。

进入微调前，至少应该确认三个条件：

第一，企业是否拥有足够稳定、高质量的训练样本；

第二，是否有独立评测集判断训练后是真的变好，而不是只拟合训练数据；

第三，调整某项能力后，模型原本正常的任务是否发生性能回退。

所以微调不是大模型客服上线的默认步骤。

更合理的使用方式是：

先证明瓶颈确实来自模型行为，再考虑通过训练改变模型。

如果机器人只是“不知道昨天刚更新的售后规则”，继续训练模型通常不是优先答案。

---

四、客户开始说“帮我查、帮我改、帮我办”，问题就进入Agent层

RAG可以让模型更准确地知道企业规则，但客服最终处理的不只是知识问答。

比较下面两个问题：

“修改收货地址有什么规则？”

和：

“帮我把这个订单的收货地址改一下。”

第一句话主要是知识查询。

第二句话已经是一项业务任务。

系统除了理解客户需求，还要完成一系列动作：

识别修改地址任务
   ↓
确认客户身份和订单
   ↓
查询订单当前状态
   ↓
判断是否允许修改
   ↓
缺信息时主动追问
   ↓
获取新的收货地址
   ↓
调用订单接口
   ↓
获得真实执行结果
   ↓
继续处理 / 转人工

这里新增的关键能力已经不是“再查一份知识”，而是任务状态、流程和工具调用。

Agent负责维护“当前到底要完成什么”

一个真实客服任务往往不会按照标准问题一次说完。

客户可能先说：

“我想改地址。”

随后补充订单号，过一会儿又修改新的收货信息。

Agent需要持续维护任务目标、已有信息和当前状态，而不是每一轮都重新理解一遍。

Workflow负责决定“下一步怎么走”

信息不完整时继续追问；订单已经出库时切换到其他流程；满足业务条件时调用接口；系统异常或超出自动处理边界时转人工。

这些都不是单纯生成一段自然语言能够解决的。

Tools真正连接企业业务系统

只有通过API或已经配置好的工具，客服系统才能查询客户、订单、物流、预约和工单，也才能在企业授权范围内执行实际动作。

因此：RAG让系统知道规则，Tools让系统接触真实业务数据和动作，Workflow把判断与动作组织起来，Agent维护整个任务的目标和状态。

超出边界时，人工仍然是业务链的一部分

真正的企业级Agent还必须考虑人工兜底。

比如客户进入投诉升级、接口持续失败、需要业务人员判断，或者操作本身有权限要求时，系统应该把已经确认的意图、上下文和已采集信息一起交给人工。

否则所谓“转人工”只是把客户重新扔回服务起点。

---

五、生产环境通常不是三选一，而是分层组合

把三种技术拆开后，会发现真正的企业客服架构通常更接近：

Agent + RAG + Tools/API + 人工协同

至于微调是否加入，则取决于是否存在明确、稳定而且值得训练的模型行为任务。

以一个售后问题为例：

客户说：

“我昨天刚收到机器，现在启动不了，能直接换货吗？”

系统首先识别售后诉求，通过RAG检索当前产品的换货政策。

如果还缺订单号、产品型号或者故障信息，Agent继续追问；获取订单号后，通过工具查询真实购买时间和订单状态；满足企业已经配置的条件时进入相应售后流程或创建工单，无法自动处理时则把已采集的信息交给人工。

在这条链路中：

• RAG没有被Agent替代，而是Agent的知识来源；

• Tools不是知识库，而是获取真实数据和执行动作的接口；

• Agent也不是“更高级的RAG”，而是负责组织知识、状态、流程和工具。

这种分层架构还有一个很实际的价值：出了问题以后更容易定位。

如果机器人回答了错误政策，去检查知识与检索链。

如果拿到了正确知识仍然输出异常，去检查模型行为和Prompt。

如果规则回答正确，却不能查询、预约、建单或回写，则去检查流程、工具、接口与权限。

这比把所有问题统一归因成“大模型不够聪明”，更适合真实生产环境。

一个现实的智能客服架构例子

合力亿捷是国内主流的企业智能客服厂商，其智能客服体系中，悦问知识库负责文档解析、语义切片、向量检索、RAG、引用依据和权限控制；自研客服智能体平台Synerow则通过Agent、Flow和Tools组织意图判断、主动追问、条件判断、工具调用、工单创建和转人工，并可连接订单、物流、客户信息、预约、工单以及CRM、ERP等企业系统。

这里同样不是让Agent替代RAG，而是把知识与业务执行放在不同层管理。具体查询、建单、预约或系统回写能否完成，仍取决于企业已经接入的接口、配置的流程、工具和权限范围。

---

六、一张表看懂RAG、微调和Agent分别解决什么

这张表最重要的不是告诉企业“选哪一个”，而是帮助企业判断：

当前故障究竟属于知识、模型行为，还是业务执行。

如果连问题发生在哪一层都没有确认，过早讨论“换模型”“做微调”或“上Agent”，很容易把技术投入用错地方。

---

七、PoC不要只测回答准确率，至少拆成三组

很多大模型客服PoC仍然只有几十道FAQ：

用户提问 → 机器人回答 → 人工判断答得对不对。

这种测试最多只能说明某一批知识问答是否可用，无法验证整套客服架构。

更有效的方法，是把PoC拆成Knowledge、Behavior和Action三类。

1. Knowledge Test：验证知识链

可以故意修改一条产品政策，然后测试：

• 新规则能否及时进入知识库；

• 旧规则是否仍会被错误召回；

• 检索结果是否包含完整条件；

• 回答是否真正依据当前知识；

• 不同权限用户是否只能看到对应知识。

这一组主要验证知识治理和RAG。

测试重点不是“模型看起来答对了几道题”，而是：

错误发生时，企业能否定位到底是知识、召回还是生成的问题。

2. Behavior Test：验证模型行为

准备一组稳定任务，例如投诉分类、信息抽取、固定格式输出。

重点观察：

• 相似输入的输出是否稳定；

• 边界样本是否容易越界；

• 是否遵循规定结构；

• Prompt或模型调整后，其他样本是否出现回归。

只有这一层长期成为瓶颈，并且已经排除知识与流程问题，才值得进一步讨论微调。

3. Action Test：验证Agent是否真的能做业务

例如直接测试：

“帮我把明天下午的安装改到周五上午。”

不要只测试一次正常流程。

可以故意让客户在中途改口，再让预约接口返回一次“原时段已满”或接口异常。

观察系统能否：

• 理解客户最新需求；

• 保留已经确认的信息；

• 正确判断还缺什么字段；

• 查询真实业务数据；

• 根据接口结果继续对话；

• 无法执行时正确转人工；

• 转人工后保留前面的上下文和结果。

这一组才真正验证一个Agent有没有进入业务流程，而不是“会不会用大模型聊天”。

---

八、大模型客服真正该先做的，是建立故障分层

很多大模型客服问题最后都会被归结成一句：

“模型还不够聪明。”

但真实生产环境中，错误可能来自完全不同的位置。

知识本身过期，是知识治理问题。

知识正确却没有被召回，是检索问题。

模型拿到了正确上下文仍无法稳定完成固定任务，才可能进入模型行为层。

模型准确回答了规则，却无法查询、预约、修改、建单，则说明缺少的是业务执行链。

因此，企业落地大模型客服时，真正需要建立的不是一套“RAG、微调、Agent谁更先进”的技术排名，而是一套分层判断方法：

知识问题回到RAG和知识治理，稳定行为问题再评估微调，需要完成真实业务任务时进入Agent、Workflow和Tools。

技术路线选得准不准，最终不取决于用了多少AI名词，而取决于企业能不能先回答一个更基础的问题：

当前这个客服问题，到底坏在哪一层？