智能体行为：智能体根据当前状态和历史经历，决定下一步是吃饭睡觉还是打豆豆
智能体互动：智能体间的互动通过交流或指令进行，当智能体处于同一环境中时可能会触发交流对话
智能体和环境交互：智能体行为会改变环境状态，例如智能体睡觉时，环境中床的状态就会变成“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)，也是最主要的模块，决定了智能体在每一个时间点要做什么，也是之智能体记忆流中的第三种记忆类型。

除了基于当前状态去生成下一步行为之外，论文比较有意思的是先规划了智能体每一天的待办事项，然后在执行事项的过程中，进行随机应变。从而保证了智能体在更长时间轴上连续行为的连贯性，一致性，和逻辑关联。

长期规划：每日待办

智能体每日待办事项是通过自上而下的多步拆解，使用大模型指令生成的

第一步，冷启动，根据任务特点，生成智能体的作息时间，如下

第二步，生成小时级别的事项规划。这里并非一次生成所有事项，而是每次只基于智能体的所有静态描述，包括以上生成的生活作息，个人特点等等（下图），和上一个生成事项，来规划下一个事项。模型指令是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

解密Prompt

解密Prompt系列18. LLM Agent之只有智能体的世界

生活番：Generative Agents