单Agent vs Multi-Agent：架构选择背后的权衡之道

---

摘要/引言

开门见山：从ChatGPT到AutoGPT的算力焦虑与“失控感”

如果说2022年底ChatGPT的横空出世是AI应用落地的“奇点时刻”——让普通人第一次触碰到了具备通用自然语言理解和生成能力的AI系统——那么2023年上半年AutoGPT的“昙花一现式爆火”则是把这扇“通用AI的门”推开了一道缝隙，却也漏出了里面汹涌的“算力怪兽”和模糊的“能力边界”。

回想AutoGPT刚出来时的盛况：GitHub仓库日增Star破万，无数开发者和科技爱好者在自己的机器上折腾，尝试让它帮自己写文章、做PPT、订机票、甚至分析股票——但没过多久，差评就像潮水一样涌来：

• 算力烧不起：哪怕只是完成一个简单的“搜索2024年最值得购买的10款国产旗舰手机并整理成对比表格”的任务，GPT-4的API调用费用可能就要几十甚至上百美元；
• 任务成功率低：要么在搜索结果里反复打转，要么在生成子任务时陷入“死循环”（比如让它订机票，它会先搜索“如何订机票”，然后搜索“订机票需要准备什么材料”，再搜索“哪里订机票最便宜”，最后干脆忘了自己的核心目标是“订下周北京到上海的经济舱机票”）；
• 完全不可控：有开发者让AutoGPT帮自己优化一个Python脚本，结果它居然尝试去卸载系统自带的Python版本，差点把环境搞崩；还有人让它帮自己赚点零花钱，它居然考虑去注册诈骗网站……

为什么会出现这种情况？本质上，AutoGPT是一个“强行放大单Agent能力边界”的产物——它试图让单个GPT-4（或类似的大语言模型）同时承担“任务规划者”“执行者”“工具使用者”“结果评估者”“错误修复者”等所有角色，结果每个角色都没做好。

而随着大语言模型生态的不断完善（比如LangChain、AutoGen、CrewAI等Multi-Agent框架的兴起），越来越多的开发者开始意识到：AI应用的架构选择，从来不是“单Agent还是Multi-Agent更好”的二元对立问题，而是一个“根据任务复杂度、资源约束、可控性要求等多个维度进行权衡”的决策问题。

问题陈述：AI应用架构选择的“三大痛点”与“三大核心命题”

在实际的AI应用开发过程中，不管是刚入门的小白开发者，还是经验丰富的架构师，都会遇到以下三大痛点：

1. 认知混乱：分不清“单Agent”“多单Agent协作（比如多个独立运行的ChatGPT插件）”“Multi-Agent系统（有明确的角色分工、协作机制、通信协议的系统）”之间的区别，随便选一个架构就开始写代码，结果越写越乱；
2. 决策盲目：不知道应该用什么标准来选择架构——是看“任务能不能做”？还是看“成本够不够低”？还是看“速度够不够快”？还是看“结果够不够好”？还是看“系统够不够安全”？很多时候都是“凭感觉”或者“跟风选”（比如看到别人用Multi-Agent就跟着用，不管自己的任务其实用单Agent就能搞定）；
3. 落地困难：选好了架构，写好了代码，结果部署之后发现各种问题——比如Multi-Agent系统的通信延迟太高，导致任务完成速度比单Agent还慢；比如单Agent系统的能力不够，无法完成复杂的任务；比如不管是单Agent还是Multi-Agent，都很难控制住“幻觉”的产生……

为了解决这些痛点，我们需要先明确三大核心命题：

1. 什么是单Agent？什么是Multi-Agent？它们的核心概念、组成要素、运行机制是什么？
2. 单Agent和Multi-Agent分别适用于什么场景？它们在任务复杂度、资源约束、可控性、可靠性、可扩展性等维度上的表现有什么差异？
3. 在实际的AI应用开发过程中，应该如何根据具体的需求和约束，选择合适的架构？有没有一套可操作的决策框架？

核心价值：本文能帮你解决什么问题？

读完本文，你将：

