多智能体应用技巧-j9九游会登录
单智能体能够应对大多数独立任务,但当业务场景涉及多个子流程、需要根据用户意图动态分流至不同专业处理逻辑时,单智能体面临的工程困境日渐凸显:提示词随业务迭代越写越长,工具挂载越堆越多,任何一处改动都可能引起连锁性的决策退化,且整体难以独立维护和精准调测。
为解决这一问题,agentarts提供了多智能体应用。其核心思路是引入一个中央控制器(多agent控制器),专职负责对用户输入进行意图识别与路由分发,将请求准确交给最匹配的子智能体处理,各子智能体之间相互独立、可单独调测。
在此架构基础上,平台支持三种递进增强的执行范式和一种可叠加的贯穿机制,覆盖从简单意图路由到复杂生命周期管控、多层嵌套分类的全场景需求。
单智能体与多智能体选型
在决定使用多智能体架构前,首先需要判断业务场景是否真正需要它。以下选型对比可帮助快速决策:
| 对比维度 | 单智能体 | 多智能体 |
|---|---|---|
| 适用任务复杂度 | 简单、单一任务 | 复杂、多步骤、多分支任务 |
| 核心机制 | 模型自主规划,调用工具完成任务 | 中央控制器识别意图,调度子智能体协同完成 |
| 工具使用 | 插件、工作流、知识库、mcp等 | 多个单智能体/工作流,按用户意图路由分发 |
| 调测复杂度 | 较低,提示词集中管理 | 较高,需分别调测各子智能体及路由逻辑 |
| 维护成本 | 较低,但改动影响范围大 | 较高,但各子智能体可独立维护 |
| 组织层级 | 单层 | 最多3层嵌套 |
如果任务逻辑简单、工具调用类型单一,优先使用单智能体。当业务需要按意图分发至多个专业处理流程,或需要多步骤协同完成时,再引入多智能体架构。
多智能体意图识别模式
agentarts的多智能体提供三种意图识别模式,可根据业务复杂度和准确率要求灵活选择:
| 模式 | 原理 | 适用场景 |
|---|---|---|
| 大模型识别模式 | 由控制器模型直接对用户输入进行意图理解并分类 | 意图数量少(10个以内)、边界清晰的场景,配置最简单 |
| 高精识别模式 | 预先创建意图包,预设多类意图场景,系统结合配置大幅提升识别准确率 | 意图数量多、容易混淆、对准确率要求高的场景 |
| 工作流识别模式 | 开发者自行编排专用于意图识别的工作流,可在工作流中引入知识库检索、规则判断等复杂逻辑 | 需要兼顾准确率和性能、或有特殊识别逻辑的场景 |
多agent控制器支持以下几种执行范式和一种贯穿机制:
| 类别 | 范式名称 | 核心机制 |
|---|---|---|
| 范式一 | 路由分发 | 控制器根据用户意图将请求路由至对应子智能体 |
| 范式二 | 固定生命周期管控 | 起始 → 业务处理 → 结束的固定首尾锚点 |
| 范式三 | 分层嵌套控制 | 多智能体嵌套多智能体,实现多层路由决策 |
| 贯穿机制 | 全局意图中断 | 任何时刻优先响应全局意图,可叠加在任意范式上 |
三种范式为递进增强关系,可按需叠加组合;贯穿机制可独立附加在任意范式上,不影响主架构选择。
| 场景特征 | 推荐范式组合 |
|---|---|
| 仅需按意图分发到不同子智能体 | 范式一 |
| 需要固定开头/结尾流程(如身份验证 满意度评价) | 范式一 范式二 |
| 需要多层分类(如售前/售后 → 细分意图) | 范式一 范式三 |
| 需要固定开头/结尾 多层分类 | 范式一 范式二 范式三 |
| 任何以上组合 需要随时中断(如转人工、不感兴趣) | 以上任意组合 叠加贯穿机制 |
范式一:路由分发
核心逻辑:控制器接收用户输入后,通过意图识别一次性将请求路由至最匹配的子智能体。每轮对话独立路由,子智能体之间无强依赖。
| 配置项 | 说明 |
|---|---|
| 意图识别 | 选择大模型识别模式、工作流识别模式或高精识别模式之一。 |
| 子智能体意图描述 | 每个子智能体写清楚能力范围和触发条件,提供示例语句。 |
| 子智能体执行动作 | 一次性任务选“终止”;需多轮对话收集信息选“等待输入”。 |
| 默认工作流 | 配置兜底工作流,防止无法匹配意图时系统无响应。 |
典型场景:企业客服(售前、售后、j9九游会登录的技术支持各一个子工作流)、多技能助手(编程、写作、分析各一个子工作流)。
在线客服示例(支持产品咨询、退款处理、物流查询):
用户: "你们产品怎么收费?" → [控制器] 意图识别 → 命中"产品咨询" → [产品咨询工作流] 回答价格信息 → 终止 用户: "我要退款" → [控制器] 意图识别 → 命中"退款申请" → [退款申请工作流] 处理退款事务 → 终止
范式二:固定生命周期管控
核心逻辑:通过起始工作流和结束工作流在业务逻辑的两端设定固定“锚点”。无论中间的业务流程如何路由跳转,这两个工作流始终执行,确保会话有一致的开头和结尾。
关键规则:
- 起始工作流和结束工作流不计入最大跳转次数。
- 全局意图触发"终止"后,结束工作流仍然执行,确保日志记录、满意度评价等收尾逻辑完整。
- 全局意图触发“继续”或“等待输入”时,起始工作流不会重复执行。
| 配置项 | 说明 |
|---|---|
| 高级配置 > 起始工作流 | 选择欢迎语、身份验证、权限校验等前置工作流。 |
| 高级配置 > 结束工作流 | 选择满意度调查、会话总结、工单归档等收尾工作流。 |
| 高级配置 > 默认工作流 | 选择兜底引导工作流,处理无法识别的意图。 |
典型场景:
- 智能外呼场景中,起始工作流负责开场白与身份确认,结束工作流负责播报结束语与满意度评价。
- 在线问诊场景中,起始工作流完成挂号验证与隐私声明,结束工作流输出诊后建议与随访提醒。
- 业务办理场景中,起始工作流执行身份认证与权限校验,结束工作流生成办理总结与工单编号。
智能外呼系统示例:
[起始工作流: 开场白](始终执行,不计入跳转次数)
您好,我是您的专属顾问,请问有什么可以帮您?
↓
[控制器调度](根据用户回应动态路由)
产品介绍工作流 ↔ 异议处理工作流 ↔ 预约下单工作流
↓
[结束工作流: 结束语](始终执行,不计入跳转次数)
感谢您的时间,祝您生活愉快!(后台自动写入工单) 范式三:分层嵌套控制
核心逻辑:将一个多智能体应用整体作为另一个多智能体的子节点,实现多层路由决策。一级控制器做粗分类,二级控制器在命中的分支内做细分类。目前支持2级嵌套控制(即最多三层组织层级:主控多智能体 → 子多智能体 → 子工作流/智能体)。
| 配置项 | 说明 |
|---|---|
| 一级控制器的子智能体类型 | 选择“多智能体”,关联已创建并发布的二级多智能体应用。 |
| 二级多智能体 | 需独立创建并发布,拥有独立的全局配置、生命周期工作流和全局意图。 |
| 嵌套层级 | 最多2级,即一级控制器 → 二级控制器 → 子工作流。 |
典型场景:
- 大型客服系统中,一级按售前、售后、技术三大域粗分类,每个域内再细分5~10个具体意图。
- 多部门企业中,一级按人事、财务、it、行政分流,每个部门内再路由到具体服务项。
- 跨产品线服务中,一级按产品线分流,每条产品线内再配置独立的服务体系。
企业在线客服示例(一级分为“售前咨询”和“售后支持”,售后支持下细分“技术故障”、“账号问题”、“发票申请”):
用户: "系统一直报错 500,无法使用"
↓
[一级控制器] 意图识别 → 命中"售后支持" → 路由至"售后支持"子多智能体
↓
[二级控制器] 意图识别 → 命中"技术故障" → 路由至"技术故障工作流"
↓
[技术故障工作流] "请您描述一下报错的具体场景和错误代码..." → 等待输入(持续收集信息) 贯穿机制:全局意图中断
核心逻辑:在任意对话阶段,全局意图始终优先于子智能体意图进行检测。一旦用户触发全局意图,立即中断当前业务子流程,执行全局意图的处理逻辑。适用于任何场景下随时可能出现的跨业务指令,如转人工、不感兴趣、重新开始。
全局意图与生命周期工作流的交互规则:
- 全局意图触发“终止”后 → 结束工作流仍然执行(确保收尾逻辑完整)。
- 全局意图触发“继续”或“等待输入”后 → 流程按执行动作继续,结束工作流在所有子智能体执行完毕后才触发;起始工作流不会重复执行。
| 参数 | 说明 |
|---|---|
| 意图名称 | 简短明确的意图标识,如“转人工”、“不感兴趣”。 |
| 处理方式 | 直接应答(配置一段固定文本直接回复用户)或流程跳转(关联一个工作流完成复杂处理动作)。 |
| 执行动作 | 大多数中断场景使用“终止”;需重新进入对话流程的场景(如“重新开始”)使用“等待输入”。 |
相关文档
意见反馈
文档内容是否对您有帮助?
如您有其它疑问,您也可以通过华为云社区问答频道来与我们联系探讨