我用 4 个开源框架搭了多 Agent 系统：CrewAI vs AutoGen vs LangGraph vs Dify 实测对比

适合正在选型多 Agent 框架的开发者，或者想从"单 Agent"升级到"多 Agent 协作"的技术人员。
本文不看官方文档，只看实际搭建过程中的真实体验——哪个好上手、哪个灵活、哪个坑最多。

为什么需要多 Agent

单 Agent 处理简单任务没问题，但复杂任务会出错：

• 让一个 Agent 同时负责选题、写作、审核、发布，上下文窗口塞满了，后面的任务质量暴跌
• 一个 Agent 身兼数职，角色混乱，写出的文章一会儿像教程一会儿像评论
• 没有审核环节，错误直接输出

多 Agent 的思路是分工：每个 Agent 只负责一个环节，像流水线一样协作。

选题 Agent → 写作 Agent → 审核 Agent → 发布 Agent

我花了一周时间，分别用 4 个主流框架搭了同一个场景的多 Agent 系统，下面是真实体验。

测试场景

4 个框架都搭同一个任务：AI 自动写技术文章。

流程：选题 Agent 搜集热点 → 写作 Agent 生成初稿 → 审核 Agent 检查质量 → 输出终稿。

每个框架的评估维度：

维度	说明
上手难度	从零到跑通第一个 demo 要多久
代码量	实现同样功能需要多少行代码
灵活性	能不能自定义 Agent 行为和工具
调试体验	出错了好不好排查
社区生态	文档、示例、社区活跃度

框架 1：CrewAI

基本信息

项目	说明
GitHub Stars	25k+
语言	Python
核心理念	角色扮演 + 任务委派
安装	pip install crewai

上手体验

CrewAI 的设计哲学是把 Agent 当"员工"管理。你需要定义角色（Role）、目标（Goal）、工具（Tools），然后分配任务。

from crewai import Agent, Task, Crew

# 定义 Agent
researcher = Agent(
    role="选题研究员",
    goal="找到当前最热门的 AI 技术话题",
    backstory="你是一个资深的技术编辑，擅长发现热门话题",
    tools=[search_tool],
    llm="gpt-4"
)

writer = Agent(
    role="技术写手",
    goal="根据选题写出高质量技术文章",
    backstory="你是一个技术博客专家，擅长把复杂概念讲清楚",
    llm="gpt-4"
)

reviewer = Agent(
    role="质量审核员",
    goal="检查文章质量，确保没有错误",
    backstory="你是一个严格的技术编辑",
    llm="gpt-4"
)

# 定义任务
task_research = Task(
    description="搜集当前 AI Agent 领域的热门话题",
    agent=researcher,
    expected_output="3 个热门选题及推荐理由"
)

task_write = Task(
    description="基于选题写一篇 3000 字技术文章",
    agent=writer,
    expected_output="完整的 Markdown 文章"
)

task_review = Task(
    description="审核文章质量，检查数据准确性和逻辑",
    agent=reviewer,
    expected_output="审核意见和修改建议"
)

# 组装 Crew 并执行
crew = Crew(
    agents=[researcher, writer, reviewer],
    tasks=[task_research, task_write, task_review],
    verbose=True
)

result = crew.kickoff()

评估

维度	评分	说明
上手难度	⭐⭐⭐⭐⭐	最简单，30 分钟跑通
代码量	⭐⭐⭐⭐⭐	约 50 行搞定 3 Agent 协作
灵活性	⭐⭐⭐	角色定义够用，但自定义流程有限
调试体验	⭐⭐⭐⭐	verbose=True 能看到每步执行
社区生态	⭐⭐⭐⭐	文档齐全，示例多

适合场景：快速原型、简单流水线任务。

框架 2：AutoGen（微软）

基本信息

项目	说明
GitHub Stars	40k+
语言	Python
核心理念	对话式多 Agent 协作
安装	pip install autogen

上手体验

AutoGen 的核心是Agent 之间通过对话协作。你定义多个 Agent，它们会自动互相讨论、质疑、修正，直到达成共识。

from autogen import AssistantAgent, UserProxyAgent

# 配置 LLM
config = {
    "config_list": [{"model": "gpt-4", "api_key": "your-key"}]
}

# 定义 Agent
writer = AssistantAgent(
    name="Writer",
    system_message="你是一个技术写手，负责写文章。写完后交给 Reviewer 审核。",
    llm_config=config
)

reviewer = AssistantAgent(
    name="Reviewer",
    system_message="你是一个严格的审核员。检查文章质量，提出修改意见。如果质量合格说 APPROVED。",
    llm_config=config
)

user_proxy = UserProxyAgent(
    name="User",
    human_input_mode="NEVER",
    max_consecutive_auto_reply=5
)

# 启动对话
user_proxy.initiate_chat(
    writer,
    message="写一篇关于 MCP 协议的技术文章，写完后让 Reviewer 审核。"
)

评估

维度	评分	说明
上手难度	⭐⭐⭐	概念多，1-2 小时跑通
代码量	⭐⭐⭐⭐	约 40 行，但配置项多
灵活性	⭐⭐⭐⭐⭐	对话模式极其灵活
调试体验	⭐⭐	对话过程长，不好追踪
社区生态	⭐⭐⭐⭐⭐	微软背书，社区最大

适合场景：需要 Agent 之间反复讨论、迭代的复杂任务。

框架 3：LangGraph

基本信息