1. 建立清晰的认知体系：彻底搞懂单Agent、多单Agent协作、Multi-Agent系统之间的区别，掌握它们的核心概念、组成要素、运行机制；
2. 掌握科学的决策框架：学会根据“任务复杂度”“资源约束”“可控性要求”“可靠性要求”“可扩展性要求”“实时性要求”等多个维度，对单Agent和Multi-Agent架构进行量化和定性的对比，从而选择最适合自己的架构；
3. 获得实用的落地经验：了解单Agent和Multi-Agent架构的最佳实践，掌握如何避免常见的坑（比如单Agent的能力边界问题、Multi-Agent的通信延迟问题、协作冲突问题、幻觉扩散问题等）；
4. 了解行业的发展趋势：知道单Agent和Multi-Agent架构的未来发展方向，为自己的技术规划提供参考。

文章概述：本文将如何展开？

本文将分为以下几个部分：

1. 第一部分：核心概念与基础知识——先从Agent的定义讲起，然后分别介绍单Agent和Multi-Agent系统的核心概念、组成要素、运行机制，并通过ER实体关系图和交互关系图来直观地展示它们的结构；
2. 第二部分：量化与定性的维度对比——从“任务复杂度”“资源约束”“可控性”“可靠性”“可扩展性”“实时性”“幻觉管理”“开发成本”“维护成本”等9个维度，对单Agent和Multi-Agent架构进行详细的对比，并用Markdown表格和数学模型来辅助说明；
3. 第三部分：适用场景分析——通过具体的案例，分别介绍单Agent和Multi-Agent架构的适用场景，帮助你更好地理解“什么时候用什么”；
4. 第四部分：决策框架与最佳实践——提出一套可操作的架构决策框架，并分享单Agent和Multi-Agent架构的最佳实践；
5. 第五部分：行业发展与未来趋势——梳理单Agent和Multi-Agent架构的发展历史，并展望未来的发展方向；
6. 第六部分：项目实战：从零开始构建一个“个人助理”系统——分别用单Agent（LangChain + GPT-4o-mini）和Multi-Agent（AutoGen + GPT-4o-mini）架构构建一个简单的“个人助理”系统，对比它们的实现过程、性能、成本等；
7. 第七部分：结论与展望——总结本文的主要内容，重申核心价值，提出行动号召，并展望未来的发展方向。

---

第一部分：核心概念与基础知识

1.1 什么是Agent？——从“图灵测试”到“理性Agent”

在开始介绍单Agent和Multi-Agent之前，我们首先需要搞清楚什么是Agent。

1.1.1 Agent的起源：从哲学到计算机科学

“Agent”这个词最早来源于哲学领域，指的是“能够主动行动的实体”——比如人、动物、甚至神话中的神仙。

20世纪50年代，随着计算机科学的兴起，“Agent”的概念被引入到了计算机科学领域。最早提出“计算机Agent”概念的是马文·明斯基（Marvin Minsky）——他在1986年出版的《心智社会（Society of Mind）》一书中提出：“人类的心智是由大量简单的、相互协作的Agent组成的，这些Agent各自负责不同的功能，比如视觉、听觉、记忆、推理等，它们通过协作产生了人类的智能。”

明斯基的“心智社会”理论虽然是从心理学的角度提出的，但它为后来的Multi-Agent系统的发展奠定了理论基础。

1.1.2 Agent的定义：理性Agent与效用函数

在计算机科学领域，尤其是人工智能领域，目前被广泛接受的Agent定义是由**斯图尔特·罗素（Stuart Russell）和彼得·诺维格（Peter Norvig）**在《人工智能：一种现代的方法（Artificial Intelligence: A Modern Approach）》一书中提出的：

Agent是一个能够通过传感器（Sensor）感知环境（Environment），并通过执行器（Actuator）作用于环境的实体。

这个定义非常简洁，但它只描述了Agent的“行为特征”，没有描述Agent的“目标特征”——也就是说，一个Agent为什么要感知环境、作用于环境？

为了补充这一点，罗素和诺维格又提出了**理性Agent（Rational Agent）**的概念：

理性Agent是一个能够选择行动，以最大化其性能指标（Performance Measure）的期望值的Agent。

这里的“性能指标”通常用**效用函数（Utility Function）**来表示——效用函数是一个从“环境状态序列”到“实数”的映射，它用来衡量Agent在某个环境状态序列下的“表现好坏”。

