检索密集型应用的Agent（智能体）架构基础知识、模式和示例

且。

江湖人称麻花滕

1024人浏览 · 2025-03-04 11:52:02

江湖人称麻花滕 · 2025-03-04 11:52:02 发布

人工智能的发展格局正随着AI Agent（智能体）的出现而发生深刻变革。随着我们超越传统的编程范式，AI Agent代表了一个全新的前沿领域，使AI系统更加智能、自主和强大。

本文将全面解析agent架构，特别是在检索密集型应用中的应用。无论你是构建单个agent系统，还是协调复杂的多agent网络，本文探讨的原则和模式都将为你的agent架构之旅奠定坚实的基础。

AI Agent的组成部分

尽管AI Agent旨在实现自主决策，但其正常运行依赖于更大的组件框架。这一框架被称为Agent的架构，包括以下关键要素：

大语言模型（LLM）：AI agent通常基于LLM，并赋予其特定的任务和角色，使其能够进行有效的推理。推理使AI Agent能够在问题解决过程中主动“思考”。在Agent架构中，推理主要承担两项关键功能：
规划（Planning）：Agent将复杂任务分解为更小的步骤，并选择合适的工具来执行。
反思（Reflecting）：Agent评估任务的执行结果，并根据结果和外部数据不断调整优化其方法。
工具（Tools）：辅助Agent完成任务的外部工具，扩展了AI Agent的能力，使其超越原始数据集的知识范围，并能够动态地与外部资源、应用程序、实时数据或其他计算资源交互。这些工具被用于执行特定任务，例如：
网页搜索
从外部数据库检索数据
读取或发送电子邮件
记忆（Memory）：使Agent能够从过去的经验中学习，从而不断优化自身行为。换句话说记忆使AI Agent能够在多次交互和会话中捕获并存储上下文和反馈。
短期记忆（Short-term Memory）用于存储即时信息，如对话历史，帮助Agent确定下一步行动，以完成整体目标。
长期记忆（Long-term Memory）存储随时间积累的信息和知识，使Agent能够进行个性化调整，并随着时间推移不断提升其性能。

记忆使AI Agent能够在多次交互和会话中捕获并存储上下文和反馈。

短期记忆（Short-term Memory）用于存储即时信息，如对话历史，帮助Agent确定下一步行动，以完成整体目标。
长期记忆（Long-term Memory）存储随时间积累的信息和知识，使Agent能够进行个性化调整，并随着时间推移不断提升其性能。

工具（Tools）扩展了AI Agent的能力，使其超越原始数据集的知识范围，并能够动态地与外部资源、应用程序、实时数据或其他计算资源交互。这些工具被用于执行特定任务，例如：

网页搜索
从外部数据库检索数据
读取或发送电子邮件

这些功能帮助AI Agent更有效地完成其目标任务。

AI Agent的组成部分

尽管AI Agent旨在实现自主决策，但其正常运行依赖于更大的组件框架。这一框架被称为Agent的架构，包括以下关键要素：

大语言模型（LLM）：AI agent通常基于LLM，并赋予其特定的任务和角色，使其能够进行有效的推理。推理使AI Agent能够在问题解决过程中主动“思考”。在Agent架构中，推理主要承担两项关键功能：
规划（Planning）：Agent将复杂任务分解为更小的步骤，并选择合适的工具来执行。
反思（Reflecting）：Agent评估任务的执行结果，并根据结果和外部数据不断调整优化其方法。
工具（Tools）：辅助Agent完成任务的外部工具，扩展了AI Agent的能力，使其超越原始数据集的知识范围，并能够动态地与外部资源、应用程序、实时数据或其他计算资源交互。这些工具被用于执行特定任务，例如：
网页搜索
从外部数据库检索数据
读取或发送电子邮件
记忆（Memory）：使Agent能够从过去的经验中学习，从而不断优化自身行为。换句话说记忆使AI Agent能够在多次交互和会话中捕获并存储上下文和反馈。
短期记忆（Short-term Memory）用于存储即时信息，如对话历史，帮助Agent确定下一步行动，以完成整体目标。
长期记忆（Long-term Memory）存储随时间积累的信息和知识，使Agent能够进行个性化调整，并随着时间推移不断提升其性能。

