AutoGen、CrewAI、MetaGPT：多 Agent 框架的三种设计哲学

假如你正在用 AI 写代码，你想要的不只是单打独斗，而是让多个 AI 组队干活——一个写需求，一个画架构，一个写代码，一个做测试，最后还能自动部署。你打开 GitHub，发现有三个热门框架都号称能做到：微软的 AutoGen、CrewAI、还有 MetaGPT。你该选哪个？

我最早也以为，它们不过是同一套东西换了层皮。直到我分别在三个项目里掉了坑，才发现它们的设计哲学简直就是在互相掐架。这篇文章，就是为了帮你少走我走过的弯路。

AutoGen：对话就是一切

AutoGen 是微软在 2023 年开源的，核心论文叫 AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation。它的设计哲学一句话就能说清楚：把多 Agent 协作建模成一段对话。

在 AutoGen 里，一切实体都是 ConversableAgent——一个能接收消息、产生消息的东西。它可以是一个纯粹的 LLM，可以是一个带着工具的 LLM，可以是一个人类用户，甚至可以是另一个 Agent 的代理。它们之间不共享任何状态，所有信息交换都得通过对话消息。

举个例子：你定义了一个“工程师 Agent”和一个“代码审查 Agent”，工程师写完代码后，会直接把代码以消息形式发给审查员，审查员再回复修改意见。这个交互过程，就像一个微信群里两个人聊天。

这种设计最大的好处是极度灵活。你可以随时插入一个人类 Agent 来接管决策，也可以让多个 Agent 组成一个 GroupChat，大家七嘴八舌地讨论，最后由一个“管理员 Agent”拍板。AutoGen 没有预设任何组织架构，只给了你一个对话的“信道”，你可以自由搭建任何拓扑。

但它的坑也在这里。我最早用 AutoGen 做一个稍复杂的任务时，Agent 之间的对话很快就失控了——它们开始互相发无意义的确认消息，甚至陷入“你说得对”“我也觉得”的死循环。因为对话没有结构，全靠 prompt 约束，而 prompt 的约束力总是有限的。我花了大量时间调 prompt 模板，像在调教一群没有纪律的自由职业者。

AutoGen 官方文档说："We envision a future where AI agents can converse with each other and with humans to solve complex tasks." 这个愿景很美，但没告诉你，毫无约束的对话会把协作变成一场无尽的会议。

CrewAI：把团队搬进代码

CrewAI 的官方文档CrewAI Documentation第一句话就是："CrewAI is a framework for orchestrating role-playing, autonomous AI agents." 它的设计哲学是：让 AI 像人类团队一样工作。

在 CrewAI 里，你首先要定义一个 Agent，它必须有 role（角色）、goal（目标）和 backstory（背景故事）。然后你定义 Task，每个 Task 有明确的描述和期望输出。最后你把这些 Agent 和 Task 扔进一个 Crew，并指定一个流程（process）——可以是顺序执行，也可以是层级委派。

这种设计最直观：你脑子里想的是“我要一个产品经理、一个设计师、一个工程师”，代码里直接写出来就行。而且 CrewAI 通过角色和背景故事，给 Agent 注入了很强的行为约束——一个“资深工程师”的 Agent 不会突然开始写销售文案，因为它的角色设定就限制了它。

我最早用 CrewAI 时觉得特别爽，因为它把混乱的对话结构化了。但后来我发现，这种结构化也有代价：它太死板了。如果你的任务需要动态调整顺序，或者需要 Agent 之间多次来回协商，CrewAI 的预设流程就会显得很笨拙。它更像一个“流水线”，而不是一个“团队”。

而且，CrewAI 的层级委派模式（hierarchical）虽然看起来高级，但实际效果严重依赖底层 LLM 的规划能力。我曾让一个“经理 Agent”分配任务，结果它把写代码的任务分给了设计师，因为设计师的 backstory 里恰好有一句“懂一点 Python”。这让我意识到，角色扮演的约束力，在 LLM 的幻觉面前依然脆弱。

MetaGPT：把 SOP 做成代码

MetaGPT 的论文MetaGPT: Meta Programming for Multi-Agent Collaborative Framework提出了一个非常不一样的思路：软件公司怎么干活，AI 就怎么干活。

它直接模拟了一家软件公司的标准操作流程（SOP）：产品经理先写 PRD（产品需求文档），架构师接着写系统设计文档，然后工程师写代码，最后 QA 写测试用例。每个 Agent 不仅对话，还输出结构化的文档（比如 JSON 格式的 PRD），这些文档作为“中间产物”在 Agent 之间传递，像看板上的卡片一样。

