探索新一代大模型代理（LLM agent）及其架构

在人工智能大模型(AI)的浪潮中，2023年我们见证了检索增强生成(Retrieval Augmented Generation, RAG)的兴起，而2024年则无疑成为了“代理”agent的元年。各大AI企业纷纷投身于聊天机器人代理的研发中，工具如MultiOn通过与外部网站的连接实现了快速增长，而框架如LangGraph和LlamaIndex Workflows则助力全球开发者构建结构化的代理应用。然而，尽管代理在AI生态系统中备受瞩目，它们却仍未能在消费者或企业用户实际业务场景中掀起波澜。今天我们一起来探索一下新一代的大模型代理及其架构。

大模型代理(llm agent)的基础概念

首先，让我们明确什么是大模型代理(llm agent)。基于LLM的代理是软件系统，它们通过串联多个处理步骤，包括LLM调用，api调用，方法调用等等以实现期望的最终结果。这些大模型代理通常包含一定量的条件逻辑或决策能力，以及在执行步骤间可访问的工作内存。了解代理的构建方式、当前面临的问题及初步解决方案，对于我们导航新框架和代理发展方向至关重要。

ReAct代理的失败与反思

回顾过去，代理的概念并非新鲜事物。去年，AI领域的社交媒体上涌现了大量声称具备惊人智能能力的ReAct(reason, act)代理。然而，这些第一代代理大多以高度的抽象化设计著称，尽管承诺广泛的结果，但实际上却难以使用且效果有限。

ReAct代理的失败促使人们开始重新思考代理的结构。过去一年中，我们见证了巨大的进步，引领我们进入第二代代理的时代。新一代代理以更严格的方式定义了代理可能采取的路径，从而避免了ReAct代理开放式设计的缺陷。这种趋势趋向于缩小解空间，即每个代理能够执行的任务范围，虽然限制了多样性，但通常能打造出更强大、更易定义的代理。

第二代大模型代理（llm agent）的核心特征

第二代代理在多个方面展现出显著的特征。首先，它们往往采用LLM路由，并在迭代循环中处理数据。许多代理包含一个名为“路由器(router)”的节点或组件，负责决定下一步应该采取的行动。router可能是由LLM或分类器等驱动的，它们根据输入信息选择执行路径。

每个行动通常由一个组件表示，这些组件是完成特定小任务的代码块，可能调用LLM、执行内部API调用或运行应用程序代码。在LangGraph中，这些组件被称为节点;而在LlamaIndex Workflows中，它们则被称为步骤。一旦组件完成其工作，它可能返回路由器或移动到其他决策组件。

无论大模型代理是否使用框架，我们都看到了解决方案空间越来越小的趋势——也就是说每个代理可以做的事情越来越少。解决方案空间越小，代理就越容易定义，这通常会使代理更强大。

大模型代理的架构模式

代理的部署通常遵循一些常见的架构模式。最简单的形式可能仅包括一个LLM路由器和一个工具调用，我们称之为“单一路由器与功能”架构。在这种架构中，路由器根据系统输入决定调用哪个工具或功能。

稍微复杂的架构则是“单一路由器与功能集”，其中路由器调用的不再是简单的工具或函数调用，而是更复杂的工作流程或功能集，这些可能包含多个组件和深度链接的动作链。

更高级的架构则将LLM调用与工具和状态混合，形成复杂的分支结构。路由器根据用户问题调用不同的功能，每个功能可能更新共享状态，并可能涉及一个或多个LLM调用来生成用户响应。

为了应对代理的复杂性，出现了如LangGraph和LlamaIndex Workflows等框架，它们旨在通过提供结构化的方式来简化代理开发。LangGraph基于Pregel图的概念，定义了节点和边，使代理能够沿其移动。而在LlamaIndex Workflows中，则使用事件和事件监听器来在不同节点间移动。

大模型代理的一些思考

是否应使用框架开发大模型代理

在决定是否使用大模型代理框架来开发代理时，我们需要权衡其提供的额外结构与复杂性之间的平衡。对于大型、复杂的大模型代理应用，大模型代理框架提供的结构和最佳实践可以大大降低开发难度。然而，对于高度定制化或特定需求的代理，直接使用代码可能更为灵活。

以我们一个项目为例，我们在开发自己的代理时采用了多层路由器架构，虽然我们没有直接使用LangGraph等框架，但我们的设计在一定程度上借鉴了它们的抽象概念。我们发现，对于当前的项目需求而言，直接使用代码比依赖框架更为高效。然而，我们也认识到随着框架的不断完善，未来可能会考虑采用这些框架来加速开发进程。