💡 Agent可以理解为某种能自主理解、规划决策、执行复杂任务的智能体。Agent 是让 LLM 具备目标实现的能力,并通过自我激励循环来实现这个目标。它可以是并行的(同时使用多个提示,试图解决同一个目标)和单向的(无需人类参与对话)。
Agent = LLM+Planning+Feedback+Tool use
决策流程:感知(Perception)→ 规划(Planning)→ 行动(Action)
Agent创建一个目标或主任务后,主要分为以下三个步骤:
- 获取第一个未完成的任务
- 收集中间结果并储存到向量数据库中
- 创建新的任务,并重新设置任务列表的优先级
AI Agent主流框架
1. 微软的Jarvis
step1: 规划:利用好LLM 的推理规划能力,对用户输入进行任务拆解;
step2: 决策:利用LLM的决策能力,判断每个拆解的子任务,我们可以用什么方案解决
step3: 行动:通过决策得出的推荐工具(API,model,插件)去解决每个问题
step4: 总结输出最终解决方案和结果给用户
缺点:需要频繁调用LLM,token数量巨大带来高昂成本
2 微软的promptFlow
step1: 任务拆分,可以是人工拆分,也可以是LLM拆分,自定义~
反正从输入到输出就是一个任务流。我们只需要定义好每个步骤的输入和输出是什么。
step2: 每个task使用LLM去决策如何执行,也可以人工实现逻辑,也可以使用成熟插件,自定义~
step3:总结输出给用户
整个思路就是每个步骤都可控,输入,输出以及f(x)是什么都是我自己定义,我们通过评估使用LLM或者按传统思路实现逻辑,都很灵活。最好这个任务流可以可视化,方便我们理清思路。
3. Langchain
Langchain也是AI Agenthttps://github.com/langchain-ai/langchain。langchain开发的初衷是让开发者能够快速的构建一个LLM原型应用。Langchain主要组件有:
Models:模型,各个类型的LLM模型集成,比如GPT-4
Prompts:提示,在提示词中引入变量以适应用户输入,包括提示模版管理,优化和序列化。
Memory:记忆,用来保存模型交互的上下文
Indexes:索引,用来结构化文档,外挂知识库就是索引的一个功能应用
Chains:链, 对模型的一系列组件工具的链式调用,以上一个输出为下一个输入的一部分。
Agents: 代理,决定模型采取哪些行动,应该选哪个工具,执行并观察流程
Multi-Agent:多个Agent共享一部分记忆,自主分工相互协作。
对于Langchain我们用的最多的就是利用他进行外挂知识库,但是这其实知识Indexes这个组件的应用,Langchain的功能远不止此;其中Chains的思路其实就是promptFlow;Agents里面的AgentAction就是Jarvis的思路。
缺点:Langchain才是功能和工具最齐全的框架,但是Langchain功能太多,导致整个框架太重,极其不灵活;大家通常只用他的一个组件功能
相关案例
斯坦福的虚拟小镇
代码已开源:https://github.com/joonspk-research/generative_agents
一个agent就是一个虚拟人物,25个agents之间的故事
架构
记忆(Memory)
短期记忆:在上下文中(prompt)学习。它是短暂有限的,因为它受到Transformer的上下文窗口长度的限制。
长期记忆:代理在查询时可以注意到的外部向量存储,可以通过快速检索访问。
反思(Reflection)
反思是由代理生成的更高级别、更抽象的思考。因为反思也是一种记忆,所以在检索时,它们会与其他观察结果一起被包含在内。反思是周期性生成的;当代理感知到的最新事件的重要性评分之和超过一定阈值时,就会生成反思。
- 让代理确定要反思什么
- 生成的问题作为检索的查询
计划(Plan)
计划是为了做更长时间的规划。像反思一样,计划也被储存在记忆流中(第三种记忆),并被包含在检索过程中。这使得代理能够在决定如何行动时,同时考虑观察、反思和计划。如果需要,代理可能在中途改变他们的计划(即响应,reacting)。
Huggingface:Transformers Agents 发布
它在 Transformers 的基础上提供了一个自然语言 API,来 “让 Transformers 可以做任何事情”。
这其中有两个概念:一个是 Agent (代理),另一个是 Tools (工具),我们定义了一系列默认的工具,让代理去理解自然语言并使用这些工具。
- 代理:这里指的是大语言模型 (LLM),你可以选择使用 OpenAI 的模型 (需要提供密钥),或者开源的 StarCoder 和 OpenAssistant 的模型,我们会提示让代理去访问一组特定的工具。
- 工具:指的是一个个单一的功能,我们定义了一系列工具,然后使用这些工具的描述来提示代理,并展示它将如何利用工具来执行查询中请求的内容。
目前在 transformers 中集成的工具 包括:文档问答、文本问答、图片配文、图片问答、图像分割、语音转文本、文本转语音、零样本文本分类、文本摘要、翻译等。
总结
观点1:Agent特点
- Agent本身是类似于DM的升级版,能够充分利用对环境的感知,进行决策规划,充分调用LLM的能力。
- 私有化部署时,集成到企业工作流中,面临的边际成本很难降低,且没有通用性。
- Agent需要调用外部工具,调用工具最好的方式就是输出类Makedown代码
由LLM大脑输出一种可执行的代码,像是一个语义分析器,由它理解每句话的含义,然后将其转换成一种机器指令,再去调用外部的工具来执行或生成答案。尽管现在的 Function Call 形式还有待改进,但是这种调用工具的方式是非常必要的,是解决幻觉问题的最彻底的手段。
观点2:Agent落地的瓶颈
Agent本身用到两部分能力,一部分是由LLM作为其“智商”或“大脑”的部分,另一部分是基于LLM,其外部需要有一个控制器,由它去完成各种Prompt,如通过检索增强Memory,从环境获得Feedback,怎样做Reflection等。
Agent既需要大脑,也要外部支撑
- LLM本身的问题:自身的“智商”不够,可进行LLM升级为GPT-5;Prompt的方式不对,问题要无歧义。
- 外部工具:系统化程度不够,需要调用外部的工具系统,这是一个长期待解决的问题。
通用AGI:现阶段Agent的落地,除了LLM本身足够通用之外,也需要实现一个通用的外部逻辑框架。不只是“智商”问题,还需要如何借助外部工具,从专用抵达通用——而这是更重要的问题。
解决特定场景的特定问题:将LLM作为一个通用大脑,通过Prompt设计为不同的角色,以完成专用的任务,而非普适性的应用。但是面临的关键问题,即Feedback将成为Agent落地实现的一大制约因素,对于复杂的Tools应用,成功概率会很低。
观点3:多模态在Agent的发展
多模态只能解决Agent感知上的问题,而无法解决认知的问题。
多模态是必然趋势,未来的大模型必然是多模态的大模型,未来的Agent也一定是多模态世界中的Agent。
观点4:Agent从专用到通用的实现路径
假设Agent最终将落地于100种不同的环境,在目前连最简单的外部应用都难以实现的前提下,最终能否抽象出一个框架模型来解决所有外部通用性问题?
先将某一场景下的Agent做到极致——足够稳定且鲁棒,再逐步将它变成通用框架,也许这是实现通用Agent的路径之一。。