智能客服的架构选型，不是挑一个更高级的Agent框架，而是让不同复杂度的请求进入不同的处理路径。本文从回答、解决、代办三层能力出发，拆解大小模型融合、Router-Agent与DAG的适用场景，并补齐生产级系统所需的八层能力，帮你避开从技术选型入手的常见误区。

用户对智能客服说了一句：帮我处理一下。

这句话可能只是问退换货规则，也可能是在催一个卡了三天的退款。前者需要准确回答，后者要查订单、判断资格、调用接口，还要处理退款失败后的状态。

很多团队会从这里直接跳到技术选型：单 Agent 还是多 Agent，要不要上 Router，要不要画一张很大的 DAG。

但这些都不是第一个问题。

第一个问题应该是，你希望智能客服做到回答、解决，还是代办。

回答只需要把信息说对。解决要理解上下文，把一个问题带到明确结论。代办则要进入真实业务系统，替用户执行动作。三者看起来只差一步，背后的数据、权限、成本和事故半径完全不同。

智能客服的架构选型，本质上不是挑一个更高级的 Agent 框架，而是让不同复杂度的请求进入不同的处理路径。简单问题别浪费强模型，专业问题别塞给一个万能 Prompt，高风险动作也别交给没有权限边界的 Agent。

能回答、能解决、能代办，是三套不同的生产要求

先把智能客服的能力拆成三层。

能回答：核心不是大模型，而是知识供给

用户问营业时间、会员权益、退款政策、某个功能怎么操作，这些问题的共同点是答案已经存在。

系统要做的不是推理出一个答案，而是找到正确版本的答案，再用用户听得懂的方式表达出来。最合适的底座通常是传统 NLP、规则、小模型与 RAG 的组合。

这里最容易出现的误区，是把模型回答得像人当成产品效果。实际上，能回答层真正该盯的是知识命中率、答案准确率、版本有效性和转人工率。语气自然只能算基础体验。

知识库也不是上传一堆文件就结束。文档需要切分，问题与答案需要建立关联，失效内容要下线，活动规则要带时间范围，不同用户权限看到的内容也不同。模型只能基于取回的材料组织语言，脏知识进来，流畅地答错反而更危险。

这一层不需要多个 Agent。高频固定问题走规则或小模型，长尾表达走大模型加 RAG，识别到投诉、情绪升级和知识缺失再转人工，成本和稳定性通常更好。

能解决：核心是把复杂问题分到正确专业域

当用户的问题不再对应一条标准答案，系统就进入能解决层。

比如用户说订单一直没收到。客服需要确认是哪笔订单、是否拆单、物流停在哪个节点、承诺时效是否已过、商家和平台分别承担什么责任。答案不是知识库里的一段文字，而是一段带上下文的信息收集与判断过程。

这时单 Agent 很容易变成万能客服。Prompt 里不断追加物流、售后、会员、发票、活动和投诉规则，工具列表越来越长，改一个场景的提示词又影响另一个场景。

Router-Agent 的价值在这里出现。Router 只负责识别当前问题属于哪个专业域，再把上下文交给对应的垂直 Agent。每个垂直 Agent 有自己的知识、工具、对话流程和评测集。

阿里云百炼的智能导购示例就是一个直观实现：规划助理将用户需求分给手机、电视或冰箱导购，垂直导购再逐项收集使用场景、尺寸、预算等参数。Router 不负责推荐商品，导购 Agent 也不需要理解所有品类。

不过 Router-Agent 不是把一个大 Prompt 拆成几个小 Prompt 就算完成。真正的拆分边界应该同时满足三件事：意图可以区分，知识相对独立，工具权限不同。只满足其中一项，拆分后的系统仍然会互相污染。

能代办：核心是受控执行，不是更会聊天

用户不满足于得到建议，还希望客服直接操作，系统才进入能代办层。

退款、改签、挂失、取消订单、修改配置，这些动作会改变真实业务状态。Agent 不仅要选择工具，还要补齐参数、确认身份、判断权限、处理超时，并在部分成功时知道下一步该做什么。

到这一层，确定性流程的重要性反而上升。

Amazon MARCO 把请求区分为信息查询、操作执行与超纲请求。信息查询交给 RAG，操作执行进入多 Agent 编排。大量确定性的 API 步骤被封装成普通工具，LLM 只在理解自然语言、补充缺失信息和选择下一步时介入。

这个设计很关键。大模型擅长处理模糊输入，不擅长替代已经明确的业务规则。退款资格、账户权限、金额上限和状态流转能写成代码，就不要让模型临场发挥。

