如今 未来 大模型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可以采取的或许执行和门路数量庞大，因此很难取得分歧的结果，并且往往让老本变高。所以目前都偏差于受限智能体，它们只能从一组或许的执行中启动选用，从而有效地限度了处置方案的空间。

本文转载自​​，作者：