智能客服架构选型常让企业陷入两难：多Agent协作复杂度失控，单Agent又难保准确率。本文提出三层能力模型，从能回答、能解决到能代办，结合网易云商、阿里、Amazon MARCO等案例，解析不同阶段的架构设计与产品经理的核心关注点，助你找到适合自身业务的发展路径。

Gartner 预测，到 2029 年，Agentic AI 将自主解决 80% 的常见客户服务问题。但在当前的落地实践中，大量企业踩的第一个坑不是模型能力不够，而是架构选错了。要么一上来就搞多 Agent 协作，复杂度失控；要么所有逻辑塞进一个 Agent，准确率随业务增长持续下滑。

架构选型的本质不是技术选择题，而是一个产品问题：你的智能客服现在处于哪个能力层级，下一步要往哪个层级走？

一、核心框架：三个能力层级决定三种架构

智能客服的产品能力演进，本质上是三个层级的递进：

每一层对 Agent 的要求是质变的：

回答只需要知道，知识库够用就行

解决需要理解，要有垂直领域的专业推理能力

代办需要动手，要调 API、跨系统协作、处理执行失败、层层护栏

关键认知：这三层在成熟产品里是共存的，不是替换的。 同一个客服系统里，简单问题回答就够了，中等问题需要解决，少数高价值场景才需要代办。架构不是选一个扔掉另外两个，而是不同层级各管各的。

二、能回答：大小模型融合

设计思想

不是把所有问题都交给大模型，而是按问题复杂度分流：

• 70% 的简单问题（FAQ、物流查询、退换政策）走传统 NLP 机器人，成本极低，响应极快
• 30% 的复杂问题（需要理解上下文的咨询）走大模型 Agent + RAG 知识库
• 极端问题（情绪激动、涉及投诉升级）转人工

核心是成本可控、风险可控、增量部署，在现有客服系统上加一层，而不是推倒重来。

架构图

### 案例：网易云商的大小模型融合实践

网易云商是国内较早跑通大小模型融合架构的服务商，已在多个行业落地。两个典型案例：

I.T 时尚零售集团，旗下品牌众多，售前咨询量大。网易云商为其提供的方案核心就是大小模型融合：70% 的常见问题交给传统 NLP 机器人，30% 的复杂咨询交给客服 Agent。落地过程遵循六步流程：角色设定、提示词编排、工具库设计、工作流编排、知识库上传、多轮调优。

甘肃ETC 公众服务场景也采用了同样的架构，公开数据如下（来源：沙丘智库）：

优势与局限

PM 在这个阶段该关注什么

核心工作重心： 知识库质量和分流准确率。这个阶段 PM 最大的杠杆不是模型能力，而是喂给模型的知识够不够好、分流规则分得准不准。80% 的时间应该花在梳理 FAQ、标注分流规则、review 知识库内容上。

该盯的指标：

• 分流准确率（简单/复杂分对了没有）
• NLP 通路的自助解决率（不转人工就解决的比例）
• Agent 通路的回答准确率（回答内容是否正确）
• 整体转人工率（越低越好，但不能为了压数字牺牲体验）

跟技术团队沟通时该问的问题：

1. 分流决策是规则驱动还是模型驱动？误分率是多少？
2. Agent 的 prompt 现在多长？增长趋势是什么？
3. 知识库更新后，回答准确率有没有回归测试机制？

什么时候该往下一层升级？

当你发现单个 Agent 出现以下信号：

1. prompt 持续膨胀，不断往里塞新规则和知识
2. 不同类型问题的回答准确率出现显著差异
3. 新增业务知识导致原有场景的准确率回退
4. 调优一个场景的 prompt 总是影响另一个场景

说明该拆了。

三、能解决：扁平分发（Router-Agent）

设计思想

一个 Router Agent 做意图分类，把不同类型的问题分发给对应的垂直 Agent，每个 Agent 独立完成全流程。

类比线下商场：前台判断你要买什么，带你到对应的品类区域，由专业导购全程服务。前台分发完就不管了，每个导购从接手到结束自己搞定。

核心特征是一次分类定终身，Router 分完就交接，垂直 Agent 不需要其他 Agent 协助。

架构图

案例：阿里巴巴 Multi-Agent 智能导购

阿里巴巴基于百炼 Assistant API 构建的智能导购助手，是典型的 Router-Agent 分发架构：

RouterAgent（规划助理）：使用轻量模型（qwen-plus），只输出一个分类结果（手机 / 电视 / 冰箱 / 其他），零业务逻辑

垂直导购 Agent：使用强模型（qwen-max），每个 Agent 有预设的参数收集清单，按顺序逐个主动向用户提问，收齐后触发商品检索

两个值得注意的设计：

1.Router的强约束输出

