夜雨聆风先看一件事。我给它一句话——write a 2048 game,然后什么都没再管。它内部一支有名有姓的 AI 团队就自己开工了:先有一个团队负责人掂量这活多大、决定怎么走,产品经理把需求写成一份正经的文档,架构师据此画出类图和时序图,工程师严格照着设计写出代码。最后落到磁盘上的,是一个分门别类、可直接接手的项目目录——需求、设计图、源码,一样不少。
中间没有我。像一家真实软件公司里的同事一样,一个把交付物递给下一个,各写各的文档,最后合出一个能跑的东西。
这不是我编的剧本,是 GitHub 上一个叫 MetaGPT 的开源项目自带的示例工程。它由 DeepWisdom(深度赋智) 团队牵头开发,背后有一篇被 ICLR 2024 收录的 论文。截至 2026 年年中,它在 GitHub 上攒下了将近 6.9 万颗星、8800 多次 fork,是“多智能体 + 软件开发”方向最有代表性的开源框架之一。
它的一句话定位,写在项目主页最显眼的地方:“第一家 AI 软件公司,迈向自然语言编程。” 你输入一句需求,它输出用户故事、竞品分析、需求文档、数据结构、API、代码——把一家软件公司从接需求到交付的整条链路,搬成了一条 agent 流水线。
先把一个底线说清楚,免得期待错位:MetaGPT 能稳定跑出来的,是中小规模、需求明确的项目(小游戏、小工具、脚本),它不是能替你造一个复杂线上系统的“一键接管”神器。它更像一个把软件工程的标准流程(SOP)固化下来、让一队 AI 照着走的框架。把这条底线放好,我们来做这篇真正要做的事:从业务架构和技术架构两个层面,把这个项目彻底拆开。
下面这篇的所有产物——需求文档、类图、时序图、代码——都取自 MetaGPT 官方仓库里那个 2048 示例工程(tests/data/demo_project),是它跑完整套流程后真实吐出来的、互相对得上的一套东西,不是我手写的示意。我们就顺着这一套,看它到底是怎么搭起来的。
〇、先看它怎么跑起来:一句话,一家 AI 公司开工
先看它实际是怎么被一句话拉起来的。
它是个标准 Python 项目,建好环境、装上依赖、配一个大模型的 key(支持 OpenAI、Anthropic、DeepSeek、Qwen、GLM 等十多家),就能用。最简单的跑法是命令行一句话:
metagpt "write a cli 2048 game"或者当成库嵌进代码,核心也就一句:
from metagpt.software_company import generate_reporepo = generate_repo("Create a 2048 game") # 传入一句需求print(repo) # 打印出生成的项目路径一句 generate_repo("write a 2048 game"),把一句自然语言需求丢进去,那支 AI 团队就自己开工了。当需求需要走完整流程时,它做的第一件事,不是急着写代码,而是先让产品经理把这句话展开成一份正经的产品需求文档。下面是官方 2048 示例工程里真实产出的 PRD 节选(字段都是钉死的):
Original Requirements:write a 2048 gameProduct Goals:打造有黏性、好玩的游戏体验;保证流畅的性能与响应;提供可定制的玩法设置。User Stories:作为玩家,我希望能在不同设备和屏幕尺寸上玩;作为玩家,我希望随进度提升难度;作为用户,我希望能撤销上一步。Requirement Pool:
[P0]实现游戏逻辑与界面 ·[P1]加入多难度和计分 ·[P2]集成自定义设置与撤销
一句“write a 2048 game”,被扩写成了产品目标、用户故事、带优先级的需求池——这一步的产出,就成了下一环架构师开工的输入。整条流水线跑完,它在 workspace/ 下留给你的是一个真实的项目目录:需求文档、设计图、源代码,各归各位。
一、业务架构设计:它在“业务上”复刻了一家软件公司
理解 MetaGPT,先别看代码,先看它在“业务”上模拟了什么。
答案是:一家真实软件公司交付一个项目的完整流程。 现实里没有哪个项目是一个人从需求想到上线——先有人接住需求、拆活派活,产品经理把模糊想法写成需求文档,架构师定技术方案,工程师照着写代码。MetaGPT 把这套分工,一比一搬成了一条 agent 流水线。
一条角色分明的协作流水线
它把软件公司的 SOP(标准作业流程)排成了一条接力链:需求文档往下传给设计,设计往下传给编码,一环接一环。这就是那句著名口号的由来——“Code = SOP(Team)”:把标准流程套在一队 LLM 身上,就能产出代码。
有意思的是,源码里给每个角色都起了人名(不是冷冰冰的职位代号),运行时它们就用这些名字互相喊话、递交付物。摊开看,这支团队是这样分工的(职责都摘自源码里各角色的 goal 定义):
Mike|团队负责人(TeamLeader):接住用户需求,先掂量这活多大、规划要做哪些事、派给谁,并在过程中协调。它是整个团队的“大脑”和“调度台”。 Alice|产品经理(ProductManager):把一句话需求,写成一份正经的产品需求文档(PRD)——产品目标、用户故事、竞品分析、需求池。它的目标定义原文就是“Create a Product Requirement Document”。 Bob|架构师(Architect):读 PRD,产出系统设计——目标写得很直白:“设计一个简洁、可用、完整的软件系统”。它交付的不是空话,而是数据结构与接口(一张类图) 和 程序调用流程(一张时序图)。 Alex|工程师(Engineer):照着架构师的设计写代码。关键是,它不许自己改设计——这背后的约束,后面技术架构会细讲。 David|数据分析师(DataAnalyst):接手数据相关的活(数据分析、脚本执行、终端操作、文档问答等),是这支团队里偏“动手跑”的一员。
值得一提的是,这份默认名单其实近两年悄悄变过:早年满网都在讲的“产品经理 → 架构师 → 项目经理 → 工程师 → 测试”固定五人流水线,在今天的源码里已经重排——generate_repo() 真正雇进团队的是上面这五个角色,老的项目经理、测试工程师(QaEngineer)都被注释掉了,取而代之的是一个统管调度的团队负责人和一个数据分析师。也就是说,它从“一条写死的 SOP 流水线”,进化成了由团队负责人编排的 agent 团队。
一句话概括这套业务架构:它把“一家软件公司交付一个项目”拆成了角色分明、各有交付物的协作链——接需求 → 写需求 → 定设计 → 照图编码,上一环的产出,就是下一环开工的输入。
二、技术架构设计:这条流水线在“技术上”怎么跑起来
业务流程清楚了,真正难的是:怎么把一队 agent、多轮协作、文档交接、模型调用,工程化成一个稳定可跑的系统?这就是技术架构要解决的。
MetaGPT 的技术架构,有三根支柱最值得拆:结构化交接、消息总线、预算闸门。
2.1 通信层:agent 之间传"结构化文档",而不是"聊天记录"
这是 MetaGPT 最核心、也最容易被讲丢的一个设计。
多 agent 框架有两条路线。一条是让 agent 们用自然语言互相聊(代表作是另一个明星项目 ChatDev,它把公司做成一群 agent 开会对话)。这条路的问题是:agent 一多、话一长,就容易寒暄、复述、跑题,token 烧得快还容易失焦。
MetaGPT 走的是另一条:agent 之间主要通过“结构化文档”协作。 每个角色的产出,不是一段大白话,而是字段固定的文档。这不是我脑补的,是写在它每个 action 的输出定义里的——
产品经理写的 PRD,字段是钉死的:
Product Goals(产品目标)、User Stories(用户故事)、Competitive Analysis(竞品分析)、Requirement Pool(需求池)、Anything UNCLEAR(尚不明确之处)
架构师出的设计,字段也是钉死的:
Implementation approach(实现思路)、Data structures and interfaces(数据结构与接口,一张 Mermaid 类图)、Program call flow(程序调用流程,一张 Mermaid 时序图)、Anything UNCLEAR
尤其值得注意的是架构师那两项:它交出的“数据结构与接口”是一张 Mermaid 类图,“程序调用流程”是一张 Mermaid 时序图——也就是说,架构师给下游的不是几段描述,而是可直接渲染的工程图纸。下游工程师接到的是图,不是话。
最能说明问题的是工程师那一环。MetaGPT 在给工程师的提示词里,有一句近乎命令的话(原文):
“YOU MUST FOLLOW ‘Data structures and interfaces’. DON'T CHANGE ANY DESIGN.” （你必须遵循“数据结构与接口”设计。不许改动任何设计。)
这就是结构化交接的威力:架构师把类图和接口定死,工程师只能照着实现,不许自由发挥。上一环的产出,是下一环必须遵守的契约。多 agent 系统最怕的“各自理解、越走越歪”,就是被这种“传文档、守契约”的方式摁住的。一句话总结:ChatDev 让 agent 开会聊,MetaGPT 让 agent 交文档。
2.2 编排层:一条"消息总线",谁该收就收
那这些文档在 agent 之间是怎么流动的?靠的不是谁直接调用谁,而是一个共享的消息环境(Environment)。
可以这么理解:整个团队待在一个共享的“工作空间”里,任何一个 agent 产出结果,都通过 publish_message(发布消息)扔进这个空间;每个 agent 各自“订阅”自己关心的消息类型,该自己接的活就接走。产品经理写完 PRD 发布出去,架构师因为订阅了“PRD 类消息”而接住它、开始设计——发布 / 订阅,而不是一根写死的调用链。
这套设计的好处是解耦:加一个角色、改一处流程,不用去重连整条流水线,只要让新角色订阅它该关心的消息即可。而前面讲的 TeamLeader,正是靠一个 publish_team_message 工具,在这个消息空间里做调度和派活。
2.3 成本层:一个"预算闸门",烧完就停
多 agent 系统绕不开一个现实问题——烧钱。一队 agent 来回协作、反复评审,如果不设上限,token 成本可能失控。
MetaGPT 的处理很直接:给整个项目设一个投资额(investment)。你在启动时给它一笔“预算”(比如几美元),它内部有一个成本管理器(cost_manager)盯着累计花费,每跑一步前先查一次余额(_check_balance)——一旦花费触到预算上限,直接抛出“预算不足”停下来,而不是闷头把钱烧光。
这个设计朴素但重要:它把“AI 公司”这个比喻落到了实处——你是老板,你投多少钱,它就干多少活,钱花完就收工。 对一个可能失控的多 agent 系统来说,这道闸门是必要的安全阀。
2.4 产出层:代码严格照着设计图长出来
跑完之后,它不是给你一段聊天记录,而是在 workspace/<项目名>/ 下,生成一个真实的项目目录:需求文档在 docs/、设计图在 resources/(类图、时序图分开放)、源代码按文件清单一个个落好。
最能说明“照图施工”的,是把代码和设计图摆在一起看。前面架构师那张类图里,Game 类写着 move(direction)、_move_left、add_new_tile 这些方法——工程师真实产出的 game.py,就是一字不差地把它们实现了出来:
classGame:defmove(self, direction: str):if direction == "up": self._move_up()elif direction == "down": self._move_down()elif direction == "left": self._move_left()elif direction == "right": self._move_right()defadd_new_tile(self): empty_cells = self.get_empty_cells()if empty_cells: x, y = random.choice(empty_cells) self.grid[x][y] = 2if random.random() < 0.9else4# 九成出 2,一成出 4类图里有的方法,代码里一个不少;类图里没有的,代码里也不会凭空冒出来。设计是契约,代码是对契约的兑现——这正是结构化交接一路贯穿到最后的结果。
这也是 MetaGPT 和“聊天式” AI 编程最不一样的地方:它的最终交付物是落在磁盘上、可直接接手的工程文件,而不是需要你再从对话里一段段抠出来的代码。
三、退一步看:它真正示范的,是"把软件工程的规矩,教给了一队 AI"
把业务架构和技术架构都拆完,会发现一条贯穿始终的主线——MetaGPT 赌的不是“单个 AI 更聪明”,而是“一队 AI + 一套规矩”。
它对 AI 的假设很清醒:单个模型直接写复杂项目,容易想到哪写到哪、前后不一致。于是它不追求一个全能的 agent,而是把软件工程几十年沉淀下来的协作规矩——先写需求再设计、设计定契约、编码守契约、产出用规整文档而非闲聊——固化成一套流程,套在一队各有分工的 agent 身上。
这和 2026 年整个 AI 领域的一个趋势是一致的:从“问一个大模型、拿一段代码”,走向“一队有角色、有流程、有交付物的 agent 协作产出”。MetaGPT 之所以值得拆,不在于它能不能替你写完所有代码,而在于它把“一家软件公司该有的分工与规矩”完整地落进了工程实现——从一句话需求,到 PRD,到设计图,到严格照图写出的代码,每一步都看得见、对得上。
四、它的天花板:架构再漂亮也兜不住的事
拆完架构,得把另一面说透。上面那套 2048 之所以能从头跑到尾、产物齐整,一半也因为它足够小、足够明确。换个更大的项目,同一套机制就没那么稳了。
它比你想象的脆弱,栽点常在“交接”这一环。 前面说过,MetaGPT 的角色之间靠严格格式的消息交接——这本是它压住幻觉的优点;但反过来,它也把稳定性押在了“每个 agent 的每一次回复,都要严格守住格式”上。链条越长、交接越多,大模型偶尔吐出一句不合规的内容(比如本该是 JSON 的地方给了段散文)的概率就越高;而只要下游一解析失败,整条流水线就可能断在半途。规划得越完整,这种“行百里者半九十”的断法就越可惜。所以你会看到:一个 2048 它跑得漂亮,一个带前后端和数据库的中型系统,它常常在中途某一次交接上掉链子。
它擅长的是“明确、中小规模”的项目。 一句话需求、边界清楚的小游戏小工具,它多数时候能跑得漂亮;但需求一模糊、系统一复杂、涉及大量外部依赖和真实业务约束,它就会力不从心——毕竟每个角色的“专业能力”,本质仍是大模型在按提示词扮演,不是真的资深工程师。
“照着设计写代码”是双刃剑。 结构化交接保证了不跑偏,但如果架构师那一步的设计本身就有缺陷,工程师“不许改设计”反而会把错误忠实地实现下去。规矩能防止散漫,防不住上游的判断失误。
它的价值在“怎么组织”,不在“替你交付一切”。 这套系统真正给你的,不是一个能一键接管所有开发的黑盒,而是一个看得见、可拆解的协作过程——你能看到一句需求怎么变成 PRD、PRD 怎么变成设计图、设计怎么约束出代码,以及工程上怎么用消息总线和预算闸门把这一切稳住。对于想搞懂“一个严肃的多 agent 系统到底怎么搭”的人来说,这种透明,远比“它能不能替我写完项目”值钱。
它没有让你从此不用写代码,但它让你看清了:要让一队 AI 像一家公司那样有序地协作产出,工程上到底得下多少功夫。
本文涉及的项目与资料:MetaGPT(DeepWisdom)、论文 arXiv:2308.00352、对比项目 ChatDev。文中的 PRD、类图、时序图、代码,均取自 MetaGPT 官方仓库自带的 2048 示例工程(
tests/data/demo_project),为其真实产出。 提醒:MetaGPT 是研究与工程用途的开源框架,适合明确、中小规模的项目;生成结果需人工审阅后再用于生产,别当成能一键交付复杂系统的成品。