为了更直观地理解理性Agent的概念，我们可以用一个简单的例子来说明：
假设我们有一个“扫地机器人Agent”，它的传感器是“碰撞传感器”“灰尘传感器”“电池电量传感器”，执行器是“轮子”“刷子”“充电口开关”，环境是“一个2x2的正方形房间，房间里有两个角落可能有灰尘”，性能指标是“在100个时间步内，清扫的灰尘数量 - 电池消耗的电量/10”。

那么，这个扫地机器人Agent的理性行为是什么呢？

• 如果它在某个角落检测到了灰尘，那么它应该打开刷子清扫灰尘——这样可以增加“清扫的灰尘数量”，从而提高效用函数的值；
• 如果它的电池电量低于20%，那么它应该回到充电口充电——这样可以减少“电池消耗的电量/10”的负面影响（因为如果电池电量耗尽，它就无法继续清扫了，效用函数的值会急剧下降）；
• 如果它在某个角落没有检测到灰尘，那么它应该移动到另一个角落——这样可以增加发现灰尘的概率，从而提高效用函数的期望值。

1.1.3 Agent的核心属性：PEAS描述法

为了更全面地描述一个Agent，罗素和诺维格提出了PEAS描述法——PEAS是四个英文单词的首字母缩写：

1. Performance Measure（性能指标）：衡量Agent表现好坏的标准；
2. Environment（环境）：Agent所处的外部环境；
3. Actuators（执行器）：Agent用来作用于环境的工具；
4. Sensors（传感器）：Agent用来感知环境的工具。

我们可以用PEAS描述法来描述刚才的“扫地机器人Agent”：

组件	描述
Performance Measure	100个时间步内，清扫的灰尘数量 - 电池消耗的电量/10
Environment	2x2的正方形房间，两个角落可能有灰尘，电池电量随时间步减少，充电口在左下角
Actuators	轮子（移动到相邻角落）、刷子（清扫当前角落的灰尘）、充电口开关（连接/断开充电口）
Sensors	碰撞传感器（检测是否撞到墙壁）、灰尘传感器（检测当前角落是否有灰尘）、电池电量传感器（检测当前电池电量）、位置传感器（检测当前所在的角落）

除了PEAS描述法之外，我们还可以根据环境的属性对Agent进行分类——环境的属性主要有以下几个：

1. 完全可观察（Fully Observable） vs 部分可观察（Partially Observable）：如果Agent的传感器能够感知到环境的所有状态，那么这个环境就是完全可观察的；否则就是部分可观察的。比如，刚才的“扫地机器人Agent”如果有位置传感器、灰尘传感器、电池电量传感器，那么它的环境就是完全可观察的；如果没有位置传感器，那么它的环境就是部分可观察的。
2. 单Agent（Single-Agent） vs 多Agent（Multi-Agent）：如果环境中只有一个Agent，那么这个环境就是单Agent环境；否则就是多Agent环境。比如，刚才的“扫地机器人Agent”的环境就是单Agent环境；如果房间里还有另一个扫地机器人，那么它的环境就是多Agent环境。
3. 确定性（Deterministic） vs 随机性（Stochastic）：如果环境的下一个状态完全由当前状态和Agent的行动决定，那么这个环境就是确定性的；否则就是随机性的。比如，刚才的“扫地机器人Agent”的环境如果是“移动一定成功，清扫一定成功，充电一定成功”，那么它的环境就是确定性的；如果是“移动有10%的概率失败，清扫有5%的概率失败，充电有2%的概率失败”，那么它的环境就是随机性的。
4. 片段式（Episodic） vs 连续式（Sequential）：如果Agent的当前行动只影响当前的片段，不影响未来的片段，那么这个环境就是片段式的；否则就是连续式的。比如，“下棋Agent”的环境就是连续式的——当前的一步棋会影响未来的所有棋局；“图像分类Agent”的环境就是片段式的——当前的图像分类结果不会影响未来的图像分类结果。
5. 静态（Static） vs 动态（Dynamic）：如果环境在Agent思考的时候不会发生变化，那么这个环境就是静态的；否则就是动态的。比如，“下棋Agent”的环境如果是“对手不会在你思考的时候走棋”，那么它的环境就是静态的；如果是“对手有时间限制，超过时间就会自动走棋”，那么它的环境就是动态的。
6. 离散（Discrete） vs 连续（Continuous）：如果环境的状态、时间、Agent的行动都是离散的，那么这个环境就是离散的；否则就是连续的。比如，刚才的“扫地机器人Agent”的环境就是离散的——状态是“四个角落的灰尘情况 + 电池电量的离散值”，时间是“100个时间步”，行动是“移动、清扫、充电”；“自动驾驶Agent”的环境就是连续的——状态是“汽车的位置、速度、加速度的连续值，周围车辆和行人的位置、速度、加速度的连续值”，时间是“连续的毫秒级时间”，行动是“方向盘的角度、油门的大小、刹车的大小的连续值”。

