探索新型 LLM 代理和架构

如果说 2023 年是检索增强生成之年，那么 2024 年则是代理之年。世界各地的公司都在尝试使用聊天机器人代理，MultiOn 等工具通过将代理连接到外部网站而不断发展，而 LangGraph 和 LlamaIndex Workflows 等框架正在帮助世界各地的开发人员构建结构化代理。

然而，尽管代理很受欢迎，但它尚未在人工智能生态系统之外引起强烈反响。无论是消费者用户还是企业用户，很少有代理能够流行起来。

团队如何驾驭新框架和新代理方向？有哪些工具可用，您应该使用哪些工具来构建下一个应用程序？作为一家公司（该公司最近构建了自己的复杂代理作为我们产品中的副驾驶）的领导者，我们对这个话题有一些见解。

定义代理

首先，它有助于定义我们所说的代理。基于 LLM 的代理是将多个处理步骤（包括对 LLM 的调用）串联在一起以实现所需的最终结果的软件系统。代理通常具有一定数量的条件逻辑或决策能力，以及它们可以在步骤之间访问的工作内存。

让我们深入了解当今代理的构建方式、现代代理的当前问题以及一些初步解决方案。

ReAct 代理商的失败

说实话，代理的概念并不新鲜。去年，AI Twitter 上推出了无数代理，声称它们拥有惊人的智能。第一代主要是ReAct（推理、行动）代理。它们被设计成尽可能抽象，并承诺实现一系列广泛的结果。

不幸的是，第一代代理架构确实存在问题。它们的抽象性太强，难以使用，尽管它们做出了很大的承诺，但最终却没有什么实际作用。

对此，许多人开始重新思考代理的结构。在过去的一年里，我们看到了巨大的进步，现在正引领我们进入下一代代理。

什么是二代特工？

新一代代理建立在以更为严格的方式定义代理可能采取的路径的原则之上，而不是 ReAct 的开放性。无论代理是否使用框架，我们都看到了解决方案空间越来越小的趋势——也就是说每个代理可以做的事情越来越少。解决方案空间越小，代理就越容易定义，这通常会使代理更强大。

第二代涵盖了许多不同类型的代理，但值得注意的是，我们今天看到的大多数代理或助手都是用没有框架的代码编写的，具有 LLM 路由器阶段，并以迭代循环处理数据。

代理人由什么组成？

许多代理都有一个称为路由器的节点或组件，它决定代理下一步应采取什么步骤。术语“路由器”通常指 LLM 或分类器，它决定要采取什么路径。代理在执行过程中可能会不断返回此路由器，每次都会带来一些更新的信息。路由器将获取该信息，将其与现有的可能后续步骤知识相结合，然后选择要采取的下一步行动。

路由器本身有时由对 LLM 的调用驱动。目前，大多数流行的 LLM 都支持函数调用，它们可以从 JSON 函数定义字典中选择一个组件进行调用。此功能使路由步骤的初始设置变得简单。然而，正如我们稍后会看到的那样，路由器通常是代理中最需要改进的步骤，因此这种设置的简易性可能会掩盖其表面下的复杂性。

代理可以采取的每个操作通常由一个组件表示。组件是完成特定小任务的代码块。这些可以调用 LLM，或进行多个 LLM 调用，进行内部 API 调用，或者只是运行某种应用程序代码。它们在不同的框架中使用不同的名称。在 LangGraph 中，这些是节点。在 LlamaIndex 工作流中，它们被称为步骤。一旦组件完成其工作，它可能会返回到路由器，或移动到其他决策组件。

根据代理的复杂程度，将组件分组为执行分支或技能会很有帮助。假设您有一个客户服务聊天机器人代理。此代理可以做的事情之一是检查订单的发货状态。要从功能上做到这一点，代理需要从用户的查询中提取订单 ID，创建对后端系统的 API 调用，制作该 API，解析结果并生成响应。这些步骤中的每一个都可以是一个组件，它们可以分组到“检查发货状态”技能中。

最后，许多代理在执行时会跟踪共享状态或内存。这使得代理能够更轻松地在各个组件之间传递上下文。

代理架构示例

如今，我们在代理部署中看到了一些常见模式。我们将在下文中概述所有这些架构，但以下示例可能是最常见的。

最简单的代理或助手可能仅使用 LLM 路由器和工具调用来定义。我们将第一个例子称为具有功能的单个路由器。我们有一个路由器，它可以是 LLM 调用、分类器调用或只是纯代码，它指示和协调要调用哪个函数。这个想法是路由器可以根据系统的输入决定调用哪个工具或功能调用。单个路由器的出现源于我们在此架构中仅使用 1 个路由器这一事实。

作者绘制的图表

我们看到的稍微复杂一点的助手是具有技能的单个路由器。在这种情况下，路由器不是调用简单的工具或函数调用，而是调用更复杂的工作流或技能集，这些工作流或技能集可能包含许多组件，并且是一组总体更深层次的链式操作。这些组件（LLM、API、工具、RAG 和代码调用）可以循环和链接以形成技能。

这可能是我们现在看到的高级 LLM 应用团队在生产中最常见的架构。

作者绘制的图表

通过将 LLM 调用的分支与工具和状态混合，一般架构变得更加复杂。在下一种情况下，路由器决定调用其哪些技能（用红色表示）来回答用户的问题。它还可以根据这个问题更新共享状态。每个技能也可以访问共享状态，并且可以涉及一个或多个自己的 LLM 调用来检索对用户的响应。

作者绘制的图表

