[AI Agent学习] MetaGPT源码浅析

前言

工作上，需要使用AI Agent，所以需要深入学习一下AI Agent，光阅读各种文章，总觉无法深入细节，所以开看各类AI Agent相关的开源项目，此为第一篇，学习一下MetaGPT的源码。

基本目标

MetaGPT是一个多智能体框架，他抽象了一个软件公司中的主要角色，用不同的AI Agent去扮演，这些AI Agent包括产品经理、软件架构师、项目经理、工程师，这些AI Agent会按照开发团队设计好的SOP去交互并最终产出一个项目。

老习惯：不为读而读，为解决某些问题或理清某些概念而读，那么面对MetaGPT，我有以下目标：

• MetaGPT是怎么抽象出的软件公司开发流程的？SOP具体在代码上是怎么实现的？
• MetaGPT中不同AI Agent是怎么交互的？
• 从效果上看，MetaGPT输出的内容是比较格式化的，要做到这样的效果，prompt是怎么写的？
• MetaGPT是怎么抽象具体的职业的？比如产品经理是怎么抽象的。

本文主要来从源码中，找到上面问题的答案。

入口

虽然README.md中说，很多同学运行时会有点问题，但我感觉，运行起来还是很轻松的，相比于早期的sd-webui，那是友好太多了，所以这里不多提，直接按README中的内容run一下就好了。

直接看到入口方法

# startup.py 

async def startup(
    idea: str,
    investment: float = 3.0,
    n_round: int = 5,
    code_review: bool = False,
    run_tests: bool = False,
    implement: bool = True
):
    # 1.开公司
    company = SoftwareCompany()
    # 2.雇员工
    company.hire([
        ProductManager(),  # 产品经理
        Architect(), # 架构师
        ProjectManager(), # 项目经理
    ])

    if implement or code_review:
        # 3.雇开发
        company.hire([Engineer(n_borg=5, use_code_review=code_review)])

    if run_tests:
        
        company.hire([QaEngineer()])
 # 4.设置金额（这次运行最多能消耗多少美金的GPT4）
    company.invest(investment)
    # 5.老板的需求
    company.start_project(idea)
    # 6.跑几轮
    await company.run(n_round=n_round)

从startup看，整个流程很清晰，可读性很高！

先看看SoftwareCompany类，部分代码如下：

# metagpt/software_company.py

class SoftwareCompany(BaseModel):
 # 环境
    environment: Environment = Field(default_factory=Environment)
    investment: float = Field(default=10.0)
    idea: str = Field(default="")

    async def run(self, n_round=3):
        """Run company until target round or no money"""
        while n_round > 0:
            # self._save()
            n_round -= 1
            logger.debug(f"{n_round=}")
            self._check_balance()
            await self.environment.run()
        return self.environment.history

通过SoftwareCompany类抽象一个软件公司，阅读代码后，你会发现SoftwareCompany类中的environment对象很重要，公司里的不同AI Agent都会与environment对象交互，这个抽象也很巧妙，就是在公司里，同事间的交流确实在公司这个“环境”里传播。

然后就是run方法，看到startup方法的最后，就是调用SoftwareCompany类的run方法，该方法会检测一下余额以及运行的轮数，如果余额不够或轮数超了，就会停止运行。

因为MetaGPT底层是使用openai api的，每次请求都需要花钱，你设置一个预算，默认是3美元，跑满3美元，就算任务没有完成，也会强行结束。

SoftwareCompany类的run方法会调用environment对象的run方法，代码如下：

# metagpt/environment.py/Environment

 async def run(self, k=1):
        """
        Process all Role runs at once
        """

        for _ in range(k):
            futures = []
            for role in self.roles.values():
                future = role.run()
                futures.append(future)
            # 当调用 asyncio.gather(*futures) 时，它会同时运行传递进来的协程，这些协程会在后台并发执行，而不会阻塞主线程。
            await asyncio.gather(*futures)

从上面代码可知，这才是真正的入口，循环所有的roles，然后调用每个role的run方法，整个过程通过python协程异步并发的运行，从而提高程序的运行效率。