Router 的 prompt 严格限定输出只能是预设类别之一，不允许包含任何其他信息。这种设计保证分发的确定性。大模型最怕话太多导致下游解析失败，强约束是最简单有效的解法。

2. 主动式交互

与传统客服的被动应答不同，阿里的导购 Agent 采用主动提问策略：按预设参数列表（使用场景、屏幕尺寸、存储空间）逐个向用户提问，一次只问一个。用户有疑问先解释，然后继续收集。这种引导式对话显著提升了信息收集效率。

扩展成本极低： 新增一个品类 = 写一个新 Agent 的 prompt + Router 分类列表加一行。

优势与局限

PM 在这个阶段该关注什么

核心工作重心： 分类体系设计和单个 Agent 的对话流程。PM 的主要工作从知识库运营转向业务流程拆解，需要把复杂业务拆成互不交叉的垂直场景，并为每个场景设计清晰的对话引导流程。

该盯的指标：

• Router 分发准确率（分错就全错，这是整个系统的命门）
• 各垂直 Agent 的解决率（横向对比，找出短板 Agent）
• 跨域问题占比（如果跨域请求持续增长，说明分类体系需要调整或该考虑 DAG）
• 单次对话轮数（引导式对话是否高效，用户有没有被反复追问）

跟技术团队沟通时该问的问题：

1. Router 分错后有没有兜底机制？用户能不能手动切换 Agent？
2. 新增一个垂直 Agent 的上线周期是多长？流程卡在哪？
3. 各 Agent 的 prompt 是否有版本管理？改一个会不会影响其他？

从能解决到能代办是怎么发生的？

这个跃迁往往不是你主动规划的，而是业务自然推动的。典型路径：

• 一开始，垂直 Agent 只是引导用户，告诉他问题可能是什么原因，建议去后台改一下某个配置
• 业务方提出需求：用户不想自己改，能不能 Agent 直接帮他改了？
• 一旦要代办，Agent 就需要调用 API 执行操作
• 某些代办场景涉及多个步骤、跨多个系统，比如查原因、改配置、发通知
• 这时候单个 Agent 搞不定了，需要调度其他 Agent 的能力

注意：不是整个系统升级成DAG，而是某些 Agent 内部长出了 DAG 子结构。 扁平分发的框架不拆，Router 还在，大部分垂直 Agent 还是独立运作，只是少数需要代办的场景下面挂了更复杂的执行逻辑。

四、能代办：DAG 层次化

设计思想

DAG（Directed Acyclic Graph，有向无环图）层次化架构的核心是：父 Agent 可以根据执行进展动态调度子 Agent，每个 Agent 自带独立的任务执行步骤和工具集。

用日常语言说就是一个多层级、只能往下派活、不会互相踢皮球的 Agent 组织架构。总监派给组长，组长判断需要哪个专员，专员执行完汇报，组长决定下一步。任务链条可以多步骤、多分支，但只能往下走，不能绕回来。

架构图

案例：Amazon MARCO

MARCO（Multi-Agent Real-time Chat Orchestration）是 Amazon 零售业务团队开发的多 Agent 实时对话编排框架。论文发表于 2024 年。

四大组件：

1. 意图分类器（IC）：LLM 驱动的三分类（OOD / Info / Action）。采用 Few-Shot prompt 策略，准确率 94.53%。同时兼任第一层安全护栏，拦截恶意请求
2. RAG：回答领域相关的信息查询类问题
3. MARS 编排器：核心调度层，管理整个 Agent 层次树。负责推理下一步动作、选择 Agent、调用工具
4. 护栏系统：四类反思检测 + 自动重试，是准确率从 66% 跳到 94% 的关键（详见下文）

两个值得关注的设计决策：

1. 确定性任务封装

Agent 执行任务时，大多数步骤其实是确定性的 API 调用链，不需要 LLM 推理。MARCO 把这些步骤封装成普通工具，LLM 只在需要理解自然语言、做判断时才介入。好处是同时降低延迟和出错率。

2. 意图分类用 Few-Shot 解决歧义

意图分类器做三分类（超纲 / 信息查询 / 操作执行），采用 Few-Shot prompt 策略，准确率 94.53%。关键是用对比示例解决近似表述的歧义，比如 What is the menu price of a food item 是问概念，What is the menu price of my food item 是要查数据，只差一个词，意图完全不同。

实测数据

值得注意的是：多 Agent 不仅准确率更高，延迟和成本反而更低。原因是每个 Agent 的 prompt 更短更聚焦，比把所有逻辑塞进一个超长 prompt 要高效。

优势与局限

PM 在这个阶段该关注什么

