从单Agent“独行侠”到Multi-Agent“英雄联盟”：一文搞懂何时该组AI战队

关键词：单Agent系统、Multi-Agent系统、扩展规模判断、任务分解、协作机制、博弈论、强化学习

摘要：当你的AI“独行侠”（单Agent系统）在某个任务上举步维艰，或者明明可以并行却只能“串行干活”浪费时间，又或者你想让AI学会合作、竞争、甚至“打配合”完成复杂任务时，你或许该考虑组建一支AI“英雄联盟”（Multi-Agent系统，简称MAS）了。本文将用“小学生组队打扫教室”“家庭分工做饭”这类通俗易懂的生活类比，从问题背景、问题描述、单AgentvsMAS的核心属性对比、何时该扩展的五大判断维度、数学模型、协作机制算法、Python代码实战、实际应用场景、最佳实践、未来趋势等方面，一步一步带你搞懂从单Agent到MAS的“升级之路”。全文约10500字，无晦涩术语堆砌，有大量生活实例、可视化图表、代码示例，适合刚接触AI Agent的初学者，也适合想优化现有Agent系统的工程师。

---

一、问题背景：从“AI独行侠”的困境说起

1.1 目的和范围

目的

本文的核心目的是帮助读者建立对“单Agent系统”“Multi-Agent系统”的清晰认知，并掌握从单Agent扩展到MAS的五大核心判断维度——任务复杂性维度、计算资源利用率维度、环境动态性维度、多目标/多约束维度、合作/竞争/混合需求维度——让读者在面对具体的AI任务时，能够像“组队参加运动会”一样，明确知道什么时候应该让AI“单打独斗”，什么时候应该“组成多人（多智能体）战队”。

同时，本文也会简单介绍MAS的核心协作机制算法（比如强化学习中的MARL算法、博弈论中的纳什均衡、拍卖算法中的VCG机制），并通过“小学生组队打扫卫生”的简化版代码实战，让读者直观感受到MAS的工作原理。

范围

本文的范围主要包括以下几点：

1. 核心概念：只介绍与“单Agent到MAS扩展”相关的核心概念，不涉及Agent的底层架构（比如Transformer-Based Agent、LLM+ReAct Agent的具体实现细节），也不涉及MAS的所有协作/竞争机制（比如只介绍最常用的几种MARL算法、博弈论基础概念）。
2. 判断维度：重点介绍我们总结的五大核心判断维度，不涉及其他可能的边缘判断标准（比如公司预算是否充足、团队是否有MAS开发经验——这些是工程落地的考虑因素，不是技术上的“何时该扩展”的核心标准）。
3. 算法与代码：算法部分只介绍简化版的协作机制（比如简化版的集中训练分散执行CTDE算法），代码部分只实现“小学生组队打扫卫生”的简化场景（比如只有扫地、擦桌子、擦窗户三种任务，只有三个小学生Agent），不涉及复杂的真实世界场景（比如自动驾驶车队、多机器人协同搜救）。
4. 应用场景：只介绍MAS已经成熟或正在快速发展的典型应用场景（比如自动驾驶、多机器人协同、电商推荐系统、游戏AI、智能客服系统），不涉及所有可能的应用场景。

1.2 预期读者

本文的预期读者主要包括以下几类：

1. AI初学者：刚接触AI Agent、LLM应用开发，对“单Agent”“Multi-Agent”有初步兴趣，但不知道它们的区别，也不知道什么时候该用哪种系统的人。
2. 全栈工程师/后端工程师：正在开发LLM应用或AI Agent系统，遇到了单Agent的瓶颈，想了解是否应该扩展到MAS的人。
3. AI产品经理：正在规划AI产品的功能，想知道是否应该引入MAS来提升产品体验的人。
4. 计算机科学/人工智能专业的学生：正在学习AI Agent、MAS相关课程，想找一篇通俗易懂的入门文章的人。

1.3 文档结构概述

本文的结构就像“小学生从不会组队到学会组队参加运动会”的过程一样，分为以下几个部分：