三层能力不是产品版本的替换关系。一套成熟客服系统里，大部分请求停在能回答，一部分进入能解决，只有少数高价值、流程稳定的任务适合代办。

三种架构不是三选一，而是局部生长

理解能力层级后，再看大小模型融合、Router-Agent 和 DAG，会发现它们不是互斥方案。

大小模型融合负责守住成本底线

客服流量有明显的长尾分布。大量问题高度重复，少量问题复杂且表达多样。如果所有请求都进入最强模型，成本和延迟会被最简单的 FAQ 拖高。

大小模型融合的做法，是在入口先判断请求复杂度。固定 FAQ、状态查询和明确指令走规则、小模型或专用分类器；需要理解上下文的请求才进入大模型；不支持、高情绪或高风险请求直接人工接管。

这里的产品难点不是选择哪一个小模型，而是分流标准。

分流器需要知道哪些问题必须查实时数据，哪些问题可以直接用知识回答，哪些问题虽然文字简单却风险很高。用户说我要投诉只有四个字，但它不应该因为句子短就进入低成本通路。

Router-Agent 负责隔离专业上下文

当业务域越来越多，单个 Agent 出现四个信号，就该考虑拆分：Prompt 持续膨胀；工具数量增长后误调用变多；不同场景之间调优互相影响；同一问题经常因为上下文不同需要完全不同的处理流程。

Router 的输出应该尽量受约束。它可以输出预定义的业务域、置信度和风险标签，不要一边分类一边给用户写长答案。分错一次，后面的专业 Agent 再强也只能沿着错误路径继续。

因此 Router 必须有兜底。低置信度时允许澄清，用户可以手动切换问题类型，垂直 Agent 也能把明显错分的请求退回重新路由。一次分类定终身，演示时很顺，生产里很脆。

DAG 只该长在真正需要协作的地方

一个请求需要多步骤、多能力协作，并且步骤之间存在数据依赖时，DAG 才有价值。

比如处理配送异常，可能先查订单，再查物流，判断责任后生成补偿方案，最后创建工单并通知用户。每一步都依赖上一步结果，其中某一步失败还要进入不同分支。

DAG 的好处是流程显式、节点可观测、失败位置可定位。代价也很直接：链路更长，状态更多，调试更难，任何一个子 Agent 的错误都会传到后面。

所以不应该把整个客服系统一次性改造成复杂 DAG。更合理的方式是保留入口分流和垂直 Agent，只在少数代办任务内部生长出 DAG 子流程。

大小模型融合是底座，Router-Agent 是主干，DAG 是局部枝干。业务越成熟，三者越可能同时存在。

生产级智能客服，需要补齐 Agent 之外的八层能力

一张只画模型、知识库和工具的架构图，距离生产系统还很远。

真正的智能客服至少包含八层。

渠道与身份层

App、网页、电话、邮件和社交渠道的输入形式不同，能拿到的身份信息也不同。系统必须先确定当前用户是谁、来自哪里、正在处理哪个业务对象。

用户在订单详情页发起咨询，订单 ID 可以成为可信上下文。用户在公开网页里输入一个订单号，同一个字段却不能自动证明所有权。上下文不是越多越好，而是要区分用户提供、系统读取和人工确认三种来源。

会话状态层

客服任务经常跨多轮甚至跨天。用户补充了一张凭证，人工客服接过一次，Agent 隔天再次进入，系统都要知道当前任务进行到哪一步。

聊天记录不等于任务状态。生产系统需要显式记录已确认的身份、已选择的业务对象、缺失参数、已经执行的动作和待审批节点。否则上下文一长，模型很容易把旧信息当成当前状态。

分流与编排层

这一层决定请求走知识问答、垂直 Agent、确定性工作流还是人工。它还要识别风险，而不只是识别意图。

同样是退款，普通商品的小额退款和虚拟商品的大额退款不能共用一条自动路径。意图标签告诉系统用户要做什么，风险标签决定系统最多能做到哪一步。

知识层

知识层负责静态或低频变化的事实，包括规则、流程、产品说明和话术。每条知识需要版本、有效期、适用人群和权限范围。

RAG 返回的不只是几段文本，还应该返回来源和版本。最终答案一旦引发投诉，团队能追溯 Agent 当时依据的是哪一条规则。

工具与业务系统层

订单、物流、支付、账户、工单和通知系统通过工具暴露给 Agent。每个工具应该只完成一个清晰动作，参数使用明确 schema，返回结构化状态。

