# 多智能体怎么设计？把 6 种常见模式先分开看

做 Agent 系统时，最容易混在一起的不是模型和工具，而是“多智能体”这个词本身。

有时候你需要的是主控调度。
有时候你需要的是角色切换。
有时候你只是想把能力拆成技能包。
还有些场景，本质上是一条处理管道，或者一张自己控制的执行图。

把这些模式拆开以后，设计会清楚很多。

## 先看什么时候真的需要 multi-agent

single agent 和 multi-agent 都离不开上下文管理。  
多数时候，只有遇到下面这些问题，才值得认真往 multi-agent 走：

- 一个 agent 上挂的工具太多，已经不好调度
- 某些任务明显需要单独的 prompt、单独的知识和单独的工具
- 某些能力只应该在特定阶段打开
- 某些步骤可以并行，不想都挤在一个上下文窗口里

如果只是功能多一点、工具多一点，先把单 agent 结构收好，往往比直接拆成多 agent 更省事。

## 一、Supervisor：主智能体统一调度，子智能体当工具

Supervisor 最像很多人直觉里的 multi-agent。

它的结构很简单：

- 主智能体直接面对用户
- 子智能体不直接接用户
- 子智能体被包装成工具，由主智能体决定什么时候调用

代码骨架可以先看成这样：

```java
@Tool
String callSubagent(String agentName, String query) {
    ReActAgent subagent = subagentRegistry.get(agentName);
    return subagent.reply(query);
}
```

再往上接一层，就是把子智能体注册进 `Toolkit`：

```java
Toolkit toolkit = Toolkit.builder()
    .subAgent("researcher", () -> buildResearchAgent())
    .subAgent("coder", () -> buildCodingAgent())
    .tool(this::callSubagent)
    .build();
```

这类模式适合：

- 一个请求天然跨多个领域
- 需要统一控制工作流
- 某些步骤适合并行
- 不希望每个子智能体都自己和用户对话

这里有一个约束要单独记住：  
subagent 最好尽量无状态。

也就是：

- 主智能体负责全局上下文
- 子智能体只做局部任务
- 调完就返回结果

这样主控层只需要管调度，不用再背子智能体各自的长期状态。

这类模式真正难的地方，一般在这几件事上：

- 要不要把额外上下文传给 subagent
- subagent 的返回值怎么标准化
- 并行分支什么时候汇总
- 用户中途打断时，哪一层负责停下来

## 二、Handoffs：不是调工具，而是切换当前接待你的 Agent

Handoffs 和 Supervisor 不是一回事。

Supervisor 是主控调别人。  
Handoffs 是系统内部直接切换“当前由谁负责”。

这类模式通常会显式维护两个状态：

- `current_step`
- `active_agent`

代码结构大概是这样：

```java
class SupportState {
    String currentStep;
    String activeAgent;
    Boolean underWarranty;
}
```

工具的作用，不只是执行动作，还会推进状态：

```java
@Tool
String recordWarrantyStatus(boolean covered) {
    state.underWarranty = covered;
    state.currentStep = "specialist";
    state.activeAgent = covered ? "support_agent" : "sales_agent";
    return "状态已更新";
}
```

然后在 Hook 或调度层，根据 `activeAgent` 决定加载哪一套 prompt 和工具：

```java
if ("support_agent".equals(state.activeAgent)) {
    usePrompt(supportPrompt);
    useTools(supportTools);
}
```

这类模式适合：

- 多步骤对话流程
- 前一步结果会决定下一步路径
- 不同阶段需要不同角色直接和用户说话

客服支持、售后分流、审批流程，都更接近这一类。

Handoffs 的难点通常不在“切角色”本身，而在状态怎么管：

- 状态放在哪里
- 多个 agent 怎么共享状态
- 传完整消息历史，还是传摘要
- 中途回退一步时，`current_step` 怎么恢复

如果系统本质上是流程型产品，这一类模式通常比 Supervisor 更贴切。

## 三、Skills：把能力拆成按需加载的技能包

Skills 更像能力装配，不像多角色接力。

一个 skill 里通常会放这些东西：

- 描述
- 业务规则
- schema
- 示例查询或示例用法

可以先看成这样：

```java
AgentSkill dataSkill = AgentSkill.builder()
    .name("data_analyst")
    .description("根据 schema 和业务规则回答数据问题")
    .content("""
        schema: orders, users, payments
        rule: GMV excludes refunded orders
        example: select ...
        """)
    .build();
```

然后把它和真正的工具一起装进 `SkillBox`：

```java
SkillBox skillBox = SkillBox.builder()
    .skill(dataSkill)
    .build();

Toolkit toolkit = Toolkit.builder()
    .skillBox(skillBox)
    .tool(queryDatabaseTool)
    .build();
```

这类模式适合：

- 单个 agent 需要很多不同能力
- 能力之间没有严格流程关系
- 不同团队要分别维护不同模块

它解决的问题主要是：

- 主上下文不要一次塞太多东西
- 能力能按需装配
- prompt、规则、工具能拆开维护

