一、什么是单智能体和多智能体

1.1、单智能体系统

单智能体系统由一个 LLM、一组工具和提示词组成的系统。

其更像一个独立的专业人士，它是独立运行的，依靠自身的逻辑和模型来完成任务，无需团队合作，它自行收集数据，做出决策并执行行动

对于智能体（Agent）的定义，每个人或者每个团队都有自己的不同的理解

LangGraph 团队对于智能体的定义是：

An AI agent is a system that uses an LLM to decide the control flow of an application.
AI 代理是一个使用 LLM 来决定应用程序控制流的系统。

llya Sutskever 在NeurIPS 2024 上的演讲中提到

目前的AI系统还不能真正理解和推理，虽然它们能模拟人类的直觉，但未来的AI将会在推理和决策方面展现出更加不可预测的能力。

1.2、多智能体系统

多智能体系统由多个更小的，独立的智能体来协作式的处理复杂的任务。

其更像一个高效运转的团队，而不是一个单独的行动者，它不依赖一个智能体来做所有的事情，而是将多个智能体聚集在一起，每个智能体负责问题的一部分，这些智能体相互交流、协作、并能实时适应变化

二、多智能体的架构设计

Excalidraw 文件：

目前最常用的是两种架构设计：群体(swarm)和监督者（supervisor）

• 监督者（协调者-工作者模式）：多个智能体由一个中控监督者智能体协调，监督者智能体控制和所有智能体之间的通信和任务委派，根据当前上下文和任务需求决定调用哪一个智能体
• 群体（工作者群体模式）：多个智能体根据它们自己的特长来动态的相互交接控制权，系统记住最后活跃的智能体，确保在后续智能体交互中，上下文可以正常从智能体开始

还有其他两种不常有的设计模式，但是可以作为参考方案

1. 层级化(Hierarchical)设计模式：是监督者模式的拓展和延伸，每一个群体都定义一个上级管理者，每一个上级管理者都有一个最终的总管理者，像正常中型公司一样的层级化，每一个团队都有一个主管，每个主管都需要向部门经理汇报
2. 自定义多智能体工作流(Custome multi-agent workflow)：每个智能体只与一部分智能体通信，流程的部分是确定的，只有某些智能体可以决定下一步的调用哪些其他智能体

✏️ 这里做一点补充理解，以上是目前可以使用到的多智能体的架构设计模式，但是其实还会有更多的模式出现，这些都可能会从自定义的工作流设计模式中成熟之后出现新的设计模式，大家不要拘束于这几种已知的设计模式，建议多多探索

三、单智能体和多智能体的区别

Excalidraw 文件：https://gcntfv628ebr.feishu.cn/file/CEUgbVu6KoVZJex523acbOHMnZc

在使用多智能体架构时，会出现一些“短板“问题

• 主智能体与子智能体的上下文中断
• 子智能体 B 与子智能体 A 的上下文中断

3.1、主智能体与子智能体上下文中断

主智能体与子智能体的上下文中断，在执行顺序是前后执行的时候，也就是主智能体先执行，子智能体再执行，当主子智能体分配子智能体执行任务之后，子智能体是新开的一个上下文窗口，这个情况下主与子智能体的上下文是中断的，原因是架构设计上没有考虑去传递上下文

这种情况是有解决方法的，只要再分配任务给子智能体的时候，提供一些关键的主智能体的上下文就可以

但是这里面依旧有一个致命的问题，这个问题是并行执行导致的上下文隔离，子智能体 A 无法知道子智能体 B 在做什么，以此我们出现的第二个问题

3.2、子智能体 B 与子智能体 A 的上下文中断

在上文中，我们可以看到，子智能体 A 和子智能体 B 有自己独立的上下文执行空间，如果这个时候有这种情况出现呢？

我们有一个文档生成的任务，因为文档内容过多和类型繁杂，我们需要分智能体去生成，分领域的去生成，子智能体 A 生成绘画领域内容文档，子智能体 B 生成音乐领域内容的文档，这个是采用提示词专业化去生成，这个生成出来的内容会更好一些，但是最终的结果可能会出现，

1. 格式不统一：子智能体 A 生成的格式是MarkDown，子智能体 B 生成的是 HTML 格式的，最终会因为格式不统一导致合并书写失败
2. 内容侧重点完全不同：子智能体 A 生成的内容和子智能体 B 生成的内容在角度上完全不同，导致的内容不连贵，非常的割裂，最终也不方便合并书写

这种情况是并行导致的问题，目前是在架构不变的情况下，是没有比较好的解决方案的

可要是更换为单智能体的架构设计，所有的问题就迎刃而解了

3.3、单智能体与多智能体的上下文管理