不要给 Agent 一个万能内部接口，再期待 Prompt 约束它只用安全部分。工具本身就要贯彻最小权限。

策略与权限层

业务规则、金额阈值、身份认证、审批和数据权限属于这一层。它独立于模型运行，模型不能通过一句自然语言绕过。

Agent 可以提出执行建议，策略引擎决定允许、拒绝还是请求人工确认。这样即使模型判断错误，系统仍有第二道确定性防线。

人工接管层

转人工不是失败出口，而是架构的一部分。

好的接管不只是把聊天记录甩给客服。系统应该同时交付用户意图、已确认事实、查过的数据、尝试过的动作、失败原因和建议下一步。用户不需要从头再讲一遍，人工也不用重新翻十几轮对话。

观测与评测层

每次路由、知识召回、工具调用、策略拦截和人工接管都要留下结构化日志。团队需要按场景查看问题，而不是只看一个总自动化率。

这八层里，Agent 只是编排与理解的一部分。真正决定系统能不能上线的，往往是它周围那些不够性感的基础设施。

代办最危险的地方，是一次工具调用看起来成功了

回答错误通常停留在对话里，工具调用错误会进入业务系统。

一条代办链路至少可能在六个位置出错。

意图误判。 用户只是问退款规则，Agent 却进入了退款执行。

函数幻觉。 Agent 生成了不存在的工具名，或者选择了名字相近但含义不同的接口。

参数幻觉。 用户没提供金额、订单或地址，Agent 根据上下文猜了一个值。

权限越界。 当前用户能查询订单，却没有权利修改它；当前 Agent 能创建工单，却不该直接退款。

重复执行。 接口超时后 Agent 重试，第一笔其实已经成功，于是用户收到两次退款或两张优惠券。

部分成功。 退款成功但通知失败，订单取消成功但库存没有释放。Agent 收到一个错误，无法判断系统到底处于什么状态。

这些问题不能只靠一句请谨慎使用工具解决。

第一道护栏是工具白名单和 schema 校验。Agent 只能看到当前任务允许使用的工具，函数名和参数类型不符合定义时直接拒绝执行。

第二道是参数接地。订单号、金额、账户、日期等关键参数必须来自用户明确输入或可信系统查询。无法确认就继续询问，不能补全一个看起来合理的值。

第三道是策略校验。工具执行前检查身份、金额、次数、对象状态和风险等级。不可逆或高风险动作需要再次确认或人工审批。

第四道是幂等与状态查询。每一次写操作都带唯一请求标识。超时后先查询结果，再决定是否重试。

第五道是补偿与人工接管。跨系统流程不能只定义成功路径，还要明确每一步失败后回滚、补偿或挂起。无法自动恢复时，把当前状态和已执行动作交给人。

MARCO 的护栏覆盖输出格式、函数是否存在、参数是否来自对话，以及参数是否满足领域规则。这个思路值得直接借鉴：护栏检查的是每次工具调用，而不只是用户输入和最终回复。

评测不能只问回答对不对

很多智能客服项目上线前准备了一批问答集，计算答案准确率。到了代办层，这套评测明显不够。

一段最终回复看起来正确，背后可能调用错了工具；工具选对了，也可能参数来自模型猜测；动作成功了，也可能重复执行两次。

评测应该沿着真实链路分层。

1. 入口层看意图分类、复杂度分流和风险召回。尤其要关注高风险请求被错分到普通通路的比例。
2. 知识层看召回命中、引用版本、事实一致性和无答案拒答。没有可靠材料时，系统能否承认不知道，比强行生成更重要。
3. Agent 层看工具选择、参数准确、对话轮数和任务规划。评测样本要包含信息缺失、用户改口、多个订单、模糊时间和恶意诱导。
4. 执行层看端到端成功、重复执行、回滚成功、部分成功识别和人工接管完整度。
5. 业务层才看自助解决率、平均处理时长、满意度和单次解决成本。

总转人工率不能越低越好。高风险场景正确转人工，是系统在工作。更合理的指标是该自动解决的是否解决，该转人的是否及时转人。

评测集也不能一次建立后长期不变。每次知识更新、Prompt 调整、模型切换、工具新增和规则变化，都要跑回归测试。线上失败案例经过脱敏和标注，再补回评测集。

产品经理怎么做选型：从工单地图开始

如果团队准备做智能客服，不要先开会决定用几个 Agent。

第一步是从历史工单中抽取任务，而不是只统计问题主题。

同样属于退款主题，咨询政策、查询进度、判断资格和真正发起退款是四个任务。它们的数据来源、所需权限和失败代价都不同。

