更新时间:2026-07-16 gmt 08:00

多智能体应用技巧-j9九游会登录

单智能体能够应对大多数独立任务,但当业务场景涉及多个子流程、需要根据用户意图动态分流至不同专业处理逻辑时,单智能体面临的工程困境日渐凸显:提示词随业务迭代越写越长,工具挂载越堆越多,任何一处改动都可能引起连锁性的决策退化,且整体难以独立维护和精准调测。

为解决这一问题,agentarts提供了多智能体应用。其核心思路是引入一个中央控制器(多agent控制器),专职负责对用户输入进行意图识别与路由分发,将请求准确交给最匹配的子智能体处理,各子智能体之间相互独立、可单独调测。

在此架构基础上,平台支持三种递进增强的执行范式和一种可叠加的贯穿机制,覆盖从简单意图路由到复杂生命周期管控、多层嵌套分类的全场景需求。

单智能体与多智能体选型

在决定使用多智能体架构前,首先需要判断业务场景是否真正需要它。以下选型对比可帮助快速决策:

表1 单智能体与多智能体选型

对比维度

单智能体

多智能体

适用任务复杂度

简单、单一任务

复杂、多步骤、多分支任务

核心机制

模型自主规划,调用工具完成任务

中央控制器识别意图,调度子智能体协同完成

工具使用

插件、工作流、知识库、mcp等

多个单智能体/工作流,按用户意图路由分发

调测复杂度

较低,提示词集中管理

较高,需分别调测各子智能体及路由逻辑

维护成本

较低,但改动影响范围大

较高,但各子智能体可独立维护

组织层级

单层

最多3层嵌套

如果任务逻辑简单、工具调用类型单一,优先使用单智能体。当业务需要按意图分发至多个专业处理流程,或需要多步骤协同完成时,再引入多智能体架构。

多智能体意图识别模式

agentarts的多智能体提供三种意图识别模式,可根据业务复杂度和准确率要求灵活选择:

表2 多智能体意图识别模式

模式

原理

适用场景

大模型识别模式

由控制器模型直接对用户输入进行意图理解并分类

意图数量少(10个以内)、边界清晰的场景,配置最简单

高精识别模式

预先创建意图包,预设多类意图场景,系统结合配置大幅提升识别准确率

意图数量多、容易混淆、对准确率要求高的场景

工作流识别模式

开发者自行编排专用于意图识别的工作流,可在工作流中引入知识库检索、规则判断等复杂逻辑

需要兼顾准确率和性能、或有特殊识别逻辑的场景

图1 多agent控制器

多agent控制器支持以下几种执行范式和一种贯穿机制:

表3 多智能体执行范式

类别

范式名称

核心机制

范式一

路由分发

控制器根据用户意图将请求路由至对应子智能体

范式二

固定生命周期管控

起始 → 业务处理 → 结束的固定首尾锚点

范式三

分层嵌套控制

多智能体嵌套多智能体,实现多层路由决策

贯穿机制

全局意图中断

任何时刻优先响应全局意图,可叠加在任意范式上

三种范式为递进增强关系,可按需叠加组合;贯穿机制可独立附加在任意范式上,不影响主架构选择。

表4 多智能体应用选型

场景特征

推荐范式组合

仅需按意图分发到不同子智能体

范式一

需要固定开头/结尾流程(如身份验证 满意度评价)

范式一 范式二

需要多层分类(如售前/售后 → 细分意图)

范式一 范式三

需要固定开头/结尾 多层分类

范式一 范式二 范式三

任何以上组合 需要随时中断(如转人工、不感兴趣)

以上任意组合 叠加贯穿机制

范式一:路由分发

核心逻辑:控制器接收用户输入后,通过意图识别一次性将请求路由至最匹配的子智能体。每轮对话独立路由,子智能体之间无强依赖。

表5 关键配置要点

配置项

说明

意图识别

选择大模型识别模式、工作流识别模式或高精识别模式之一。

子智能体意图描述

每个子智能体写清楚能力范围和触发条件,提供示例语句。

子智能体执行动作

一次性任务选“终止”;需多轮对话收集信息选“等待输入”。

默认工作流

配置兜底工作流,防止无法匹配意图时系统无响应。

典型场景:企业客服(售前、售后、j9九游会登录的技术支持各一个子工作流)、多技能助手(编程、写作、分析各一个子工作流)。

在线客服示例(支持产品咨询、退款处理、物流查询):

用户: "你们产品怎么收费?"
  → [控制器] 意图识别 → 命中"产品咨询"
  → [产品咨询工作流] 回答价格信息 → 终止