1. 问题背景：从“AI独行侠”的困境说起，介绍本文的目的、范围、预期读者、文档结构、术语表。
2. 核心概念与联系：用“小学生单人打扫教室vs多人组队打扫教室”的生活类比，解释单Agent、MAS的核心概念，对比它们的核心属性，给出它们的ER实体关系图和交互关系图，以及核心原理的文本示意图和Mermaid流程图。
3. 何时该扩展：五大核心判断维度：这是本文的核心部分，用大量生活实例和技术案例，详细介绍我们总结的五大核心判断维度——任务复杂性维度、计算资源利用率维度、环境动态性维度、多目标/多约束维度、合作/竞争/混合需求维度——每个维度都有“判断标准”“生活实例”“技术案例”“什么时候不该扩展”四个小节。
4. MAS的核心数学模型与协作机制：简单介绍MAS的核心数学模型（比如马尔可夫博弈模型）、核心协作机制算法（比如简化版的CTDE算法、VCG拍卖算法），并给出算法的Mermaid流程图。
5. 项目实战：小学生组队打扫教室的简化版MAS实现：详细介绍“小学生组队打扫教室”的简化版MAS的开发环境搭建、系统功能设计、系统架构设计、系统核心实现源代码、代码解读与分析。
6. 实际应用场景：MAS的“英雄联盟时刻”：介绍MAS已经成熟或正在快速发展的典型应用场景——自动驾驶车队、多机器人协同搜救、电商多智能体推荐系统、游戏AI（比如OpenAI Five、AlphaStar）、智能多客服系统——每个场景都有“场景介绍”“为什么用MAS而不是单Agent”“MAS的具体应用方式”三个小节。
7. 最佳实践：组建AI“英雄联盟”的五大技巧：介绍我们总结的组建AI“英雄联盟”的五大技巧——先明确任务的需求再选择扩展方式、从简单的协作机制开始、合理划分任务和角色、做好通信机制的设计、做好测试和调试——每个技巧都有“技巧说明”“生活实例”“技术案例”三个小节。
8. 行业发展与未来趋势：AI“英雄联盟”的进化之路：用一个markdown表格，介绍MAS从1950年代到2020年代的问题演变发展历史，然后介绍MAS的未来发展趋势——通用多智能体系统、脑机接口+MAS、跨领域多智能体协作——每个趋势都有“趋势说明”“可能的应用场景”“面临的挑战”三个小节。
9. 总结：学到了什么？：用通俗易懂的语言，总结本文的主要内容，再次强调单Agent、MAS的核心概念，以及从单Agent扩展到MAS的五大核心判断维度。
10. 思考题：动动小脑筋：提出三个思考题，鼓励读者进一步思考和应用所学知识。
11. 附录：常见问题与解答：解答读者可能会遇到的五个常见问题——单Agent和MAS的性能谁更好？MAS的开发难度一定比单Agent大吗？LLM+ReAct Agent是单Agent还是MAS？MAS一定需要强化学习吗？如何评估MAS的性能？
12. 扩展阅读 & 参考资料：列出五篇/本适合进一步学习的MAS相关的论文、书籍、网站。

1.4 术语表

为了让读者更好地理解本文的内容，我们在这里列出一些本文中会用到的核心术语的定义，以及相关概念的解释，还有缩略词列表。

核心术语定义

1. Agent（智能体）：我们可以把Agent想象成一个“有感知、有决策、有行动能力的‘小机器人’或者‘小精灵’”——它能通过传感器（比如摄像头、麦克风、API接口）感知周围的环境，能根据自己的感知结果和内部的规则（比如代码、算法、LLM的推理能力）做出决策，能通过执行器（比如机械臂、扬声器、API接口）对周围的环境产生影响。比如，我们手机上的语音助手（比如Siri、小爱同学）就是一个简单的Agent——它能通过麦克风感知我们的语音（环境感知），能通过LLM的推理能力理解我们的意图并做出决策（比如“播放音乐”“打开微信”），能通过扬声器播放音乐或者通过系统接口打开微信（环境影响）。
2. 单Agent系统（Single-Agent System，简称SAS）：我们可以把单Agent系统想象成一个“只有一个‘小机器人’或者‘小精灵’在独立完成任务的系统”——这个系统里只有一个Agent，它要自己感知所有的环境信息，自己做出所有的决策，自己执行所有的行动。比如，我们手机上的“自动擦除照片背景”的应用就是一个简单的单Agent系统——这个应用里只有一个Agent，它要自己感知照片的所有像素信息（环境感知），自己做出“哪些像素是背景、哪些像素是主体”的决策（决策），自己执行“擦除背景像素、保留主体像素”的行动（环境影响）。
3. Multi-Agent系统（Multi-Agent System，简称MAS）：我们可以把Multi-Agent系统想象成一个“有多个‘小机器人’或者‘小精灵’在一起完成任务的系统”——这个系统里有两个或两个以上的Agent，这些Agent可能是同类型的（比如三个扫地机器人），也可能是不同类型的（比如一个扫地机器人、一个擦桌子机器人、一个擦窗户机器人），它们可能会合作完成任务（比如三个扫地机器人一起打扫一个大房间），也可能会竞争完成任务（比如两个电商推荐系统的Agent竞争给用户推荐商品），还可能会既有合作又有竞争（比如一支足球队里的11个Agent既要合作进球，又要和对方球队的11个Agent竞争）。比如，我们家里的“小米智能家居套装”就是一个简单的MAS——这个套装里有多个Agent（比如小米扫地机器人、小米空气净化器、小米智能灯、小米智能门锁），它们会合作完成“让家里更舒适、更安全”的任务——比如，当小米智能门锁检测到我们回家时（环境感知），它会通过蓝牙或者Wi-Fi把这个信息告诉小米智能灯和小米空气净化器（Agent之间的通信），小米智能灯会自动打开（环境影响），小米空气净化器会自动开启（环境影响）。

相关概念解释