如果你想做的是“一个 agent，很多技能”，那 Skills 往往比 Supervisor 和 Handoffs 更自然。

## 四、Routing：先分流，再决定交给谁

Routing 经常和 Supervisor 混在一起，但重点不一样。

Supervisor 是主智能体在会话里决定调用谁。  
Routing 是系统先做分类，再把请求送到不同入口。

一个最简单的 router，大概就是这样：

```java
String route(String query) {
    if (isBilling(query)) return "billing_agent";
    if (isSupport(query)) return "support_agent";
    if (isSales(query)) return "sales_agent";
    return "general_agent";
}
```

然后再根据路由结果去调用对应 agent。

这类模式适合：

- 不同请求有明确的垂直领域
- 入口处就能完成大部分分类
- 某些请求需要并行发给多个领域再汇总

常见做法有两种：

- 单智能体里做隐式路由
- 多智能体并行处理后再合并结果

最常见的 router 往往是无状态的：

- 一次请求做一次分类
- 路由结束就结束
- 下一次请求重新判断

如果 router 也要记状态，那通常要在外面再包一层 agent 或 workflow，复杂度会马上上去。

所以 Routing 的关键问题不是“agent 有几个”，而是：

**入口怎么分流。**

## 五、Pipeline：有些 multi-agent 就是一条处理管道

有些场景根本不需要复杂调度。

如果问题天然是一条处理链，那就直接上 Pipeline。

最常见的是两类：

```java
new SequentialPipeline(agent1, agent2, agent3);
new FanoutPipeline(agentA, agentB, agentC);
```

前者是顺序处理：

输入 -> Agent1 -> Agent2 -> Agent3 -> 输出

后者是扇出处理：

一个输入同时发给多个 Agent，各自产生结果，再做汇总。

这类模式适合：

- 检索 -> 提取 -> 归纳
- 生成 -> 评审 -> 改写
- 数据清洗 -> 分析 -> 汇总

这一类模式的重点不在角色切换，也不在复杂状态，而在数据流本身。

如果问题本来就是线性的，或者天然适合扇出再汇总，Pipeline 往往比 Handoffs 和 Supervisor 更直接。

## 六、Custom Workflow：前面几种都不够，就自己写执行图

如果前面几种模式都装不下，最实际的做法就是自己写 workflow。

代码结构大概会长成这样：

```java
if (needRetrieval) {
    runRetriever();
}

if (needParallelAnalysis) {
    fanout(analyzerA, analyzerB, analyzerC);
}

if (!verified(result)) {
    runReviewer();
}
```

也就是把：

- 顺序
- 条件
- 循环
- 并行
- agent 调用

都放进你自己的执行图里。

这类模式通常出现在：

- 业务逻辑本身就复杂
- 需要严格控制步骤
- 要混合 RAG、路由、推理、验证
- 前面几类模式只是其中某几个节点

这时候，不如把 Supervisor、Handoffs、Pipeline、Routing 当成积木，按业务重新拼。

## 最后怎么选

如果只想先有个可落地的判断，可以直接这样看：

- 需要一个主控统一调专家，用 `Supervisor`
- 需要会话在不同阶段切角色，用 `Handoffs`
- 需要给一个主智能体不断加能力，用 `Skills`
- 需要在入口先分类分流，用 `Routing`
- 需要一条线性或扇出的处理链，用 `Pipeline`
- 前面都装不下，再写 `Custom Workflow`

把这几种模式分开以后，multi-agent 这个词就不会再那么含糊。

很多时候，问题不在“要不要 multi-agent”，而在：

- 你是在拆上下文
- 还是在拆流程
- 是在拆能力
- 还是在拆入口

先把这个问题想清楚，再选模式，系统会稳很多。

如果这篇文章对你有帮助，欢迎点个赞、点个在看，也欢迎关注。
后面还会继续写 Claude Code、Codex、OpenClaw 这些项目的源码分析和使用笔记。

做 Agent 系统时，最容易混在一起的不是模型和工具，而是“多智能体”这个词本身。

多智能体怎么设计？把 6 种常见模式先分开看

软件研发

人工智能

架构设计

多智能体系统设计需区分6种模式：Supervisor主控调度、Handoffs角色切换、Skills能力拆解、Routing请求分流、Pipeline处理管道、CustomWorkflow自定义流程。根据业务场景选择合适模式，如统一调度用Supervisor、流程切换用Handoffs、能力扩展用Skills。关键要明确是拆解上下文还是流程，是能力还是入口，才能构建稳定系统。

数据清洗

数据流

智能体

路由

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

多智能体系统设计需区分6种模式：Supervisor主控调度、Handoffs角色切换、Skills能力拆解、Routing请求分流、Pipeline处理管道、CustomWorkflow自定义流程。根据业务场景选择合适模式，如统一调度用Supervisor、流程切换用Handoffs、能力扩展用Skills。关键要明...

多智能体怎么设计？把 6 种常见模式先分开看-腾讯云开发者社区-腾讯云

多智能体怎么设计？把 6 种常见模式先分开看

多智能体怎么设计？把 6 种常见模式先分开看

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