多智能体概述

一、多智能体概述

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

1、为什么要用多智能体

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

• 上下文管理：在不压垮模型上下文的前提下暴露专项知识。当上下文与延迟都有限时，需要按步骤或按智能体只呈现相关内容。
• 分工开发：让不同团队负责不同能力（如技能、子智能体、专家），并在清晰边界下组合使用。
• 并行化：对子任务并行运行专职工作者，以降低延迟。

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

二、多Agent支持的模式

1、管道：

基于 Spring AI Alibaba Flow 和 AgentScope 的这种构建方式，就像是在搭乐高，把不同的智能体按特定的"形状"拼在一起。

1.1 三大"流水线"模式拆解

① 顺序模式（A → B → C）

• 形象比喻： 接力赛。
• 例子： "自然语言 --->SQL ---> 打分"。
  • 选手 A（翻译员）： 把你的中文变成数据库代码（SQL）。
  • 选手 B（执行员）： 拿着代码去数据库查数据。
  • 选手 C（质检员）： 看一下查出来的结果对不对，打个分。
• 特点： 环环相扣，前一个人的输出 是下一个人的输入。

② 并行模式（同一输入---> 多个 A/B/C --->合并）

• 形象比喻： 专家会诊 / 多路记者采访。
• 例子： "一个主题--->多个研究角度 ---->合并报告"。
  • 任务： 调研"智能无人空中驾驶"。
  • 智能体 A： 去查政策法规。
  • 智能体 B： 去查技术瓶颈。
  • 智能体 C： 去查市场规模。
  • 最后： 它们同时开工，最后把三份稿子交给一个"主编"汇总成一份。
• 特点： 效率极高，大家互不干扰，最后由一个节点做"向心合并"。

③ 循环模式（重复直到条件满足）

• 形象比喻： 改稿直到老板满意。
• 例子： "写代码 ---> 运行报错 ----> 修复 ------> 重新运行"。
  • 循环： 智能体写完代码，交给测试智能体；如果测试不通过，打回重写；直到测试通过，才准许"出厂"。
• 特点： 带有逻辑判断（If/While），不达目的不罢休。

---

1.2 为什么要用这种架构？（适用场景）

这种模式最怕的是"自由发挥"，最强的是"可预测性"。

• 流程极其明确： 你不需要 AI 去思考"下一步该干嘛"，因为业务逻辑是死的。
• 强一致性： 每次处理"NL 转 SQL"都要走这三步，确保质量跟稳定
• 复杂任务拆解： 一个大任务（写行业研究报告）如果只让一个 AI 干，它会"胡言乱语"；但拆成并行的小任务，每个 AI 只需要专注一个小点。

2、路由器：

路由器对输入分类并转发给一个或多个专家智能体；结果合并为单一回答。

2.1 通俗比喻：

去餐饮店点餐：

• 用户输入： 你对着点餐机器说："我想吃一碗兰州拉面 ，再来一杯芝士奶茶。"
• 路由器（智能点餐机）： 它不是厨师，它拉不出来面也不调奶茶。
  • 它迅速分析你的话：识别出"面食类"和"饮品类"。
  • 精准转发： 它瞬间把订单拆开，一份发给"拉面档口"，一份发给"奶茶档口"。
• 专家智能体（各专业档口）：
  • 拉面专家： 只负责揉面、拉面，它甚至不知道奶茶长什么样，但它是做面的顶级高手。
  • 奶茶专家： 只负责加冰、摇匀，它动作极快，只管出饮料。
• 结果合并（取餐通知）： 点餐机后台监测到两个档口都出货了。
  • 它不会让你跑两次，而是屏幕一闪，报出你的号："拉面和奶茶都好了，请取餐。"

3、按需披露

一个智能体只看到技能名/描述，通过工具（read_skill）按需加载完整技能内容（如 SKILL.md）。无独立子智能体进程。

3.1. 通俗比喻：超级维修工与他的"工具手册"

想象你请了一个全能维修工来家里。