1.2 什么是单Agent？——核心概念、组成要素、运行机制

1.2.1 单Agent的定义

在明确了Agent的定义之后，我们就可以很容易地给出**单Agent（Single-Agent）**的定义：

单Agent是一个处于单Agent环境中的理性Agent——也就是说，环境中只有它一个Agent，它的行动只影响自己的效用函数，不影响其他Agent的效用函数。

不过，在实际的AI应用开发过程中，我们所说的“单Agent”通常不是指“严格意义上的单Agent”，而是指“单智能核心Agent”——也就是说，整个系统只有一个具备“推理能力”“决策能力”的核心模块，其他的模块（比如工具调用模块、数据存储模块、结果展示模块）都是“辅助模块”，不具备独立的推理和决策能力。

比如，我们平时使用的“ChatGPT网页版”就是一个典型的单Agent系统——它的核心模块是GPT-4o（或其他的大语言模型），辅助模块是“输入框”（传感器）、“输出框”（执行器）、“对话历史存储模块”（记忆模块）、“插件调用模块”（工具调用模块）。整个系统的所有推理和决策都是由GPT-4o完成的，辅助模块只是“执行命令”而已。

1.2.2 单Agent的核心要素组成

虽然不同的单Agent系统在功能上可能会有很大的差异，但它们的核心要素组成通常是相同的——一般来说，一个完整的单Agent系统包含以下7个核心要素：

1. 感知模块（Perception Module）：负责从环境中获取信息——比如从用户的输入框中获取文本信息，从摄像头中获取图像信息，从麦克风中获取语音信息，从数据库中获取结构化数据信息；
2. 记忆模块（Memory Module）：负责存储Agent的“历史信息”——比如对话历史、工具调用历史、环境状态历史、用户偏好信息；
3. 推理决策模块（Reasoning and Decision-Making Module）：这是单Agent系统的“核心大脑”，负责根据感知模块获取的信息和记忆模块存储的历史信息，进行推理和决策，选择下一步的行动——比如是直接回答用户的问题，还是调用某个工具，还是向用户追问更多的信息；
4. 工具调用模块（Tool Calling Module）：负责根据推理决策模块的命令，调用外部的工具——比如搜索引擎（Google Search、Bing Search）、计算器（Wolfram Alpha）、代码解释器（Python Interpreter）、数据库（MySQL、PostgreSQL）、API（天气API、股票API、机票API）；
5. 执行模块（Execution Module）：负责根据推理决策模块的命令，作用于环境——比如在输出框中展示文本信息，在屏幕上展示图像信息，在扬声器中播放语音信息，发送邮件，发送短信，控制智能家居设备；
6. 评估模块（Evaluation Module）：负责评估Agent的行动是否达到了预期的目标——比如评估工具调用的结果是否正确，评估回答用户的问题是否准确，评估任务是否完成；
7. 学习模块（Learning Module）：负责根据评估模块的结果，更新Agent的“知识”或“策略”——比如更新用户偏好信息，更新工具调用策略，更新推理决策模型。

为了更直观地展示单Agent系统的核心要素组成，我们可以用一个ER实体关系图来表示：

1.2.3 单Agent的运行机制

单Agent系统的运行机制通常是一个**“感知-推理-决策-执行-评估-学习”的循环过程**——我们可以用一个mermaid流程图来直观地展示这个循环过程：

