重新回来聊Agent,前四章的LLM Agent,不论是和数据库和模型还是和搜索引擎交互,更多还是大模型和人之间的交互。这一章我们来唠唠只有大模型智能体的世界!分别介绍斯坦福小镇和Chatdev两篇论文。它们的共同特点是使用多个大模型智能体协同完成任务。
多智能相比单一智能体可能有以下的应用场景
- 协同任务完成/创意生成:通过多智能体间的沟通,反思,校验,完成复杂任务,激发创意的小火花
- 模拟世界:多智能体模拟社会环境,现实应用是游戏NPC,脑洞再大一点是不是可以用于社会学研究,因果推断,平行世界模拟??
生活番:Generative Agents
- Generative Agents: Interactive Simulacra of Human Behavior
- https://github.com/joonspk-research/generative_agents
斯坦福小镇算是这几个月来看到的最有意思的大模型应用了,作者设计了虚拟的小镇环境,并在其中设计众多不同性格的虚拟智能体,完全基于LLM的生成能力,让众多AI们在小镇中开始了生活,思考和互动。
生活环境和经历塑造了每一个个体,AI也不例外,所以后面的介绍我们会围绕以下三个核心组件相关代码来展开
- 沙盒环境: 描述AI们的生存环境,并让AI感知当前所处环境,并随AI行动更新环境状态
- 智能体框架
- 行为规划:智能体每一步行为的生成
- 记忆流: 智能体历史记忆的存储
在以上组件的加持下,小镇中的智能体们会发生以下基础行为
- 智能体行为:智能体根据当前状态和历史经历,决定下一步是吃饭睡觉还是打豆豆
- 智能体互动:智能体间的互动通过交流或指令进行,当智能体处于同一环境中时可能会触发交流对话
- 智能体和环境交互:智能体行为会改变环境状态,例如智能体睡觉时,环境中床的状态就会变成“Occupied”。当然我们也可以直接修改环境状态
- 智能体规划:想要触发以上1和2的行为和互动,智能体肯定不能在小镇里随机游走。论文的实现是让智能每天都生成一天的Todo List,根据计划行动,并在行动中不断更新当日计划。
- 智能体自我思考:通过对历史经历的不断总结和反思得到更高级层次的自我思考,从而影响日常智能体的行为
- 其他衍生能力:信息在智能体之间传播,多智能体合作,etc
沙盒环境
这里我们把沙盒环境放到第一个部分,因为个人感觉如何定义环境,决定了
- Perceive:智能体能接收到哪些环境信息
- Action:智能体可以做出哪些行为,包括在当前位置行为,和位置移动
- Influence: 行为可以对环境产生哪些影响
- 地图(maze.py)
环境本身被抽象成一个二维矩阵,这类二维游戏地图也叫瓦片地图(Tiled Map)。地图上每一个瓦片,都是一个字典存储了该瓦片内的所有信息,以下信息中的events字段都是智能体可以感知,并影响的环境信息。
self.tiles[9][58] = {'world': 'double studio',
'sector': 'double studio', 'arena': 'bedroom 2',
'game_object': 'bed',
'spawning_location': 'bedroom-2-a',
'collision': False,
'events': {('double studio:double studio:bedroom 2:bed', None, None)}}
同时Maze还存储了一份倒排索引,也就是给定当前智能体当前的地址,需要返回在地图中对应的二维坐标,这样就可以规划智能体从当前位置到某个地点的行动路径。
self.address_tiles['<spawn_loc>bedroom-2-a'] == {(58, 9)}
- 环境感知(perceive.py)
有了环境,再说下智能体如何感知环境。给定智能体当前在地图中的位置,智能体可以感知周围设定范围内所有瓦片中最新的事件。如果周围发生的事件太多,会先按照和智能体之间的距离排序,选择最近的N个。同时对于智能体之前未感知的事件,会加入到智能体的记忆流中。
记忆流
记忆流的设计算是论文的一大核心,分成以下两个部分
- 记忆提取:其一是传统的RAG,也就是智能体的每一步行为都需要依赖智能体的历史记忆,如何抽取相关记忆是核心
- 记忆存储:其二是智能体的记忆除了感知的环境,还包含哪些信息?
记忆提取(retrieve.py)
话接上面的环境感知部分,智能体感知到了周边的环境是第一步,第二步就是用感知到的信息,去召回智能体相关的历史记忆。这里被召回的记忆,除了之前感知的环境和事件,还有思考记忆,思考后面会讲到。召回除了使用embedding相似度召回之外, 记忆召回加入了另外两个打分维度时效性和重要性。
其中时效性打分是一个指数时间衰减模块,给久远的记忆降权,哈哈时效性打分是个宝,在很多场景下都是相似度的好伴侣,实际应用场景中RAG真的不止是一个Embedding模型就够用的。
重要性打分是基于大模型对每个记忆的重要程度进行打分。打分指令如下
最后在召回打分时,相似度,时效性,重要性进行等权加和。
记忆存储 (reflect.py)
智能体记忆流中存储的除了感知到的环境之外,论文还增加了一类很有趣的思考记忆。哈哈不由让我想起了工作中听到的一个梗"老板说不能只干活,你要多思考!!"
触发机制也很有insight,就是每个智能体会有一个重要性Counter,当近期智能体新观察到的各类事件的重要性打分之和超过某个阈值,就触发思考任务。哈哈今天你思考了么?没有的话来学习下智能是如何思考的,对打工人很有启发哟
- 第一步定位问题??论文取了智能体近100条的记忆,通过指令让模型从中提N个问题。指令如下
Given only the information above, what are !<INPUT 1>! most salient high-level questions we can answer about the subjects grounded in the statements?
1)
- 第二步反思问题??针对以上N个问题进行相关记忆的抽取,然后基于抽取记忆进行思考。这里允许召回的记忆本身是之前生成的思考,也就是基于思考再思考,基于反思再反思。从这里我真的看好智能体成为天选打工人......
What !<INPUT 1>! high-level insights can you infer from the above statements? (example format: insight (because of 1, 5, 3))
1.
最后生成的思考会存储入记忆流中,用于之后的行为规划或者再进一步的思考。
行为和规划
最后一个模块是行为规划(plan.py),也是最主要的模块,决定了智能体在每一个时间点要做什么,也是之智能体记忆流中的第三种记忆类型。
除了基于当前状态去生成下一步行为之外,论文比较有意思的是先规划了智能体每一天的待办事项,然后在执行事项的过程中,进行随机应变。从而保证了智能体在更长时间轴上连续行为的连贯性,一致性,和逻辑关联。
长期规划:每日待办
智能体每日待办事项是通过自上而下的多步拆解,使用大模型指令生成的(plan.py)
第一步,冷启动,根据任务特点,生成智能体的作息时间,如下
第二步,生成小时级别的事项规划。这里并非一次生成所有事项,而是每次只基于智能体的所有静态描述,包括以上生成的生活作息,个人特点等等(下图),和上一个生成事项,来规划下一个事项。模型指令是1-shot,输出事项和事项持续的事件
第三步,是把小时级的事项规划进行事项拆解,拆分成5-分钟级别的待办事项。模型指令同样是1-shot,模板给出一个小时级别任务的拆分方式,让模型去依次对每个小时的事项进行拆解,模型指令中1-shot的部分格式如下:
Today is Saturday May 10. From 08:00am ~09:00am, Kelly is planning on having breakfast, from 09:00am ~ 12:00pm, Kelly is planning on working on the next day's kindergarten lesson plan, and from 12:00 ~ 13pm, Kelly is planning on taking a break.
In 5 min increments, list the subtasks Kelly does when Kelly is working on the next day's kindergarten lesson plan from 09:00am ~ 12:00pm (total duration in minutes: 180):
1) Kelly is reviewing the kindergarten curriculum standards. (duration in minutes: 15, minutes left: 165)
2) Kelly is brainstorming ideas for the lesson. (duration in minutes: 30, minutes left: 135)
3) Kelly is creating the lesson plan. (duration in minutes: 30, minutes left: 105)
4) Kelly is creating materials for the lesson. (duration in minutes: 30, minutes left: 75)
5) Kelly is taking a break. (duration in minutes: 15, minutes left: 60)
6) Kelly is reviewing the lesson plan. (duration in minutes: 30, minutes left: 30)
7) Kelly is making final changes to the lesson plan. (duration in minutes: 15, minutes left: 15)
8) Kelly is printing the lesson plan. (duration in minutes: 10, minutes left: 5)
9) Kelly is putting the lesson plan in her bag. (duration in minutes: 5, minutes left: 0)
最终分钟级别的待办事项会作为智能体当日的主线行为,写入以上的记忆流中,在之后的每一次行为规划中,提醒智能体,当前时间要干点啥。
短期规划:随机应变
以当日长期行为规划为基础,智能体在按计划完成当日事项的过程中,会不时的感知周围环境。当出现新的观测事件时,智能体需要判断是否需要触发临时行为,并调整计划。这里主要分成两种临时行为:交流和行动。这两种行为的触发会基于智能体当前的状态,和大模型基于上文的指令输出,例如对于是否产生对话行为的判断
当智能体A,出现在当前智能体可以感知的环境范围内时,通过以上的环境感知模块,智能体的记忆流中会出现智能体A的当前行为。这时智能体会在记忆流中检索和智能体A相关的记忆,合并当前状态作为上文,使用大模型指令判断是否要发起和A的对话
如果判断需要发起对话,则触发对话模块进行交流,而交流是所有社会性行为产生的根本。
效果
主要模块基本就说这么多,技术评估就不多说了,在智能体行为上论文验证了当前框架会产生一定的社会效应,包括信息会在智能体之间传播,智能体之间会形成新的关系,以及智能体间会合作完成任务等等。
论文也讨论了当前框架的一些不足,包括如何在更长时间周期上泛化,如何避免智能体犯一些低级错误,例如躺上有人的床哈哈哈哈~
个人感觉还需要讨论的是如何在当前的记忆流中衍生成更高级的,抽象的思考,以及对世界的认知。这些认知是否有更高效,结构化的存储和召回方式。只依赖反思和记忆流的线性存储可能是不够的。
职场番:ChatDev
- Communicative Agents for Software Development
- https://github.com/OpenBMB/ChatDev
哈哈如果说斯坦福小镇对标综艺桃花坞,那ChatDev就是对标令人心动的Offer。论文参考了斯坦福小镇的记忆流,CAMEL的任务导向型对话方案,通过智能体间对话协同完成特定软件开发任务。
论文把软件开发流程,抽象成多个智能体的对话型任务。整个开发流程分成设计,编程,测试,文档编写四个大环节,每个环节又可以拆分成多个执行步骤,其中每个步骤都由两个角色的智能体通过对话合作来完成,如下
在进入主要流程前,让我们先完成准备工作。开发流程的准备工作需要定义三类配置文件,源码提供了默认的配置文件,用户可以根据自己的需求,选择覆盖部分配置。配置文件从Top to Bottom分别是
- ChatChainConfig:定义了整个任务链的所有步骤和执行顺序(phrase),以及所有参与的智能体角色。
以默认配置为例,任务链包含以下步骤:DemandAnalysis -> LanguageChoose -> Coding -> CodeCompleteAll -> CodeReview -> Test -> EnvironmentDoc -> Manual
参与智能体角色包括:CEO,CFO, CPO, CCO, CTO, programmer,Reviewer,Tester等
-
PhaseConfig:下钻到每个步骤,分别定义了每个步骤的prompt指令,以及参与的两个Agent角色。
-
RoleConfig:下钻到每个角色,分别定义了每个角色的prompt指令
初始化配置文件后我们进入软件开发的四个主要流程~
Design
产品设计环节,负责把用户需求转化成项目方案,包括两个原子步骤:CEO和CPO进行需求分析和产品设计,CEO和CTO选择编程语言。考虑每个phase的实现其实是相似的,只不过参与智能体不同,以及phase对应的指令和多轮对话形式不同,这里我们只说CEO和CPO之间关于需求分析对话实现(role_play.py)~
这里融合了CAMEL的Inception Prompting和斯坦福小镇的记忆流和自我反思来完成任务导向的对话。
- Role Assignment
首先初始化参与phase的两个智能体角色,并生成初始prompt(Inception Prompt)。包括用户需求(task_prompt),本阶段的任务描述(phase_prompt)和两个智能体的角色描述(role_prompt)。
基于初始指令,之后两个智能体会通过对话相互为对方生成指令,而人工参与的部分只有最初的角色描述和任务描述,所以叫初始指令。产品涉及环节的具体指令如下,需求分析阶段的任务指令使用了few-shot,给出不同的产品形态例如图片,文档,应用等实现方式,并明确了对话的两个智能体的讨论主题,以及终止讨论的条件,即确定产品形态
以下是论文附录给出的一个需求分析阶段的具体对话示例,不过对话终止符似乎变成了<END>
- Memory Stream
老实说感觉这里的memoery stream和上面小镇中实现的memory stream关联似乎并不是很大。看代码实现,对话是直接使用上文对话history作为输入,只有当输入上文长度超长的时候,会保留Inception prompt和最近的N轮对话......难道是我漏看了代码,如果是请评论指出 >.<
- Self-Reflection
小镇中自我反思是为了产生更抽象,更高级的个人思考。而在这篇论文self-Reflection其实更像是会议总结模块,当多轮对话完成,但是并未出现对话停止<END>符号,这时可以触发总结模块,把前面的多轮对话作为上文,来总结对话得到的结论,用于后续步骤的进行,如下
Coding
编程环节包括两个基本步骤:后端写代码,和前端设计交互界面。编程环节最大的难点就是如何避免模型幻觉,最大正度保证代码的正确性,以及在多轮对话中如何进行复杂长代码的编写和修改。这里同样我们只说下后端编写代码这一个步骤。
代码编写步骤的核心指令如下,CTO智能体给程序员智能体的指令是:以面向对象的编程语言python为基础,先给出核心类和方法。程序员智能体会按照指令以markdown为语法进行代码和注释的编写。之后代码编写环节会循环执行N次多轮对话,不断对代码进行更新优化。
在指令的基础上,为了优化复杂代码的编写效果,论文在代码编写环节引入了version control环节。在每一步代码编写完成后,会使用difflib对两版代码进行比对,并从记忆流中删除旧版本的代码,这样对话会永远基于最新的代码版本进行,对最新代码进行不断更新。
Testing
测试环节包括两个基本步骤:代码评审和测试环节。
评审环节,程序员智能体会给评审智能体指令,让其对代码进行检查,例如是否有未实现的类或方法,以及整个项目是否符合用户需求等等(角色指令如下图),并给出评审建议。其次程序员之智能体会基于以上建议对代码进行调整。
测试环节是基于代码执行后出现的bug进行修复。论文在这里引入了Thought Instruction,有点类似Decomposed Prompt的任务拆分。因为如果直接基于代码执行bug让大模型进行修复,问题可能过于复杂导致模型无法直接修复,或者产生幻觉。因此通过多轮对话引入一步任务拆分,先经过TestErrorSummary步骤对测试bug的位置和产生原因进行总结,再基于以上总结进行代码调整。
Documentation
文档生成环节就比较简单了,包括多个phase步骤,一个phase对应一类文档说明。这里使用了few-shot指令来引导智能体生成requirements.txt, README.MD等用户文档,以下是生成requirements.txt的指令示例
效果
效果上ChatDev从CAMEL编程相关的任务中随机抽了70个任务进行测试,任务平均代码量是131行代码,4个文件,3个上游依赖库,说明ChatDev整体生成的软件还是偏简单,小型,不涉及复杂的设计。具体效果大家可以直接去Chatdev的代码库里给的生成案例感受下。在这样的代码复杂度下,ChatDev最终代码的执行成功率在86% ,平均任务完成时间在7分钟左右,且调用成本相对较低。
除了以上提到了两个比较火爆的多智能体协同应用,还有很多相关应用和开源实现,这里就不一一介绍了,感兴趣的同学可以去自己试试看
- AgentSims:国内开源的类似斯坦福小镇
- AgentVerse:多模型交互环境
- MetaGPT:覆盖软件公司全生命流程,例如产品经理等各个职业的AutoGPT
- CAMEL:任务导向型,沟通式多智能体协同框架,Chatdev的基础
想看更全的大模型相关论文梳理·微调及预训练数据和框架·AIGC应用,移步Github >> DecryPrompt
标签:18,代码,Agent,智能,指令,记忆,LLM,对话,minutes From: https://www.cnblogs.com/gogoSandy/p/17793236.html