Agent（智能体）架构（三）Agent架构示例

企业开发 2025-04-08 06:59:39 阅读次数: 0

四、Agent架构示例

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

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

1、重新审视简单的RAG架构

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

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

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

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

2、单Agent架构

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

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

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

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

3、多Agent架构

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

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

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

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

4、层级示例

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

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

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

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

5、人类参与的示例

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

6、共享工具示例

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

7、顺序示例

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

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

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

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

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

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

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

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

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

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

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

五、总结

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

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

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

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