MetaGPT：多智能体协作框架的工程实践

MetaGPT多智能体协作框架的工程实践各位开发者朋友们大家好我是架构师老杨在技术圈摸爬滚打已经15年了——写过Java后端系统搞过微服务架构玩过云原生落地最近两年更是扎进了AI Agent和多智能体协作的深坑。和很多技术人一样我第一次接触到单个大模型比如GPT-4时惊为天人能写代码、能写文档、能解数学题、能当翻译官……简直是无所不能的“超级程序员”但兴奋劲过去后现实的问题接踵而至单个大模型能力强但“一个人”干复杂的软件工程活太容易翻车了上下文窗口有限写个10万行级别的项目GPT-4 Turbo的128K上下文根本装不下所有需求、设计、测试用例、代码库状态。角色单一导致局限性一会儿让它当产品经理写PRD一会儿让它当架构师画UML一会儿让它当全栈工程师写代码——虽然它都能做但每一项都做得“差点意思”没有术业有专攻的人类团队做得严谨。容易“失忆”和“跑题”你让它先写后端API再写前端调用写着写着可能后端用了/api/v1/user前端写成了/api/users或者本来要做电商后台突然开始写购物车的推荐算法了。缺乏协作和验证机制单个模型输出的代码没人审查没人测试没人写文档——直接上线那简直是在给自己埋定时炸弹。就在我对着单个大模型的“翻车现场”叹气的时候MetaGPT横空出世了这个由字节跳动和UC Berkeley联合提出的多智能体协作框架直接把人类软件开发生命周期SDLC搬到了AI世界它不再让单个模型单打独斗而是创建了一支由产品经理、架构师、项目经理、全栈工程师、测试工程师、文档工程师组成的“AI虚拟团队”每个角色各司其职、相互协作、相互验证最终输出可运行的、结构清晰的、有文档有测试的完整软件项目。第一次用MetaGPT写一个简单的“待办事项管理系统”时我简直不敢相信自己的眼睛只输入了一句“写一个带用户登录、待办增删改查、优先级排序、标签管理功能的Web应用”MetaGPT花了不到20分钟就输出了一份详细的产品需求文档PRD一份包含技术选型、系统架构图、接口定义的技术方案一份项目任务分解和进度安排的Gantt图一套完整的前后端代码后端用Python FastAPI前端用React TypeScript一套用Pytest写的后端单元测试和用Playwright写的端到端测试一份项目README文档和API接口文档Swagger自动生成的不算还有专门的Markdown文档更神奇的是我直接cd frontend npm install npm run devcd backend pip install -r requirements.txt uvicorn main:app --reload项目就直接跑起来了所有功能都正常没有语法错误没有逻辑漏洞——这效率比我自己一个人写快了10倍都不止从那以后我就成了MetaGPT的“忠实粉丝”不仅在工作中用它做快速原型开发还在业余时间深入研究它的源码和原理甚至还基于它做了一些二次开发。今天我就把这半年多来的研究和实践心得整理成这篇万字长文和大家好好聊聊MetaGPT到底是什么、它的核心原理是什么、怎么用它做项目、怎么搭建它的开发环境、怎么对它进行二次开发——希望能帮大家也快速上手这个“AI时代的软件工程神器”目录问题背景与MetaGPT的诞生1.1 单个大模型在软件工程中的局限性1.2 多智能体协作Multi-Agent System, MAS的兴起1.3 MetaGPT的提出、特点与核心贡献MetaGPT的核心概念与系统架构2.1 核心概念角色Role、环境Environment、消息Message、工具Tool、记忆Memory2.2 人类软件开发生命周期SDLC在MetaGPT中的映射2.3 MetaGPT的整体系统架构图Mermaid2.4 概念之间的关系核心属性维度对比、ER实体关系图、交互关系图MermaidMetaGPT的核心算法原理与具体操作步骤3.1 SOP标准操作流程驱动的智能体协作机制3.2 消息队列与订阅-发布模式Pub/Sub的实现3.3 结构化记忆系统的设计与实现3.4 工具调用的机制与逻辑3.5 元编程Meta-Programming与代码审查机制3.6 算法流程图Mermaid3.7 算法源代码Python简化版核心逻辑MetaGPT的数学模型与公式推导4.1 多智能体协作的马尔可夫决策过程MDP建模4.2 消息优先级的计算模型4.3 任务分配的效用函数4.4 角色输出质量的评估模型项目实战用MetaGPT从零搭建一个“个人博客系统”5.1 项目介绍与需求定义5.2 开发环境搭建本地Docker部署 云端GPU部署5.3 系统功能设计5.4 系统架构设计5.5 系统接口设计5.6 系统核心实现源代码与解读5.7 项目部署与上线5.8 遇到的问题与解决方案MetaGPT的最佳实践与优化技巧6.1 如何写好“提示词工程”Prompt Engineering来提升MetaGPT的输出质量6.2 如何扩展自定义角色Custom Role6.3 如何扩展自定义工具Custom Tool6.4 如何优化MetaGPT的运行效率减少Token消耗、缩短响应时间6.5 如何与现有系统集成MetaGPT的实际应用场景7.1 快速原型开发MVP7.2 遗留系统的重构与文档化7.3 代码审查与自动修复7.4 教育与培训辅助学习编程7.5 其他非软件工程的应用场景比如文案创作、数据分析、游戏设计MetaGPT的工具和资源推荐8.1 官方资源8.2 社区资源8.3 相关开源项目MetaGPT的发展历史、现状与未来趋势9.1 问题演变发展历史的Markdown表格9.2 MetaGPT的版本更新历史9.3 当前的局限性与挑战9.4 未来的发展方向本章小结参考文献致谢1. 问题背景与MetaGPT的诞生在讲MetaGPT之前我们得先搞清楚为什么我们需要它——也就是单个大模型在软件工程中遇到的“痛点”到底是什么以及多智能体协作为什么能解决这些痛点。1.1 单个大模型在软件工程中的局限性我相信很多开发者朋友都有过用单个大模型写代码的经历对吧比如用ChatGPT写一个简单的Python脚本或者用GitHub Copilot补全一行代码——这时候单个大模型确实很好用能帮我们节省不少时间。但如果我们让它做稍微复杂一点的软件工程任务比如写一个完整的Web应用、重构一个10万行级别的遗留系统、设计一个分布式数据库的架构——这时候单个大模型的问题就暴露出来了而且是“致命的”。我把单个大模型在软件工程中的局限性总结为以下5个维度每个维度我都举了一个我自己遇到的“真实翻车现场”的例子1.1.1 维度一上下文窗口Context Window的物理限制问题描述不管是GPT-4 Turbo128K上下文、Claude 3 Opus200K上下文、还是Gemini 1.5 Pro1M上下文它们的上下文窗口都是有物理上限的——也就是说它们能“记住”的对话历史、输入的文本、输出的文本的总长度是有限的。而软件工程任务尤其是复杂的软件工程任务需要处理的信息量是非常大的一份详细的PRD可能就有几万字一份技术方案可能包含几十页的文档、十几张UML图一个10万行级别的代码库光是所有文件的内容加起来就有几十MB转换成Token的话可能是几百万甚至上千万还有测试用例、Bug报告、部署文档……当信息量超过单个大模型的上下文窗口时它要么会**“选择性遗忘”之前的对话历史和输入内容**要么会直接报错说“上下文太长了”——不管是哪种情况都会导致它的输出质量急剧下降甚至完全无法完成任务。真实翻车现场上个月我让GPT-4 Turbo帮我重构一个10万行级别的Java遗留电商系统的订单模块。我先把订单模块的所有Java文件大概50个总共有20万行代码不对是10万行级别的系统订单模块大概占2万行代码的内容压缩了一下去掉了注释、空行、日志代码然后粘贴到了GPT-4 Turbo的输入框里——结果直接报错说“上下文超过了128K的限制”。然后我想“那我分批输入吧先输入订单模块的核心实体类再输入Service层的代码再输入Controller层的代码。”于是我先输入了核心实体类Order.java、OrderItem.java、OrderStatus.java的代码大概500行然后让GPT-4 Turbo帮我分析一下这些实体类的设计有没有问题——它分析得很好指出了几个问题比如Order.java里的createTime和updateTime应该用LocalDateTime而不是Date比如OrderStatus.java里缺少“已退款”的状态。然后我又输入了Service层的OrderService.java和OrderServiceImpl.java的代码大概3000行然后让GPT-4 Turbo帮我分析一下Service层的代码有没有问题——它分析得也还可以指出了几个问题比如有几个方法没有加事务注解Transactional比如有几个方法的参数校验做得不够完善。然后我又输入了Controller层的OrderController.java的代码大概1000行然后让GPT-4 Turbo帮我结合之前分析的实体类和Service层的问题重构整个订单模块——结果你猜怎么着它完全忘记了之前分析的实体类的问题它重构的Order.java里的createTime和updateTime还是用的DateOrderStatus.java里还是没有“已退款”的状态而且它重构的Service层和Controller层的代码和之前输入的代码完全不一样——甚至连接口的路径都变了我当时就无语了“合着我分批输入了这么多代码你只记住了最后一批输入的Controller层的代码之前输入的实体类和Service层的代码都白搭了”1.1.2 维度二角色单一导致的“认知偏差”和“能力瓶颈”问题描述单个大模型虽然看起来“无所不能”但本质上它是没有“角色意识”的——你让它当产品经理它就是产品经理你让它当架构师它就是架构师你让它当全栈工程师它就是全栈工程师。但问题是人类的产品经理、架构师、全栈工程师都是术业有专攻的——他们有不同的知识背景、不同的思维方式、不同的技能树他们在一起协作的时候才能互补彼此的不足输出高质量的成果。而单个大模型呢它的知识背景、思维方式、技能树都是**“大杂烩”**——它既懂一点产品又懂一点架构又懂一点前端又懂一点后端但每一项都做得“差点意思”当产品经理的时候它写的PRD可能不够详细没有考虑到用户的真实需求没有考虑到技术可行性当架构师的时候它画的架构图可能不够合理没有考虑到系统的可扩展性、可维护性、高可用性当全栈工程师的时候它写的代码可能不够规范没有考虑到代码的可读性、可测试性、安全性当测试工程师的时候它写的测试用例可能不够全面没有覆盖到所有的边界条件和异常场景而且单个大模型还会有**“认知偏差”**——比如你让它先写前端代码它可能会过度关注前端的“美观性”而忽略了后端的“性能”和“安全性”比如你让它先写后端代码它可能会过度关注后端的“性能”而忽略了前端的“用户体验”。真实翻车现场今年年初我让Claude 3 Opus帮我写一个“在线会议室预订系统”的MVP。我给它的需求很简单“写一个带用户登录、会议室列表展示、会议室预订、预订记录查询、预订取消功能的Web应用。”Claude 3 Opus花了大概10分钟就输出了一套完整的前后端代码后端用Python Flask前端用React TypeScript。我当时很高兴觉得“这个MVP应该能直接用了”——结果我一运行就发现了一堆问题产品层面的问题没有考虑到“会议室的容量”——比如一个会议室只能容纳10个人但用户可以预订它给20个人用没有考虑到“预订的时间冲突”——比如用户A已经预订了会议室A在今天下午2点到4点用户B还可以预订会议室A在今天下午3点到5点没有考虑到“预订的权限”——比如普通用户可以预订所有会议室包括CEO专用会议室架构层面的问题没有用数据库而是用了Flask的session来存储数据——服务器一重启所有的用户信息、会议室信息、预订记录都没了没有做前后端分离的身份验证——前端直接把用户名和密码存储在localStorage里而且是明文存储没有做API接口的限流——任何人都可以无限次地调用API接口很容易被DDoS攻击代码层面的问题后端代码没有加任何注释可读性很差后端代码没有加任何参数校验比如用户输入的预订开始时间可以是过去的时间前端代码没有加任何错误处理比如后端API接口返回500错误的时候前端直接白屏了前端代码没有加任何响应式设计在手机上完全没法用测试层面的问题没有任何单元测试没有任何端到端测试没有任何性能测试我当时就叹了口气“合着你写的这个MVP就是一个‘花架子’——看起来很美但根本没法用”1.1.3 维度三缺乏“长期记忆”和“上下文连贯性”问题描述我刚才在维度一里提到了单个大模型的“上下文窗口限制”但其实就算是在上下文窗口之内单个大模型也会有**“短期记忆丢失”和“上下文连贯性差”**的问题——比如你和它聊了100轮对话它可能会忘记你在第10轮对话里说的某个重要的细节比如你让它先写后端API的接口定义再写前端的调用代码写着写着可能后端用了POST /api/v1/booking前端写成了PUT /api/v1/bookings。为什么会这样呢因为单个大模型的“记忆”本质上是**“基于当前上下文窗口的注意力机制”——它只会“记住”当前上下文窗口里的内容而且它对这些内容的“注意力”是不均匀的**它会更关注最近输入的内容而对较早输入的内容的关注度会逐渐降低。而软件工程任务是需要“长期记忆”和“上下文连贯性”的——你需要记住整个项目的需求、设计、技术选型、代码库状态你需要确保你写的每一行代码、每一个文档、每一个测试用例都和之前的内容保持一致。真实翻车现场去年年底我让GPT-4帮我写一个“在线题库系统”的后端API。我先给它输入了需求“后端API需要支持用户登录、用户注册、题目列表展示、题目详情查询、题目添加、题目修改、题目删除、题目作答、作答记录查询、成绩统计功能。技术选型用Python FastAPI PostgreSQL SQLAlchemy ORM JWT身份验证。”然后我让它先写数据库的表结构定义SQLAlchemy的Model类——它写得很好定义了User、Question、Answer、Submission、Score这5个Model类每个类的字段都很合理主键、外键、索引都加了。然后我让它写JWT身份验证的中间件——它写得也很好定义了create_access_token、verify_access_token、get_current_user这3个函数中间件的逻辑也很清晰。然后我让它写User相关的API接口登录、注册、获取当前用户信息——它写得也还可以接口的路径是POST /api/v1/auth/login、POST /api/v1/auth/register、GET /api/v1/users/me和我之前在需求里提到的技术选型一致。然后我让它写Question相关的API接口列表展示、详情查询、添加、修改、删除——结果你猜怎么着它写的接口路径变成了GET /api/questions、GET /api/questions/{id}、POST /api/questions、PUT /api/questions/{id}、DELETE /api/questions/{id}——不仅去掉了/v1的版本号还把/api/v1/question改成了/api/questions复数形式而且它写的Question的添加接口没有加JWT身份验证的依赖——任何人都可以添加题目我当时就提醒它“你之前写的User相关的API接口路径是/api/v1/auth/...和/api/v1/users/me有/v1的版本号而且都是用的复数形式/users。还有Question的添加、修改、删除接口应该只有管理员才能访问需要加JWT身份验证的依赖还要加一个is_admin的权限检查。”它当时的回复是“哦对不起我忘了我马上修改。”然后它修改了Question相关的API接口的路径改成了GET /api/v1/questions、GET /api/v1/questions/{id}、POST /api/v1/questions、PUT /api/v1/questions/{id}、DELETE /api/v1/questions/{id}也加了JWT身份验证的依赖和is_admin的权限检查。然后我让它写Answer相关的API接口——结果它又犯了同样的错误接口路径变成了GET /api/answers没有/v1的版本号而且它写的Answer的添加接口也没有加JWT身份验证的依赖我当时就彻底无语了“合着你每次都要我提醒你一次你就不能自己记住之前的约定吗”1.1.4 维度四缺乏“协作机制”和“验证机制”问题描述人类软件开发生命周期SDLC之所以能输出高质量的成果是因为它有一套完善的协作机制和验证机制协作机制产品经理、架构师、项目经理、全栈工程师、测试工程师、文档工程师各司其职相互沟通相互配合共同完成项目验证机制产品经理写的PRD要经过架构师和项目经理的评审架构师画的架构图要经过全栈工程师的评审全栈工程师写的代码要经过代码审查Code Review测试工程师写的测试用例要覆盖所有的功能点和边界条件代码上线前要经过测试环境的测试和预发布环境的验证而单个大模型呢它没有任何协作机制和验证机制——它写的PRD没人评审它画的架构图没人评审它写的代码没人审查它写的测试用例没人检查——完全是“自己写自己的自己说了算”。这样一来它的输出质量就完全没有保障很容易出现各种问题。真实翻车现场今年3月份我让Gemini 1.5 Pro帮我写一个“在线投票系统”的完整项目。我给它的需求很详细“写一个带用户登录、用户注册、投票创建、投票参与、投票结果展示、投票修改、投票删除功能的Web应用。技术选型用Python Django PostgreSQL Redis Vue 3 Element Plus。投票创建的时候需要设置投票的标题、描述、选项、开始时间、结束时间、是否匿名、是否允许多选。投票参与的时候需要验证用户是否已经登录是否在投票的时间范围内是否已经参与过这个投票如果不允许重复参与的话。投票结果展示的时候需要用柱状图或者饼图来可视化。”Gemini 1.5 Pro花了大概30分钟就输出了一套完整的前后端代码、一份PRD、一份技术方案、一份README文档。我当时很高兴觉得“这次应该没问题了吧Gemini 1.5 Pro的上下文窗口可是1M呢”——结果我一检查就发现了一堆问题PRD的问题没有考虑到“投票的权限”——比如普通用户可以创建投票也可以修改和删除任何用户创建的投票没有考虑到“投票的可见性”——比如所有投票都是公开的任何人都可以看到没有考虑到“投票结果的可见性”——比如投票结束前任何人都可以看到投票结果技术方案的问题没有提到Redis的用途——我明明在需求里说了技术选型要用Redis结果技术方案里完全没提没有提到Vue 3和Element Plus的用途——技术方案里只提到了Django的模板引擎说要用Django的模板引擎来写前端没有提到数据库的索引优化——比如Vote表的start_time和end_time字段应该加索引Submission表的vote_id和user_id字段应该加联合索引代码的问题后端代码确实用了Django但完全没用Redis前端代码确实用了Django的模板引擎但完全没用Vue 3和Element PlusVote模型类里没有is_anonymous和allow_multiple字段——我明明在需求里说了投票创建的时候需要设置这两个字段Submission模型类里没有user_id字段——完全没法验证用户是否已经参与过这个投票投票参与的视图函数里没有验证用户是否已经登录没有验证是否在投票的时间范围内没有验证是否已经参与过这个投票投票结果展示的视图函数里没有用任何可视化工具——只是用表格展示了每个选项的票数我当时就问它“我明明在需求里说了技术选型要用Python Django PostgreSQL Redis Vue 3 Element Plus结果你写的代码里完全没用Redis和Vue 3 Element Plus还用了Django的模板引擎。还有我明明在需求里说了投票创建的时候需要设置is_anonymous和allow_multiple字段结果你写的Vote模型类里没有这两个字段。还有我明明在需求里说了投票参与的时候需要验证用户是否已经登录、是否在投票的时间范围内、是否已经参与过这个投票结果你写的投票参与的视图函数里完全没有这些验证。这是怎么回事”它当时的回复是“哦对不起我刚才有点忙看错了需求。我马上修改。”然后它修改了技术方案提到了Redis的用途用来缓存投票结果提到了Vue 3和Element Plus的用途用来写前端也修改了Vote模型类加了is_anonymous和allow_multiple字段也修改了Submission模型类加了user_id字段也修改了投票参与的视图函数加了那些验证。但它还是没有修改前端代码——还是用的Django的模板引擎没有用Vue 3和Element Plus我当时就彻底放弃了“合着你根本就没有‘自我验证’的能力你写完代码之后就不会自己检查一下吗”1.1.5 维度五缺乏“元认知能力”和“自我修复能力”问题描述什么是“元认知能力”就是“对自己的认知过程的认知”——也就是你知道自己“知道什么”、“不知道什么”、“擅长什么”、“不擅长什么”。什么是“自我修复能力”就是当你发现自己犯了错误的时候你能自己找到错误的原因然后自己修改错误。人类开发者是有“元认知能力”和“自我修复能力”的——比如当你写代码的时候你知道自己“不擅长写正则表达式”所以你会去查文档或者用工具来生成正则表达式比如当你发现自己写的代码有Bug的时候你会自己调试找到Bug的原因然后自己修改Bug。而单个大模型呢它基本上没有“元认知能力”和“自我修复能力”——它不知道自己“知道什么”、“不知道什么”、“擅长什么”、“不擅长什么”它只会“根据输入的内容生成输出的内容”当你发现它犯了错误的时候它也不会自己找到错误的原因然后自己修改错误——除非你明确地告诉它“你哪里犯了错误错误的原因是什么应该怎么修改”。真实翻车现场今年4月份我让GPT-4 Turbo帮我写一个“正则表达式生成器”的Python脚本。我给它的需求很简单“写一个Python脚本输入是一段文本和一个描述比如‘提取所有的邮箱地址’、‘提取所有的手机号码’、‘提取所有的URL’输出是一个能匹配描述的正则表达式并且用这个正则表达式来提取文本中的内容。”GPT-4 Turbo花了大概2分钟就输出了一个Python脚本。我当时很高兴觉得“这个脚本应该能直接用了”——结果我一测试就发现了问题我输入的文本是“我的邮箱地址是laoyangexample.com我的手机号码是13800138000我的个人网站是https://laoyang.example.com。”我输入的描述是“提取所有的邮箱地址”结果它生成的正则表达式是r[a-zA-Z0-9_.-][a-zA-Z0-9-]\.[a-zA-Z0-9-.]——这个正则表达式其实是对的能匹配大多数邮箱地址。但它用这个正则表达式提取文本中的内容的时候只提取到了laoyangexample.com——这其实也是对的因为文本里只有这一个邮箱地址。然后我又输入了一段文本“我的邮箱地址是lao.yangtagexample.co.uk我的手机号码是13900139000我的个人网站是http://lao-yang.example.org。”我输入的描述还是“提取所有的邮箱地址”结果它生成的正则表达式还是r[a-zA-Z0-9_.-][a-zA-Z0-9-]\.[a-zA-Z0-9-.]——这个正则表达式其实也能匹配lao.yangtagexample.co.uk对吧因为[a-zA-Z0-9_.-]能匹配lao.yangtag[a-zA-Z0-9-]能匹配example[a-zA-Z0-9-.]能匹配co.uk。但它用这个正则表达式提取文本中的内容的时候却只提取到了lao.yangtagexample.co——漏掉了.uk我当时就提醒它“你生成的正则表达式漏掉了.uk只提取到了lao.yangtagexample.co。你能修改一下正则表达式吗”它当时的回复是“哦对不起我刚才的正则表达式有点问题。我马上修改。”然后它修改了正则表达式改成了r[a-zA-Z0-9_.-][a-zA-Z0-9-]\.[a-zA-Z]{2,}——这个正则表达式其实也不对因为它只能匹配顶级域名是2个或更多字母的邮箱地址但不能匹配顶级域名是数字的邮箱地址虽然很少见但确实存在也不能匹配顶级域名是多个部分的邮箱地址比如example.co.uk它的顶级域名是.uk二级域名是.co这个正则表达式其实也能匹配但它的逻辑是不对的。然后我又测试了一下这个修改后的正则表达式——结果它还是只提取到了lao.yangtagexample.co我当时又提醒它“你修改后的正则表达式还是不对还是只提取到了lao.yangtagexample.co。你能自己调试一下吗看看为什么会漏掉.uk”它当时的回复是“哦对不起我刚才的修改还是有问题。让我再想想……嗯我觉得应该把正则表达式改成r[a-zA-Z0-9_.-][a-zA-Z0-9-](\.[a-zA-Z0-9-])——这个正则表达式应该能匹配所有的邮箱地址了。”然后我又测试了一下这个修改后的正则表达式——结果这次它终于提取到了lao.yangtagexample.co.uk但我当时还是叹了口气“合着你根本就不会自己调试你每次都要我提醒你一次你就不能自己用Python的re模块测试一下你生成的正则表达式吗”好了讲完了单个大模型在软件工程中的5个局限性相信大家都能理解“为什么我们需要多智能体协作框架”了——因为单个大模型的能力确实有限只有让多个大模型扮演不同的角色各司其职、相互协作、相互验证才能解决这些局限性输出高质量的软件项目。接下来我们就来聊聊多智能体协作Multi-Agent System, MAS的兴起。1.2 多智能体协作Multi-Agent System, MAS的兴起其实多智能体协作MAS并不是一个新的概念——它早在20世纪80年代就已经被提出来了是人工智能领域的一个重要分支。那么什么是多智能体协作MAS呢根据维基百科的定义**多智能体系统Multi-Agent System, MAS**是由多个相互作用的智能体Agent组成的计算机系统。智能体可以是软件程序、机器人、或者其他实体它们具有一定的自主性、社会性、反应性和主动性能够感知环境、与其他智能体通信、协作完成共同的目标。多智能体协作MAS的核心思想是“分而治之协作共赢”——把一个复杂的任务分解成多个简单的子任务然后把每个子任务分配给一个专门的智能体来完成最后把各个智能体的输出结果整合起来得到最终的解决方案。在过去的几十年里多智能体协作MAS已经在很多领域得到了应用比如机器人领域多个机器人协作完成仓库货物搬运、灾难救援、足球比赛等任务交通领域多个无人驾驶汽车协作完成道路行驶、交通调度等任务金融领域多个智能体协作完成股票交易、风险管理等任务游戏领域多个NPC非玩家角色协作完成游戏剧情、战斗等任务但在软件工程领域多智能体协作MAS的应用一直都比较少——直到最近两年随着大语言模型LLM的兴起多智能体协作MAS才终于在软件工程领域“大放异彩”为什么大语言模型LLM的兴起会带动多智能体协作MAS在软件工程领域的应用呢原因主要有以下3个1.2.1 原因一大语言模型LLM具有“通用人工智能AGI的雏形”可以扮演多种不同的角色在大语言模型LLM兴起之前要开发一个能在软件工程领域应用的多智能体协作MAS系统是非常困难的——因为你需要为每个角色比如产品经理、架构师、全栈工程师开发一个专门的智能体每个智能体都需要有自己的知识图谱、推理引擎、对话系统……这需要大量的人力、物力、财力而且开发出来的智能体的能力也非常有限只能完成一些非常简单的任务。但现在不一样了——大语言模型LLM具有“通用人工智能AGI的雏形”它的知识背景非常丰富几乎涵盖了人类所有的公开知识它的推理能力非常强能进行逻辑推理、数学推理、常识推理它的对话能力非常好能理解人类的自然语言能生成流畅的自然语言——你只需要给它一个“角色设定”的提示词Prompt它就能很好地扮演这个角色比如你给大语言模型LLM一个这样的提示词“你是一位经验丰富的产品经理拥有10年以上的互联网产品开发经验。你的职责是理解用户的需求将用户的模糊需求转化为详细的、可执行的产品需求文档PRD分析产品的市场定位、用户群体、竞争对手与架构师、项目经理、全栈工程师沟通确保产品需求的技术可行性跟踪产品的开发进度确保产品按时上线请你现在开始工作。”然后你给它一个用户的模糊需求“写一个在线会议室预订系统”——它就能很好地扮演产品经理的角色输出一份详细的PRD再比如你给大语言模型LLM一个这样的提示词“你是一位经验丰富的架构师拥有15年以上的软件架构设计经验。你的职责是理解产品经理的PRD分析产品的技术需求设计产品的系统架构包括技术选型、系统架构图、数据库设计、接口定义与产品经理、项目经理、全栈工程师沟通确保系统架构的可扩展性、可维护性、高可用性审查全栈工程师写的代码确保代码符合系统架构的要求请你现在开始工作。”然后你给它一份产品经理输出的PRD——它就能很好地扮演架构师的角色输出一份详细的技术方案你看有了大语言模型LLM开发一个能在软件工程领域应用的多智能体协作MAS系统就变得非常简单了——你只需要给每个角色一个“角色设定”的提示词然后让它们相互沟通、相互协作、相互验证就行了1.2.2 原因二大语言模型LLM具有“强大的自然语言处理能力”可以很好地处理智能体之间的通信在多智能体协作MAS系统中智能体之间的通信是非常重要的——如果智能体之间不能很好地沟通那么它们就无法协作完成共同的目标。在大语言模型LLM兴起之前智能体之间的通信通常是用结构化的语言比如JSON、XML、或者专门的Agent Communication Language, ACL来进行的——这种通信方式虽然很规范但也很死板而且开发起来也很困难因为你需要为每个通信场景定义一套结构化的消息格式。但现在不一样了——大语言模型LLM具有“强大的自然语言处理能力”它可以很好地理解和生成人类的自然语言——你只需要让智能体之间用人类的自然语言来沟通就行了比如产品经理智能体可以给架构师智能体发这样一条消息“架构师你好我是产品经理。我已经完成了在线会议室预订系统的PRD现在发给你请你查收。请你根据这份PRD设计系统的技术方案包括技术选型、系统架构图、数据库设计、接口定义。如果PRD里有什么不明确的地方或者有什么技术上不可行的地方请你随时和我沟通。谢谢”然后架构师智能体可以给产品经理智能体回这样一条消息“产品经理你好我是架构师。我已经收到了你发来的PRD我现在开始设计技术方案。我看了一下PRD有几个地方想和你确认一下PRD里提到了‘会议室的容量’但没有提到‘是否需要考虑会议室的设备比如投影仪、白板、视频会议系统’——请问需要考虑吗PRD里提到了‘预订的时间冲突’但没有提到‘是否允许预订的时间有部分重叠’——请问允许吗PRD里提到了‘预订的权限’但没有提到‘用户的角色有哪些比如普通用户、管理员、CEO’——请问用户的角色有哪些不同的角色有什么不同的权限请你尽快回复我谢谢”你看这种用自然语言进行的通信是不是非常自然、非常灵活而且开发起来也非常简单因为你不需要为每个通信场景定义一套结构化的消息格式——你只需要让智能体之间用自然语言沟通就行了1.2.3 原因三大语言模型LLM具有“强大的工具调用能力”可以很好地与外部工具和系统集成在软件工程领域我们经常需要用到很多外部工具和系统——比如Git版本控制、Docker容器化、Kubernetes容器编排、Jira项目管理、Slack团队沟通、PostmanAPI测试、PyCharmIDE……在大语言模型LLM兴起之前要让智能体与这些外部工具和系统集成是非常困难的——因为你需要为每个工具和系统开发一个专门的适配器Adapter而且开发出来的适配器的功能也非常有限。但现在不一样了——大语言模型LLM具有“强大的工具调用能力”比如OpenAI的GPT-4 Turbo支持Function CallingAnthropic的Claude 3 Opus支持Tool UseGoogle的Gemini 1.5 Pro支持Function Calling——你只需要给大语言模型LLM一个“工具定义”的提示词Prompt它就能很好地调用这个工具比如你给大语言模型LLM一个这样的工具定义用OpenAI的Function Calling格式{name:git_clone,description:Clone a Git repository to the local directory,parameters:{type:object,properties:{repo_url:{type:string,description:The URL of the Git repository to clone},local_dir:{type:string,description:The local directory to clone the repository to}},required:[repo_url,local_dir]}}然后你给大语言模型LLM一个这样的提示词“请你把MetaGPT的Git仓库克隆到本地的/home/laoyang/metagpt目录下”——它就能很好地调用git_clone这个工具完成Git仓库的克隆你看有了大语言模型LLM的工具调用能力让智能体与外部工具和系统集成就变得非常简单了——你只需要给每个工具一个“工具定义”的提示词然后让智能体调用这个工具就行了好了讲完了多智能体协作MAS的兴起相信大家都能理解“为什么大语言模型LLM的兴起会带动多智能体协作MAS在软件工程领域的应用”了。接下来我们就来聊聊今天的主角——MetaGPT的提出、特点与核心贡献。1.3 MetaGPT的提出、特点与核心贡献MetaGPT是由字节跳动和UC Berkeley联合提出的多智能体协作框架它的论文《MetaGPT: Meta Programming for Multi-Agent Collaborative Software Development》于2023年8月发表在arXiv上论文链接https://arxiv.org/abs/2308.00352它的开源代码于2023年7月发布在GitHub上GitHub链接https://github.com/geekan/MetaGPT。截至2024年5月MetaGPT的GitHub仓库已经获得了超过50,000个Star超过10,000个Fork超过2,000个Watch——这足以说明MetaGPT在技术圈的受欢迎程度1.3.1 MetaGPT的核心思想MetaGPT的核心思想非常简单但也非常深刻“把人类软件开发生命周期SDLC的标准操作流程SOP和最佳实践编码到多智能体协作框架中让AI虚拟团队像人类团队一样工作”什么是人类软件开发生命周期SDLC的标准操作流程SOP比如产品经理先写PRD然后架构师根据PRD写技术方案然后项目经理根据技术方案做任务分解和进度安排然后全栈工程师根据任务分解写代码然后测试工程师根据代码写测试用例然后文档工程师根据代码和测试用例写文档全栈工程师写代码之前要先看技术方案和任务分解写代码之后要先自己测试一下然后提交代码审查测试工程师写测试用例之前要先看PRD和技术方案写测试用例之后要先自己运行一下然后提交测试报告什么是人类软件开发生命周期SDLC的最佳实践比如PRD要包含产品的背景、目标、用户群体、功能需求、非功能需求、竞品分析、原型图技术方案要包含技术选型、系统架构图、数据库设计、接口定义、部署方案代码要符合编码规范要有注释要有单元测试文档要清晰、易懂、完整MetaGPT的做法就是把这些SOP和最佳实践编码到框架的代码中让AI虚拟团队严格按照这些SOP和最佳实践来工作这样一来AI虚拟团队的输出质量就有了保障——因为它们不是“自己写自己的自己说了算”而是“严格按照人类的SOP和最佳实践来工作”1.3.2 MetaGPT的核心特点MetaGPT有以下6个核心特点这也是它区别于其他多智能体协作