Agent架构中的向量数据库

在Agent架构中，向量数据库可以用于不同的目的。

1. 作为Agent的工具（Tools）

向量数据库最常见的用途是作为RAG流程中的工具。在这种情况下，Agent使用一个定制的搜索工具，该工具连接到向量数据库。向量数据库作为外部知识源，存储用户自有的非结构化数据，如文本或图像。

Agent可以调用搜索工具，在连接的向量数据库中执行向量搜索、混合搜索或关键词搜索，从而检索相关信息。在Agent驱动的RAG流程中，AI Agent从外部知识源中获取信息，并利用这些信息回答用户查询。

2. 作为Agent的记忆（Memory）

向量数据库也可用于Agent的记忆存储。将过去交互的信息存储在向量数据库中，使Agent能够通过语义检索（Semantic Retrieval）回忆和利用历史信息，从而增强其长期记忆和智能交互能力。

单Agent vs. 多Agent架构

Agent AI系统通常使用LLM作为核心决策引擎，并配备一系列工具。在单Agent架构中，LLM会在运行过程中评估某个工具是否有助于解决（部分）查询，并决定是否调用该工具。

然而，在某些情况下，初始化多个Agent来分别负责不同的任务组是更合理的，这被称为多Agent架构（Multi-Agent Architecture）。在这种架构下，通常仍然会有一个主要Agent（LLM）负责统筹整个流程，即主Agent（Main Agent）。

选择单Agent还是多Agent架构取决于具体的使用场景以及Agent所需执行任务的复杂性。

单Agent架构

单Agent架构只有一个AI Agent，能够独立处理任务。

优势

复杂度较低，因此更容易开发和管理。
无需协调多个Agent，简化系统架构。
可能比多个低性能Agent更节省计算资源，只需一个高性能Agent即可完成任务。

劣势

可能难以处理复杂或动态变化的任务。
在需要协作或涉及多种专业知识的任务中能力有限。
如果Agent可用的工具种类过多，可能会混淆，导致错误的工具调用参数。
可能需要更大、更昂贵的模型来处理多个推理步骤。

多Agent架构

有多个AI Agent协作解决任务。

请注意，在多Agent架构中，每个Agent都配备了自己的记忆。但你也可以为整个组合式Agent架构提供共享记忆。

优势

能够处理复杂和动态任务。
具备并行处理能力，提高执行效率。
可以使用更小、更专业化的模型来处理特定任务，提高性能与资源利用率。

劣势

由于多个Agent需要协作，系统复杂度增加。
需要强大的机制来管理Agent之间的交互。
由于架构更复杂，调试和优化更具挑战性。
随着Agent数量增加，系统可能需要更多计算资源。

如何选择合适的架构？

正如所见，单Agent和多Agent架构各有优缺点：

单Agent架构适用于任务简单、定义明确，且资源限制不严格的场景。
多Agent架构适用于复杂和动态的任务，需要更专业的知识和协作能力，或对可扩展性和适应性有更高要求的应用。

多Agent系统中的模式

顾名思义，多Agent系统由多个Agent协同工作来解决复杂任务。这些系统可以采用不同的设计模式进行结构化，每种模式都有其优缺点。

这些模式是原子化的，并且可以组合使用，这意味着你可以设计一个多Agent系统，其中同时包含路由（router）、循环（loop）和并行（parallel）等不同的模式。

如果这些模式对你来说似曾相识，那是因为它们并不是全新的概念。我们借鉴了软件工程等其他领域的组件连接模式，因此，本节内容仅作为对可能模式的回顾。

并行

多个Agent同时在任务的不同部分上工作。

顺序

任务按顺序处理，一个Agent的输出成为下一个Agent的输入。示例：多步骤审批。

循环

Agent在迭代周期中操作，基于其他Agent的反馈不断改进其输出。示例：评估类应用场景，如代码编写和代码测试。

