MetaGPT meta programing for a multi-agent collaborative framework论文理解和写法解读

1. 概要：

提出基于SOP和大模型agent相结合的一个多agent的框架，该框架模拟软件开发的SOP，定义具有不同角色、能力、工具使用、标准化输出限制的agent，并且为agent之间的交互定义交互接口，结构化的输出（而不是简单基于文本），并且设计了基于Publish-Subscribe的沟通机制以提高agent之间的沟通效率；另外，还设计了一个反馈机制，让agent可以自己根据反馈修改输出，最后与多agent框架、代码助手工具进行结果对比，在HumanEval、MBPP以及自己的SoftwareDev数据集上都要好于其他。

2. 论文整体行文逻辑、布局及意思理解

摘要

• 2-3句话引出MetaGPT：面相复杂问题解决领域的一些基于LLM的进展；当前主要是对话式的模式，在复杂问题需要更高的逻辑能力要求的情况下，面临幻觉的问题；所以本文提出将人类的工作流引入通过创建multiagent系统的解决办法
• 2句话说明MetaGPT的核心思想：SOP是用来让擅长不同模块的专家来生成并验证每一步的中间结果的正确以此减少错误；通过工作流拆分复杂的任务到小的任务，并给付给每个任务的agent不同的角色。
• 1句话说明实验结果：MetaGPT在多个软件benchmarks下表现出更好且更具解释型的结果。
• 1句话给出于Meta相关工作的索引

Introduction

• 第一段先讲问题：在基于LLM的自动化agent用来代替人类做一些流程性和重复性的工作上，虽然已经有很多应用，但这些应用普遍简单化问题的复杂性，主要在效率、条理性、问题解决方案的准确性上的问题，尤其是对于需要协作解决的一些场景。
• 第二段引出SOP：人类在各个领域都形成了SOP，而SOP主要是进行任务分解、有效协调方面起作用。SOP定义不同角色的人来解决不同的任务，并且指定中间结果以及建立相应标准，从而一个好的SOP对任务的一致性和完成的正确性提供很大的保障。比如软件的SOP中，PM就需要产出结构化的标准的包括竞品分析、用户需求这些在PRD作为其输出。
• 第三部分将基于上面的问题和SOP，启发来MetaGPT：MetaGPT就是要求不同的agents产出标准化的中间结果，如PRD、design、flowchart、interface specification等，这些中间结果保证了核心的生成代码的成功率。因此这减少了在合作的沟通过程中的不一致性、二义性和错误。用一个类似MetaGPT的公司来比喻，就是所有员工都要遵守严格的标准和工作流，所有的对接物都需要满足标准，以减少无意义的无效沟通，比如闲聊，这就像基于LLM中的agent之间的幻觉导致的错误传递；
• 第四部分将meta-programing类似的工作的区别有优势：Meta-programming有其他如CodeBERT、CodeLlama、WizardCode的工作，但是MetaGPT不同的是通过agents间的高效协同，根据标准为不同的agents定义不同的角色和技能，产生各自的标准化产物，如需求分析、系统涉及、代码、修改记录等，以完成自动化的软件全生命周期流程，从而展示来多agent框架对于解决meta-programing问题是很有价值的。
• 第五部分要点概括在数据集上结果：使用来HumanEval、MBPP的公开数据集；结果准确的达到SoTA级别的85.95%和87.7%；对比与其他相似的解决方案，如AutoGPT、LangChain、AgentVerse、ChatDev，结果依然更优；并且MetaGPT对于实验的所有问题都成功生成代码，说明MetaGPT在Token利用率和时间效率上的鲁棒性。
• 最后，三个角度说明论文工作的贡献：
  • 一是，在实现了MetaGPT这个多agent框架系统，有很好的函数定义和信息分享设计，从而可以在基于LLM的多agent系统的开发上提供有用的框架；
  • 二是，基于SOP来设计多agent系统的创新想法，提高了多agent设计中的沟通效率，并且进一步提出了一种反馈机制用来对生成的代码进行review和修改，结果也证明这是非常有效的；
  • 三是，在两个公开数据集上做了全面的实验，用实验结果说明基于LLM的多agent系统在解决复杂的软件生成问题上的价值。