1. 环境（Environment）：我们可以把环境想象成“Agent周围的‘世界’”——这个世界里有Agent需要感知的信息（比如照片的像素、教室里的垃圾、家里的温度），也有Agent的行动会影响的对象（比如照片的背景、教室里的干净程度、家里的空气质量）。根据不同的分类标准，环境可以分为不同的类型：
   • 完全可观测环境vs部分可观测环境：完全可观测环境是指Agent能感知到环境的所有信息的环境（比如下棋游戏的棋盘——Agent能看到所有的棋子位置）；部分可观测环境是指Agent只能感知到环境的部分信息的环境（比如扑克牌游戏——Agent只能看到自己的牌和已经打出的牌，看不到对方的牌）。
   • 静态环境vs动态环境：静态环境是指在Agent做决策和执行行动的过程中，环境不会发生变化的环境（比如下棋游戏——除非Agent自己走棋，否则棋盘不会发生变化）；动态环境是指在Agent做决策和执行行动的过程中，环境会发生变化的环境（比如自动驾驶——路上的行人和其他车辆会随时移动）。
   • 离散环境vs连续环境：离散环境是指环境的状态和Agent的行动都是离散的（比如下棋游戏——棋子的位置是离散的，Agent的行动是“走某一步棋”）；连续环境是指环境的状态和Agent的行动都是连续的（比如自动驾驶——车辆的位置、速度、加速度都是连续的，Agent的行动是“踩油门的力度”“打方向盘的角度”）。
   • 确定性环境vs随机性环境：确定性环境是指Agent的行动会产生确定的结果的环境（比如下棋游戏——Agent走某一步棋，棋盘的变化是确定的）；随机性环境是指Agent的行动会产生不确定的结果的环境（比如掷骰子游戏——Agent掷骰子的结果是随机的）。
2. 感知（Perception）：我们可以把感知想象成“Agent通过‘眼睛’‘耳朵’‘鼻子’（传感器）‘看’‘听’‘闻’周围环境的过程”——Agent通过传感器获取环境的信息，然后把这些信息转换成自己能理解的格式（比如数字、字符串、向量）。
3. 决策（Decision Making）：我们可以把决策想象成“Agent根据自己的感知结果和内部的规则（比如代码、算法、LLM的推理能力）‘思考’接下来该做什么的过程”——Agent的内部规则可能是预先写好的（比如“如果检测到家里的温度超过26度，就自动打开空调”），也可能是通过学习得到的（比如通过强化学习学会下棋）。
4. 行动（Action）：我们可以把行动想象成“Agent通过‘手’‘脚’‘嘴巴’（执行器）‘做’某件事的过程”——Agent的行动会对周围的环境产生影响，比如“擦桌子”会让桌子变干净，“踩油门”会让车辆加速。
5. 通信（Communication）：我们可以把通信想象成“多个Agent之间通过‘说话’‘写字’‘手势’（通信接口）‘交流’信息的过程”——通信是MAS的核心特征之一，没有通信，多个Agent就只是“各自为政”的单Agent，而不是一个“协同工作”的MAS。
6. 协作（Cooperation）：我们可以把协作想象成“多个Agent一起‘努力’完成同一个目标的过程”——比如三个小学生一起打扫教室，它们的目标都是“让教室变干净”。
7. 竞争（Competition）：我们可以把竞争想象成“多个Agent为了‘争夺’同一个或不同的目标而‘对抗’的过程”——比如两个电商推荐系统的Agent竞争给用户推荐商品，它们的目标都是“让用户点击自己推荐的商品”。
8. 混合（Mixed）：我们可以把混合想象成“多个Agent之间既有‘协作’又有‘竞争’的过程”——比如一支足球队里的11个Agent既要协作进球，又要和对方球队的11个Agent竞争。

缩略词列表

1. SAS：Single-Agent System，单Agent系统
2. MAS：Multi-Agent System，多Agent系统
3. LLM：Large Language Model，大语言模型
4. ReAct：Reasoning + Acting，推理+行动，一种LLM Agent的交互范式
5. MARL：Multi-Agent Reinforcement Learning，多智能体强化学习
6. CTDE：Centralized Training with Decentralized Execution，集中训练分散执行，一种MARL的训练范式
7. VCG：Vickrey-Clarke-Groves，一种拍卖算法，用于在MAS中分配资源
8. NLP：Natural Language Processing，自然语言处理
9. CV：Computer Vision，计算机视觉
10. API：Application Programming Interface，应用程序编程接口

---

二、核心概念与联系：从“单人打扫”到“多人组队”的故事

2.1 故事引入

让我们先来看一个生活中的小故事——小明的单人打扫vs小红带领的三人小组打扫：

场景一：小明的单人打扫
今天是周五，轮到小明一个人打扫教室了。教室很大，有30张桌子、30把椅子、2个黑板、4扇窗户、1个讲台，还有很多垃圾（比如废纸、橡皮屑、零食袋）。
小明首先得把所有的椅子搬到桌子上（避免扫地的时候扫到椅子腿），然后得扫地（从教室的前面扫到后面，扫完一遍还要检查有没有漏扫的地方），然后得把垃圾倒进垃圾桶里，然后得把椅子搬回桌子下面，然后得擦桌子（每张桌子都要擦一遍，还要擦黑板、讲台、窗户），最后得把垃圾桶里的垃圾倒进楼下的大垃圾桶里。
小明一个人从下午3点开始打扫，一直打扫到下午5点半，累得满头大汗，而且擦窗户的时候还差点摔下来（因为窗户很高，小明够不到，只能踩在椅子上）。最后，老师检查的时候发现，小明漏扫了讲台下面的垃圾，而且擦的窗户也不干净（因为小明踩在椅子上晃来晃去，擦的时候只擦了一半）。