经过上文的两种实际应用场景的讨论，我们可以知道单智能体和多智能体存在的关键差异：

在多智能体的架构设计中，其协调复杂性是会迅速增长的，这会导致上下文的管理带来更多的挑战

但是单智能体可以不用在“上下文管理协调”上面花费过多的心思，单智能体天然的上下文结合，不会产生隔离

那我们现在来总结一下单智能体与多智能体的区别有哪些

1. 上下文管理：单智能体的上下文连贵，多智能体会在子智能体并行执行的情况下导致上下文隔离
2. 执行协调：单智能体不需要执行协调，只要按照任务顺序执行即可，多智能体最有难度的是需要协调多个子智能体的执行
3. 技术开发：单智能体因为架构简单，开发难度比多智能体要低很多，开发能力有限的团队可以优先考虑单智能体，但是对于开发中的维护和测试，多智能体比单智能体有优势，因为多智能体更贴合“模块化”开发

一、单智能体的优势

🌟🌟** 当需要智能体共享上下文或者智能体间大量互相依赖，这种情况下，单智能体是最合适的**

单智能体的开发成本和难度会比较低，不用花费大量的心思在上下文管理方面，大部分情况下只需要配合一个上下文压缩的策略就可以，开发单智能体重要是如何收集上下文和收集哪些上下文

✏️ 我建议如果你不是完全确定要开发多智能体，那就开发单智能体，先从简单开发，只在需要时增加复杂性

单智能体在“写入”操作的任务中比多智能体有更大的优势，可以避免很多开发负担

这里有一个例子可以看看

2024 年，许多模型在编辑代码方面表现很差。编码代理、IDE、应用构建器等（包括 Devin）普遍采用“编辑应用模型”的常见做法。其核心思想是，给定想要进行的更改的 Markdown 说明，让一个小模型重写整个文件，实际上比让大模型输出格式正确的 diff 更可靠。因此，构建者让大模型输出代码编辑的 Markdown 说明，然后将这些 Markdown 说明输入给小模型以实际重写文件。然而，这些系统仍然存在很多错误。例如，小模型经常误解大模型的指令，由于指令中最细微的歧义而做出错误的编辑。如今，编辑决策和执行通常由单个模型在一个动作中完成

五、多智能体的优势

🌟🌟 多智能体系统擅长涉及大量并行化、超出单个上下文窗口的信息以及与众多复杂工具交互的有价值任务。

5.1、多智能体“读”操作的优势

多智能体在“读取”的操作上面比单智能体有更大的优势，目前最合适的场景是研究任务的场景

研究任务的本质是：在研究调查的过程中具有转向或探索支连接的灵活性，研究中最重要的就是搜索

而搜索的本质是压缩，从庞大的语料库中提炼有效的见解

有一个类比可以考虑：集体可以比个人有更大的能力，能做更多的事情，但集体也比个人需要更强的协调管理能力，当单智能体达到智能阈值的时候，多智能体系统可以成为一种扩展性能的重要方式

在这个多智能体系统中，协调者负责任务的分配和协调，那么这个时候子智能体在执行搜索的过程中会有两个好处

1. 多个子智能体能够提供更多的可能性和思路，还有不同的见解
2. 子智能体因为上下文窗口充足和隔离，可以同时追求多个独立方向的前序查询

在这个研究搜索任务的多智能体中，其实最关键的其实就是协调者，所以对于协调者需要更强的模型能力，Claude 的解决方法是

Claude团队发现在使用Claude Opus4为领导智能体，Claude Sonnet4为子智能体的多智能体系统，会比单智能体Claude Opus4表现高出90.2%

5.2、多智能体在复杂工具交互有价值

在上下文管理的文章中有提到，上下文混淆会导致模型在工具的选择执行上面，效果大大减低

最近的一篇论文中，评估了小型模型在 GeoEngine 基准测试中的表现，该测试包含 46 种不同的工具。当团队给一个量化（压缩）的 Llama 3.1 8b 模型提供包含所有 46 种工具的查询时，尽管上下文完全在 16k 上下文窗口内，它却失败了。但当团队只给模型 19 种工具时，它就成功了。

在《RAG MCP》论文中也提到过一点：

在提示 DeepSeek-v3 时，团队发现当工具数量超过 30 个时，选择合适的工具变得至关重要。超过 30 个后，工具的描述开始重叠，造成混淆。超过 100 个工具时，模型几乎肯定会失败测试。使用 RAG 技术选择少于 30 个工具，可以显著缩短提示长度，并使工具选择准确率提高 3 倍。

多智能体系统，可以进行上下文隔离，为特定领域和任务类型的子智能体提供符合要求的工具，这样多智能体系统可以利用多个子智能体来同时消化复杂的工具配置

