MetaGPT是一个基于大语言模型的多智能体框架，它把真实软件公司里的关键岗位抽象成智能体，让它们在同一个项目里按流程配合。与让一个模型从头做到尾不同，MetaGPT强调岗位边界和交接物，用角色分工解决复杂任务容易跑偏、漏需求的问题。
一、MetaGPT中的核心角色定位
在MetaGPT的默认流水线中，产品经理、架构师和工程师是最常被提及的三类基础角色。产品经理负责把用户的自然语言想法转成结构化的产品需求文档，相当于把模糊目标讲清楚。架构师拿到需求后，设计系统模块、接口关系和关键技术选型，给出可落地的蓝图。工程师则依据前面两份文档编写具体代码、配置文件与测试用例。
这种设定并不是简单贴标签。每个角色在框架里都有专属的提示词、可用工具和输出规范。比如产品经理输出的是带有用户故事和优先级的文档，架构师输出的是带目录树的系统设计，工程师输出的是仓库代码。正因为产物格式固定，后一个角色才能直接消费前一个角色的成果，不必反复猜意图。
1. 产品经理的职责边界
产品经理智能体主要做需求澄清与范围控制。它会把一句话需求扩写成背景、目标、功能列表和非功能要求。实践中，如果用户说做一个待办工具，产品经理会补全使用人群、核心页面和数据处理方式，避免工程师自由发挥导致偏离。
它还承担排优先级的工作。通过标明哪些是必须先做的主流程，哪些是可延后的优化，后续角色可以把精力放在关键路径上。这种前置梳理大幅降低了架构师和工程师在中期返工的概率。
2. 架构师与工程师的差异
架构师不写业务代码，只决定系统怎么拆。它会规划模块名、调用顺序和存储方案，让复杂系统变得可分工。工程师严格按图施工，遇到架构文档里没覆盖的异常，通常先记到待确认列表，而不是自行改设计。
二者最大的区别是抽象层级。架构师输出的是关系和规则，工程师输出的是实现和细节。MetaGPT用这种分层，模拟了现实团队里先设计再编码的习惯，使大模型生成的内容具备一致性。
二、三者如何完成协作闭环
MetaGPT的协作不是群聊式自由讨论，而是基于消息和文档的有序流转。用户给出任务后，框架按既定顺序唤醒角色，前一个角色的产物自动成为后一个角色的输入上下文。这种方式减少了多头指挥，也方便追溯责任。
当工程师发现需求或设计有矛盾时，可以触发修订消息回传给上游。此时产品经理或架构师会更新文档，再向下游同步。整个闭环保证了变更被记录，而不是散落在对话历史里被人遗忘。
1. 以文档为契约的交接
在MetaGPT里，文档就是合同。产品经理文档定义做什么，架构师文档定义怎么做，工程师代码证明做完了。因为都落成了文件，任何人都能打开看上游怎么想，下游怎么改。
这比纯对话协作更稳。对话容易丢失重点，文档则强制角色产出可检查的中间结果。团队外部的人也能通过读文档快速理解项目，不必翻几百轮聊天记录。
2. 消息订阅与角色唤醒
框架内部采用发布订阅机制。产品经理发布需求文档后，架构师订阅到该消息被激活；架构师发布设计后，工程师被激活。没有被订阅的角色处于休眠，不会乱插手，保证了流程干净。
这种机制也支持并行。若系统分多个子系统，不同工程师可同时订阅同一份架构文档的不同章节，各自实现再合并。角色分工由此从线性变成可扩展的协作网络。
三、对比单智能体与真实团队
单智能体处理小脚本尚可，一旦涉及多模块系统就容易前后矛盾。它没有岗位概念，写需求时顺手把实现也定了，到编码阶段又推翻，造成资源浪费。MetaGPT用分工把思考和实现切开，各角色专注自己一层。
和真实人类团队比，MetaGPT角色不会疲劳、不闹情绪，且严格读文档办事。但它也缺少人类的主观判断，所以当需求极度模糊时，仍需要用户在产品经理阶段给足背景，否则智能体之间也会基于错误前提空转。
| 协作模式 | 优点 | 风险 |
|---|---|---|
| 单智能体 | 启动快、适合小任务 | 大项目易逻辑断裂 |
| MetaGPT角色分工 | 职责清、可追溯、易并行 | 上游错则全线错 |
| 真实人类团队 | 能灵活判断模糊项 | 沟通成本高、易延期 |
四、用好角色分工的实践建议
想让产品经理、架构师和工程师真正协作顺，第一步是给清初始指令。把业务背景、约束条件和期望产出写细一点，产品经理才能产出靠谱文档。指令越糊，后面角色补全的空间越大，偏差也越大。
第二步是 review 中间文档。在架构师出图后、工程师写码前，人工扫一遍设计是否合理。MetaGPT允许你中途改文档再续跑，这比等代码出来再重来便宜得多。把智能体当同事，关键节点做把关，效率最高。
角色分工的价值不在于替你思考，而在于把思考过程外显成可管理的步骤。
总体看，MetaGPT用产品经理、架构师、工程师的分岗协作，把软件开发里成熟的岗位逻辑搬进大模型。理解每张文档的作用和流转顺序，就能用它稳稳吃下中等复杂度的项目，而不必担心一个模型想到哪写到哪。