一、多智能体概述多智能体系统通过协调多个专职智能体或组件来完成复杂流程。并非所有复杂任务都需要多智能体——单个智能体配合合适的工具与提示词往往就够用。我们何时采用多智能体模式更有价值以及 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 的“内存压力”上下文窗口限制拒绝“信息过载”如果一次性把 GitHub的几万字文档全塞给 AI它会变得“丢三落四”中间信息丢失效应。省钱节省 TokenAI 是按阅读字数收费的。只读相关的 500 字比每次都读全量 50,000 字要便宜得多。专注度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 点的法餐顺便发邮件告诉我的秘书取消原定的会议。”中心监督者管家* 他听到了你的所有要求。他转身去拨通了两个内部专线专家智能体拨通餐厅订位系统“帮 808 房客订今晚 7 点两人位。” ——专家 A 搞定后挂断不跟你说话。拨通办公中心manage_email“给秘书发个邮件内容是取消会议。” ——专家 B 搞定后挂断也不跟你说话。最后管家回到麦克风前对你说“好的先生餐厅已订好邮件也发出了。”2. 为什么要把“专家”当成“工具”在技术实现上这被称为“Function Calling”函数调用。它的核心逻辑是专家就是个“按钮”监督者中心 AI在对话时如果发现你需要“发邮件”它不会尝试自己去写底层协议而是直接按一下manage_email这个按钮并把收件人和内容填进去。专家“无状态”邮件专家不需要知道你之前是否订过餐。它就像一个全自动打印机给它指令和数据它就执行执行完就“失忆”。只有监督者能回话这样可以保证你听到的声音是统一的。不会出现日历专家说“日程已添加”邮件专家又跳出来说“邮件已发送”显得乱糟糟。3. 适用场景对比为了让你更清楚我们把这种模式单入口路由和之前的模式多领域协作对比一下维度协作模式之前的工具模式现在的典型案例修复 Bug、写复杂的项目报告订会议室、查工资、发周报专家关系专家之间可能需要互相传递数据专家互不相干各干各的逻辑复杂度高需要多步推理中主要是精准分发路由你的感受像是在指挥一个智囊团像是在使用一个全能控制面板这种架构的妙处极度精准专门管日历的智能体它的 Prompt提示词里只写日历规则不会被“怎么写邮件”这种杂事干扰出错率极低。易于维护如果明天你想增加一个“订外卖”的功能你只需要给监督者再加一个order_food的工具按钮就行了不需要改动原来的日历和邮件逻辑。结果合并监督者能把多个专家的结果汇总成一句人话。比如“日程改好了机票也帮你查了都没问题。”三、类似区别路由 与 中心监督者智能体 的区别两种模式都能把工作分发给多个智能体但路由决策的方式不同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 的运行方式核心新上下文重点来了 当你调用一个 SubAgentcall 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加载 SkillSkill → 主Agent上下文污染主上下文SubAgent加载 SkillSkill → SubAgent自己的上下文污染的是“子上下文”不是主上下文Skills 与 中心编排智能体/ 中心监督者智能体 的区别主要区别在于上下文是否隔离Skills技能技能内容如SKILL.md通过工具如read_skill按需加载到主智能体的上下文中与主智能体共享同一段对话上下文无法隔离。主智能体只有一个进程、一段上下文只是按需把大段领域文本拉进来。适合「一个智能体多种专长、按需加载」、且不需要独立执行或隔离上下文的场景。Subagents / Supervisor子智能体 / 监督者子智能体或专家在独立调用或独立会话中执行与主智能体编排者或监督者的对话上下文隔离每次调用可带独立的系统提示与工具集结果汇总回主智能体。适合需要隔离执行、避免上下文污染、或对专家做工具/权限限制的场景。选型建议若希望在一个对话里按需加载多领域知识且不介意上下文共享用Skills若需要专职子智能体/专家在隔离上下文中执行再汇总用Subagents或Supervisor。