文档教程人工智能大模型【免费下载链接】awesome-generative-ai-guideA one stop repository for generative AI research updates, interview resources, notebooks and much more!项目地址https://gitcode.com/GitHub_Trending/aw/awesome-generative-ai-guide点击查看免费下载本文基于仓库中 Agentic AI Crash Course 第 8 部分课程总目录展开。前几讲已经系统拆解了单个 Agent 的四大支柱——工具Tools、RAG、MCP、规划与推理模型 与记忆Memory。本讲回答一个更进阶的问题当单个 Agent 不够用时多个 Agent 该怎么组织、协调以及——你真的需要多个 Agent 吗读完本文你将掌握多智能体系统Multi-Agent Systems的两种主流协调模式层级式 Hierarchical 与扁平式 Flat及其适用边界、多智能体在工程落地中的真实代价非确定性、状态复杂性、延迟、成本、共谋等以及贯穿整个课程始终的**问题优先Problem First**选型方法论——用它可以判断你的业务场景到底该用单 Agent 还是多 Agent。一、为什么需要多智能体系统在前面的课程中我们已经明确了一个 Agent 的基本定义LLM 工具 规划 记忆它是一个能够理解目标、调用工具、跟踪状态并端到端完成任务的系统。但现实中的很多任务单靠一个 Agent 往往心有余而力不足原因集中在三个维度规模scale、专业化specialization与并行思考parallel thinking。典型的多 Agent 业务场景原文档给出了三个非常具体的例子场景任务拆解为什么单 Agent 吃力营销策略生成需要同时覆盖市场洞察、法律审查、创意建议三种能力差异巨大要求截然不同的知识域与语气合规助手需要抽取信息、标记风险、交叉核对政策每步都是独立且专业化的子任务串行会非常慢销售流程自动化一个 Agent 与用户对话、另一个丰富数据、第三个处理跟进不同角色拥有不同的工具、记忆与职责边界能不能用一个大而全的 Agent 搞定——也许可以。但把任务拆给多个专业化 Agent能换来三个关键收益并行化Parallelization多个 Agent 可以同时处理任务的不同部分而不是串行排队专业化Specialization一个 Agent 精通法律文书另一个擅长写邮件各司其职工具独立性Tooling independence每个 Agent 可以拥有自己独立的工具集和记忆空间互不干扰。这与第 2 讲中提到的自主性-控制力权衡一脉相承多智能体并不是把自主性简单堆叠而是通过协调机制重新分配任务、状态与责任。二、两种协调模式层级式 vs 扁平式任何多智能体系统都需要某种**协调coordination**机制否则多个 Agent 只会各行其是。原文档总结了两种最常见的通信模式这也是业界构建多智能体系统时最基础的分野。1. 层级式Hierarchical更可控核心思想一个orchestrator编排者/主管Agent负责把控全局——它看到任务的完整图景把任务分解成子任务然后委派给其他专门 Agent 执行。适用场景任务可以被清晰地分解成有边界的子步骤你希望对流程有严格的控制你已经明确了 Agent 的角色分工例如summarizer 摘要器、generator 生成器、checker 检查器。典型形态企业工作流、工具套件tool suites、并行管线parallel pipelines。用工程语言来说层级式协调的本质是分解-委派-汇总主管 Agent 承担规划与状态跟踪执行 Agent 只负责自己那一小块。这种模式的好处是决策路径可预期、可控——每一层的职责边界清晰出问题时可以快速定位到具体环节。2. 扁平式Flat更动态核心思想多个 Agent 以**对等peer**身份互相交流没有老板没有固定指挥链。适用场景任务需要创造性的碰撞或辩论如头脑风暴你希望 Agent 之间互相评估、互相挑错不存在单一正确答案路径需要从多视角综合推理。典型形态头脑风暴、方案排序ranking options、多视角推理multi-view reasoning。扁平式协调更像是辩论赛多个 Agent 各自持有立场通过互相质疑逼近更好的结论。它的优势是灵活、发散但代价是收敛困难——没有权威节点来裁定分歧。两种模式并非互斥很多生产系统会混合使用外层用层级编排保证可控内层在某个子问题上用扁平式让多个 Agent 互相评审。选哪种取决于你的问题对控制力与创造性的配比需求。三、没人告诉你的真相多智能体系统很痛苦原文档用一整节篇幅提醒读者从纸面上看多智能体系统很美好快速搭个原型也很有趣但一旦进入客户/企业级场景它可能非常痛苦。很多人读到多智能体的博客后会兴奋地把模块化类比为——这不就是微服务吗AI Agent 不是微服务这是本讲最核心的一个反直觉点。AI Agent 与微服务的本质区别在于代码是确定性的deterministic而 AI 模型是非确定性的non-deterministic。同样的输入模型不一定产生同样的输出——这在仓库中关于 AI 评测的文档里被反复强调为 AI 系统工程与确定性软件的根本差异。微服务之间传递的是契约明确的请求与响应而 Agent 之间传递的是自然语言与意图每一跳都可能引入新的歧义和偏差。因此每增加一个 Agent系统复杂度不是线性增长而是组合爆炸式增长代价维度具体表现非确定性放大不仅是单个 Agent 内部的行为波动而是多个 Agent 之间的行为交叉波动记忆与状态复杂性谁知道什么、什么时候知道的——状态在所有参与者之间如何同步与共享延迟与成本多 Agent 串行/并行调用 LLMToken 消耗与端到端延迟显著上升协调 Bug 与故障点通信协议、超时、重试、死锁、循环每个环节都是新的失败源共谋CollusionAgent 之间本该互相制衡却互相附和——发生频率比你想象的高得多共谋这个概念尤其值得警惕在扁平式协调中如果设计不当多个 Agent 会倾向于互相认同因为大模型天然偏向顺承上下文导致所谓的评审形同虚设——本该被拦截的错误被一路放行。仓库中 agentic_search_retrieval_table.md 收录的ARIS研究正是针对这类失败模式设计的它引入跨模型家族的对抗性评审executor 驱动进展、来自不同模型家族的 reviewer 批判中间产物并要求修改并通过三阶段声明核查integrity verification → result-to-claim mapping → claim auditing防止长期运行的 Agent 产出看似合理但缺乏证据支撑的成功。这从研究层面印证了原文档的判断多智能体的协调与制衡是需要刻意设计的。原文档作者甚至直言关于如何让多智能体系统稳定工作我可以写一本书——它就是这么难。四、所以……你到底该不该用多智能体面对上述代价作者的个人经验法则非常明确在企业环境中不要一开始就上多智能体。先从一个 Agent 开始。让那一个 Agent先失败——无论是通过评估指标eval metrics实证其能力不足还是在运维层面暴露其不可靠——然后再考虑扩展成多智能体。原文档给出的经验观察是70% 的企业用例用单个设计良好的 Agent配备工具、记忆、RAG 与规划就能跑得很好。这个数字是作者基于客户与系统的经验观察它传递的核心信号是单 Agent 不够是一个需要被证据证实的假设而不是默认前提。多智能体系统真正发光的时刻那么什么情况下多智能体才是合理的原文档给出了三个明确条件任务大到需要并行执行parallel execution——串行会显著拖慢交付需要清晰的专业化分工clear specialization——不同子任务要求差异巨大的能力与知识域需要创造性辩论、互相评估或分布式决策creative debate, evaluation, distributed decision-making——单一视角无法覆盖问题的多面性。即便满足这些条件强设计仍是前提——尤其是围绕**记忆memory、状态state与通信协议communication protocols**这三件事。这与第 7 讲记忆专题的结论完全呼应在多 Agent 场景下谁该记住什么、何时共享、如何保持新鲜会从单 Agent 的锦上添花变成系统是否成立的关键。五、最终箴言问题优先永远如此这是整个课程从第 1 讲就开始反复强调的 mantra在多智能体这个话题上尤其重要不要因为多智能体听起来很Agentic就去构建它。只有当你的问题确实需要它时才去构建。那么怎么知道确实需要三条硬标准有正确的指标metrics——能用数据判断单 Agent 到底行不行测试test——让假设接受实证检验让简单系统先失败let simpler systems fail first——用失败证据驱动架构升级而不是用直觉驱动。这种先用最简方案、用评估数据说话的思路与仓库中 ai_evals_for_everyone 课程倡导的先建立评估体系再谈扩展完全一致——没有评估的多智能体架构升级本质上是在给不确定性加杠杆。六、仓库源码佐证单 Agent 先行的工程范式为了让先单后多的抽象原则落地可以看看仓库中一个真实的工程示例——客户支持 Agentcustomer-support-agent 的 核心实现。这是一个用 LangGraph 状态机实现的单 Agent但它示范了原文档强调的单 Agent 可靠运行所需的全部工程细节有界的 Agent 循环代码通过MAX_STEPS 3明确给一个困惑的 Agent 设置上限防止它无限空转见 support_agent.py 中的MAX_STEPS与route_agent中的步数检查状态显式建模State用 TypedDict 显式声明question / context / tool_result / decision / steps / answer / escalate / trace等字段——这正是原文档所说状态复杂性的可控化处理护栏与人类升级路径guardrail escalaten_guardrail检查回答是否有检索上下文支撑、是否被提示注入不通过则交给n_escalate升级给人工——这对应原文档让单 Agent 先失败、再扩展的运维前提先有一个可观测、可回退的单 Agent再谈多 Agent。从源码结构看这个示例刻意保持小而离线可运行见文件头注释把向量检索、缓存、可观测性与评估门槛留给生产环境——它验证了一个重要观点在把系统复杂化为多 Agent 之前先把单个 Agent 的循环边界、状态、护栏和可观测性做扎实。与之呼应的是仓库中 sdr-sales-agent 等系统设计案例销售自动化正是原文档提到的多 Agent 典型场景在仓库中同样以单个有界 Agent 明确职责划分的形态给出参考实现进一步佐证复杂业务也可以先从单 Agent 起步。七、研究趋势佐证多智能体是活跃前沿但协调成本是核心议题如果你确实走到了多智能体这一步仓库的 research_updates/agentic_search_retrieval_table.md 汇总了 2025–2026 年间大量多智能体相关论文可以帮你看到该领域正在解决的真实问题上下文预算与委派智能如 SearchSwarm 研究主 Agent 分解任务并派发给子 Agent子 Agent 只返回摘要以节省主 Agent 有限的上下文预算——这正是层级式协调中状态与记忆共享成本的研究化表达宽度扩展width scalingWideSeek-R1 提出主 Agent-子 Agent框架通过隔离上下文与专用工具的并行化用 4B 小模型达到 DeepSeek-R1-671B 单 Agent 的搜索表现——这是并行执行换能力的量化证据对抗性评审与防共谋前述 ARIS 用跨模型家族 reviewer 三阶段声明核查直接回应了原文档提到的共谋collusion痛点多智能体评测WideSearch、DR³-Eval 等基准显示当前多智能体在长时程、宽范围信息收集任务上成功率仍然很低——说明**多 Agent ≠ 更可靠**评测门槛必须先于架构升级。这些研究共同指向一个结论多智能体系统的核心工程问题不在怎么加 Agent而在怎么设计记忆、状态与通信协议让协作成本可控。这与原文档的判断完全一致。下一步多智能体系统的概念、协调模式与选型原则到这里就讲完了。下一讲将进入本系列的高潮——Part 9: 真实世界中的 Agentic 系统深入内部看看 NotebookLM、Perplexity、DeepResearch 等公开系统是如何把工具、RAG、规划、记忆与协调真正组合进生产形态的。在那之前请把本讲的一句话带在身上先让一个 Agent 失败再考虑第二个。赞分享文档教程人工智能大模型【免费下载链接】awesome-generative-ai-guideA one stop repository for generative AI research updates, interview resources, notebooks and much more!项目地址https://gitcode.com/GitHub_Trending/aw/awesome-generative-ai-guide点击查看免费下载相关推荐React Native Swipeout 动画原理揭秘TweenState 与橡胶带效果实现React Native Swipeout 动画原理揭秘TweenState 与橡胶带效果实现 React Native Swipeout 是一个实现 iOSVoltAgent多智能体系统构建Supervisor与Sub-Agent协调实战VoltAgent多智能体系统构建Supervisor与Sub Agent协调实战 VoltAgent是一个强大的开源TypeScript AI Agent框人工智能AI AgentAgent 框架后端多智能体RAG工具调用Agent 记忆Agent 工作流AI 评测MCP 服务MCP Clients语音LLM Zoomcamp 多智能体系统实战用 Kestra 构建可协作、可调试的 Multi-Agent 研究工作流LLM Zoomcamp 多智能体系统实战用 Kestra 构建可协作、可调试的 Multi Agent 研究工作流 在本篇技术指南中我们深入讲解 LLM示例工程教程人工智能大模型上一篇Cherry Studio 图像生成与多模态聊天从零到第一张图的实操步骤下一篇过平滑问题怎么破Maths CS AI Compendium 带你避开 GNN 常见陷阱创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 多智能体系统（Multi-Agent Systems）架构选型实战：层级协调、扁平对等与“问题优先“的设计原则
文档教程人工智能大模型【免费下载链接】awesome-generative-ai-guideA one stop repository for generative AI research updates, interview resources, notebooks and much more!项目地址https://gitcode.com/GitHub_Trending/aw/awesome-generative-ai-guide点击查看免费下载本文基于仓库中 Agentic AI Crash Course 第 8 部分课程总目录展开。前几讲已经系统拆解了单个 Agent 的四大支柱——工具Tools、RAG、MCP、规划与推理模型 与记忆Memory。本讲回答一个更进阶的问题当单个 Agent 不够用时多个 Agent 该怎么组织、协调以及——你真的需要多个 Agent 吗读完本文你将掌握多智能体系统Multi-Agent Systems的两种主流协调模式层级式 Hierarchical 与扁平式 Flat及其适用边界、多智能体在工程落地中的真实代价非确定性、状态复杂性、延迟、成本、共谋等以及贯穿整个课程始终的**问题优先Problem First**选型方法论——用它可以判断你的业务场景到底该用单 Agent 还是多 Agent。一、为什么需要多智能体系统在前面的课程中我们已经明确了一个 Agent 的基本定义LLM 工具 规划 记忆它是一个能够理解目标、调用工具、跟踪状态并端到端完成任务的系统。但现实中的很多任务单靠一个 Agent 往往心有余而力不足原因集中在三个维度规模scale、专业化specialization与并行思考parallel thinking。典型的多 Agent 业务场景原文档给出了三个非常具体的例子场景任务拆解为什么单 Agent 吃力营销策略生成需要同时覆盖市场洞察、法律审查、创意建议三种能力差异巨大要求截然不同的知识域与语气合规助手需要抽取信息、标记风险、交叉核对政策每步都是独立且专业化的子任务串行会非常慢销售流程自动化一个 Agent 与用户对话、另一个丰富数据、第三个处理跟进不同角色拥有不同的工具、记忆与职责边界能不能用一个大而全的 Agent 搞定——也许可以。但把任务拆给多个专业化 Agent能换来三个关键收益并行化Parallelization多个 Agent 可以同时处理任务的不同部分而不是串行排队专业化Specialization一个 Agent 精通法律文书另一个擅长写邮件各司其职工具独立性Tooling independence每个 Agent 可以拥有自己独立的工具集和记忆空间互不干扰。这与第 2 讲中提到的自主性-控制力权衡一脉相承多智能体并不是把自主性简单堆叠而是通过协调机制重新分配任务、状态与责任。二、两种协调模式层级式 vs 扁平式任何多智能体系统都需要某种**协调coordination**机制否则多个 Agent 只会各行其是。原文档总结了两种最常见的通信模式这也是业界构建多智能体系统时最基础的分野。1. 层级式Hierarchical更可控核心思想一个orchestrator编排者/主管Agent负责把控全局——它看到任务的完整图景把任务分解成子任务然后委派给其他专门 Agent 执行。适用场景任务可以被清晰地分解成有边界的子步骤你希望对流程有严格的控制你已经明确了 Agent 的角色分工例如summarizer 摘要器、generator 生成器、checker 检查器。典型形态企业工作流、工具套件tool suites、并行管线parallel pipelines。用工程语言来说层级式协调的本质是分解-委派-汇总主管 Agent 承担规划与状态跟踪执行 Agent 只负责自己那一小块。这种模式的好处是决策路径可预期、可控——每一层的职责边界清晰出问题时可以快速定位到具体环节。2. 扁平式Flat更动态核心思想多个 Agent 以**对等peer**身份互相交流没有老板没有固定指挥链。适用场景任务需要创造性的碰撞或辩论如头脑风暴你希望 Agent 之间互相评估、互相挑错不存在单一正确答案路径需要从多视角综合推理。典型形态头脑风暴、方案排序ranking options、多视角推理multi-view reasoning。扁平式协调更像是辩论赛多个 Agent 各自持有立场通过互相质疑逼近更好的结论。它的优势是灵活、发散但代价是收敛困难——没有权威节点来裁定分歧。两种模式并非互斥很多生产系统会混合使用外层用层级编排保证可控内层在某个子问题上用扁平式让多个 Agent 互相评审。选哪种取决于你的问题对控制力与创造性的配比需求。三、没人告诉你的真相多智能体系统很痛苦原文档用一整节篇幅提醒读者从纸面上看多智能体系统很美好快速搭个原型也很有趣但一旦进入客户/企业级场景它可能非常痛苦。很多人读到多智能体的博客后会兴奋地把模块化类比为——这不就是微服务吗AI Agent 不是微服务这是本讲最核心的一个反直觉点。AI Agent 与微服务的本质区别在于代码是确定性的deterministic而 AI 模型是非确定性的non-deterministic。同样的输入模型不一定产生同样的输出——这在仓库中关于 AI 评测的文档里被反复强调为 AI 系统工程与确定性软件的根本差异。微服务之间传递的是契约明确的请求与响应而 Agent 之间传递的是自然语言与意图每一跳都可能引入新的歧义和偏差。因此每增加一个 Agent系统复杂度不是线性增长而是组合爆炸式增长代价维度具体表现非确定性放大不仅是单个 Agent 内部的行为波动而是多个 Agent 之间的行为交叉波动记忆与状态复杂性谁知道什么、什么时候知道的——状态在所有参与者之间如何同步与共享延迟与成本多 Agent 串行/并行调用 LLMToken 消耗与端到端延迟显著上升协调 Bug 与故障点通信协议、超时、重试、死锁、循环每个环节都是新的失败源共谋CollusionAgent 之间本该互相制衡却互相附和——发生频率比你想象的高得多共谋这个概念尤其值得警惕在扁平式协调中如果设计不当多个 Agent 会倾向于互相认同因为大模型天然偏向顺承上下文导致所谓的评审形同虚设——本该被拦截的错误被一路放行。仓库中 agentic_search_retrieval_table.md 收录的ARIS研究正是针对这类失败模式设计的它引入跨模型家族的对抗性评审executor 驱动进展、来自不同模型家族的 reviewer 批判中间产物并要求修改并通过三阶段声明核查integrity verification → result-to-claim mapping → claim auditing防止长期运行的 Agent 产出看似合理但缺乏证据支撑的成功。这从研究层面印证了原文档的判断多智能体的协调与制衡是需要刻意设计的。原文档作者甚至直言关于如何让多智能体系统稳定工作我可以写一本书——它就是这么难。四、所以……你到底该不该用多智能体面对上述代价作者的个人经验法则非常明确在企业环境中不要一开始就上多智能体。先从一个 Agent 开始。让那一个 Agent先失败——无论是通过评估指标eval metrics实证其能力不足还是在运维层面暴露其不可靠——然后再考虑扩展成多智能体。原文档给出的经验观察是70% 的企业用例用单个设计良好的 Agent配备工具、记忆、RAG 与规划就能跑得很好。这个数字是作者基于客户与系统的经验观察它传递的核心信号是单 Agent 不够是一个需要被证据证实的假设而不是默认前提。多智能体系统真正发光的时刻那么什么情况下多智能体才是合理的原文档给出了三个明确条件任务大到需要并行执行parallel execution——串行会显著拖慢交付需要清晰的专业化分工clear specialization——不同子任务要求差异巨大的能力与知识域需要创造性辩论、互相评估或分布式决策creative debate, evaluation, distributed decision-making——单一视角无法覆盖问题的多面性。即便满足这些条件强设计仍是前提——尤其是围绕**记忆memory、状态state与通信协议communication protocols**这三件事。这与第 7 讲记忆专题的结论完全呼应在多 Agent 场景下谁该记住什么、何时共享、如何保持新鲜会从单 Agent 的锦上添花变成系统是否成立的关键。五、最终箴言问题优先永远如此这是整个课程从第 1 讲就开始反复强调的 mantra在多智能体这个话题上尤其重要不要因为多智能体听起来很Agentic就去构建它。只有当你的问题确实需要它时才去构建。那么怎么知道确实需要三条硬标准有正确的指标metrics——能用数据判断单 Agent 到底行不行测试test——让假设接受实证检验让简单系统先失败let simpler systems fail first——用失败证据驱动架构升级而不是用直觉驱动。这种先用最简方案、用评估数据说话的思路与仓库中 ai_evals_for_everyone 课程倡导的先建立评估体系再谈扩展完全一致——没有评估的多智能体架构升级本质上是在给不确定性加杠杆。六、仓库源码佐证单 Agent 先行的工程范式为了让先单后多的抽象原则落地可以看看仓库中一个真实的工程示例——客户支持 Agentcustomer-support-agent 的 核心实现。这是一个用 LangGraph 状态机实现的单 Agent但它示范了原文档强调的单 Agent 可靠运行所需的全部工程细节有界的 Agent 循环代码通过MAX_STEPS 3明确给一个困惑的 Agent 设置上限防止它无限空转见 support_agent.py 中的MAX_STEPS与route_agent中的步数检查状态显式建模State用 TypedDict 显式声明question / context / tool_result / decision / steps / answer / escalate / trace等字段——这正是原文档所说状态复杂性的可控化处理护栏与人类升级路径guardrail escalaten_guardrail检查回答是否有检索上下文支撑、是否被提示注入不通过则交给n_escalate升级给人工——这对应原文档让单 Agent 先失败、再扩展的运维前提先有一个可观测、可回退的单 Agent再谈多 Agent。从源码结构看这个示例刻意保持小而离线可运行见文件头注释把向量检索、缓存、可观测性与评估门槛留给生产环境——它验证了一个重要观点在把系统复杂化为多 Agent 之前先把单个 Agent 的循环边界、状态、护栏和可观测性做扎实。与之呼应的是仓库中 sdr-sales-agent 等系统设计案例销售自动化正是原文档提到的多 Agent 典型场景在仓库中同样以单个有界 Agent 明确职责划分的形态给出参考实现进一步佐证复杂业务也可以先从单 Agent 起步。七、研究趋势佐证多智能体是活跃前沿但协调成本是核心议题如果你确实走到了多智能体这一步仓库的 research_updates/agentic_search_retrieval_table.md 汇总了 2025–2026 年间大量多智能体相关论文可以帮你看到该领域正在解决的真实问题上下文预算与委派智能如 SearchSwarm 研究主 Agent 分解任务并派发给子 Agent子 Agent 只返回摘要以节省主 Agent 有限的上下文预算——这正是层级式协调中状态与记忆共享成本的研究化表达宽度扩展width scalingWideSeek-R1 提出主 Agent-子 Agent框架通过隔离上下文与专用工具的并行化用 4B 小模型达到 DeepSeek-R1-671B 单 Agent 的搜索表现——这是并行执行换能力的量化证据对抗性评审与防共谋前述 ARIS 用跨模型家族 reviewer 三阶段声明核查直接回应了原文档提到的共谋collusion痛点多智能体评测WideSearch、DR³-Eval 等基准显示当前多智能体在长时程、宽范围信息收集任务上成功率仍然很低——说明**多 Agent ≠ 更可靠**评测门槛必须先于架构升级。这些研究共同指向一个结论多智能体系统的核心工程问题不在怎么加 Agent而在怎么设计记忆、状态与通信协议让协作成本可控。这与原文档的判断完全一致。下一步多智能体系统的概念、协调模式与选型原则到这里就讲完了。下一讲将进入本系列的高潮——Part 9: 真实世界中的 Agentic 系统深入内部看看 NotebookLM、Perplexity、DeepResearch 等公开系统是如何把工具、RAG、规划、记忆与协调真正组合进生产形态的。在那之前请把本讲的一句话带在身上先让一个 Agent 失败再考虑第二个。赞分享文档教程人工智能大模型【免费下载链接】awesome-generative-ai-guideA one stop repository for generative AI research updates, interview resources, notebooks and much more!项目地址https://gitcode.com/GitHub_Trending/aw/awesome-generative-ai-guide点击查看免费下载相关推荐React Native Swipeout 动画原理揭秘TweenState 与橡胶带效果实现React Native Swipeout 动画原理揭秘TweenState 与橡胶带效果实现 React Native Swipeout 是一个实现 iOSVoltAgent多智能体系统构建Supervisor与Sub-Agent协调实战VoltAgent多智能体系统构建Supervisor与Sub Agent协调实战 VoltAgent是一个强大的开源TypeScript AI Agent框人工智能AI AgentAgent 框架后端多智能体RAG工具调用Agent 记忆Agent 工作流AI 评测MCP 服务MCP Clients语音LLM Zoomcamp 多智能体系统实战用 Kestra 构建可协作、可调试的 Multi-Agent 研究工作流LLM Zoomcamp 多智能体系统实战用 Kestra 构建可协作、可调试的 Multi Agent 研究工作流 在本篇技术指南中我们深入讲解 LLM示例工程教程人工智能大模型上一篇Cherry Studio 图像生成与多模态聊天从零到第一张图的实操步骤下一篇过平滑问题怎么破Maths CS AI Compendium 带你避开 GNN 常见陷阱创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考