场景二：小红带领的三人小组打扫
又到了周五，这次轮到小红、小刚、小丽三个人组成小组打扫教室了。
小红首先开了一个1分钟的小组会（分工）：“小刚力气大，负责把所有的椅子搬到桌子上，然后扫地、倒垃圾、把椅子搬回桌子下面；小丽个子高，负责擦黑板、讲台、窗户；我负责擦桌子，顺便检查小刚和小丽的工作有没有做完，有没有做好。”
分工完成后，三个人就开始行动了：

• 小刚首先从下午3点01分开始搬椅子，只用了10分钟就搬完了所有的椅子；
• 小刚搬椅子的同时，小丽已经开始擦黑板了（因为擦黑板不需要用到椅子），只用了5分钟就擦完了两个黑板；
• 小刚搬完椅子后，小丽已经开始擦讲台了，小刚就开始扫地；
• 小刚扫完地后，小丽已经开始擦窗户了，小刚就开始倒垃圾、搬椅子；
• 小红在小刚搬完椅子、小丽擦完黑板后，就开始擦桌子了；
• 小丽擦完窗户后，小红也差不多擦完桌子了，小刚也搬完椅子了；
• 最后，小红检查了一下：小刚没有漏扫讲台下面的垃圾，小丽擦的窗户也很干净，小红擦的桌子也很干净。
  三个人从下午3点开始打扫，只用了下午3点40分就完成了所有的任务，而且都不累（因为每个人只做了自己擅长的、适合自己的任务）。

看完这个小故事，你是不是觉得“多人组队打扫”比“单人打扫”快多了、轻松多了、效果也好很多？其实，AI Agent系统也是一样的——当任务足够复杂时，单Agent（小明）就会举步维艰，而Multi-Agent（小红带领的三人小组）就会表现得更好。

接下来，我们就用这个小故事里的“小明的单人打扫”和“小红带领的三人小组打扫”作为类比，详细解释单Agent、MAS的核心概念，以及它们之间的关系。

2.2 核心概念解释（像给小学生讲故事一样）

核心概念一：单Agent系统（SAS）——就像“小明一个人打扫教室”

我们已经在术语表中给出了单Agent系统的专业定义，现在我们用“小明一个人打扫教室”作为类比，再解释一遍：

• 小明就是单Agent系统里的唯一的Agent：小明有“眼睛”（能看到教室里的垃圾、桌子、椅子、黑板、窗户、讲台）、“脑子”（能思考接下来该做什么——比如“先搬椅子，再扫地，再倒垃圾，再搬椅子，再擦桌子，再擦黑板、讲台、窗户，最后倒楼下的大垃圾桶”）、“手”“脚”（能搬椅子、扫地、倒垃圾、擦桌子、擦黑板、擦讲台、擦窗户）。
• 教室就是单Agent系统里的环境：教室里有小明需要感知的信息（比如垃圾的位置、桌子的数量、窗户的高度），也有小明的行动会影响的对象（比如教室的干净程度）。这个环境是部分可观测的（因为小明只能看到自己视线范围内的垃圾，看不到讲台下面的垃圾——除非他蹲下来看）、动态的（因为如果小明扫垃圾的时候不小心把零食袋碰破了，零食就会掉出来，环境就会发生变化）、离散的（因为椅子的数量、桌子的数量都是离散的，小明的行动是“搬某一张椅子”“扫某一块地方”）、随机性的（因为如果小明踩在椅子上擦窗户，可能会摔下来，也可能不会摔下来）。
• 小明的感知、决策、行动都是独立完成的：小明不需要和任何人交流，自己“看”教室里的情况，自己“思考”接下来该做什么，自己“做”某件事。

核心概念二：Multi-Agent系统（MAS）——就像“小红带领的三人小组打扫教室”

我们也已经在术语表中给出了Multi-Agent系统的专业定义，现在我们用“小红带领的三人小组打扫教室”作为类比，再解释一遍：