用户: "我要退款"
  → [控制器] 意图识别 → 命中"退款申请"
  → [退款申请工作流] 处理退款事务 → 终止

范式二:固定生命周期管控

核心逻辑:通过起始工作流和结束工作流在业务逻辑的两端设定固定“锚点”。无论中间的业务流程如何路由跳转,这两个工作流始终执行,确保会话有一致的开头和结尾。

关键规则:

  • 起始工作流和结束工作流不计入最大跳转次数。
  • 全局意图触发"终止"后,结束工作流仍然执行,确保日志记录、满意度评价等收尾逻辑完整。
  • 全局意图触发“继续”或“等待输入”时,起始工作流不会重复执行。
表6 关键配置要点

配置项

说明

高级配置 > 起始工作流

选择欢迎语、身份验证、权限校验等前置工作流。

高级配置 > 结束工作流

选择满意度调查、会话总结、工单归档等收尾工作流。

高级配置 > 默认工作流

选择兜底引导工作流,处理无法识别的意图。

典型场景:

  • 智能外呼场景中,起始工作流负责开场白与身份确认,结束工作流负责播报结束语与满意度评价。
  • 在线问诊场景中,起始工作流完成挂号验证与隐私声明,结束工作流输出诊后建议与随访提醒。
  • 业务办理场景中,起始工作流执行身份认证与权限校验,结束工作流生成办理总结与工单编号。

智能外呼系统示例:

[起始工作流: 开场白](始终执行,不计入跳转次数)
  您好,我是您的专属顾问,请问有什么可以帮您?
         ↓
[控制器调度](根据用户回应动态路由)
  产品介绍工作流 ↔ 异议处理工作流 ↔ 预约下单工作流
         ↓
[结束工作流: 结束语](始终执行,不计入跳转次数)
  感谢您的时间,祝您生活愉快!(后台自动写入工单)

范式三:分层嵌套控制

核心逻辑:将一个多智能体应用整体作为另一个多智能体的子节点,实现多层路由决策。一级控制器做粗分类,二级控制器在命中的分支内做细分类。目前支持2级嵌套控制(即最多三层组织层级:主控多智能体 → 子多智能体 → 子工作流/智能体)。

表7 关键配置要点

配置项

说明

一级控制器的子智能体类型

选择“多智能体”,关联已创建并发布的二级多智能体应用。

二级多智能体

需独立创建并发布,拥有独立的全局配置、生命周期工作流和全局意图。

嵌套层级

最多2级,即一级控制器 → 二级控制器 → 子工作流。

典型场景:

  • 大型客服系统中,一级按售前、售后、技术三大域粗分类,每个域内再细分5~10个具体意图。
  • 多部门企业中,一级按人事、财务、it、行政分流,每个部门内再路由到具体服务项。
  • 跨产品线服务中,一级按产品线分流,每条产品线内再配置独立的服务体系。

企业在线客服示例(一级分为“售前咨询”和“售后支持”,售后支持下细分“技术故障”、“账号问题”、“发票申请”):

用户: "系统一直报错 500,无法使用"
         ↓
[一级控制器] 意图识别 → 命中"售后支持" → 路由至"售后支持"子多智能体
         ↓
[二级控制器] 意图识别 → 命中"技术故障" → 路由至"技术故障工作流"
         ↓
[技术故障工作流] "请您描述一下报错的具体场景和错误代码..." → 等待输入(持续收集信息)

贯穿机制:全局意图中断

核心逻辑:在任意对话阶段,全局意图始终优先于子智能体意图进行检测。一旦用户触发全局意图,立即中断当前业务子流程,执行全局意图的处理逻辑。适用于任何场景下随时可能出现的跨业务指令,如转人工、不感兴趣、重新开始。

全局意图与生命周期工作流的交互规则:

  • 全局意图触发“终止”后 → 结束工作流仍然执行(确保收尾逻辑完整)。
  • 全局意图触发“继续”或“等待输入”后 → 流程按执行动作继续,结束工作流在所有子智能体执行完毕后才触发;起始工作流不会重复执行。
表8 关键配置要点

参数

说明

意图名称

简短明确的意图标识,如“转人工”、“不感兴趣”。

处理方式

直接应答(配置一段固定文本直接回复用户)或流程跳转(关联一个工作流完成复杂处理动作)。

执行动作

大多数中断场景使用“终止”;需重新进入对话流程的场景(如“重新开始”)使用“等待输入”。

相关文档

网站地图