给每个任务补齐八个字段：发生频率、用户目标、输入信息、数据来源、执行动作、流程确定性、错误代价、人工负责人。

第二步是划分能力层级。

只读知识就能完成的进入能回答；需要多轮收集和专业判断的进入能解决；需要修改业务状态的才进入能代办。先把绝大多数任务放到前两层，别为了展示 Agent 能力强行代办。

第三步是选择最小可用架构。

高频 FAQ 用规则、小模型和 RAG。专业域少、工具有限时先用单 Agent。出现上下文污染和工具误选后，再按业务域拆 Router-Agent。只有某个任务出现稳定的多步骤依赖，才在它内部增加 DAG。

第四步是定义自动化边界。

列出哪些动作可自动执行，哪些需要二次确认，哪些必须审批，哪些永远只能由人决定。边界要写进策略和权限系统，不要只留在需求文档里。

第五步是小流量灰度。

先选高频、流程稳定、可逆、后果可控的任务。观察真实失败，再扩工具、扩用户和扩自动化额度。每次扩张只改变一个变量，否则出了问题很难归因。

一个很好用的判断是：如果团队还说不清动作失败后系统处于什么状态，就还没准备好让 Agent 代办。

四类场景，只是同一套框架的四次压力测试

框架确定以后，行业案例才有意义。

电商：从低额、可逆动作开始

电商高频任务集中，订单、物流、库存和售后状态也相对结构化，最适合从代办开始试。

静态退换规则走 RAG，订单和物流状态走 API，退款资格走规则引擎。查询物流、创建售后单、修改未出库订单备注可以较早自动化。退款、补发和优惠券设置金额、品类与次数上限，超过阈值转人工。

它的关键护栏是幂等、防欺诈与活动规则版本。促销高峰期规则快速变化，Agent 不能拿昨天的政策处理今天的订单。

医疗：能回答和能解决，不等于能诊断

挂号、科室介绍、报告入口和复诊材料提醒适合知识问答与查询。用户开始描述症状后，系统要优先识别高风险信号，按规则进入急诊提示或人工接管。

Agent 可以收集症状持续时间、既往史和当前用药，减少医护人员重复询问，但不应该把信息继续推理成确定诊断，更不能自动生成处方。国家卫健委的互联网诊疗监管要求明确，处方应由接诊医师本人开具，严禁使用人工智能等自动生成处方。

医疗场景的核心不是 Agent 数量，而是专业责任始终留在人和医疗机构。

金融：每一次执行都要先证明有权做

查账单、查进度和产品说明可以自动完成。挂失、修改账户信息和交易异议需要强身份认证、最小权限与完整审计。

模型负责理解用户意图，认证服务确认用户身份，策略引擎决定能否执行。查询账单的工具不能顺手转账，解释产品的 Agent 也不该访问完整交易明细。

涉及投资建议、授信、可疑交易和大额资金变化时，Agent 负责收集证据与流转工单，专业人员负责决定。

打车：普通履约与安全事件必须分链

查发票、司机位置、取消费、遗失物品和人身安全事件都可能进入同一个客服入口，但不能共用同一条处理链。

履约链可以查询实时行程、处理有限额退费，并在校验车辆和订单状态后结束异常行程。安全链一旦识别到威胁、骚扰、事故或失联，应立刻进入紧急流程，联系专业团队并保存位置与行程证据。

Uber 公开的 COTA 会把工单文本、行程信息和用户选择组合起来辅助分类。今天的 Agent 也一样，不能只看用户的一句话，必须读取带时间戳的行程阶段与可信状态。

电商、医疗、金融、打车的差别，不在于要不要用 Agent，而在于 Agent 能走到哪一步。

同一个能代办的目标，在电商里可能是自动退一笔小额订单，在医疗里只能是替用户完成预约，在金融里要经过强身份和审批，在打车安全事件里则应该立即把责任交给专业团队。

好的智能客服，不是尽量不找人，而是简单问题不浪费人，复杂问题不糊弄人，高风险动作不擅自替人做决定。

主要参考资料

OpenAI Agents SDK：Agent 编排

OpenAI Agents SDK：Guardrails

智能客服 Agent 架构选型：从能回答到能解决到能代办

Amazon MARCO 论文

阿里云百炼：Multi-Agent 智能导购示例

AWS：企业 Agent 架构治理指南

国家卫健委：互联网诊疗管理办法（试行）

中国人民银行：个人金融信息保护技术规范

Uber：COTA 客服工单辅助架构