核心工作重心： Agent 层次设计和护栏规则定义。PM 需要和技术团队一起定义哪些任务需要拆成子 Agent、每个 Agent 的能力边界在哪、哪些操作必须加护栏。这个阶段 PM 的角色更接近业务架构师。

该盯的指标：

• 任务执行准确率（不只是回答对不对，而是操作有没有做对）
• 护栏拦截率和误拦率（拦太少会出事故，拦太多用户体验差）
• 端到端任务完成时长（多 Agent 调度链条长了，延迟是不是还可接受）
• 人工兜底率（代办失败后转人工的比例，这是系统可靠性的直接体现）

跟技术团队沟通时该问的问题：

1. 哪些操作是可逆的、哪些不可逆？不可逆操作加了什么确认机制？
2. Agent 代办出错后有没有回滚能力？
3. 护栏规则怎么更新？业务规则变了，护栏能不能跟着变，还是要改代码？

护栏系统：准确率从 66% 到 94% 的关键

护栏不是可选组件，是智能客服能否上生产的决定性因素。MARCO 的实验数据显示，加上护栏后准确率提升了 28 到 32 个百分点。

护栏系统包含四类检测，每类检测失败后会生成一条反思提示加入对话历史，让 Agent 自我纠正：

1. 输出格式校验：LLM 生成的输出格式不对，下游解析失败，护栏要求重新生成
2. 函数幻觉检测：LLM 编造了不存在的函数名，护栏检查可用工具列表后要求重新选择
3. 参数值接地检测：最关键的一类。LLM 调用函数时会编造参数值而不是向用户询问，护栏检查每个非布尔型参数值是否出现在用户对话历史中，没出现过就判定为幻觉，要求 Agent 向用户确认
4. 领域知识规则：为每个参数定义静态校验规则（如 merchant_id 必须是 6-8 位字母数字串），不满足则提供规则信息让 Agent 纠正

反思重试的效果： 带反思提示的重试，第一次就能解决几乎所有错误；不带反思的直接重试，即使重试四次也无法消除错误。最大重试次数设为 2，在准确率和延迟之间取得平衡。

五、横向对比

三种架构对比

选型决策树

面对一个具体的智能客服项目，按以下问题逐步判断：

Q1：你需要多快上线？团队是否有多 Agent 系统的搭建经验？

要快速验证 / 团队经验有限：大小模型融合起步，不管有没有现成系统，先用最简架构跑通

时间充裕、团队有能力：继续 Q2

Q2：你的复杂问题能否按类型清晰分类，且各类型之间相互独立？

可以，类型之间几乎没有交叉：扁平分发

分类边界模糊，经常跨类：继续 Q3

Q3：用户请求是否经常需要多步骤、多能力协作才能完成？

是，且步骤之间有数据依赖：DAG层次化

偶尔有，不是主流：先扁平分发，观察后再决定

无论最终选哪种架构，大小模型融合作为底座都应该保留。它不是一个会被淘汰的初级方案，而是控制成本的基础设施。扁平分发和 DAG 只管复杂问题那 30%，简单问题永远走 NLP 通路。

六、实操建议：共存式架构，局部生长

成熟系统的最终形态

三种架构不是三选一，而是在一个成熟系统里共存：

大小模型融合是底座（永远存在，控制成本），扁平分发是主干（处理已知类型的复杂问题），DAG 是局部枝干（在特定 Agent 内部按需生长）。

演进路径

不是阶段一做完换阶段二，而是：

1. 先把底座打好：NLP 处理简单问题，单 Agent + RAG 处理复杂问题，极端转人工
2. 按信号拆 Agent：当单 Agent 出现 prompt 过长、准确率下降、场景互相干扰时，拆成垂直 Agent
3. 按需求长DAG：当某个垂直 Agent 从引导用户演进到代替用户操作，且操作涉及多步骤跨系统时，在这个 Agent 内部引入 DAG 子结构

贯穿始终的基础设施

无论处于哪个层级，以下组件应从 Day 1 开始建设：

RAG 知识库：Agent 回答问题的知识来源。层级一用全局库，层级二拆垂直库

护栏系统：至少包含输出格式校验、敏感信息拦截、转人工判断

评估体系：准确率、解决率、满意度、转人工率，作为升级决策的数据依据

对话日志：完整记录用户交互，为 prompt 调优和架构升级提供数据支撑

参考来源：

• Amazon MARCO 论文：https://arxiv.org/html/2410.21784v1
• 阿里云百炼 Multi-Agent 导购教程：https://help.aliyun.com/zh/model-studio/use-cases/create-an-ai-shopping-assistant
• 网易云商智能客服 3.0（极客公园）：https://www.geekpark.net/news/348095
• 沙丘智库《2025年“大模型+智能客服”最佳实践报告》：https://mp.weixin.qq.com/s/CXalVa8aKmLj1Cn4WC8KDA