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

最新推荐文章于 2025-04-07 23:06:00 发布

程序员鑫港

最新推荐文章于 2025-04-07 23:06:00 发布

阅读量1.2k

点赞数 31

文章标签：架构人工智能机器学习开源 langchain 爬虫

本文链接：https://blog.csdn.net/a2875254060/article/details/144431649

版权

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

前排提示，文末有大模型AGI-CSDN独家资料包哦！

大模型代理(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等框架，但我们的设计在一定程度上借鉴了它们的抽象概念。我们发现，对于当前的项目需求而言，直接使用代码比依赖框架更为高效。然而，我们也认识到随着框架的不断完善，未来可能会考虑采用这些框架来加速开发进程。

你真的需要大模型代理吗?

在决定构建大模型代理之前，我们首先需要明确代理的适用场景。如果你的应用遵循基于输入数据的迭代流程，需要根据先前的行动或反馈进行调整，或者存在一个可遍历的状态空间，那么代理可能是一个很好的选择。

然而，代理并非万能的解决方案。它们在复杂任务分解、长期规划和性能一致性方面仍面临挑战。为了克服这些挑战，我们需要采用一系列策略，如缩小解空间、引入领域和业务启发式、明确行动意图和创建可重复的过程等等，真是落地还需要很多实际业务场景的探索

使用大模型代理常见问题及可能的解决方案

问题：

1.长期规划难题：Agent在分解复杂任务和避免陷入循环方面存在困难，常需人类干预。

2.不一致的性能：由于解决空间的庞大，Agent难以实现一致结果，且成本高昂。市场倾向于使用受限Agent以限制解决空间。

可能的应对策略 ：

1、缩小解决空间：通过预先定义可能的行动和结果范围来减少不确定性。2、引入业务逻辑：将领域和业务启发式融入Agent的决策系统中，提升决策质量。

3、明确行动意图和标准化流程：清晰定义每个行动的目的，标准化执行步骤，增强可靠性和可纠错性。

4、代码化编排：使用代码替代LLM进行编排，提高过程的确定性和可控性。

在一项新技术火热崛起之时，大家很容易盲目跟风忽视其本质问题，这时候花点时间思考一下大模型代理框架何时何地可能(或可能不)适合您的业务场景，这个思考是必要的也是值得的。