7.7
深览指数
科技人人都是产品经理·Amber··AI 生成
智能客服 Agent 架构选型：从【能回答】到【能解决】到【能代办】
本文提出智能客服架构的「三层能力模型」（能回答/能解决/能代办），并论证了这三种架构在成熟系统里是共存而非替换关系。不同于常见的纯技术选型文章，作者强调了架构选择本质上是产品问题，给出了从大小模型融合（底座）到扁平分发（主干）再到DAG层次化（局部枝干）的渐进式演进路径，并引用了网易云商、阿里巴巴和Amazon MARCO三个具体案例的实测数据。适合已进入智能客服产品设计或选型阶段的产品经理与架构师阅读。原文 ↗
核心观点
- ▍智能客服架构选型的本质不是技术选择题，而是产品问题：应根据业务当前的能力层级（能回答/能解决/能代办）选择对应架构，且三种架构在成熟系统里是共存的，不是替换的。
- ▍从「能解决」到「能代办」的跃迁往往不是主动规划，而是业务自然推动的：当用户从被动接受建议演进到要求Agent直接代为操作时，才需要引入DAG子结构，且通常只在少数高价值场景下生长。
- 01网易云商在I.T时尚零售集团和甘肃ETC的实践表明，大小模型融合架构能有效处理70%简单问题（走传统NLP）和30%复杂问题（走大模型Agent+RAG），实现成本可控的增量部署。
- 02阿里巴巴基于百炼API构建的智能导购采用Router-Agent扁平分发架构，Router使用轻量模型（qwen-plus）只输出分类结果，垂直Agent使用强模型（qwen-max）执行完整导购流程，扩展成本极低。
- 03Amazon MARCO的多Agent实际数据表明，多Agent架构不仅准确率更高，其延迟和成本反而低于单Agent超长prompt方案，原因在于每个Agent的prompt更短更聚焦。
- 04MARCO的护栏系统包含四类检测（输出格式校验、函数幻觉检测、参数值接地检测、领域知识规则），将准确率从66%提升至94%，其中带反思提示的重试机制是关键。
- 05Agent准备进入代办阶段时，需要解决确定性任务封装问题：MARCO将大多数确定性API调用链封装成普通工具，LLM仅在有输入理解或判断需求时才介入，以此降低延迟和出错率。
反方 / 局限
- — 作者承认，DAG层次化架构的复杂度最高，容易出现跨Agent调试困难、依赖关系复杂导致局部故障级联扩散的问题，且对团队的技术能力和运维水平要求较高。
- — 文中引用的案例（网易云商、阿里巴巴、Amazon MARCO）均来自大型科技公司或成熟平台，其设计经验和数据对于中小型团队或业务复杂度较低的客服场景，可能面临适用性不足的问题。
大小模型融合Router-Agent（扁平分发）DAG层次化RAG知识库护栏系统网易云商阿里巴巴Amazon MARCOI.T时尚零售集团甘肃ETCAmberGartner百炼Assistant API
16 分钟 · 4 卡片 · 7 资料
读原文 →