智能体(AI Agents)是人工智能领域的重要发展方向,它们能够通过传感器感知环境并通过执行器对环境采取行动。根据罗素和诺维格在《人工智能:一种现代方法》(2016年)中的定义,AI Agent是任何可以通过传感器感知其环境并通过执行器对环境采取行动的东西。
智能体与环境互动通常包括几个重要组件:
这个框架适用于所有与各种环境互动的代理,比如与物理环境互动的机器人或与软件互动的AI Agents。
使用"增强型"LLM,Agent可以通过文本输入观察环境,并通过使用工具执行某些行动。为了选择要采取哪些行动,LLM Agent有一个关键组件:它的计划能力。为此,LLM需要能够通过链式思考等方法进行"推理"和"思考"。
利用这种推理行为,LLM Agent将计划出要采取的必要行动。这种计划行为使Agent能够理解情况(LLM)、计划下一步(计划)、采取行动(工具)并跟踪已采取的行动(记忆)。
根据系统,你可以拥有不同程度自主性的LLM Agents。一个系统越"agentic",LLM就越能决定系统的行动方式。
参考链接:硬核,AI Agents全栈技术框架综述与未来
参考链接:Anthropic CPO万字专访:不再只做模型!后悔没有更早做第一方产品
参考链接:Deep ReSearch
LLM Agent的三个主要组件包括:
LLM是健忘的系统,或者更准确地说,在与它们互动时,它们根本不进行任何记忆。例如,当你问LLM一个问题,然后又接着问另一个问题时,它不会记得前者。
我们通常将其称为短期记忆,也称为工作记忆,它作为(近乎)即时上下文的缓冲区。这包括LLM代理最近采取的行动。
实现短期记忆最直接的方法是使用模型的上下文窗口,这本质上是LLM可以处理的token数量。较大的上下文窗口可以用来跟踪完整的对话历史,作为输入提示的一部分。对于上下文窗口较小的模型,或者当对话历史较大时,可以改用另一个LLM来总结到目前为止发生的对话。
LLM代理还需要跟踪可能多达数十步的行动,而不仅仅是最近的行动。这被称为长期记忆,因为LLM代理理论上可能需要记住多达数十步甚至数百步。
LLM Agents的长期记忆包括需要长期保留的Agents过去的行动空间。实现长期记忆的一个常见技术是将所有之前的互动、行动和对话存储在一个外部向量数据库中。在构建数据库之后,可以通过RAG方式检索相关信息。
参考链接:对话记忆架构详解
对话记忆(chatmemory)会话id先取InMemoryChatMemory,不存在时从数据库获取,并写入至InMemoryChatMemory**
工具允许给定的LLM要么与外部环境(如数据库)互动,要么使用外部应用程序(如运行自定义代码)。工具通常有两种用例:获取数据以检索最新信息和采取行动,比如安排会议或点餐。
要实际使用一个工具,LLM必须生成适合给定工具的API的文本。我们通常期望的是可以格式化为JSON的字符串,以便可以轻松地输入到代码解释器中。
工具使用是一种强大的技术,可以增强LLM的能力并弥补它们的不足。因此,关于工具使用和学习的研究在过去几年中迅速增加。最早实现这一目标的技术之一被称为Toolformer,这是一个训练用于决定调用哪些API以及如何调用的模型。
参考链接:Manus的技术实现原理浅析与简单复刻
工具使用使LLM能够增强其能力。它们通常通过类似JSON的请求调用。但是,LLM在具代理性的系统中如何决定使用哪个工具以及何时使用呢?这就是计划的作用。
LLM代理中的计划涉及将给定任务分解为可操作的步骤。
在LLM中启用推理行为很好,但并不一定使其能够规划可操作的步骤。到目前为止关注的技术要么展示推理行为,要么通过工具与环境互动。例如,链式思考纯粹关注推理。
将这两个过程结合起来的最早技术之一被称为ReAct(推理与行动)。ReAct通过精心设计的提示来实现这一点。ReAct提示描述了三个步骤:
LLM使用这个提示来引导其行为以循环的方式进行思考、行动和观察。
没有人,即使是具有ReAct的LLM,也并非每个任务都能完美完成。失败是过程的一部分,只要你能反思这个过程就行。这个过程在ReAct中缺失,而Reflexion正是填补这一空白的地方,利用verbal reinforcement帮助代理从之前的失败中学习的技术。
假设了三个LLM角色:
单智能体系统是智能体开发的基础框架,适用于相对简单的任务场景。
Multi-Agent系统解决了Single-Agent存在的几个问题:工具太多可能会使选择复杂化,上下文变得过于复杂,任务可能需要专业化。
Multi-Agent系统通常由专业化的代理组成,每个Agent都配备了自己的一套工具,并由一个主管监督。主管管理Agent之间的通信,并可以为专业化的代理分配特定的任务。每个Agent可能有不同的工具类型可用,也可能有不同的记忆系统。
在实践中,有几十种Multi-Agent架构,其核心有两个组成部分:
可以说最具影响力且坦率地说非常酷的多代理论文之一是"Generative agents: Interactive simulacra of human behavior"。创建了可以模拟可信人类行为的计算软件代理,他们将其称为生成性代理。
每个生成性代理被赋予的档案使它们以独特的方式行事,并有助于创造更有趣和动态的行为。每个Agent都用三个模块(记忆、计划和反思)初始化,非常类似于我们之前看到的ReAct和Reflexion的核心组件。它们共同允许代理自由地进行行为并相互互动。因此,Agent之间几乎没有协调,因为它们没有特定的目标需要努力实现。
无论你选择哪种框架来创建Multi-Agent系统,它们通常由几个要素组成,包括其档案、对环境的感知、记忆、计划和可用行动。流行框架是AutoGen、MetaGPT和CAMEL。每个框架在Agent之间的通信方式上略有不同。但归根结底,它们都依赖于这种协作性的沟通。Agent有机会相互交流,以更新它们的当前状态、目标和下一步行动。
最近几周,这些框架的增长呈爆炸式增长。2025年将是令人兴奋的一年,AI Agents将迎来更多的落地,什么时候入局AI Agents都不晚!
参考链接:主流多智能体框架设计原理
参考链接:DeepSeek + Function Call:基于Eino的"计划------执行"多智能体范式实战
参考链接:有没有复杂任务自动化的Multi-Agent框架?用Nexus,几行YAML搞定数据清洗
参考链接:智能体工作流开源项目大盘点,20个项目轻松构建Agentic Workflow
Dify(发音:deifai)是一个低代码应用开发平台,专注于AI应用开发。
参考链接:如何用AI搭建自己的数字员工?Dify保姆级教程!
Open-WebUI提供了灵活的界面来快速测试和比较不同模型,特别适合在研究环境中工作。
环境要求:conda py311
启动命令:open-webui serve
Server-Sent Events(SSE)是一种基于HTTP协议的单向通信技术,允许服务器向客户端推送实时更新。SSE通过保持HTTP连接并持续发送数据来实现实时通信,适用于需要频繁更新但不需要客户端频繁响应的场景。
SSE基于HTTP协议,使用的是标准的HTTP请求和响应。客户端通过发送一个普通的HTTP请求来订阅服务器的事件流,服务器则通过保持这个连接并持续发送数据来实现实时更新。
在GPT场景中,SSE可以用于实现实时对话生成、实时文本生成和实时状态更新等功能。例如,在聊天机器人或对话系统中,使用SSE可以实现服务器向客户端推送实时生成的对话内容,用户可以在对话过程中实时看到生成的回复。
参考链接:大模型推理主战场:什么才是通信协议标配?
参考链接:SSE技术详解
在智能体系统中,通常定义三种角色:
参考链接:ChatGPT角色系统详解
system(系统角色):代表系统的,一般用于设立AI的功能,"system"角色指示了ChatGPT在对话消息中应该具有哪种个性。虽然传递带有系统角色的消息并非必需,但它有助于在内部为对话设置模型行为。
user(用户角色):代表用户,指示消息/提示来自最终用户或人类。
assistant(助手角色):代表AI模型,响应最终用户提示的实体。这个角色表示消息是助手(聊天模型)的响应。"assistant"角色用于在当前请求中设置模型的先前响应,以保持对话的连贯性。
对话记忆是智能体系统中的重要组成部分,用于维护对话的连续性和上下文信息。
模型上下文协议(Model Context Protocol,MCP)是Anthropic开发的标准,用于简化工具在智能体框架中的实现。
工具是具代理性框架的重要组成部分,允许LLM与世界互动并扩展其能力。然而,当你有许多不同的API时,启用工具使用变得很麻烦,因为任何工具都需要:
MCP为天气应用和GitHub等服务标准化了API访问。它由三个组件组成:
假设你希望某个LLM应用程序总结你仓库中的最新5次提交。MCP主机(与客户端一起)将首先调用MCP服务器,询问有哪些工具可用。LLM收到信息后,可能会选择使用某个工具。它通过主机向MCP服务器发送请求,然后接收结果,包括所使用的工具。最后,LLM收到结果,并可以向用户解析答案。
参考链接:awesome-mcp-clients
参考链接:awesome-mcp-servers
参考链接:7000字详解火爆全网的Claude模型上下文协议(MCP)
参考链接:MCP协议从原理到开发:一文读懂大模型交互的标准化革命!
参考链接:MCP实现AI应用架构新范式转型
参考链接:阿里MCP相关文章
参考链接:Nacos 3.0正式发布:MCP Registry、安全零信任、链接更多生态