这里的role就是不同身份的员工，其本质就是使用不同Prompt的请求openai的代码逻辑。

我们需要阅读一下role相关的代码，来尝试理解顺序性的问题。

role

在startup方法中，我们首先雇佣了3个不同的role：

company.hire([
        ProductManager(),  # 产品经理
        Architect(), # 架构师
        ProjectManager(),
    ])

雇佣的顺序是有讲究的。一开始雇佣的是ProductManager实例，也就是，这里已经执行了实例ProductManager类的实例化代码了：

# metagpt/roles/product_manager.py

class ProductManager(Role):

    
    def __init__(self, 
                 name: str = "Alice", 
                 profile: str = "Product Manager", 
                 goal: str = "Efficiently create a successful product",
                 constraints: str = "") -> None:
   
        super().__init__(name, profile, goal, constraints)
        # 1.写产品需求文档（Product Requirement Document）
        self._init_actions([WritePRD])
        # 2.观察老板的需求
        self._watch([BossRequirement])

上面代码中，_init_actions与_watch都是Role类中的方法，也就是当前产品经理这个role自己的方法。它初始化了自己的动作：写需求文档，以及定了自己要观察的东西：老板的需求。

BossRequirement怎么来的？在startup方法中，我们调用了SoftwareCompany的start_project方法，该方法会就我们的需要以BOSS的身份发送到SoftwareCompany的environment中，代码如下：

# metagpt/software_company.py/SoftwareCompany

def start_project(self, idea):
        """Start a project from publishing boss requirement."""
        self.idea = idea
        # Role初始观察到的message
        self.environment.publish_message(Message(role="BOSS", content=idea, cause_by=BossRequirement))

这个过程类似于，公司里，老板走到产研区域，大喊一声，我要做个xxxx，然后大家就知道了，metagpt就是抽象了这个过程，其他的role可以通过SoftwareCompany的environment的读到老板和其他role的信息。

当environment对象的run方法被运行时，role的run方法就会被执行，

async def run(self, message=None):
        if message:
            # 1.如果有人给你发消息，则将消息存入role的短期记忆中
            if isinstance(message, str):
                message = Message(message)
            if isinstance(message, Message):
                self.recv(message)
            if isinstance(message, list):
                self.recv(Message("\n".join(message)))
        # 2.观察环境中的信息，看看有没有需要处理的
        elif not await self._observe():
            # If there is no new information, suspend and wait
            logger.debug(f"{self._setting}: no news. waiting.")
            return
     # 3.如果有需要处理的，则通过 _react 处理，并获得处理结果
        rsp = await self._react()
        # 4.将处理的结果发到 environment 中
        self._publish_message(rsp)
        return rsp

run方法的逻辑也很清晰，先观察environment中的信息，如果有需要处理的，则_react进行处理并将结果发送回environment中。

那具体怎么观察呢？看到_observe方法的代码：

# metagpt/roles/role.py/Role
 
 async def _observe(self) -> int:
        if not self._rc.env:
            return 0
        # 从env的短期记忆中，获取信息
        env_msgs = self._rc.env.memory.get()
        # 从env中观察要观察的对象，获得对应的message
        observed = self._rc.env.memory.get_by_actions(self._rc.watch)
        # 记下来（role自己的memory）
        self._rc.news = self._rc.memory.remember(observed)  # remember recent exact or similar memories

        for i in env_msgs:
            # 将环境中的信息记到role memory中
            self.recv(i)

        news_text = [f"{i.role}: {i.content[:20]}..." for i in self._rc.news]
        if news_text:
            logger.debug(f'{self._setting} observed: {news_text}')
        return len(self._rc.news)

    def recv(self, message: Message) -> None:
        if message in self._rc.memory.get():
            return
        # 记一下信息
        self._rc.memory.add(message)

上面代码中，self._rc.env 对象就是当前role所在的环境，这里用了常见的双向关联技巧。

当其他role通过publish_message方法向environment发消息时，消息其实存在environment的memory中，在_observe方法中，首先environment的memory中读取消息，然后在通过get_by_actions方法去获得需要某个action产生的message，以ProductManager为里，ProductManager通过_watch方法将BossRequirement设置为需要观察的对象。