• 普通 AI（上下文爆炸）： 他背着 100 本厚厚的维修手册（水电、木工、网络、家电...）进门。还没开始干活，他已经被书包压垮了，脑子里塞满了各种参数，甚至分不清电路图和水管图。
• 按需披露 AI（当前模式）： 他只带了一张"目录单"进门。
  • 你： "师傅，我家的洗碗机漏水了。"
  • AI 维修工： 他看了一眼目录，发现有《洗碗机专项维修.md》。
  • 动作（read_skill）： 他从工具箱里翻出这一本手册快速读了一下，瞬间掌握了洗碗机的构造。
  • 执行： 他修好了洗碗机。
  • 下一步： 当你又说"顺便帮我调一下路由器"时，他会放下洗碗机手册，再去读《网络配置.md》。

---

3.2 为什么要"按需披露"？（解决痛点）

这种模式主要为了解决 AI 的"内存压力"（上下文窗口限制）：

1. 拒绝"信息过载"： 如果一次性把 GitHub的几万字文档全塞给 AI，它会变得"丢三落四"（中间信息丢失效应）。
2. 省钱（节省 Token）： AI 是按阅读字数收费的。只读相关的 500 字，比每次都读全量 50,000 字要便宜得多。
3. 专注度： AI 此时只看到《SKILL.md》，它的思考逻辑会非常纯粹，不会被其他领域的知识干扰。

4、中心编排智能体

中心编排智能体 通过工具将工作委托给子智能体。子智能体可用 Markdown 或代码定义；编排智能体持有对话，子智能体每次调用无状态。

4.1 核心概念

• 中心编排智能体： 它是大脑和指挥官。它直接面对用户，负责理解需求、拆解任务，并决定把活儿分给哪个子智能体。
• 工具（Task / TaskOutput）： 这是它们沟通的"工单"。中心智能体下达一个 Task（任务书），子智能体完成后返回一个 TaskOutput（交付物）。
• 子智能体定义（Markdown 或代码）：
  • Markdown： 意味着子智能体可以是由一段自然语言描述的指令（Prompt）驱动。
  • 代码： 意味着子智能体也可以是一个具备逻辑处理能力的函数或脚本。
• 持有对话： 只有中心智能体记得你之前说过什么。它保存着完整的聊天记录（上下文）。
• 无状态： 子智能体像"临时工"。它们每次被调用时，除了当前收到的任务，不记得任何之前的对话。它们干完活就走，不留记忆。

4.2 场景具象化：处理一个"环境报错"

假设你给中心智能体发了一条消息："我的项目运行报错，提示找不到 maven依赖了，帮我修好它。"

1. 中心编排智能体（项目经理）

• 职责： 听取你的要求，维护对话状态（记得你刚才提了报错）。
• 决策： 他看了一下任务，决定分三步走，分别派给不同的子智能体。

2. 子智能体（隐形专家）

这些专家不直接回复你 ，只给项目经理发 TaskOutput：

• 子智能体 A（网络专家）： 任务： 检查当前服务器能不能连上 maven
  • 动作： 运行 ping maven.org。
  • 输出（给中心）： "网络正常，延迟 20ms。"
• 子智能体 B（代码库/文件专家）：
  • 任务： 检查项目根目录下的 代码是否引入包了。
  • 动作： 读取文件内容。
  • 输出（给中心）： "文件中确实没有引入。"
• 子智能体 C（依赖管理专家）：
  • 任务： 重新验证。
  • 动作： 运行 mvn spring-boot:run 。
  • 输出（给中心）： "无问题"

3. 最终汇总

中心智能体 拿到这些内部报告后，才会对用户说话：

"我已经帮你搞定了！经检查，你的网络没问题，但 代码里确实没有引入依赖 ，漏掉了这个依赖。我刚才已经运行 mvn spring-boot:run 没问题了，你现在可以重新运行项目了。"

5、中心监督者智能体

中心监督者 智能体将专家智能体当作工具 调用（每个专家一个工具，如 schedule_event、manage_email）。专家无状态；仅监督者的回复呈现给用户。

这个模式可以通俗地理解为："一个全能前台 + 一堆专业后台系统"。

如果说上一个场景（代码/网络/依赖）像是一个"技术开发组"，那么这个场景（日历/邮件/订票）更像是一个"高级私人管家"。

---

1. 通俗比喻：酒店的高级管家服务

想象你住进一家五星级酒店，房间里有一个"万能服务按钮"（中心监督者）。