Related Work

相关工作主要有两个：

• 第一部分和自动化编程相关的背景工作：自动化编程最早可以追溯到1969年的PROW系统，一种通过算术表达式来表示软件的需求规范，从而生成算法的系统，进一步有许多工作在推进自动编程（给了三篇80年代文章索引）；直到最近的使用自然语言生成程序的方法（2020-2023），包括一些代码大模型、代码生成的相关prompt等技巧、NLP生成代码的一些神经网络等；其中React和Reflextion这两篇文章通过生成推理过程和执行计划的方式说明了提高LLM在代码生成上的有效性，ToolFormer通过让LLM学习使用工具来提高LLM的能力（这两个应该都是本文工作实现时用LLM用到的技巧）；与此文最相近的两个研究分别是Camel和“comminucative agents for software development”这两个工作都是通过多agent架构来解决自动编程的问题，但是他们都是用到workflow和结构化的输出的设计，因此也没能很好解决一些复杂软件问题；
• 第二部分是基于LLM的多agent系统：基于LLM可自主agent已经在工业和学术界都取得很大关注（一篇综述），多agent系统也在许多研究中被提出用来让LLM解决更复杂的问题（7篇基于LLM的multiagent来提高解决复杂难度任务的相关工作）；目的上，有些工作是通过agent之间的沟通来吼去共识的价值观从而获取一些instruction的数据集，有些事关注在社会现象上，有些是通过agent的头脑风暴来解决复杂问题，有些是使用大模型与小模型agent协作来达到成本缩减的目的；方法上，有些是通过在agent之间创建竞争和协作的方法来提高推理和计划能力，有些提出了一些agent之间的经济模型；这些都是聚焦在让agents模拟出开放世界中的人类行为，而MetaGPT则是直接将人类的实践经验直接注入到agents的框架；并且在基于LLM的agents工作上，面临着“指令重复”或者“消息无限循环”的问题，特别是对面向任务的协作方面的工作，这就要求一致性和有效的交互；这是基于这些本文才提出基于SOP的方法用于解决软件生成问题的多agent框架。

MetaGPT框架介绍

总体先说明分三部分介绍框架，第一部分是相关角色定义、工作流、结构化的输入输出交流这些针对SOP的多agent框架设计的要点；第二部分与第一部分的结构化输入输出有点重复，但是是以communication protocol的大帽子下来讲“结构化的交流接口”以有效的P-B机制，用来保证agent从其他agent获得指定消息并且共享一些公共知识；第三部分是关于一个自称很“novel”的反馈机制，其实就是真实执行生成的代码的单元测试，如果出现bug就反馈，其实很直接；

• 第一部分sop中的agent的设计的具体内容，分两个小部分：
  • 第一个小部分是规范角色，将复杂问题解决所需要的协作分配到拥有不同技能的agent，每个agent解决特定领域的问题给出输出，这对问题的简化很重要；meta定义来5种角色（ProductM、Architect、ProjectM、En、QA En），每个角色包括名字，profile，goal， constrains以及context和skills；这里用两个图说明，一个图是人类SOP与Meta定义的multi-agent的workflow的对比，另一个图是metagpt的在communication-pool和engineer的示意图；这里所有角色的Prompt的书写以及工作方式都遵循React风格；
  • 第二个小部分是agents的工作流，以一个例子的简要流程图以及语言介绍，从用户需求输入，经过Product M的需求分析，产出包含用户故事和需求池的PRD并输入到Architect，接着输出系统设计，包括文件列表、数据结构、接口定义，然后再激情系统设计输入给Project M进行任务分配，后面看主要是根据文件进行任务拆分，包括文件名、该文件需要完成的功能，然后Engineer继续执行指定文件的实现，再接着QA Engineer再进行测试用例生成。