MetaGPT 最让我佩服的一点是，它把“经验”编码进了流程。比如，论文里提到，人类产品经理在写 PRD 时通常会参考竞品分析，所以 MetaGPT 的 Agent 也先做竞品分析，再写 PRD。这种“把人类经验编程化”的思路，让协作质量有了极大提升——幻觉被大幅减少了，因为每个 Agent 的输出都被后续的文档格式约束着。

但它的局限也很明显：场景太窄了。MetaGPT 几乎就是为“软件生成”这个场景定制的，SOP 里全是软件开发角色。如果你想让它做市场调研或学术论文合著，就得自己重新设计 SOP，而这需要你对目标领域的人类协作流程有深入理解。换句话说，MetaGPT 把门槛从“写 prompt”转移到了“写 SOP”。

我当初想用 MetaGPT 做一个自动化写作团队，结果发现它预设的文档模板全是代码相关的，我不得不大量修改源码，最后搞成了一个四不像。

一张表说清三种哲学

我踩过的坑，以及怎么想通的

有一个问题困扰了我很久：为什么 AutoGen 这么灵活，却在做正经项目时总翻车？后来我意识到，对话是最不靠谱的协作方式。人类开会都需要严格的议程和会议纪要，否则就会跑题。你把一群 AI 扔进一个没有规则的聊天室，指望它们自行组织，这本身就是一种幻觉。

而 MetaGPT 之所以效果好，恰恰是因为它取消了对话的自由度。每个 Agent 必须产出标准化的文档，这就像把会议变成了“每个人交一份报告，然后传阅”。信息传递的效率变高了，但灵活性也丢了。

CrewAI 试图在中间找一个平衡：用角色和任务来约束，但还保留了一定的对话空间。但实际使用中，这个平衡点很难调——你给的约束越多，它就越像 MetaGPT；你给的约束越少，它就越像 AutoGen。

所以，我现在选框架的准则很简单：如果你的任务能被拆成“输入→处理→输出”的流水线，用 CrewAI；如果你的任务需要大量探索和试错，而且你能容忍混乱，用 AutoGen；如果你的任务正好是软件开发，或者你愿意花时间设计一个完美的 SOP，用 MetaGPT。

常见误解 FAQ

AutoGen 是不是只能聊天，不能干活？

不是。AutoGen 的 Agent 可以挂载工具（函数调用），所以它们对话时也能执行代码、搜索网页。只是所有行动的触发都来自对话消息，这会让调试变得很痛苦，因为你要从一堆聊天记录里找“谁调用了什么”。

CrewAI 的角色设定会不会变成“戏精”模式？

有可能。如果你给 Agent 的 backstory 写得太详细，它可能会过度代入角色，开始输出无关的“内心戏”。解决办法是保持 backstory 简明扼要，只描述关键能力。

MetaGPT 是不是只能做软件生成？

目前来看，它的核心优势在软件生成，因为 SOP 是现成的。但理论上，只要你为其他领域定义好 SOP 和文档模板，它也能用。只是社区里现成的非软件 SOP 还很少，你需要自己动手。

能不能把这三个框架混着用？

技术上可以，但得不偿失。它们的 Agent 定义和通信协议都不一样，强行混用只会增加复杂度。除非你有一个超级复杂的系统，需要不同部分用不同哲学，否则不建议。

我的判断：它们的能力边界在哪

这三个框架都还没到“开箱即用解决复杂任务”的程度。它们本质上是组合 LLM 的脚手架，而不是智能体本身。所有框架的可靠性，最终都取决于底层 LLM 的能力和你写的 prompt 质量。

AutoGen 在需要频繁人机交互的场景下优势明显，比如代码审查过程中人类介入决策。CrewAI 适合快速原型化一个角色分明的团队，但一旦任务变复杂，它的层级委派就会暴露问题。MetaGPT 在软件生成这个垂直领域接近可用，但稍微偏离预设流程，就需要大量定制。

如果你问我最看好哪个方向，我会说是 MetaGPT 代表的“SOP 注入”思路。因为现实世界中最可靠的协作，永远是那些被流程管起来的部分。但路还很长，现在我们手里的 SOP，还太粗糙了。

如果你正在选框架，我的建议是：先想清楚你的协作模式更接近“开会讨论”还是“流水线作业”，然后反推框架。 别被“多 Agent”这个词迷惑了，真正决定成败的，是协作的设计，而不是 Agent 的数量。