• 你的操作： 你按下按钮说："帮我订今晚 7 点的法餐，顺便发邮件告诉我的秘书取消原定的会议。"
• 中心监督者（管家）： * 他听到了你的所有要求。
  • 他转身去拨通了两个内部专线 （专家智能体）：
    1. 拨通餐厅订位系统： "帮 808 房客订今晚 7 点两人位。" ------ 专家 A 搞定后挂断，不跟你说话。
    2. 拨通办公中心（manage_email）： "给秘书发个邮件，内容是取消会议。" ------ 专家 B 搞定后挂断，也不跟你说话。
• 最后： 管家回到麦克风前对你说："好的先生，餐厅已订好，邮件也发出了。"

---

2. 为什么要把"专家"当成"工具"？

在技术实现上，这被称为 "Function Calling"（函数调用）。它的核心逻辑是：

• 专家就是个"按钮"： 监督者（中心 AI）在对话时，如果发现你需要"发邮件"，它不会尝试自己去写底层协议，而是直接按一下 manage_email 这个按钮，并把收件人和内容填进去。
• 专家"无状态"： 邮件专家不需要知道你之前是否订过餐。它就像一个全自动打印机，给它指令和数据，它就执行，执行完就"失忆"。
• 只有监督者能回话： 这样可以保证你听到的声音是统一的。不会出现日历专家说"日程已添加"，邮件专家又跳出来说"邮件已发送"，显得乱糟糟。

---

3. 适用场景对比

为了让你更清楚，我们把这种模式（单入口路由 ）和之前的模式（多领域协作）对比一下：

维度	协作模式（之前的）	工具模式（现在的）
典型案例	修复 Bug、写复杂的项目报告	订会议室、查工资、发周报
专家关系	专家之间可能需要互相传递数据	专家互不相干，各干各的
逻辑复杂度	高，需要多步推理	中，主要是精准分发（路由）
你的感受	像是在指挥一个智囊团	像是在使用一个全能控制面板

这种架构的妙处

1. 极度精准： 专门管日历的智能体，它的 Prompt（提示词）里只写日历规则，不会被"怎么写邮件"这种杂事干扰，出错率极低。
2. 易于维护： 如果明天你想增加一个"订外卖"的功能，你只需要给监督者再加一个 order_food 的工具（按钮）就行了，不需要改动原来的日历和邮件逻辑。
3. 结果合并： 监督者能把多个专家的结果汇总成一句人话。比如："日程改好了，机票也帮你查了，都没问题。"

三、类似区别

路由 与 中心监督者智能体 的区别

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

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

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

在深一些理解区别

"既然子智能体也会加载 skill，那它和主智能体用 skill 有什么本质区别？"

回答：隔离的关键不在 skill，而在"上下文的边界"。

1、一句话先讲透

Skill 是"知识加载方式"
SubAgent 是"执行上下文隔离机制"

2、Skill 在主智能体里的运行方式（不隔离）

比如：

主Agent上下文：
[用户问题 + 历史对话 + 当前思考 + Skill内容]

当你：

调用 read_skill("send_message")

本质是：

把 SKILL.md 内容 直接拼进当前上下文

结果是：

• ✔ 和主Agent共享一切记忆
• ✔ 会污染上下文（越来越长）
• ✔ 推理链是连续的
• 没有边界

Skill = "往当前脑子里塞知识"

---

3、SubAgent 的运行方式（核心：新上下文）

重点来了 ，当你调用一个 SubAgent：

call SubAgent("send_message")

底层实际发生的是：

创建一个新的上下文（全新对话）

类似：

SubAgent上下文：
[系统Prompt + 当前任务 + 可选skills + 工具]

这个上下文 ≠ 主Agent上下文

---

关键区别来了

Skill（主Agent内）

主Agent上下文：
A + B + C + Skill内容

所有东西混在一起

SubAgent（隔离执行）

主Agent上下文：
A + B + C

SubAgent上下文（新开）：
任务 + Skill + 工具

完全两块内存

SubAgent 也加载 Skill，为什么还能隔离？

核心在这里

Skill 是"加载到谁的上下文"

情况对比

主Agent加载 Skill

Skill → 主Agent上下文

污染主上下文

SubAgent加载 Skill

Skill → SubAgent自己的上下文

污染的是"子上下文"，不是主上下文

Skills 与 中心编排智能体 / 中心监督者智能体 的区别

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

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

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