• 小红、小刚、小丽就是MAS里的三个Agent：这三个Agent是不同类型的（小红擅长擦桌子和检查工作、小刚力气大擅长搬椅子和扫地、小丽个子高擅长擦黑板和擦窗户），它们都有“眼睛”“脑子”“手”“脚”——能感知环境、能做出决策、能执行行动。
• 教室还是MAS里的环境：和单Agent系统里的环境一样，这个环境是部分可观测的、动态的、离散的、随机性的——不过，MAS里的每个Agent可能只能感知到环境的一部分信息（比如小刚只能看到自己扫地范围内的垃圾，小丽只能看到自己擦窗户范围内的窗户），但它们可以通过通信来交换信息（比如小丽可以告诉小红“我擦完黑板了”，小红可以告诉小刚“讲台下面还有垃圾，你再扫一下”）。
• 小红、小刚、小丽之间有分工、有通信、有协作：
  • 分工：小红开小组会给每个人分配了任务——小刚负责搬椅子、扫地、倒垃圾、搬椅子；小丽负责擦黑板、讲台、窗户；小红负责擦桌子、检查工作。分工是MAS的核心技巧之一——合理的分工可以让每个Agent只做自己擅长的、适合自己的任务，从而提高整个系统的效率和效果。
  • 通信：小红、小刚、小丽之间通过“说话”（通信接口）来交换信息——比如小丽可以告诉小红“我擦完黑板了”，小红可以告诉小刚“讲台下面还有垃圾，你再扫一下”，小刚可以告诉小红“我扫完地了”。通信是MAS的核心特征之一——没有通信，多个Agent就只是“各自为政”的单Agent，而不是一个“协同工作”的MAS。
  • 协作：小红、小刚、小丽的目标都是“让教室变干净”——它们一起努力，共同完成这个目标。协作是MAS的核心功能之一——有些任务（比如打扫一个大教室）单Agent很难完成，或者完成得很慢、效果不好，而多个Agent协作就能快速、高效、高质量地完成。

核心概念三：Agent的角色——就像“小组里的组长、力气大的同学、个子高的同学”

在MAS里，每个Agent可能会有不同的角色——就像“小红带领的三人小组打扫教室”里的小红是“组长”、小刚是“力气大的同学”、小丽是“个子高的同学”一样。

Agent的角色通常可以分为以下几类：

1. 协调者（Coordinator）/管理者（Manager）：就像“小组里的组长”——负责给其他Agent分配任务、协调其他Agent的行动、检查其他Agent的工作有没有做完、有没有做好。比如“小红带领的三人小组打扫教室”里的小红就是协调者/管理者。
2. 执行者（Executor）/工人（Worker）：就像“小组里的力气大的同学、个子高的同学”——负责完成协调者/管理者分配的具体任务。比如“小红带领的三人小组打扫教室”里的小刚和小丽就是执行者/工人。
3. 信息提供者（Information Provider）：就像“小组里的‘情报员’”——负责收集环境的信息，并把这些信息提供给其他Agent。比如在“多机器人协同搜救”的场景里，一个带有摄像头和麦克风的小型无人机Agent就是信息提供者——它负责飞到废墟上面，收集废墟下面的幸存者的信息（比如声音、位置），并把这些信息提供给地面上的搜救机器人Agent。
4. 资源分配者（Resource Allocator）：就像“小组里的‘保管员’”——负责分配系统里的资源（比如时间、空间、能源、工具）给其他Agent。比如在“电商多智能体推荐系统”的场景里，一个资源分配者Agent负责分配“首页推荐位”“搜索结果推荐位”这些资源给其他推荐Agent。

2.3 核心概念之间的关系（用小学生能理解的比喻）

2.3.1 概念一和概念二的关系：单Agent和MAS的关系——就像“单人运动员”和“多人运动队”的关系

我们可以把单Agent和MAS的关系想象成“单人运动员”和“多人运动队”的关系：

• 单人运动员（单Agent）：适合参加“单人项目”（比如100米短跑、跳远、跳高、下棋）——这些项目只需要一个人就能完成，而且多人参加反而会干扰彼此（比如两个人一起下棋，肯定会下得很乱）。
• 多人运动队（MAS）：适合参加“多人项目”（比如足球、篮球、排球、接力赛）——这些项目需要多个人协作才能完成，而且单个人很难完成（比如一个人很难踢赢一支11人的足球队）。

2.3.2 概念二和概念三的关系：MAS和Agent角色的关系——就像“多人运动队”和“队员位置”的关系

我们可以把MAS和Agent角色的关系想象成“多人运动队”和“队员位置”的关系：

• 多人运动队（MAS）：需要有不同位置的队员（比如足球队需要有守门员、后卫、中场、前锋）——不同位置的队员有不同的职责（比如守门员的职责是守住球门，前锋的职责是进球）。
• 队员位置（Agent角色）：是根据队员的特点（比如身高、体重、速度、技术）和任务的需求（比如足球队需要进球，所以需要有速度快、技术好的前锋）来确定的——合理的队员位置安排可以提高整个运动队的效率和效果（比如把身高高、弹跳好的队员安排成守门员，把速度快、技术好的队员安排成前锋）。

2.3.3 概念一、概念二、概念三的关系：单Agent、MAS、Agent角色的关系——就像“单人运动员”“多人运动队”“队员位置”的关系

我们可以把单Agent、MAS、Agent角色的关系想象成“单人运动员”“多人运动队”“队员位置”的关系：

• 单人运动员（单Agent）：没有队员位置的说法——因为只有一个人，所有的职责都要自己承担（比如单人运动员既要“进攻”又要“防守”）。
• 多人运动队（MAS）：需要有不同位置的队员（Agent角色）——不同位置的队员有不同的职责，它们一起协作完成任务（比如足球队里的守门员负责“防守”，前锋负责“进攻”，中场负责“组织进攻和防守”）。

