多智能体架构设计
智能客服系统中的多智能体（Multi-Agent）架构设计指南。
一、多智能体系统的概念和优势
概念
大语言模型（LLM）充当"大脑"，RAG 为大脑提供新鲜信息，而 Agent 则是使用大脑和工具进行计划、行动并自我纠正的"决策者"。
多智能体系统是将任务拆分，让具有特定清晰角色的多个专家 Agent 组成团队，分担任务并共同完善输出的自治系统。
核心优势
| 优势 | 说明 |
|---|---|
| 专注与专业 | 多个拥有狭窄焦点的专业 Agent 协作，在复杂任务上可能表现更好 |
| 协作与互相监督 | 各个 Agent 可以交换见解并相互完善响应，可能减少幻觉 |
| 可扩展性 | 可以灵活添加新的 Agent 角色来扩展系统能力 |
| 容错性 | 单个 Agent 故障不会导致整个系统崩溃 |
注意：
- 多智能体会带来复杂度和额外开销
- 建议先评估单 Agent 方案是否足够
- OpenAI 官方指南建议先把单 Agent 做到极限，再考虑多 Agent
二、智能客服中常见的 Agent 角色
架构图
用户输入
↓
┌─────────────────────────────────────────────────────────┐
│ 意图识别 Agent │
│ (实体抽取、意图分类、情绪识别) │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 问题规划 Agent (指挥中心) │
│ (理解需求、调度子 Agent、决策路径) │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────┬─────────────┬─────────────┬─────────────┐
│ 检索 Agent │ 生成 Agent │ 经验 Agent │ 转人工 Agent │
│ (知识图谱) │ (答案生成) │ (规则引擎) │ (护栏) │
└─────────────┴─────────────┴─────────────┴─────────────┘
↓
└──────────────────────→ 最终答案
各 Agent 职责
1. 意图识别与需求感知 Agent
职责：作为系统前端，从用户输入中抽取关键实体，进行意图分类，识别用户情绪
技术实现：
- 实体抽取：BiLSTM-CRF + BERT
- 意图分类：预训练模型
- 情绪识别：情感分析模型
2. 问题规划 Agent（指挥中心）
职责：理解用户的复杂需求，充当"调度员"，决定调用哪些具体的子 Agent 或工具
技术实现：
- LLM 理解用户意图
- 动态规划调用路径
- 决策使用哪些工具
3. 知识/检索 Agent
职责：专门负责在企业知识图谱或向量数据库中检索相关信息
技术实现：
- 图谱实体检索（Local）
- 全局关系检索（Global）
- 传统文本检索（Chunk）
4. 生成与总结 Agent
职责：提取检索到的关键见解，确保其遵循清晰、专业的布局，将其浓缩为用户易于阅读的答案
技术实现：
- Prompt 工程
- 答案生成
- 格式化输出
5. 经验/规则 Agent
职责：处理带有固定逻辑的业务，在规则引擎和 LLM 之间提供混合决策支持
技术实现：
- 规则引擎（如 Drools）
- API 调用
- 自动化排查
6. 转人工 Agent（护栏 Agent）
职责：负责监控触发条件，及时将对话路由给人工客服
触发条件：
- 用户明确发送"转人工"
- 多次重复相似问题
- 答案被给差评
- 情绪识别到严重负面情绪
三、Agent 之间的协作模式
编排与调度（Orchestration & Routing）
通常由一个主控的 AI Agent 充当"指挥中心"，它解析问题背后的真实需求，动态规划并决策搜索路径或工具调用顺序。
双引擎决策协作
在业务执行中，往往采用"规则引擎 + LLM 生成"的双模式协作：
用户问题
↓
┌─────────────────────────────────────┐
│ 问题分析 │
└─────────────────────────────────────┘
↓
┌─────────────┐ ┌─────────────┐
│ 规则引擎 │ │ LLM 生成 │
│ (确定性) │ │ (灵活性) │
└─────────────┘ └─────────────┘
↓ ↓
┌─────────────────────────────────────┐
│ 结果融合 │
└─────────────────────────────────────┘
↓
最终答案
任务分担与反馈闭环
各个 Agent 根据工作流交换数据：
检索 Agent → 获取数据 → 总结 Agent → 提取核心见解
↑
│ 反馈回路
│ (缺少数据时)
└────────────────┘
四、多智能体框架的选择
框架对比
| 框架 | 特点 | 适用场景 |
|---|---|---|
| LangGraph | 底层流程控制，状态机 | 复杂多轮对话、高度自定义 |
| CrewAI | 角色扮演、团队协作 | 专家协同任务、流水线式处理 |
| AutoGen | 对话模式、多 Agent 辩论 | 开放式问题求解、代码生成 |
| Dify | 低代码、可视化 | 快速原型、简单场景 |
LangGraph
特点：
- 内置持久化层（MemorySaver）
- 自动持久化消息历史记录
- 基于状态机的工作流控制
- 通过定义状态（StateGraph）管理多轮对话上下文
适用场景：需要复杂多轮对话管理的应用
CrewAI
特点：
- 支持为不同 Agent 定义明确的角色（Role-playing）
- 支持专注点和专属工具
- 可以构建 Agent 团队（Crew）
- 通过定义清晰的任务（Task）让 Agent 紧密协作
适用场景：多 Agent 协同任务
框架选择建议
需求分析
↓
┌─────────────────────────────────────────┐
│ 需要复杂多轮对话管理？ │
│ → 选择 LangGraph │
├─────────────────────────────────────────┤
│ 需要专家协同任务？ │
│ → 选择 CrewAI │
├─────────────────────────────────────────┤
│ 需要快速原型？ │
│ → 选择 Dify / Coze │
├─────────────────────────────────────────┤
│ 需要开放式问题求解？ │
│ → 选择 AutoGen │
└─────────────────────────────────────────┘
五、对话管理和状态追踪
状态机与多轮上下文维护
利用基于状态机的设计追踪多轮对话的进展，处理槽位填充、状态转换及重试机制。
示例：
会话状态:
├── thread_id: "user_123_session_456"
├── 当前意图: "查询产品信息"
├── 已填充槽位:
│ ├── 产品名称: "Qwen3 Embedding"
│ └── 查询属性: 未填充
└── 对话历史: [...]
记忆机制
短期记忆
保留最近几轮的对话历史（采用滑动窗口机制或截断冗余 Token）以提供上下文。
长期与实体记忆
跨会话记住用户的偏好及提及的关键实体信息，使响应更加连贯和个性化。
上下文感知与问题重写
遇到多轮追问时，在送入向量数据库之前，需要利用大模型对问题进行重写：
原始追问: "这个参数默认值是多少？"
问题重写: "Qwen3 Embedding 的默认维度是多少？"
六、实际案例和最佳实践
案例：蚂蚁集团"多 Agent 协同专家"
架构：
- 问题规划 Agent 统筹全局
- 知识 Agent 负责向量和图谱检索
- 研发 Agent 和经验 Agent 负责 API 调用及排查思路聚类
效果：
- 复杂问题的检索召回率达到 95% 以上
- 月人工工单量降低 10%
案例：某电商平台客服系统
架构：
- 意图分类器、实体抽取系统并行处理前端请求
- 后端结合规则引擎与 LLM 动态规划工具调用
- 通过 Redis 维持 10 万级并发会话状态
效果：
- 成功应对双 11 的咨询高峰
- 降低人工成本
最佳实践
1. 设立"护栏（Guardrails）"
为 Agent 限制特定工具的使用边界，设置验证检查点，提供转人工的 Fallback 兜底机制。
2. 重"持续运营"，轻"模型微调"
面临细分领域不准确时，不要急于微调模型，而是建立运营平台，不断通过收集 Few-Shot 示例并更新知识库去纠正模型。
3. 模块化设计
每个 Agent 应该是独立的模块，可以单独测试、部署和升级。
4. 可观测性
为每个 Agent 添加日志和监控，便于调试和性能优化。
七、参考资料
- NotebookLM 智能客服与 AI Agent 工程 — 完整调研资料库