大模型Agent的过去、现在、未来

嘿，大家好！这里是一个专注于AI智能体的频道！

今天跟大家聊一些关于Agent发展的事情。如果说去年是RAG的元年，大家都在naive RAG中添加各种技巧，使其变成Adavanced RAG。今年应该就是Agent的元年，年初RAG的迭代变成了Agentic RAG的发展方向，上半年Agent、Agentic、workflow等名词的爆火。当然后来到年终，RAG炒作到了RAG2.0、GraphRAG等上面，最近的RAG炒作变成了MemoryRAG，或者RAG已死等等相关的~

尽管智能体Agent很热门，但它们真的很难，很少有Agent能够在消费者或企业用户中取得成功。

Agent的定义：基于LLM的Agent是将多个处理步骤（包括对LLMs的调用）串联在一起的系统，以实现所需的最终结果。Agent通常具有一定量的条件逻辑或决策能力，以及他们可以在步骤之间访问的长短期记忆。

初代Agent：Agent的想法其实蛮早的，去年外网上经常能看到Agent的身影，表示他们的系统有多牛掰。初代的Agent主要是基于ReAct的架构，这个架构比较抽象，完全由引擎LLM来主导。引擎做出决策，工具调用完的结果回到引擎。他这种非常非常极端的抽象，导致他很难落地使用。尽管理论很美好，但是现实击垮了理想。

一年中，无数的人，企业再探索下一代Agent是什么？一个新的构建原则是，用更清晰的方式定义出业务流程，定义出可能的路径。而不是ReAct的那种完全的开放性。

不论是否使用外部的Agent框架，我们可以看到整个解决方案空间变小的一个趋势，也就是说每个Agent可以做的事情更少了，也就意味着更容易定义出Agent。反过来这种模式能产生更强大的Agent。

Agent的组成形式：大多数的Agent都有一个路由-Route的模块/组件，用于决定agent下一步应采取的步骤。通常用LLM或分类器来充当，它对要采取的路径做出意图判断。 agent在执行过程中可能会不断返回到该路由组件，每次都会带来一些更新的信息。路由将获取该信息，将其与可能的后续步骤的现有知识相结合，并选择下一步要采取的操作。

Agent采取的后续操作通常由一个组件来表示，组件可能是一个代码块。可能会调用多次LLM，甚至是一个复杂的业务流程。

最简单的Agent形式，我们只有一个路由，决定调用哪个工具或函数，循环迭代。

高级的Agent, 路由的调用不在是一个简单的工具或函数了，可能包含更复杂的组件，更深层次的链式调用。这是目前生产场景下最常见的形式。

如果将LLM调用的分支，工具，状态混在一起，结构会变得更加的复杂。下图，路由决定调用哪些技能来回答用户的问题。它也可能根据这个问题更新共享状态。每项技能还可以访问共享状态，并且可能进行一个或多个LLM调用实现对用户的回复。

最后几个问题：

应该使用框架来开发Agent吗？例如langgraph、llamaindex

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

目前的答案还没有。整个系统过于复杂，不适合基于 Pregel 的架构。如果你粗看，可以将它映射到节点和边缘，但软件抽象可能会妨碍整体的开发。就目前情况而言，我们更倾向于更喜欢代码实现而不是框架。

然而，我们也看到了agent框架方法的价值。它们也在不断变得更好，扩大它们的用处以及可以用它们做什么。随着这些框架的改进，我们未来可能会进行迁移。

你真的需要Agent吗？哪些类型的应用需要Agent？

常见的有3个标准：

• 应用是否是基于输入数据，然后进行迭代的流程？
• 应用是否需要根据之前采取的操作或反馈，来适应和遵循不同的流程？
• 是否存在可以采取的行动的状态空间？状态空间可以通过多种方式遍历，而不仅仅限于线性路径。

构建Agent，可能会面临哪些问题？

首先是长远的规划。尽管理想中的Agent很强大，但他们仍然难以将复杂的任务分解为逻辑计划。更难的是，他们还会陷入循环，阻碍他们找到解决方案。另外一个常见的就是工具调用时候的格式错误。这些通常是因为LLM的能力限制，可能还需要一定的人工干预来纠正方向。

另一个需要注意的问题是由于解决方案空间巨大而导致性能问题。 agent可以采取的可能行动和路径数量庞大，因此很难获得一致的结果，并且往往让成本变高。所以目前都倾向于受限智能体，它们只能从一组可能的行动中进行选择，从而有效地限制了解决方案的空间。

本文转载自 ​​探索AGI​​，作者： 猕猴桃