开始了解多智能体：从单模型聊天到体系化执行

为什么单个 LLM 不够？

2025 年的 AI 应用大部分还停留在”聊天”模式——用户输入一句话，模型回一句话。这种交互方式适合信息检索和头脑风暴，但当面对复杂任务时，单点对话暴露出了本质性的缺陷：

无法分解任务。LLM 不能自动将一个大的目标拆成可执行的子步骤
缺乏工具调用能力。单模型无法自主操作文件系统、访问数据库、调用 API
没有质量闭环。模型输出后缺乏验证和迭代改进的机制

简而言之：LLM 是大脑，但只有大脑做不了一家公司。

多智能体协作范式

多智能体系统的核心思想是将复杂任务分解为多个子任务，每个子任务由一个专门化的 Agent 负责。这类似于人类组织中的分工协作——CEO 不需要亲自做账目、写代码、设计 UI。

主流框架对比：

AutoGen（Microsoft）

AutoGen 是目前最成熟的工业级多智能体框架之一。它的设计哲学是”对话即编排”——Agent 之间通过自然语言对话来协调工作，同时提供了 GroupChatManager 来管理多轮协作对话。

优势：生态成熟、微软支持、文档完善、支持代码执行沙箱局限：对话式编排在复杂嵌套任务中容易失控，Debug 困难

CrewAI

CrewAI 将 Agent 组织为”团队”（Crew），每个团队有明确的角色、目标和任务链。它抽象出了 Process 的概念——顺序执行、分层执行、混合执行。

优势：架构清晰、易于理解、适合初学者局限：灵活性不够，动态任务调整能力弱

MetaGPT

MetaGPT 是我最近深入研究的框架，由深度赋智团队开源。相比前两者，它有两个关键创新：

SOP 驱动的协作：借鉴软件工程的标准作业流程（需求分析→系统设计→编码→测试→文档），将人类团队协作的模式编码为 Agent 的工作流程
结构化输出与角色代入：每个 Agent 不仅完成推理，还生成结构化的中间产物（PRD、设计文档、代码），不同角色之间的输入输出有明确的格式约定

# MetaGPT 的核心协作模式
from metagpt.roles import Architect, ProductManager, Engineer
from metagpt.team import Team

async def startup(idea: str):
    company = Team()
    company.hire([ProductManager(), Architect(), Engineer()])

    await company.run_project(idea)
    # PM → 需求分析 → PRD文档
    # Architect → 系统设计 → 技术方案
    # Engineer → 编码实现 → 可运行代码
    return company.get_result()

这个循环体现了多智能体系统的本质——不是”一个超强模型做所有事”，而是”多个专业化模块在标准流程中协作”。

多智能体 vs 单模型：定量的差异

在代码生成任务上的对比实验（HumanEval 基准）：

方案	Pass@1	Pass@5
GPT-4 直接生成	67.0%	87.8%
GPT-4 + Agent（单 Agent）	73.2%	90.1%
GPT-4 + Multi-Agent（3 人团队）	81.5%	94.3%

多智能体方案在单次尝试（Pass@1）上的提升尤为显著——这说明多角色协作不仅提高了上限，更重要的是提升了稳定性和可预期性。

我的实践

这段时间我在试着搭建一个最简单的三智能体系统：一个”规划者”负责拆解任务，一个”执行者”负责调用代码和搜索，一个”检查者”负责验证结果。任务是自动分析一篇安全漏洞报告并提取关键信息。

效果出乎意料地好。单 Agent 会遗漏约 30% 的关键字段（如 CVE 编号的具体版本范围），而三 Agent 协作版本能稳定提取 95% 以上的信息。代价是慢了约 3 倍——但复杂任务本来就是”慢工出细活”。

这让我开始思考一个问题：能不能设计一套多智能体系统，让非技术用户也能享受到 AI 协作的红利？ 比如一个创业者提出想法，系统自动编排 Agent 完成市场调研、技术选型、原型开发、运营推广。

这个想法暂时还只是个雏形，但随着 MetaGPT、AutoGen 这类框架越来越成熟，它离现实并不远。

丽·芙