当role调用get_by_actions时，会去找BossRequirement对应的message（其实就是需要message，然后交给GPT4去处理），get_by_actions代码如下：

# metagpt/memory.py/Memory

 def get_by_action(self, action: Type[Action]) -> list[Message]:
        """Return all messages triggered by a specified Action"""
        return self.index[action]

    def get_by_actions(self, actions: Iterable[Type[Action]]) -> list[Message]:
        """Return all messages triggered by specified Actions"""
        rsp = []
        for action in actions:
            if action not in self.index:
                continue
            rsp += self.index[action]
        return rsp

    def add(self, message: Message):
        """Add a new message to storage, while updating the index"""
        if message in self.storage:
            return
        self.storage.append(message)
        if message.cause_by:
            self.index[message.cause_by].append(message)

因为get_by_actions其实就是从self.index中找到action这个key对应的value，所以self.index是什么就很关键，而这就需要看到add方法，以BossRequirement为例，就是将key设置为BossRequirement，然后存message。

简单而言，get_by_actions方法会获取由role的_watch方法指定的要观察的对象其对应的message，作为self._rc.news，然后role将这些news存到memory中。

如果role通过_observe方法观察到了news，那么就需要执行_react方法：

# metagpt/roles/role.py

 async def _react(self) -> Message:
        """Think first, then act"""
        await self._think()
        logger.debug(f"{self._setting}: {self._rc.state=}, will do {self._rc.todo}")
        return await self._act()

先看到_think方法：

# metagpt/roles/role.py/Role

 async def _think(self) -> None:
        # 1.如果只有一个动作，那么就直接让_act执行这一个动作则可
        if len(self._actions) == 1:
            self._set_state(0)
            return
        prompt = self._get_prefix()
        # 2.整合role的memory和state到prompt中，让GPT4处理
        prompt += STATE_TEMPLATE.format(history=self._rc.history, states="\n".join(self._states),
                                        n_states=len(self._states) - 1)
        next_state = await self._llm.aask(prompt)
        logger.debug(f"{prompt=}")
        if not next_state.isdigit() or int(next_state) not in range(len(self._states)):
            logger.warning(f'Invalid answer of state, {next_state=}')
            next_state = "0"
        self._set_state(int(next_state))

_think方法的作用是设置state，然后_act才会根据设置好的state决定要执行的action，如果当前role只有一个state，那么state直接设置成0则可，如果有多个action，那么就交由GPT4去判断：将role的memory中的信息全部取出作为history，然后将role的所有state也整合起来，一起放到prompt中，交由GPT4去选择当前history下要做什么action是最好的，让其返回state。

然后看_act方法：

async def _act(self) -> Message:
        logger.info(f"{self._setting}: ready to {self._rc.todo}")
        # 让role执行相应的action
        response = await self._rc.todo.run(self._rc.important_memory)
        if isinstance(response, ActionOutput):
            msg = Message(content=response.content, instruct_content=response.instruct_content,
                        role=self.profile, cause_by=type(self._rc.todo))
        else:
            msg = Message(content=response, role=self.profile, cause_by=type(self._rc.todo))
        # 记下当前action返回的msg
        self._rc.memory.add(msg)
        # logger.debug(f"{response}")

        return msg

_act方法的逻辑就是执行self._rc.todo对应的action，这个action是_think方法通过_set_state方法设置的，比如产品经理只有一个action：WritePRD，那么就会执行WritePRD的run方法，需要注意的是，为了让不同的role可以交互，_act还会产生message，每个message都会设置cause_by参数，以表明当前的message是由哪个动作产生的，其他role就可以通过_watch方法看到需要的message了。

随后，我们看到WritePRD的细节，代码如下：