• 第二部分介绍所谓的沟通协议，分两小部分：第一小部分是结构化沟通接口，也就是上面讲到的结构化输出，现有的很多mutiagent工作都是用自然语言作为agent之间的沟通接口，这导致信息在流动过程中的扭曲或遗失，因此要求agent输出结构化标准的输出，用来规范agents之间的沟通接口来解决这个问题；第二小部分是P-S机制，之间的工作在agent之间的沟通是一对一的，着导致沟通的拓扑复杂性很高，交流效率低，因此meta提出一个全局的消息池，所有agent都可以通过池子交流消息，这样就不用一对一的查询等待消息，只需要消息池中有自己感兴趣有用的消息就获取，当满足条件足够促发自己的行动；
• 第三部分介绍所谓的自我纠正反馈机制：在meta没有反馈机制之间因为LLM幻觉问题存在一些错误，因此在生成代码之后进行单元测试的执行，根据执行错误信息再反馈给engineer进行修改，并且engineer有一个关于debug历史的一个memory（由此可见这里的反馈机制很直接，也只限于代码的代码能通过单元测试，没有更广泛的反馈比如代码不满足需求）

实验

• 第一部分实验设定，包括数据集、测试指标、对比基准：【数据集】使用公开的HumanEval和MBPP，这两个也是在代码生成领域用的比较多的，但都是函数级别，数据集包括函数功能描述（prompt）、测试用例、示例代码这些，并且分别只有164和427个，本文在这两个数据集上的对比很多事基于之前一篇论文的结果直接用的；因为这两个主要是函数级别的代码补全，与metagpt想突出的软件工程有一定不同，因此自己创建了一个包含70个例子的测试集合SoftwareDev（未开源），包括不同领域的软件生成；【测试指标】，HumalEval和MBPP都是使用经典的Pass@K指标，本实验中k就是1；另外对于Software Dev测试集，自创了五个指标，包括主观、客观的指标，用来衡量结果的可用性和性能表现，主观的指标需要人工打分，客观指标主要是一些数据的统计；A指标是可执行度，4个等级，需要人工；B指标是成本，包括运行时间、token使用、价格；C指标是生成的代码静态数据，包括代码文件数目、每个文件代码行数、总代码行数；D指标是生产力，是指每行代码生成需要的token数据，用总token数目除以总代码行数就行；E指标是需要人工修改的程度，为了达到可用需要人工修改几处地方；【对比基准】，主要有两种，一种是AlphaCode、InCoder这些主要CodeLLM的代码生成助手，并且就是使用上面的Pass@1，之前工作做过这些事，因此部分结果来自于之前的工作，并且metagpt为了在这些数据集上实验需要修改prompt以符合生成结果的格式（怎么修改没说）；另一种是类似于AUtoGPT、LangChian（不理解为什么用langchain）、AgentVerse、ChatDev这些multiagent的工具，在Software Dev数据集上对比；
• 第二部分实验结果，两部分：
  • 实验一结果，在HumanEval和MBPP上比其他工具的Pass@1指标都更优达到85%左右，其他最优的GPT4都只有67%；
  • 实验二结果，在Software Dev上主要和ChatDev对比（不知道为什么没展示上面声称的和autogpt、langchain、agentverse的对比），结果也是更优；
• 第三部分能力分析，定性的生成内容和能力上的分析：与其他multiagent工具对比，除了代码生成都有之外，PRD、技术文档、API、编译执行、任务管理、代码REview是metagpt都具备的，而其他基本都不具备；
• 第四部分消融研究，角色和反馈机制的有效性分析：角色有效性分析在除了保留engineer之外其他角色去除后的在SoftDev各项指标上的结果；反馈机制有效性是在HumanEval、MBPP、SofwareDEV三个数据集上都跑了有反馈和没有反馈的MetaGPT，以及对比记过，都是有反馈的更佳；