2.4 核心概念原理和架构的文本示意图（专业定义）

接下来，我们给出单Agent系统和Multi-Agent系统的核心概念原理和架构的文本示意图（专业定义）。

单Agent系统的核心概念原理和架构的文本示意图

单Agent系统的核心概念原理和架构可以用下面的文本示意图来表示：

【环境（Environment）】
    ↓↑（感知信息/环境变化）
【感知模块（Perception Module）】→【单Agent（Agent）】→【执行模块（Action Module）】
    ↓↑（内部状态更新）
【内部状态存储（Internal State Storage）】

文本示意图的解释（专业定义）：

1. 环境（Environment）：Agent周围的世界，包含Agent需要感知的信息和Agent的行动会影响的对象。
2. 感知模块（Perception Module）：Agent的“传感器”，负责从环境中获取信息，并把这些信息转换成Agent能理解的格式（比如数字、字符串、向量）。
3. 单Agent（Agent）：系统里的唯一的智能体，包含“决策模块（Decision Making Module）”——决策模块负责根据感知模块获取的信息和内部状态存储里的内部状态，做出下一步的行动决策。
4. 内部状态存储（Internal State Storage）：Agent的“记忆”，负责存储Agent的内部状态（比如Agent已经完成的任务、Agent感知到的历史信息）。
5. 执行模块（Action Module）：Agent的“执行器”，负责执行Agent的决策模块做出的行动决策，并对环境产生影响。

Multi-Agent系统的核心概念原理和架构的文本示意图

Multi-Agent系统的核心概念原理和架构可以用下面的文本示意图来表示：

【共享环境（Shared Environment）】
    ↓↑（感知信息/环境变化）
【感知模块1】→【Agent1（决策模块1 + 内部状态存储1）】→【执行模块1】
    ↓↑（Agent间通信）
【感知模块2】→【Agent2（决策模块2 + 内部状态存储2）】→【执行模块2】
    ↓↑（Agent间通信）
【感知模块3】→【Agent3（决策模块3 + 内部状态存储3）】→【执行模块3】
    ↓↑（Agent间通信）
...
    ↓↑（Agent间通信）
【感知模块n】→【Agentn（决策模块n + 内部状态存储n）】→【执行模块n】

文本示意图的解释（专业定义）：

1. 共享环境（Shared Environment）：所有Agent共享的周围的世界，包含所有Agent需要感知的信息和所有Agent的行动会影响的对象。
2. 感知模块1~感知模块n：每个Agent的“传感器”，负责从共享环境中获取信息，并把这些信息转换成对应的Agent能理解的格式（比如数字、字符串、向量）。
3. **Agent1_{Agentn**：系统里的n个智能体（n≥2），每个Agent都包含“决策模块1}决策模块n”和“内部状态存储1~内部状态存储n”——决策模块负责根据对应的感知模块获取的信息、对应的内部状态存储里的内部状态、以及其他Agent通过通信接口传来的信息，做出下一步的行动决策；内部状态存储负责存储对应的Agent的内部状态（比如对应的Agent已经完成的任务、对应的Agent感知到的历史信息、对应的Agent从其他Agent那里收到的信息）。
4. 执行模块1~执行模块n：每个Agent的“执行器”，负责执行对应的Agent的决策模块做出的行动决策，并对共享环境产生影响。
5. Agent间通信（Inter-Agent Communication）：多个Agent之间通过“通信接口”交换信息的过程——通信接口可以是有线的（比如以太网、USB），也可以是无线的（比如Wi-Fi、蓝牙、5G）；通信的内容可以是Agent的感知信息、Agent的内部状态、Agent的行动决策、Agent的需求（比如“我需要一个工具”）、Agent的反馈（比如“我已经完成了任务”）。

2.5 Mermaid 流程图

接下来，我们给出单Agent系统和Multi-Agent系统的核心工作流程的Mermaid流程图（Mermaid流程节点中不要有括号()、逗号,等特殊字符）。

单Agent系统的核心工作流程的Mermaid流程图

Mermaid流程图的解释：

1. 首先启动单Agent系统。
2. 然后单Agent初始化自己的内部状态（比如清空自己的记忆）。
3. 然后单Agent通过感知模块获取环境信息。
4. 然后单Agent根据获取的环境信息更新自己的内部状态。
5. 然后单Agent根据自己的内部状态和获取的环境信息做出下一步的行动决策。
6. 然后单Agent通过执行模块执行自己的行动决策。
7. 然后单Agent检查任务是否完成。
8. 如果任务完成，就关闭单Agent系统；如果任务没有完成，就回到步骤3，继续获取环境信息、更新内部状态、做出行动决策、执行行动决策，直到任务完成。

Multi-Agent系统的核心工作流程的Mermaid流程图

Mermaid流程图的解释：