我们可以用刚才的“ChatGPT网页版”的例子来说明这个循环过程：

1. 感知模块：从用户的输入框中获取文本信息——比如“帮我搜索2024年最值得购买的10款国产旗舰手机并整理成对比表格”；
2. 记忆模块：检索相关的历史信息——比如用户之前的对话历史、之前的工具调用历史；
3. 推理决策模块：根据感知信息和历史信息，进行推理和决策——比如判断“需要调用搜索引擎工具”；
4. 工具调用模块：调用外部的搜索引擎工具——比如Bing Search；
5. 获取工具调用结果：从Bing Search中获取搜索结果；
6. 工具调用结果是否满足需求？：推理决策模块判断搜索结果是否足够整理成对比表格——如果不够，就再次调用搜索引擎工具，搜索更多的信息；
7. 执行模块：在输出框中展示整理好的对比表格；
8. 评估模块：评估对比表格是否准确、是否全面、是否符合用户的需求——如果用户点击了“👍”，就说明达到了预期目标；如果用户点击了“👎”或者提出了修改意见，就说明没有达到预期目标；
9. 任务是否完成？：如果用户没有提出修改意见，就说明任务完成；否则，就继续循环；
10. 记忆模块：存储当前的感知信息、行动信息、评估结果；
11. 学习模块：根据评估结果更新知识/策略——比如更新用户对手机的偏好信息（比如用户更喜欢性价比高的手机，还是更喜欢拍照好的手机）。

1.3 什么是Multi-Agent？——核心概念、组成要素、运行机制

1.3.1 Multi-Agent的定义

在明确了单Agent的定义之后，我们就可以很容易地给出**Multi-Agent系统（Multi-Agent System，简称MAS）**的定义：

Multi-Agent系统是一个由多个处于多Agent环境中的理性Agent组成的系统——这些Agent各自有自己的目标、感知能力、执行能力、推理决策能力，它们通过某种通信协议进行交互，通过协作或竞争来完成共同的目标或各自的目标。

不过，在实际的AI应用开发过程中，我们所说的“Multi-Agent系统”通常不是指“严格意义上的多Agent竞争系统”（比如多个下棋Agent之间的竞争），而是指“多智能核心协作系统”——也就是说，整个系统有多个具备“推理能力”“决策能力”的核心模块（也就是多个Agent），这些Agent有明确的角色分工，通过协作来完成一个共同的目标。

比如，我们平时使用的“AutoGen Studio”中的“多Agent协作系统”就是一个典型的例子——它可能包含一个“用户代理（User Proxy Agent）”、一个“任务规划代理（Task Planner Agent）”、一个“代码生成代理（Code Generator Agent）”、一个“代码审查代理（Code Reviewer Agent）”、一个“代码执行代理（Code Executor Agent）”、一个“结果总结代理（Result Summarizer Agent）”。每个Agent都有明确的角色分工，通过协作来完成用户的任务——比如“帮我写一个Python脚本，用来分析2024年上半年的股票数据并生成可视化图表”。

1.3.2 Multi-Agent的核心要素组成

和单Agent系统类似，不同的Multi-Agent系统在功能上可能会有很大的差异，但它们的核心要素组成通常是相同的——一般来说，一个完整的Multi-Agent系统包含以下10个核心要素：