项目	说明
GitHub Stars	10k+
语言	Python
核心理念	有向图定义 Agent 工作流
安装	pip install langgraph

上手体验

LangGraph 把 Agent 工作流定义成一个有向图，每个节点是一个 Agent 或工具，边定义了流转逻辑。适合需要精确控制流程的场景。

from langgraph.graph import StateGraph, END
from typing import TypedDict

# 定义状态
class ArticleState(TypedDict):
    topic: str
    draft: str
    review_result: str
    final: str

# 定义节点函数
def research(state):
    # 选题逻辑
    return {"topic": "MCP 协议实战"}

def write(state):
    # 写作逻辑
    return {"draft": f"关于 {state['topic']} 的文章..."}

def review(state):
    # 审核逻辑
    if len(state["draft"]) > 500:
        return {"review_result": "PASS", "final": state["draft"]}
    else:
        return {"review_result": "FAIL"}

def should_continue(state):
    if state["review_result"] == "PASS":
        return "end"
    return "write"  # 打回重写

# 构建图
graph = StateGraph(ArticleState)
graph.add_node("research", research)
graph.add_node("write", write)
graph.add_node("review", review)

graph.set_entry_point("research")
graph.add_edge("research", "write")
graph.add_edge("write", "review")
graph.add_conditional_edges("review", should_continue, {
    "end": END,
    "write": "write"
})

# 执行
app = graph.compile()
result = app.invoke({"topic": "", "draft": "", "review_result": "", "final": ""})

评估

维度	评分	说明
上手难度	⭐⭐	概念最复杂，半天跑通
代码量	⭐⭐	约 80 行，最多
灵活性	⭐⭐⭐⭐⭐	图结构最灵活，支持条件分支、循环
调试体验	⭐⭐⭐⭐	图结构可视化，好追踪
社区生态	⭐⭐⭐⭐	LangChain 生态，文档齐全

适合场景：复杂流程、需要条件分支和循环的任务。

框架 4：Dify

基本信息

项目	说明
GitHub Stars	60k+
语言	Python（后端）+ 可视化界面
核心理念	低代码 AI 工作流
安装	docker-compose up

上手体验

Dify 是唯一一个可视化界面的方案。不用写代码，在画布上拖拽节点、连线就能搭出多 Agent 工作流。

1. 创建 Agent 节点，填写 System Prompt
2. 用线连接节点，定义数据流向
3. 点击"运行"即可

对于不写代码的人（比如运营、编辑），Dify 是唯一可行的方案。

评估

维度	评分	说明
上手难度	⭐⭐⭐⭐⭐	最简单，拖拽即可
代码量	⭐⭐⭐⭐⭐	零代码
灵活性	⭐⭐	可视化界面限制了自定义
调试体验	⭐⭐⭐⭐	可视化流程好理解
社区生态	⭐⭐⭐⭐⭐	最活跃的开源 AI 平台

适合场景：非技术人员、快速验证想法、不需要深度自定义的场景。

横向对比

维度	CrewAI	AutoGen	LangGraph	Dify
上手难度	最易	中等	最难	最易
代码量	~50 行	~40 行	~80 行	0 行
灵活性	中	高	最高	低
调试体验	好	差	好	好
适合谁	快速原型	复杂对话	精确控制	非技术人员
生产可用	原型级	可用	可用	可用

选型建议

你的需求	推荐
快速验证想法，30 分钟出 demo	CrewAI
Agent 之间需要反复讨论迭代	AutoGen
流程复杂，有分支和循环	LangGraph
团队里有非技术人员要参与	Dify
生产环境部署，稳定性优先	LangGraph 或 Dify

踩坑记录

坑 1：CrewAI 的 Agent 角色定义太模糊

症状：写作 Agent 有时会越权去做选题的工作。

原因：Role 和 Goal 定义不够精确，Agent 理解偏差。

解决：在 backstory 里明确写"你只负责写作，不要做选题和审核"。

坑 2：AutoGen 对话无限循环

症状：Writer 和 Reviewer 互相打回，永远达不成共识。

原因：没有设置最大对话轮数。

解决：设置 max_consecutive_auto_reply=5，超过就强制结束。

坑 3：LangGraph 状态传递丢失

症状：review 节点拿不到 write 节点输出的 draft。

原因：状态字段名写错了，大小写不一致。

解决：用 TypedDict 定义状态，确保字段名完全一致。

坑 4：Dify 的 Agent 响应太慢

症状：一个 3 步工作流要跑 2 分钟。

原因：每个节点都调用大模型 API，网络延迟叠加。

解决：非关键节点用小模型（如 GPT-3.5），只有写作节点用大模型。

坑 5：所有框架的 Token 成本都比预期高

症状：多 Agent 系统的 API 费用是单 Agent 的 3-5 倍。

原因：每个 Agent 都要独立调用 LLM，上下文重复传递。

解决：Agent 之间只传摘要，不传全文。用共享存储替代直接传递。

总结

3 条核心经验：

1. 先用 CrewAI 或 Dify 验证想法，再用 LangGraph 做生产版本。别一上来就选最复杂的框架，先把流程跑通。

2. 多 Agent 的成本是单 Agent 的 3-5 倍。不是所有任务都需要多 Agent，简单任务用单 Agent 就够了。

3. Agent 之间的通信设计比 Agent 本身更重要。传什么、传多少、什么时候传，直接决定了系统的效率和成本。

---

你在用哪个多 Agent 框架？遇到过什么问题？评论区交流。