1. 首先启动MultiAgent系统。
2. 然后所有Agent初始化自己的内部状态（比如清空自己的记忆）。
3. 然后协调者Agent召开虚拟小组会给所有执行者Agent分配任务（如果系统里没有明确的协调者Agent，也可以通过拍卖算法、博弈论等方式让执行者Agent自己选择任务）。
4. 然后所有Agent通过感知模块获取共享环境信息。
5. 然后所有Agent根据获取的共享环境信息更新自己的内部状态。
6. 然后所有Agent之间通过通信接口交换信息（比如执行者Agent告诉协调者Agent自己已经完成了任务，协调者Agent告诉执行者Agent哪里还有任务需要完成）。
7. 然后所有Agent根据自己的内部状态、获取的共享环境信息、以及从其他Agent那里交换的信息做出下一步的行动决策。
8. 然后所有Agent通过执行模块执行自己的行动决策。
9. 然后协调者Agent检查所有任务是否完成（如果系统里没有明确的协调者Agent，也可以通过所有Agent之间交换信息的方式来检查）。
10. 如果所有任务完成，就关闭MultiAgent系统；如果所有任务没有完成，就回到步骤4，继续获取共享环境信息、更新内部状态、交换信息、做出行动决策、执行行动决策，直到所有任务完成。

---

三、何时该扩展：五大核心判断维度——像“组队参加运动会”一样做决策

这是本文的核心部分，我们将用大量生活实例和技术案例，详细介绍我们总结的五大核心判断维度——任务复杂性维度、计算资源利用率维度、环境动态性维度、多目标多约束维度、合作竞争混合需求维度——每个维度都有“判断标准”“生活实例”“技术案例”“什么时候不该扩展”四个小节。

我们可以把这五大核心判断维度想象成“组队参加运动会的五大报名条件”——只有当你的任务满足至少一个报名条件时，你才应该考虑组队（扩展到MAS）；如果你的任务一个报名条件都不满足，那么你应该让AI“单打独斗”（继续使用单Agent系统）。

3.1 判断维度一：任务复杂性维度——任务是否太大太杂，单Agent“吃不下”

3.1.1 判断标准

我们可以用下面的三个子判断标准来判断任务是否在任务复杂性维度上需要扩展到MAS：

1. 任务是否可以分解成多个独立的或 loosely coupled（松耦合）的子任务：如果任务可以分解成多个独立的或松耦合的子任务（也就是说，子任务之间的依赖关系很少，甚至没有依赖关系），那么我们可以让不同的Agent负责不同的子任务，从而提高整个系统的效率。
2. 单Agent完成整个任务的时间是否太长，无法满足需求：如果单Agent完成整个任务的时间太长，无法满足用户的需求（比如用户需要在10分钟内打扫完一个大教室，而单Agent需要2个小时才能完成），那么我们可以让多个Agent协作完成任务，从而缩短整个系统的完成时间。
3. 单Agent的能力是否有限，无法完成整个任务：如果单Agent的能力有限（比如单Agent的个子不够高，无法擦到很高的窗户；单Agent的算力不够强，无法在短时间内处理大量的数据），无法完成整个任务，那么我们可以让不同能力的Agent负责不同的子任务，从而完成整个任务。

3.1.2 生活实例

我们已经在2.1 故事引入里给出了一个非常典型的生活实例——小明的单人打扫vs小红带领的三人小组打扫：

• 任务可以分解成多个独立的或松耦合的子任务：打扫教室的任务可以分解成“搬椅子”“扫地”“倒垃圾”“搬椅子”“擦桌子”“擦黑板”“擦讲台”“擦窗户”这些子任务——这些子任务之间的依赖关系很少（比如“擦黑板”不需要等到“搬椅子”完成，“擦桌子”只需要等到“搬椅子”完成）。
• 单Agent完成整个任务的时间太长：小明一个人需要2个半小时才能完成整个任务，而小红带领的三人小组只需要40分钟就能完成整个任务。
• 单Agent的能力有限：小明的个子不够高，无法擦到很高的窗户（只能踩在椅子上晃来晃去，擦的时候只擦了一半），而小丽的个子很高，可以很轻松地擦到很高的窗户。

另一个典型的生活实例是家庭分工做饭：

• 任务可以分解成多个独立的或松耦合的子任务：家庭分工做饭的任务可以分解成“买菜”“洗菜”“切菜”“炒菜”“煮饭”“摆碗筷”这些子任务——这些子任务之间的依赖关系很少（比如“煮饭”不需要等到“买菜”完成，“摆碗筷”只需要等到“炒菜”和“煮饭”完成）。
• 单Agent完成整个任务的时间太长：如果妈妈一个人做饭，需要1个半小时才能完成，而如果爸爸负责买菜、洗菜、切菜，妈妈负责炒菜、煮饭，孩子负责摆碗筷，只需要40分钟就能完成。
• 单Agent的能力有限：如果妈妈不会开车，无法去很远的超市买新鲜的菜，而爸爸会开车，可以很轻松地去很远的超市买新鲜的菜。

3.1.3 技术案例

一个非常典型的技术案例是大规模图像识别任务：