这通常还是很简单的，但是代理通常要复杂得多。随着代理变得越来越复杂，您开始看到构建框架以尝试降低这种复杂性。

代理架构框架

语言图谱

LangGraph 以 Pregel 图的现有概念为基础，但将其转换为代理。在 LangGraph 中，您可以定义代理可以沿其行进的节点和边。虽然可以在 LangGraph 中定义路由器节点，但除非您使用的是多代理应用程序，否则通常没有必要这样做。相反，路由器中可能存在的相同条件逻辑现在存在于 LangGraph 引入的节点和条件边对象中。

下面是一个 LangGraph 代理的示例，它既可以响应用户的问候，也可以执行某种 RAG 信息查找：

作者绘制的图表

在这里，路由逻辑存在于节点和条件边中，这些节点和条件边根据函数响应选择将用户在不同节点之间移动。在本例中，is_greeting和check_rag_response是条件边。定义其中一个边如下所示：

graph.add_conditional_edges（“classify_input”，is_greeting，{ True：“handle_greeting”，False：“handle_RAG” }）

我们不是将所有路由逻辑都集中在一个节点中，而是将其分散到相关边缘之间。这很有用，尤其是当您需要在代理上施加预定义的结构，并希望将各个逻辑部分分开时。

LlamaIndex 工作流程

其他框架（如LlamaIndex Workflows）采用了不同的方法，而是使用事件和事件侦听器在节点之间移动。与 LangGraph 一样，Workflows 不一定需要路由节点来处理代理的条件逻辑。相反，Workflows 依靠单个节点（或它们所称的步骤）来处理传入事件，并广播传出事件以供其他步骤处理。这导致大多数 Workflows 逻辑在每个步骤中处理，而不是在步骤和节点中处理。

反射式 SQL 生成代理作为 LlamaIndex 工作流（作者绘制的图表）

CrewAI、Autogen、Swarm 等

还有其他框架旨在简化代理开发，包括一些专门处理代理组协同工作的框架。这个领域正在快速发展，值得研究这些框架和其他框架。

考虑代理时的关键问题

您应该使用框架来开发您的代理吗？

无论您使用哪种框架，这些工具提供的附加结构都有助于构建代理应用程序。在创建更大、更复杂的应用程序时，使用这些框架是否有益是一个更具挑战性的问题。

我们对此有相当强烈的意见，因为我们自己构建了一个助手。我们的助手使用多层路由器架构，其分支和步骤与当前框架的一些抽象相呼应。我们在 LangGraph 稳定之前就开始构建我们的助手。因此，我们不断问自己：如果我们从头开始，我们会使用当前的框架抽象吗？它们能胜任这项任务吗？

目前的答案是还没有。整个系统太复杂了，不适合基于 Pregel 的架构。如果你仔细想想，你可以将其映射到节点和边缘，但软件抽象可能会妨碍它。就目前而言，我们的团队倾向于使用代码而不是框架。

然而，我们确实看到了代理框架方法的价值。也就是说，它确实强制采用具有一些最佳实践和良好工具的架构。它们也在不断改进，扩大了它们的实用性和可用功能。随着这些框架的改进，我们的答案很可能在不久的将来发生变化。

您确实需要经纪人吗？

这就引出了另一个重要问题：哪些类型的应用程序需要代理？毕竟，代理涵盖了广泛的系统——如今人们对“代理”一词的炒作如此之多。

以下三个标准可以帮助您确定是否需要代理：

• 您的应用程序是否遵循基于传入数据的迭代流程？
• 您的应用程序是否需要根据先前采取的操作或反馈来调整并遵循不同的流程？
• 是否存在可以采取的行动状态空间？状态空间可以以各种方式遍历，而不仅限于线性路径。

预计会出现哪些常见问题？

假设您对其中一个问题的回答是肯定的，并且需要代理。以下是您在构建时需要注意的几个已知问题。

首先是长期规划。虽然代理功能强大，但它们仍然难以将复杂的任务分解为合理的计划。更糟糕的是，它们经常会陷入循环，无法找到解决方案。代理还会遇到格式错误的工具调用问题。这通常是由于底层 LLM 为代理提供支持。在每种情况下，通常都需要人工干预来纠正路线。

另一个需要注意的问题是由于解决方案空间巨大而导致的性能不一致。代理可以采取的可能操作和路径数量之多使得实现一致的结果变得困难，并且往往会推高成本。也许这就是为什么市场倾向于只能从一组可能的操作中进行选择的受限代理，从而有效地限制了解决方案空间。

应对这些挑战有哪些策略？

如上所述，最有效的策略之一是预先映射或缩小解决方案空间。通过彻底定义可能的操作和结果的范围，您可以减少歧义。将领域和业务启发式方法纳入代理的指导系统也是一种轻松的方法，为代理提供了做出更好决策所需的背景。明确行动意图（明确定义每个行动旨在实现的目标）和创建可重复的流程（标准化代理遵循的步骤和方法）也可以提高可靠性，并使在发生错误时更容易识别和纠正错误。

最后，使用代码和更可靠的方法进行编排，而不是仅仅依赖 LLM 规划，可以显著提高代理性能。这涉及在可能的情况下将 LLM 路由器换成基于代码的路由器。通过使用基于代码的编排，您可以实现更具确定性和可控性的流程，并减少基于 LLM 的规划通常带来的不可预测性。

结论

在充满 FOMO 的疯狂生成式 AI 环境中，炒作如此之多，新框架层出不穷，人们很容易忽视基本问题。在一头扎进 MVP 之前，花点时间思考一下现代代理框架何时何地可能（或可能不）适合您的用例，这总是值得的。