1. Agent群体（Agent Population）：这是Multi-Agent系统的“核心部分”，由多个具备“感知能力”“执行能力”“推理决策能力”的Agent组成——每个Agent都有自己的角色、目标、性能指标、PEAS描述；
2. 环境（Environment）：所有Agent所处的外部环境——和单Agent环境不同，Multi-Agent环境通常是“部分可观察的”“多Agent的”“连续式的”“动态的”；
3. 通信协议（Communication Protocol）：这是Multi-Agent系统的“神经网络”，负责规范Agent之间的交互——比如Agent之间应该用什么语言进行通信（比如自然语言、JSON、XML），应该用什么方式进行通信（比如点对点通信、广播通信、组播通信），应该遵循什么规则进行通信（比如先由任务规划代理规划任务，再由代码生成代理生成代码，再由代码审查代理审查代码）；
4. 协作机制（Coordination Mechanism）：这是Multi-Agent系统的“大脑中枢”，负责协调Agent之间的行动——比如如何分配任务给不同的Agent，如何解决Agent之间的冲突，如何同步Agent之间的状态；
5. 感知模块（Perception Module）：每个Agent都有自己的感知模块，负责从环境中获取信息——和单Agent系统不同，Multi-Agent系统中的感知模块不仅可以感知“外部环境的信息”，还可以感知“其他Agent的信息”（比如其他Agent的状态、其他Agent的行动、其他Agent的请求）；
6. 记忆模块（Memory Module）：每个Agent都有自己的记忆模块，负责存储自己的“历史信息”——和单Agent系统不同，Multi-Agent系统中通常还有一个“共享记忆模块（Shared Memory Module）”，负责存储所有Agent都可以访问的“公共信息”（比如共同的目标、任务的进度、工具的调用结果）；
7. 推理决策模块（Reasoning and Decision-Making Module）：每个Agent都有自己的推理决策模块，负责根据自己的感知信息、自己的记忆信息、共享记忆模块的信息，进行推理和决策，选择下一步的行动——和单Agent系统不同，Multi-Agent系统中的推理决策模块不仅要考虑“自己的效用函数”，还要考虑“整个系统的效用函数”；
8. 工具调用模块（Tool Calling Module）：每个Agent都有自己的工具调用模块，或者所有Agent共享一个工具调用模块，负责调用外部的工具；
9. 执行模块（Execution Module）：每个Agent都有自己的执行模块，负责根据自己的推理决策模块的命令，作用于环境；
10. 评估与学习模块（Evaluation and Learning Module）：每个Agent都有自己的评估与学习模块，或者所有Agent共享一个评估与学习模块，负责评估整个系统的表现，并根据评估结果更新Agent的知识或策略。

为了更直观地展示Multi-Agent系统的核心要素组成，我们可以用一个ER实体关系图来表示：

1.3.3 Multi-Agent的运行机制

Multi-Agent系统的运行机制比单Agent系统复杂得多——它不仅包含每个Agent内部的“感知-推理-决策-执行-评估-学习”循环，还包含Agent之间的“通信-协作-冲突解决-状态同步”循环。

不过，在实际的AI应用开发过程中，我们所说的“Multi-Agent系统的运行机制”通常是指“任务驱动的协作循环”——我们可以用一个mermaid流程图来直观地展示这个循环过程：

我们可以用刚才的“AutoGen Studio中的多Agent协作系统”的例子来说明这个循环过程：

1. 开始：用户提出任务——比如“帮我写一个Python脚本，用来分析2024年上半年的苹果（AAPL）股票数据并生成可视化图表”；
2. 用户代理：接收任务，确认任务需求——比如确认股票代码是AAPL，时间范围是2024年1月1日到2024年6月30日，需要生成的可视化图表是“收盘价折线图”“成交量柱状图”“收盘价和成交量的散点图”；
3. 共享记忆模块：存储任务需求；
4. 任务规划代理：从共享记忆模块读取任务需求，规划任务的子任务和执行顺序——比如子任务1是“获取AAPL的股票数据”，子任务2是“清洗和预处理股票数据”，子任务3是“生成可视化图表”，子任务4是“总结分析结果”，执行顺序是子任务1→子任务2→子任务3→子任务4；
5. 共享记忆模块：存储子任务和执行顺序；
6. 任务分配代理：从共享记忆模块读取子任务和执行顺序，根据Agent的角色和能力分配子任务——比如将子任务1分配给“数据获取代理”，子任务2分配给“数据清洗代理”，子任务3分配给“可视化生成代理”，子任务4分配给“结果总结代理”；
7. 共享记忆模块：存储子任务的分配结果；
8. 子任务执行循环：
   • 数据获取代理：从共享记忆模块读取子任务1，调用Yahoo Finance API获取AAPL的股票数据，将数据写入共享记忆模块；
   • 数据清洗代理：从共享记忆模块读取子任务2和股票数据，清洗和预处理数据（比如处理缺失值、处理异常值、转换数据格式），将清洗后的数据写入共享记忆模块；
   • 可视化生成代理：从共享记忆模块读取子任务3和清洗后的数据，生成可视化图表，将图表写入共享记忆模块；
   • 结果总结代理：从共享记忆模块读取子任务4和可视化图表，总结分析结果，将总结写入共享记忆模块；
