原文：
towardsdatascience.com/navigating-the-new-types-of-llm-agents-and-architectures-309382ce9f88?source=collection_archive---------0-----------------------#2024-08-30
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/5939b58b0944ef661493ed70b68e1810.png
图像由作者使用 Dall-E 创作
ReAct 代理的失败为新一代代理及其可能性铺平了道路
https://aparnadhinak.medium.com/?source=post_page---byline--309382ce9f88--------------------------------https://towardsdatascience.com/?source=post_page---byline--309382ce9f88-------------------------------- Aparna Dhinakaran
·发表于 Towards Data Science ·10 分钟阅读·2024 年 8 月 30 日
–
感谢 John Gilhuly 为本篇文章的贡献
如果 2023 年是检索增强生成（Retrieval Augmented Generation, RAG）的一年，那么 2024 年就是代理的年份。全球各地的公司正在尝试聊天机器人代理，像 MultiOn 这样的工具通过将代理连接到外部网站而得到发展，像 LangGraph 和 LlamaIndex Workflows 这样的框架帮助世界各地的开发人员构建结构化代理。
然而，尽管代理受到了广泛关注，但它们仍未在人工智能生态系统之外取得显著的突破。无论是消费者还是企业用户中，只有少数代理得以推广。
团队如何在新的框架和代理方向中航行？有哪些工具可用，你应该使用哪些工具来构建下一个应用程序？作为一家最近在产品中构建了一个复杂代理作为副驾驶的公司的领导者，我们对此话题有一些见解。
定义代理
首先，定义我们所说的代理是非常重要的。基于 LLM 的代理是将多个处理步骤（包括对 LLM 的调用）串联起来的软件系统，以实现期望的最终结果。代理通常具有一定的条件逻辑或决策能力，并且拥有在各步骤之间可以访问的工作记忆。
让我们深入了解今天代理的构建方式、现代代理存在的问题以及一些初步的解决方案。
ReAct 代理的失败
让我们诚实一点，智能体的概念并不新鲜。在过去一年中，AI Twitter 上推出了无数智能体，宣称具有惊人的智能表现。这些第一代智能体主要是ReAct（推理，行动）智能体。它们的设计目标是尽可能地抽象化，并承诺能带来广泛的结果。
不幸的是，第一代智能体架构确实面临了很多挑战。它们的高度抽象化使得使用起来困难，尽管它们做出了宏大的承诺，但最终它们几乎什么都做不了。
针对此情况，许多人开始重新思考智能体的结构方式。在过去的一年里，我们见证了巨大的进展，这也将我们引入了下一代智能体。
什么是第二代智能体？
这一代新的智能体建立在定义智能体可以走的路径的原则上，这些路径比 ReAct 的开放性方式更为严格。无论智能体是否使用框架，我们已经看到一种趋势，那就是智能体的解决方案空间变得更小——也就是说，每个智能体能做的事情减少了。更小的解决方案空间意味着智能体更容易定义，这通常也会导致更强大的智能体。
第二代智能体涵盖了许多不同类型的智能体，但值得注意的是，我们今天看到的大多数智能体或助手都是通过无框架的代码编写的，具有 LLM 路由阶段，并且以迭代循环的方式处理数据。
什么构成了一个智能体？
许多智能体都有一个叫做路由器的节点或组件，用来决定智能体应该执行哪个下一步。路由器通常是指由 LLM 或分类器做出的路径选择决策。智能体在执行过程中可能会不断返回这个路由器，每次都带上一些更新的信息。路由器会利用这些信息，结合它对可能的下一步的已有知识，选择接下来的行动。
路由器本身有时由对 LLM 的调用提供支持。目前大多数流行的 LLM 都支持函数调用，它们可以从函数定义的 JSON 字典中选择一个组件进行调用。这种能力使得路由步骤的初步设置变得容易。然而，正如我们稍后将看到的，路由器通常是智能体中需要最多改进的步骤，因此这种设置的简便性掩盖了其背后的复杂性。
智能体可以执行的每一个动作通常由一个组件表示。组件是完成特定小任务的代码块。这些组件可以调用 LLM，或进行多次 LLM 调用，发起内部 API 调用，或仅仅运行某种应用代码。在不同的框架中，它们有不同的名称。在 LangGraph 中，这些称为节点；在 LlamaIndex Workflows 中，它们被称为步骤。一旦组件完成任务，它可能会返回到路由器，或者转到其他决策组件。
根据代理的复杂性，将组件作为执行分支或技能进行分组可能会有所帮助。假设你有一个客户服务聊天机器人代理。这个代理能够做的事情之一是检查订单的运输状态。为了实现这一功能，代理需要从用户的查询中提取订单 ID，创建一个 API 调用到后端系统，执行该 API，解析结果，并生成回应。每一个步骤都可能是一个组件，它们可以被归类为“检查运输状态”技能。
最后，许多代理在执行过程中会追踪共享状态或记忆。这使得代理更容易在各个组件之间传递上下文。
代理架构的示例
今天我们在代理部署中看到一些常见的模式。我们将在接下来的部分中概述所有这些架构，但下面的示例可能是最常见的。
在其最简单的形式下，代理或助手可能仅由一个 LLM 路由器和一个工具调用来定义。我们将这个第一个示例称为单路由器与函数。我们有一个单一的路由器，可以是一个 LLM 调用、一个分类器调用，或仅仅是简单的代码，来指引和协调要调用哪个函数。其理念是，路由器可以根据系统的输入来决定调用哪个工具或功能。单路由器来自于我们在这个架构中只使用了一个路由器这一事实。
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/11f1778aef2eec4c137a1a670bcc2dca.png
图示由作者提供
我们看到的一个稍微复杂一些的助手是单路由器与技能。在这种情况下，路由器不再仅仅调用一个简单的工具或函数，而是可以调用一个更复杂的工作流或技能集，这些技能集可能包括多个组件，是一系列更深的链式动作。这些组件（LLM、API、工具、RAG 和代码调用）可以被循环和链式连接，以形成一个技能。
这可能是目前我们看到的最常见的生产环境中高级 LLM 应用团队使用的架构。
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/75fe8804f273eab573708fd0d9f133ca.png
图示由作者提供
一般架构通过将 LLM 调用、工具和状态的分支混合在一起，变得更加复杂。在这个案例中，路由器决定调用其哪些技能（用红色标注）来回答用户的问题。它还可能根据这个问题更新共享状态。每个技能也可以访问共享状态，并可能涉及一个或多个 LLM 调用，以获取对用户的回应。
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/eeaa1ebe2277c41c4e42f3e33f2e536c.png
图示由作者提供
这通常仍然比较简单，然而，代理通常要复杂得多。随着代理变得更加复杂，你会开始看到一些框架被构建出来，以帮助降低这种复杂性。
代理架构框架
LangGraph
LangGraph 基于预先存在的 Pregel 图概念，但将其转化为代理。在 LangGraph 中，你定义代理可以沿着其移动的节点和边缘。虽然在 LangGraph 中定义一个路由节点是可能的，但除非你正在处理多代理应用，否则通常是不必要的。相反，原本可以在路由器中存在的相同条件逻辑现在存在于 LangGraph 引入的节点和条件边缘对象中。
这是一个 LangGraph 代理的示例，它可以回应用户的问候，或者执行某种 RAG 信息查找：
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/862a65a67f7fcea3ce139a3442f0dea2.png
图示由作者提供
在这里，路由逻辑实际上存在于节点和条件边缘中，这些边缘根据函数响应决定是否在不同节点之间移动用户。在这个例子中，is_greeting和check_rag_response是条件边缘。定义其中一个边缘如下所示：
graph.add_conditional_edges("classify_input",is_greeting,{True:"handle_greeting",False:"handle_RAG"})我们不是将所有的路由逻辑集中在一个节点中，而是将它分布在相关的边缘之间。这在你需要为代理强加一个预定义结构，并且希望将各个逻辑部分分开时特别有用。
LlamaIndex 工作流
像 LlamaIndex 工作流 这样的其他框架采用不同的方法，使用事件和事件监听器在节点之间移动。与 LangGraph 类似，工作流不一定需要一个路由节点来处理代理的条件逻辑。相反，工作流依赖于各个节点，或者它们称之为“步骤”，来处理传入事件，并广播传出的事件，以便其他步骤处理。这导致大多数工作流逻辑都在每个步骤内部处理，而不是在步骤和节点之间处理。
https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/51e53013177ba3f241d11757c1882504.png
作为 LlamaIndex 工作流的反射型 SQL 生成代理（图示由作者提供）
CrewAI、Autogen、Swarm 等
还有其他框架旨在简化代理开发，其中包括一些专注于处理多个代理协同工作的框架。这个领域发展迅速，值得查看这些及其他框架。
考虑代理时的关键问题
是否应该使用框架来开发你的代理？
无论你使用什么框架，这些工具提供的额外结构都能帮助你构建代理应用。使用这些框架是否对创建更大、更复杂的应用有益是一个更具挑战性的问题。
我们在这一领域有一个相当强烈的观点，因为我们自己也构建了一个助手。我们的助手使用多层路由架构，具有与当前框架的一些抽象概念相呼应的分支和步骤。在 LangGraph 稳定之前，我们就开始构建我们的助手。因此，我们不断自问：如果我们从零开始，我们会使用当前的框架抽象吗？它们能胜任这一任务吗？
当前的回答是“尚不需要”。整体系统的复杂性太大，不适合基于 Pregel 的架构。如果你眯着眼睛看，可以将其映射为节点和边，但软件抽象可能会阻碍这一点。就目前而言，我们团队更倾向于使用代码而非框架。
然而，我们确实看到了代理框架方法的价值。也就是说，它确实强制执行了一种架构，这种架构具有一些最佳实践和良好的工具。它们也在不断进步，扩展它们的适用范围以及你可以用它们做什么。随着这些框架的改进，我们的回答很可能在不久的将来会发生变化。
你真的需要一个代理吗？
这引出了另一个重要问题：究竟什么类型的应用程序需要代理？毕竟，代理涵盖了广泛的系统 —— 而且如今关于什么是“代理化”的话题也充满了炒作。
这里有三个标准来判断你是否可能需要代理：
你的应用程序是否基于输入数据遵循迭代流？
你的应用程序是否需要根据先前采取的行动或途中反馈来调整并遵循不同的流程？
是否存在可以采取的行动的状态空间？该状态空间可以通过多种方式遍历，而不仅仅限于线性路径。
需要预期的常见问题有哪些？
假设你对其中一个问题回答是肯定的，并且需要一个代理。以下是你在构建时需要注意的几个已知问题。
第一个是长期规划。虽然代理很强大，但它们在将复杂任务分解为逻辑计划方面仍然存在困难。更糟的是，它们常常会陷入循环，无法找到解决方案。代理还在格式不正确的工具调用方面存在困难。这通常是由于驱动代理的底层 LLM 所致。在每种情况下，通常需要人工干预来纠正方向。
另一个需要注意的问题是由于解决方案空间的广阔而导致的性能不一致。代理可以采取的可能行动和路径的数量庞大，使得难以实现一致的结果，并且往往推高成本。也许正因为如此，市场正在趋向于受限代理，只能从一组可能的行动中进行选择，有效地限制了解决方案空间。
应对这些挑战的一些策略是什么？
如前所述，最有效的策略之一是事先映射或缩小解决方案空间。通过彻底定义可能的行动和结果范围，你可以减少模糊性。将领域和业务启发式融入代理的指导系统也是一个简单且有效的方法，它为代理提供了做出更好决策所需的背景。明确行动意图（清晰定义每个行动的目的）并创建可重复的过程（标准化代理遵循的步骤和方法）也能增强可靠性，并在出现错误时更容易识别和纠正。
最后，通过代码和更可靠的方法进行协调，而不是仅仅依赖于 LLM 规划，可以显著提高代理的性能。这涉及到在可能的情况下用基于代码的路由器替代 LLM 路由器。通过使用基于代码的协调，你可以实现更确定性和可控的过程，减少常伴 LLM 规划的不可预测性。
结论
在充满 FOMO 的新框架和狂热生成式 AI 环境中，过度炒作的情况下，很容易忽视基本问题。在全力投入 MVP 之前，花时间思考现代代理框架在何时何地可能适合——或不适合——你的使用场景，始终是值得的。
有问题吗？欢迎在此联系我或在 Slack 上，或者在我们每两周一次的AI 研究论文阅读会中找到我。