路由器

一个中央路由器根据任务或输入决定调用哪个Agent。

聚合器或合成器

多个Agent的输出被一个聚合器Agent收集并合成，形成最终结果。

网络或横向

Agent之间以多对多的方式直接进行通信，形成去中心化的网络。

优点

分布式协作和群体驱动的决策制定。
即使部分Agent失败，系统仍然可以正常运行。

缺点

管理Agent之间的通信可能会变得具有挑战性。
更多的通信可能导致效率低下，并可能导致Agent重复努力。

层级或纵向

Agent按照树状结构组织，高层Agent（监督Agent）管理低层Agent。

优点

在不同层级的Agent之间有明确的角色和职责划分。
简化的通信流程。
适用于具有结构化决策流的大型系统。

缺点

上层Agent的故障可能会破坏整个系统。
低层Agent的独立性有限。

Agent架构示例

本节讨论了几种Agent化RAG工作流架构的示例。整体架构取决于你的应用场景需求。

对于较简单的应用场景，单Agent路由器架构可能足够，而对于更复杂的应用场景，可能需要一个具有专业化Agent的多Agent架构。

重新审视简单的RAG架构

在深入探讨适用于检索密集型应用场景的各种Agent架构之前，让我们先回顾一下简单的RAG架构，以便提醒我们其局限性。

简单的（非Agent化的）RAG架构通常由一个嵌入模型、一个向量数据库和一个生成型LLM组成。这种非Agent化的简单方法是一种单次处理的解决方案，它直接使用用户查询来检索额外信息，然后将检索到的信息直接用于提示中。

虽然简单方法的优点在于其简洁性，但也存在很多错误的可能性：

原始的用户查询在没有进一步处理的情况下，可能不适用于向量搜索，因为有时重新表述或使用元数据过滤器可以帮助提高检索性能。此外，某些用户查询较为复杂，可能需要拆解成更小的查询来提高处理效果。
没有验证步骤来确定检索到的信息是否与用户查询相关。
信息只被检索一次。

单Agent架构

在单Agent的RAG架构中，一个多功能Agent负责检索所需的信息，并根据这些信息生成响应。

下图展示了一个示例的Agent化工作流程，展示了这个多功能Agent如何检索额外信息，以生成更为事实性和准确的答案。

正如你所看到的，通用RAG Agent的大部分工作流程都围绕着改进检索。因此，在某些使用案例中，定义具有专门任务和角色的特定Agent可能更有意义，这样它们可以加速执行。

例如，你可以定义一个专门用于从外部知识源检索信息的Agent（查询Agent），该Agent专注于查询分解、查询路由、查询转换和评估。

多Agent架构

尽管单Agent架构克服了传统RAG工作流的静态局限性，但它仍然仅限于一个Agent，且该Agent负责推理、检索和生成答案。

拥有一个多功能Agent可能会导致性能下降，尤其是在Agent任务过于广泛且不够明确时。因此，我们在上一页讨论过，通过定义任务较小且更明确的Agent，可以帮助它们在特定角色上表现出色，例如将多功能Agent拆分为一个专门用于检索的查询Agent和一个根据检索到的信息生成答案的Agent。

如果你的使用案例更复杂，将多个Agent串联成一个多Agent架构可能是有益的。例如，如果你的使用案例需要多个工具或具有专门子任务的专门Agent。

现在，事情变得有趣了，因为在多Agent架构中，Agent之间的串联有无穷的可能性。本节并不打算列出详尽无遗的清单。相反，本节展示了架构及其考虑因素的示例，以便你可以开始构建适合你特定使用案例的架构。

层级示例

让我们从一个简单的层级架构开始，其中有一个主管代理负责协调多个专门的Agent。

例如，你可以拥有一个主管Agent，它负责协调多个专门Agent之间的信息检索，这些Agent负责从外部知识源查询信息（查询Agent）：

一个Agent可以从专有的内部数据源中检索信息，另一个Agent也可以专门负责从网络搜索中检索公开信息，而第三个Agent则专门从个人账户中检索信息，如电子邮件或Slack聊天记录。