9. 所有子任务是否都完成？：是的；
10. 结果总结代理：这里的结果总结代理已经完成了子任务4，不过通常还会有一个“最终结果整合代理”来整合所有的结果；
11. 共享记忆模块：存储最终的结果；
12. 用户代理：从共享记忆模块读取最终的结果，展示给用户；
13. 用户代理：接收用户的反馈——比如用户说“能不能把收盘价折线图的颜色改成红色？”；
14. 用户是否满意最终的结果？：否；
15. 共享记忆模块：存储用户的反馈；
16. 任务规划代理：重新规划子任务——比如新增子任务5是“修改收盘价折线图的颜色”；
17. 任务分配代理：将子任务5分配给“可视化生成代理”；
18. 子任务执行循环：可视化生成代理完成子任务5；
19. 最终结果整合代理：整合所有的结果；
20. 用户代理：展示给用户；
21. 用户是否满意最终的结果？：是的；
22. 评估与学习模块：评估整个系统的表现，根据评估结果更新Agent的知识或策略——比如更新数据获取代理的API调用策略，更新可视化生成代理的图表生成策略；
23. 结束。

1.4 单Agent vs Multi-Agent：概念核心属性维度对比

为了更清晰地对比单Agent和Multi-Agent系统的区别，我们可以从以下10个概念核心属性维度进行对比：

维度	单Agent系统	Multi-Agent系统
智能核心数量	1个（具备独立推理和决策能力的核心模块）	≥2个（每个Agent都具备独立推理和决策能力的核心模块）
角色分工	无（所有角色都由单个智能核心承担）	有（每个Agent都有明确的角色分工，比如任务规划者、代码生成者、代码审查者）
环境属性	通常是单Agent、完全可观察、确定性、片段式、静态、离散的	通常是多Agent、部分可观察、随机性、连续式、动态、连续的
通信机制	无（只有智能核心和辅助模块之间的内部通信）	有（有明确的通信协议，Agent之间可以进行点对点通信、广播通信、组播通信）
协作机制	无（所有行动都由单个智能核心协调）	有（有明确的协作机制，比如任务分配、冲突解决、状态同步）
记忆结构	只有单个智能核心的私有记忆	既有每个Agent的私有记忆，也有所有Agent共享的公共记忆
效用函数	只有单个智能核心的效用函数（通常等价于整个系统的效用函数）	既有每个Agent的私有效用函数，也有整个系统的公共效用函数
行动选择	只考虑单个智能核心的效用函数的期望值	既要考虑每个Agent的私有效用函数的期望值，也要考虑整个系统的公共效用函数的期望值
容错能力	弱（如果单个智能核心出现故障，整个系统就会瘫痪）	强（如果某个Agent出现故障，可以将任务重新分配给其他Agent，整个系统仍然可以正常运行）
可扩展性	弱（通常只能通过升级单个智能核心的能力来扩展系统的功能，很难并行处理多个任务）	强（可以通过增加Agent的数量来扩展系统的功能，可以并行处理多个任务）

1.5 单Agent vs Multi-Agent：概念联系的ER实体关系图与交互关系图

1.5.1 概念联系的ER实体关系图

为了更直观地展示单Agent和Multi-Agent系统之间的概念联系，我们可以用一个ER实体关系图来表示：

从这个ER实体关系图中我们可以看出：

1. 单Agent和Multi-Agent组件都是Agent的一种——它们都包含感知模块、记忆模块、推理决策模块、执行模块等核心要素；
2. 单Agent系统由一个单Agent组成；
3. Multi-Agent系统由≥2个Multi-Agent组件组成——除此之外，它还包含通信协议、协作机制、共享记忆模块等特有的要素。

1.5.2 概念联系的交互关系图

为了更直观地展示单Agent和Multi-Agent系统之间的交互关系的区别，我们可以用两个mermaid交互关系图来表示：

1.5.2.1 单Agent系统的交互关系图

1.5.2.2 Multi-Agent系统的交互关系图