#  metagpt/actions/write_prd.py
class WritePRD(Action):
    def __init__(self, name="", context=None, llm=None):
        super().__init__(name, context, llm)

    async def run(self, requirements, *args, **kwargs) -> ActionOutput:
        sas = SearchAndSummarize()
        rsp = ""
        info = f"### Search Results\n{sas.result}\n\n### Search Summary\n{rsp}"
        if sas.result:
            logger.info(sas.result)
            logger.info(rsp)

        prompt = PROMPT_TEMPLATE.format(requirements=requirements, search_information=info,
                                        format_example=FORMAT_EXAMPLE)
        logger.debug(prompt)
        prd = await self._aask_v1(prompt, "prd", OUTPUT_MAPPING)
        return prd

WritePRD类的本质也是一个prompt，它会接受requirements参数，从metagpt整个流程看，requirements参数就是老板的需求message，也就是产品经理要基于老板需求message写出PRD（产品需求文档），获得结果后，自己再记到role到memory中。

role间的交互

一开始时，用户以BOSS role输入一个需求message，这个message被丢到environment上，代码如下，主要publish_message方法的cause_by使用了BossRequirement，为了方便解释，我将需求定为：开发一个Crypto的量化交易系统。

# metagpt/software_company.py/SoftwareCompany

 def start_project(self, idea):
        self.idea = idea
        # Role初始观察到的message
        self.environment.publish_message(Message(role="BOSS", content=idea, cause_by=BossRequirement))

ProductManager通过_watch方法关注BossRequirement，从而在运行ProductManager时，_observe方法会收到【开发一个Crypto的量化交易系统】的message作为self._rc.news，随后调用_think和_act方法，因为只有WritePRD这一个action，所以就调用WritePRD的run方法了，并将role memory中记忆的【开发一个Crypto的量化交易系统】的message作为requirements，传入了prompt中。

从startup方法相关代码可知，ProductManager后是Architect（架构师），Architect通过_watch方法关注WritePRD。

在ProductManager的_act中，将Message添加到environment中，cause_by为WritePRD，此时就可以被Architect通过_watch方法关注，并通过_observe方法获得WritePRD产出的结果，存入Architect的记忆中，然后作为WriteDesign这个action的输入，WriteDesign会将WritePRD的内容放到它的prompt中。

至此，role的交互流程就比较清晰了。

回答问题

Metagpt还有很多代码细节，但读到这，已经可以回答开头的问题了：

1.MetaGPT是怎么抽象出的软件公司开发流程的？SOP具体在代码上是怎么实现的？SOP就是不同role之间交互的顺序，比如产品经理需要BOSS的message作为他prompt的约束，而产品经理的产出是架构师的输入，不同角色间的输入输出，就是SOP。

2.MetaGPT中不同AI Agent是怎么交互的？role通过_watch确定要从哪个role的哪个action中获得这个action的输出，具体获取的过程在_observer方法中，获得其他role的message后，如果当前的role有多个action可执行，则通过_think去选一个action（使用env的memory，即当前环境中发生的内容），再通过_act去具体的执行action，执行action时，会从role的memory中获取需要的message。

3.从效果上看，MetaGPT输出的内容是比较格式化的，要做到这样的效果，prompt是怎么写的？MetaGPT的prompt的设计形式值得学习，它主要使用MarkDown格式来设计prompt，多数prompt中都会有context、example，从而让GPT4更好的发挥zero-shot能力，想知道具体的，建议直接拉代码下来看。

4.MetaGPT是怎么抽象具体的职业的？从职业这个角度讲，主要通过action和承接的message来抽象，比如产品经理，就抽象成，接收老板需求，产出产品需求文档，将需求文档给到架构师的对象，然后每个role生成的结果都会放到env中，其他人也可以看到（很多角色只有一个action，就不会用到env中的message）。

结尾

我自己跑了几遍MetaGPT，还是有明显的局限性的。如果我按example的形式，让他写python小游戏，过程是丝滑的，但我换成让MetaGPT帮我设计一个今日头条的广告推荐系统，他就给了我下面这样的东西，很明显，不太可用。

此外，在阅读源码的过程，也发现MetaGPT团队自己提出的一些问题，比如大段的代码受限GPT4的tokens限制还做不到，切开生成，可能又需要提供额外的code作为context，效果也没那么理想。

当然MetaGPT的team我还是很respect的，代码设计清晰，然后让MetaGPT可以实现自举的这个目标也很酷。

以上。