通过为每个查询Agent分配专门的任务，你可以增加每个Agent在其任务中表现出色的机会，并且只为它提供所需的工具。此外，你还可以限制对某些敏感数据工具的访问，以确保数据安全，例如在使用API调用个人账户时，如电子邮件、日历或聊天消息。

人类参与的示例

如果你不想让Agent访问敏感信息，例如员工的个人电子邮件、日历或聊天消息，你可以构建一个人类参与的架构。在这种情况下，你可以使用一个专门的Agent，在执行下一步操作之前请求人类输入。

共享工具示例

另一方面，根据你的使用案例，拥有不同的Agent共享相同的工具也可能是有帮助的。例如，如果你的Agent需要访问中央用户信息，那么为它们提供一个可以查询中央数据库的搜索工具可能是必要的。

顺序示例

到目前为止，我们只看了层级多Agent架构，但如果不需要监督Agent，你也可以选择网络（或横向）架构模式。

上面你可以看到一个横向架构模式的示例，包含三个顺序执行的Agent：

第一个查询Agent通过调用向量搜索工具，根据用户输入检索信息。
然后，第二个查询Agent基于用户输入和第一个查询Agent检索到的信息，通过调用网络搜索工具来检索额外的信息。
最后，第三个生成Agent根据用户输入、来自向量搜索的信息和来自网络搜索的信息生成响应。

将两个独立的查询Agent按顺序连接在一起，当两个Agent使用不同的工具且第二个Agent基于第一个Agent的输入执行操作时，这种结构是有用的。

共享数据库与不同工具的示例

数据库中的数据并不总是干净、组织良好或分离得很好。历史上，这些问题通常由数据库管理员或专门负责质量和数据丰富的团队来解决，他们需要支持庞大而复杂的管道来修改或创建新的数据视图。

但是，如果你可以通过一个AI Agent来替代这些工作，让它在插入时转换用户数据和/或在规模化的情况下转换现有的数据呢？这个Agent的任务是将现有数据转化为丰富的用户数据，提供复杂的数据分析，并将不可搜索的数据转换为可搜索的格式。

例如，假设你有客户评价并且希望添加一些属性。你可以让Agent生成一个新的属性，以便以后能够更好地对这些属性进行筛选。或者，你可以生成一款产品的所有现有评价的摘要。

为了适应这种数据转换，你可以引入一个数据转换Agent，如下所示。这个Agent与查询数据库的Agent不同，它将使用数据转换工具来访问与查询数据库的Agent相同的数据库。

通过工具使用进行记忆转化

由于过去的互动可以存储在充当记忆的向量数据库中，数据转换Agent也可以应用于记忆。这在你想要例如总结过去的互动时非常有用。你可以总结最近五次互动，或者总结关于某个特定话题讨论的内容。

总结

本文介绍了智能架构。讨论了作为基础构建块的组件以及可以组合成整体架构的底层模式。

根据你的使用案例的复杂性，我们首先讨论了单Agent架构与多Agent架构的优缺点。如果任务相对简单，单一Agent方法通常是最佳选择。然而，对于更复杂的任务，多Agent架构提供了更好的质量和灵活性。

接下来，我们探讨了一些常见的多Agent架构设计模式以及每种模式的优缺点。我们还看了一些面向检索密集型系统的智能架构示例，以及如何通过单一Agent设置来克服简单RAG的局限性。然而，这种方法可能是有限制的，因为推理、检索和答案生成仅限于单个Agent。为了改进这一点，将Agent划分为更小、明确的任务有助于它们在特定角色中表现出色。最后，我们讨论了一个设计用于在插入时转换用户数据的AI Agent，同时能够大规模转换现有集合。

正如你所看到的，构建智能架构有很多不同的方法。本文仅涉及了几个示例，但可能性是无限的。本文中讨论的示例仅是一个起点，让你大致了解划分独立Agent的思考过程，并了解将单一Agent连接成整体架构时需要考虑的因素。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述