这样每一个智能体拿到的工具数量是不多的，在工具的选择执行中，成功率会大大提升

5.3、多智能体系统改善方法

在使用多智能体系统来开发的时候，会在出现以下的问题

• 将简单的查询复杂化，为一个简单的查询生成 50 个子代理
• 无休止的搜索不存在的来源
• 代理之间频繁互相更新，导致信息互相干扰过多
• 多智能体的 Token 消耗成本是会比单智能高 3-4 倍
• ......

其实上面的问题都是因为协调复杂性上升导致的，我们可以使用下面的方法来改善

1、 像你的智能体一样思考，借助调试平台，仔细观察智能体的每一步的决策，像调试程序一下，发现逻辑跑偏的地方，以此优化相应的提示词

2、 协调者在分派任务的时候子任务的描述要足够的清晰，每一个子代理都需要如下的关键信息一个目、输出格式、使用工具、来源指导

3、 使用提示词中的规则来指导协调者根据查询的复杂度调整工作规模，

• 简单的查询：一个智能体，3-10次的工具调用
• 中等的查询：2-4个智能体，10-15次的工具调用
• 复杂的查询：10个以上的智能体，不限制工具调用

4、 重视工具的设计和选择，这里有提供工具给 LLM 时遵循一套明确的参考方案

• 首先检查所有可用工具
• 将工具使用与用户意图匹配
• 选择合适的探索路径：是“通用搜索”还是“专业搜索”

5、 使用智能体来进行自我改进，可以让智能体从失败的输出中来改进提示词，也可以从工具的调用错误中来改进工具的描述

6、 在研究搜索任务中，让智能体从宽泛开始，然后逐步聚焦，这个可以使用提示词来控制，这个策略是参考专家级人类研究：先探索整体格局，再深入具体细节

7、 指导思考（推理）过程，在提示词中：

1. 主代理可以指导思考的方向：
   1. 评估哪些工具适合任务
   2. 确定查询复杂性和子代理数量
   3. 并定义每个子代理的角色
2. 子代理可以指导思考的方向：
   1. 交错思考来评估质量
   2. 识别差距并优化下一个查询

8、 并行调用工具提升速度和性能

六、智能体的渐进式构建策略

Excalidraw 文件：https://gcntfv628ebr.feishu.cn/file/HETNbc5dkoECO9xMqlfcdvoxnth

我觉得合理的智能体策略是：先构建小模块单智能体 -> 再构建多智能体 -> 最后升级为完整单智能体

1. 我们在开发智能体的初期，根据开发成本和开发阶段来先选择单智能体的开发，先构建原型和小模块
2. 当单一模块构建的单智能体生效时，我们可以为系统中更多的节点开发单智能体，这样在该系统中逐渐构建出来了多智能体系统，由多个单智能体有向组成的多智能体系统
3. 当系统中许多模块被单智能体有效替代，并且整个系统中的各个子智能体有机的结合在一起组成多智能体系统，这个时候就可以将该系统升级为完整的单智能体

而这种构建方式的核心理念：从简单到复杂，从局部到整体的逐步迭代优化

第一步：我们的系统核心主要由循环和判断的逻辑构成的，根据业务会有多个不同的模块逻辑流通

第二步：我们开始挑选部分代码逻辑模块构建成为单智能体运行

第三步：我们发现单智能体模块和系统一起运行良好，于是我们构建更多的单智能体模块组装多智能体系统

第四步：最终我们将多智能体系统完整构建成为一个单智能体来运行，以此来提高系统运行效率和移植性

我们选择先构建小模块的智能体的优势：

1. 易于管理的上下文：较小的上下文窗口意味更好的 LLM 性能
2. 明确的职责：每个代理都有清晰的范围和目的
3. 更高的可靠性：在复杂业务中迷失的可能性更小
4. 测试更简单：更易于测试和验证特定功能
5. 调试更高效：容易找到和识别问题

这种构建的方式也合理的利用了技术迭代的思路：当 LLM 变得更加智能，对于我们的构建方向没有很大的影响，反而可以加快我们的构建迭代速度同时显著的提高系统的效果，因为智能体的核心 LLM 变得更加可靠了

我们的构建思路和方式：在代理的大小和范围上保持合理的意图，并且只在能够保持质量的方式下扩展，正如 Notebook 团队说的

I feel like consistently, the most magical moments out of AI building come about for me when I'm really, really, really just close to the edge of the model capability

我觉得在 AI 构建中，最神奇的时刻总是出现在我非常接近模型能力极限的时候

无论这个边界在哪里，如果你能找到这个边界并始终正确地把握它，你就能构建出神奇体验。这里有很多需要构建的护城河，但和往常一样，它们需要一定的工程严谨性。