多智能体概览¶

多智能体系统通过协调多个专职智能体或组件来完成复杂流程。并非所有复杂任务都需要多智能体——单个智能体配合合适的工具与提示往往就够用。本文概览何时采用多智能体模式更有价值，以及 AgentScope 支持哪些模式。

为何使用多智能体？¶

在以下一种或多种需求出现时，多智能体模式会很有用：

上下文管理：在不压垮模型上下文的前提下暴露专项知识。当上下文与延迟都有限时，需要按步骤或按智能体只呈现相关内容。
分工开发：让不同团队负责不同能力（如技能、子智能体、专家），并在清晰边界下组合使用。
并行化：对子任务并行运行专职工作者，以降低延迟。
结构化流程：强制顺序（如先分类再路由，或循环直到满足条件）或按角色交接（如销售 vs 支持），单智能体难以自然保证这些约束。

当单智能体工具过多且选择不佳、任务需要深领域上下文（长提示与领域工具）、或需要顺序/状态驱动路由（如先收集信息再升级、或切换“负责”对话的智能体）时，多智能体模式尤其有价值。

支持的模式¶

AgentScope 支持以下多智能体模式，每种都有独立页面说明实现与示例。

模式	作用	适用场景
Pipeline	按固定流程运行智能体：顺序（A → B → C）、并行（同一输入给多个智能体再合并）、循环（子流程重复直到条件满足）。基于 Spring AI Alibaba flow 与 AgentScopeAgent 构建。	流程明确（如 NL → SQL → 打分，或一主题 → 多研究角度 → 合并报告）。
Routing	路由器对输入分类并转发给一个或多个专家智能体（如 GitHub、Notion、Slack）；结果合并为单一回答。	有明确垂直领域，希望一次完成「分类 → 专家 → 综合」，或用图实现。
Skills	按需披露：一个智能体只看到技能名/描述，通过工具（`read_skill`）按需加载完整技能内容（如 `SKILL.md`）。无独立子智能体进程。	希望一个智能体具备多种专长，但不想一次性把所有领域文本塞进上下文。
Subagents	中心编排智能体通过工具（如 Task / TaskOutput）将工作委托给子智能体。子智能体可用 Markdown 或代码定义；编排智能体持有对话，子智能体每次调用无状态。	多领域（如代码库、网络、依赖），希望一个协调者，且子智能体无需直接对用户说话。
Supervisor	中心监督者智能体将专家智能体当作工具调用（每个专家一个工具，如 `schedule_event`、`manage_email`）。专家无状态；仅监督者的回复呈现给用户。	领域清晰（如日历、邮件），希望单一入口完成路由与结果合并。
Handoffs	状态驱动路由：工具更新状态变量（如 `active_agent`），图根据该变量路由到不同智能体节点。每个智能体可通过工具调用「交接」给另一智能体。	需要按角色或按顺序交接（如销售 ↔ 支持），对话过程中「当前负责」的智能体会变化。
Multi-Agent Debate	辩手通过 MsgHub 交换论点；主持人用结构化输出评估并决定辩论何时结束。	需要多视角（如推理任务）以及明确的结束条件与最终答案。
Custom Workflow	使用 StateGraph 自定图结构：顺序、条件或确定性 + 智能体混合步骤（如 rewrite → retrieve → agent，或 list_tables → get_schema → generate_query）。节点可为函数或 AgentScopeAgent。	标准模式不适用；需要多阶段、显式控制或非 LLM 与 LLM/智能体步骤混合时。

如何选型¶

工作流（workflow）vs 对话（conversational）¶

从整体上，多智能体模式可分为 工作流（workflow） 与 对话（conversational） 两类：

工作流模式：包含 Pipeline、Routing、Custom Workflow。流程在智能体或节点之间流转，每个节点都可能与用户交互。
对话模式：包含 Supervisor、Subagents、Skills。智能体的决策在连续的对话上下文中进行，通常只有主智能体与用户交互并将结果输出给用户。

其余模式（如 MsgHub、Agent as Tool、Handoffs、Multi-Agent Debate）可按需与上述两类组合使用。

Routing 与 Supervisor 的区别¶

两种模式都能把工作分发给多个智能体，但路由决策的方式不同：

Routing（路由）：有一个独立的路由步骤（通常是一次 LLM 分类或规则逻辑），对当前输入做分类后分发给一个或多个专家；路由器本身不维护对话历史，也不做多轮编排，本质是预处理。适合输入类别清晰、希望用轻量或确定性分类、一次请求完成「分类 → 专家 → 合并」的场景。
Supervisor（监督者）：由主监督者智能体在持续对话中动态决定下一步调用哪个专家（以工具形式）；主智能体维护上下文，可在多轮中多次调用不同专家，编排复杂多步流程。适合需要灵活、对话感知的编排、由 LLM 根据演进中的上下文决定下一步的场景。

选型建议：输入类别清晰、希望一次完成分类与合并时用 Routing；需要多轮对话、由主智能体根据上下文灵活调度专家时用 Supervisor。

Skills 与 Subagents / Supervisor 的区别¶

主要区别在于上下文是否隔离：

Skills（技能）：技能内容（如 SKILL.md）通过工具（如 read_skill）按需加载到主智能体的上下文中，与主智能体共享同一段对话上下文，无法隔离。主智能体只有一个进程、一段上下文，只是按需把大段领域文本拉进来。适合「一个智能体多种专长、按需加载」、且不需要独立执行或隔离上下文的场景。
Subagents / Supervisor（子智能体 / 监督者）：子智能体或专家在独立调用或独立会话中执行，与主智能体（编排者或监督者）的对话上下文隔离；每次调用可带独立的系统提示与工具集，结果汇总回主智能体。适合需要隔离执行、避免上下文污染、或对专家做工具/权限限制的场景。

选型建议：若希望在一个对话里按需加载多领域知识且不介意上下文共享，用 Skills；若需要专职子智能体/专家在隔离上下文中执行再汇总，用 Subagents 或 Supervisor。

选型快速参考¶

若你需要…	可考虑
固定流水线（顺序、并行或循环）	Pipeline
一次分类后交给专家并合并结果	Routing
通过工具在智能体间切换（如销售 ↔ 支持）	Handoffs
一个智能体多种专长、按需加载上下文	Skills
一个编排智能体通过 Task 工具分发给多个子智能体	Subagents
一个监督者，每个专家一个工具（如日历、邮件）	Supervisor
多个辩手 + 主持人 + 明确结束规则	Multi-Agent Debate
自定义图（确定性 + 智能体步骤、多阶段）	自定义工作流

组合使用：可以混用。例如监督者用 Agent as Tool 调用专家；子智能体编排智能体用 Skills 做按需上下文；图中某段用 Handoffs、另一段用 Routing。按流程各部分需求选择最合适的模式即可。

小结¶

Pipeline：预定义流程（顺序、并行、循环）。
Routing：分类 → 专家 → 综合。
Skills：单智能体按需加载专项提示/内容。
Subagents：一个编排智能体委托给多个任务式子智能体。
Supervisor：一个智能体将专家以「一专家一工具」方式路由与合并。
Handoffs：图中通过工具驱动状态切换「当前」智能体。
Multi-Agent Debate：辩手 + 主持人 + 明确结束条件。
Custom Workflow：自定图结构，混合确定性步骤与智能体步骤。

实现细节、代码示例与示例项目见各模式对应链接页面。