MetaGPT的多智能体方案和AutoGPT这类自主智能体有一个明显区别：它不是让多个Agent自由聊天，而是把一家软件公司的岗位职责和协作流程直接编码进框架。角色不只是系统提示词，而是一个包含观察、思考、行动、记忆的完整状态机；SOP也不是简单的任务顺序，而是约束消息流向和产物格式的状态图。理解这两层设计，才能用好MetaGPT。
角色定义：从岗位职责到可执行状态机
在MetaGPT中，角色通过Role类定义。一个角色必须提供name、profile、goal、constraints等字段，这些字段不是装饰，而是会进入提示词模板，直接影响模型生成内容的方向。比如一个工程师角色的goal写成“根据需求编写可运行代码”，另一个写成“输出高质量的工程实现”，模型在行动时的侧重就会不同。更关键的是，角色通过watch订阅消息类型，只有相关消息到来时才会触发后续动作，这就从机制上避免了多个智能体同时抢话。
下面是一个最小角色定义示例，展示工程师如何绑定写代码动作并监听需求消息：
from metagpt.roles import Role
from metagpt.actions import Action
from metagpt.schema import Message
class WriteCode(Action):
name: str = "WriteCode"
async def run(self, instruction: str):
# 实际项目中这里会调用 LLM 或代码生成服务
return "def main():\n print('hello')"
class Coder(Role):
name: str = "Coder"
profile: str = "软件工程师"
goal: str = "根据需求编写可运行代码"
constraints: str = "代码需要包含必要的异常处理"
def __init__(self):
super().__init__()
self._init_actions([WriteCode])
self._watch([Message])
这个例子中，Coder只绑定了一个WriteCode动作，并监听所有Message。实际项目中可以把监听范围收窄到某个动作类型，例如只监听产品经理的输出，避免工程师收到测试报告后也触发编码。Role内部还有一个_observe方法负责接收消息，随后_react决定是否执行以及执行哪个动作，_act调用动作并返回结果。这种状态机设计让角色的行为边界变得非常清晰。
相比直接给单个Agent写一长段提示词，MetaGPT的角色抽象还有两个好处。第一，角色可以复用，同一个工程师角色可以出现在不同SOP流程里，不需要重写提示词。第二，角色的记忆和上下文被封装在RoleContext中，消息历史、已完成动作、中间产物都能按角色维度管理，这为后续排查问题提供了明确线索。
SOP：用状态图约束多角色协作
角色定义解决的是单个岗位做什么，SOP解决的是一群人怎么配合。MetaGPT把软件研发流程抽象成有向图，节点是角色，边是消息。一个最典型的SOP是：用户需求进入产品经理，产品经理输出PRD；PRD流转给架构师，架构师输出技术设计方案；方案流转给工程师，工程师输出代码；代码流转给QA，QA输出测试报告。每一步的产物都不是自由文本，而是带有明确结构的中间文档。
这种设计最大的价值在于减少沟通随机性。自由对话式的多智能体系统容易出现重复问答、目标漂移和上下文污染。SOP强制每个角色只看到前一个角色的输出，并按预设格式继续加工，整个流程可以追踪到具体是谁在哪个环节引入了问题。下面展示如何使用Team和Role组装一个简化SOP：
from metagpt.roles import Role
from metagpt.actions import Action
from metagpt.schema import Message
from metagpt.team import Team
class CreatePRD(Action):
name: str = "CreatePRD"
async def run(self, requirement: str):
return f"产品需求文档：{requirement}"
class DesignArchitecture(Action):
name: str = "DesignArchitecture"
async def run(self, prd: str):
return f"技术方案：{prd}"
class PM(Role):
name: str = "PM"
profile: str = "产品经理"
goal: str = "输出清晰的产品需求文档"
constraints: str = "需求必须可量化"
def __init__(self):
super().__init__()
self._init_actions([CreatePRD])
self._watch([Message])
class Architect(Role):
name: str = "Architect"
profile: str = "架构师"
goal: str = "基于PRD输出技术方案"
constraints: str = "方案需要包含模块划分"
def __init__(self):
super().__init__()
self._init_actions([DesignArchitecture])
self._watch([CreatePRD])
team = Team()
team.hire([PM(), Architect()])
team.run_project("做一个天气应用")
上面的SOP虽然简单，但已经体现了关键原则：Architect不监听所有Message，而是只监听CreatePRD动作的输出。这样即使QA后续产生大量测试消息，也不会干扰架构师当前的工作。MetaGPT在标准团队中预置了更完整的SOP图，例如研发流程会包含Boss、产品经理、架构师、项目经理、工程师、QA等多个角色，并且每个角色输出都有对应的文档格式。项目启动后，消息会沿着图的边自动流转，直到所有节点完成。
自定义SOP时，不建议一开始就设计过于复杂的图。可以先从两三个角色开始，确认每个动作的输出字段足够明确，再逐步加入评审、测试和部署节点。中间产物最好使用结构化的Schema，而不是任意字符串，这样后续节点可以按字段解析，减少因为格式不一致造成的解析失败。
调优标准化流程：避开上下文膨胀、错误传播与角色耦合
标准化操作能减少随机性，但它不是没有代价。第一个常见问题是上下文膨胀。串行SOP中，前一个角色的完整输出会作为下一个角色的输入。如果PRD长达几千字，技术方案又追加几千字，到工程师节点时上下文已经非常拥挤。模型可能会忽略早期的重要约束，或者因为注意力分散而降低代码质量。处理方式有两种：一是在Action内部对输入做摘要或提取，只保留关键字段；二是把长文档落盘，消息中只传递文件路径和简短摘要。
第二个问题是错误传播。SOP是串行的，产品经理PRD里的一个错误描述，到了工程师阶段会被继续放大。更麻烦的是，如果没有反馈回路，错误只在最后才暴露。解决办法是在关键节点后增加校验动作。例如定义一个ValidatePRD动作，检查PRD是否包含验收标准、边界条件等内容，未通过就返回给上一节点重写。
class ValidatePRD(Action):
name: str = "ValidatePRD"
async def run(self, prd: str):
if "验收标准" not in prd:
return "校验失败：PRD缺少验收标准，需要补充"
return "校验通过"
第三个问题是角色耦合。固定SOP让流程变得可控，但也降低了灵活性。如果某个任务需要工程师先做技术预研再写代码，而当前SOP没有这个节点，新增角色会牵动整张图。实际项目中可以采用条件分支或人工评审节点来缓解。比如在架构师输出后设置一个人工确认动作，由人判断是继续进入开发，还是退回重新设计。MetaGPT的图结构支持这种分支，但需要在设计阶段就明确条件，而不是等运行时再临时调整。
总的来说，MetaGPT的角色定义和SOP是一套面向软件研发场景的多智能体组织方式。它把提示词、工具调用、消息订阅和状态流转统一到角色抽象中，再用SOP图管理协作顺序。理解了角色是行为边界、SOP是消息管线这两个核心，你在做多智能体应用时就能减少无效对话，获得更稳定的输出。