• 任务可以分解成多个独立的或松耦合的子任务：大规模图像识别任务可以分解成“图像预处理”“特征提取”“分类”这些子任务——不过更常见的分解方式是“数据并行”分解（也就是说，把大规模的图像数据集分成多个小的图像数据集，让不同的Agent负责处理不同的小的图像数据集）。
• 单Agent完成整个任务的时间太长：如果用一台单GPU的服务器（单Agent）处理ImageNet数据集（包含1400万张图像，1000个类别），可能需要几个月才能完成训练，而如果用100台单GPU的服务器组成的集群（MAS，数据并行），可能只需要几天就能完成训练。
• 单Agent的能力有限：一台单GPU的服务器的算力不够强，无法在短时间内处理大规模的图像数据集，而100台单GPU的服务器组成的集群的算力很强，可以在短时间内处理大规模的图像数据集。

另一个非常典型的技术案例是多机器人协同搜救任务：

• 任务可以分解成多个独立的或松耦合的子任务：多机器人协同搜救任务可以分解成“信息收集”“幸存者定位”“幸存者救援”这些子任务——让一个带有摄像头和麦克风的小型无人机Agent负责信息收集和幸存者定位，让多个带有机械臂和生命探测仪的地面搜救机器人Agent负责幸存者救援。
• 单Agent完成整个任务的时间太长：如果用一个地面搜救机器人Agent（单Agent）完成整个任务，可能需要几天才能搜索完整个废墟，而且可能会错过很多幸存者，而如果用一个小型无人机Agent和10个地面搜救机器人Agent组成的集群（MAS），可能只需要几个小时就能搜索完整个废墟，而且可以找到更多的幸存者。
• 单Agent的能力有限：一个地面搜救机器人Agent无法飞到废墟上面收集信息和定位幸存者，而一个小型无人机Agent可以很轻松地飞到废墟上面收集信息和定位幸存者；一个地面搜救机器人Agent的搜索范围有限，而10个地面搜救机器人Agent的搜索范围很大。

3.1.4 什么时候不该扩展

虽然任务复杂性维度是最常见的扩展到MAS的理由，但并不是所有复杂的任务都需要扩展到MAS——如果任务无法分解成多个独立的或松耦合的子任务，或者分解后的子任务之间的依赖关系非常强（紧耦合），那么你不应该扩展到MAS。

一个典型的例子是单人下棋游戏（比如国际象棋、围棋）：

• 任务无法分解成多个独立的或松耦合的子任务：单人下棋游戏的任务是“下一步好棋”——这个任务无法分解成多个独立的或松耦合的子任务（比如“思考第一步走什么”“思考第二步走什么”——这些子任务之间的依赖关系非常强，第二步走什么完全取决于第一步走什么，以及对方第一步走什么）。
• 扩展到MAS反而会降低性能：如果让多个Agent协作下单人下棋游戏，反而会因为Agent之间的意见不一致而降低性能（比如Agent1建议走“马”，Agent2建议走“车”，最后不知道该走什么）。

另一个典型的例子是复杂的科学计算任务（紧耦合）（比如计算流体力学的直接数值模拟DNS）：

• 任务可以分解成多个子任务，但子任务之间的依赖关系非常强（紧耦合）：计算流体力学的直接数值模拟DNS可以分解成“计算每个网格点的速度”“计算每个网格点的压力”这些子任务——但这些子任务之间的依赖关系非常强，每个网格点的速度和压力都取决于周围所有网格点的速度和压力。
• 扩展到MAS的收益很小：虽然扩展到MAS可以缩短完成时间，但因为子任务之间的依赖关系非常强，Agent之间需要频繁地交换信息，所以通信成本很高，收益很小（比如用100台服务器组成的集群，可能只能把完成时间缩短到原来的10倍，而不是100倍）。

3.2 判断维度二：计算资源利用率维度——是否有大量空闲的计算资源可以利用

3.2.1 判断标准

我们可以用下面的两个子判断标准来判断任务是否在计算资源利用率维度上需要扩展到MAS：

1. 是否有大量空闲的计算资源可以利用：比如你有一台多CPU的服务器，或者有多台空闲的服务器，或者有一个云服务器集群，这些计算资源目前都没有被充分利用（利用率低于50%）。
2. 任务是否可以通过并行计算来提高效率：比如任务是大规模数据处理、大规模图像识别、大规模文本生成等，这些任务都可以通过并行计算来提高效率。

3.2.2 生活实例

一个典型的生活实例是用多台洗衣机洗衣服：

• 有大量空闲的计算资源（洗衣机）可以利用：比如你家里有3台洗衣机，但平时只用1台，另外2台都是空闲的（利用率只有33%）。
• 任务（洗衣服）可以通过并行计算来提高效率：比如你有30件衣服需要洗，如果用1台洗衣机洗，需要洗3次（每次洗10件），每次洗30分钟，总共需要90分钟；如果用3台洗衣机洗，只需要洗1次（每台洗10件），总共需要30分钟，而且另外2台空闲的洗衣机也被充分利用了（利用率提高到了100%）。

另一个典型的生活实例是用多个打印机打印文件：

• 有大量空闲的计算资源（打印机）可以利用：比如你办公室里有5台打印机，但平时只用1台，另外4台都是空闲的（利用率只有20%）。