我实测了 3 个 AI Agent 框架，发现它们适合的场景完全不同

我用同一个多智能体协作任务，分别在 AutoGen、CrewAI、LangGraph 三个框架上实现，结果差异大到让我意外。

测试任务：三人协作完成一份技术报告

任务很简单：一个调研 agent 收集信息，一个写作 agent 整理内容，一个审核 agent 质检报告，最后输出最终结果。看似简单，但涉及：

• Agent 间通信协议
• 任务分配和依赖
• 状态管理和错误恢复
• 工具调用和权限控制

我预期三个框架都能轻松搞定，实际踩了一周的坑。

AutoGen：学术研究利器，但生产环境太折腾

实现难度：⭐⭐⭐⭐☆

代码量：约 250 行

核心体验

AutoGen 的设计理念是”Agent = LLM + 工具 + 人”，每个 agent 可以是人，也可以是 AI。这听起来很优雅，但实际开发让我崩溃。

from autogen import AssistantAgent, UserProxyAgent, GroupChat, GroupChatManager

# 定义三个 agent
researcher = AssistantAgent(
    name="researcher",
    system_message="你是信息收集专家...",
    llm_config={"model": "gpt-4"}
)

writer = AssistantAgent(
    name="writer",
    system_message="你是技术写作专家...",
    llm_config={"model": "gpt-4"}
)

reviewer = AssistantAgent(
    name="reviewer",
    system_message="你是内容审核专家...",
    llm_config={"model": "gpt-4"}
)

# 创建群组聊天
groupchat = GroupChat(
    agents=[researcher, writer, reviewer],
    messages=[],
    max_round=10
)

manager = GroupChatManager(groupchat=groupchat)

踩坑 1：对话协议不可控

AutoGen 默认让 agent 自由对话，但在我的场景中，必须严格按顺序执行：调研 → 写作 → 审核。AutoGen 提供了 speaker_selection_method，但配置复杂且容易出错。

最终我不得不写了一个自定义的 selector 函数，手动控制下一个发言者：

def custom_selector(last_speaker, groupchat):
    if last_speaker.name == "UserProxy":
        return researcher
    elif last_speaker.name == "researcher":
        return writer
    elif last_speaker.name == "writer":
        return reviewer
    elif last_speaker.name == "reviewer":
        return None  # 结束
    else:
        return None

这让代码复杂度翻倍，违背了框架设计的初衷。

踩坑 2：工具调用权限混乱

AutoGen 的工具调用默认需要用户确认（human_input_mode="ALWAYS"），这在生产环境不现实。改成 "NEVER" 后，工具调用日志难以追踪，调试时完全不知道 agent 调用了什么工具。

最终我用一个中间层包装工具调用：

def safe_tool_call(tool_name, **kwargs):
    print(f"[Tool Call] {tool_name} with {kwargs}")
    result = original_tool(tool_name, **kwargs)
    print(f"[Tool Result] {result}")
    return result

但这意味着所有工具都要手动包装，工作量巨大。

性能表现

• Token 消耗：最高（每个 agent 都会输出大量中间对话）
• 执行时间：约 45 秒
• 错误恢复：难（对话状态难以追踪和回滚）

适用场景

✅ 学术研究、论文实验、需要高度灵活对话协议的场景 ❌ 生产环境、快速迭代、团队协作项目

CrewAI：开箱即用，但定制性受限

实现难度：⭐⭐☆☆☆

代码量：约 120 行

核心体验

CrewAI 的设计理念是”Agent团队协作”，借鉴了人类团队的工作模式。上手速度最快，几乎零配置就能跑起来。

from crewai import Agent, Task, Crew

# 定义三个 agent
researcher = Agent(
    role="信息收集专家",
    goal="收集项目相关的技术资料",
    backstory="你擅长快速检索和分析技术文档...",
    llm="gpt-4"
)

writer = Agent(
    role="技术写作专家",
    goal="整理资料并撰写技术报告",
    backstory="你擅长将复杂技术转化为易读文档...",
    llm="gpt-4"
)

reviewer = Agent(
    role="内容审核专家",
    goal="质检报告质量和准确性",
    backstory="你有丰富的技术文档审核经验...",
    llm="gpt-4"
)

# 定义任务
research_task = Task(
    description="收集[项目名称]的技术架构和实现细节",
    agent=researcher
)

write_task = Task(
    description="根据调研结果撰写完整的技术报告",
    agent=writer,
    context=[research_task]
)

review_task = Task(
    description="审核技术报告，确保准确性和可读性",
    agent=reviewer,
    context=[write_task]
)

# 创建 crew 并执行
crew = Crew(
    agents=[researcher, writer, reviewer],
    tasks=[research_task, write_task, review_task]
)

result = crew.kickoff()

踩坑 1：状态管理缺失

CrewAI 的任务依赖通过 context 声明，但任务间的数据传递完全隐式。在调试时，我完全不知道 write_task 拿到了 research_task 的什么输出。

CrewAI 提供了 context 属性查看依赖，但无法实时监控数据流。最终我写了一个回调函数来追踪：

def task_callback(task_output):
    print(f"[Task {task_output.task}] Output: {task_output.raw[:100]}...")

crew = Crew(
    agents=[...],
    tasks=[...],
    step_callback=task_callback
)

但这只是临时方案，CrewAI 没有提供原生的状态监控。

踩坑 2：并发控制薄弱

CrewAI 支持任务并发（通过 process=Process.hierarchical），但并发任务的依赖关系需要手动管理。在我尝试让 researcher 和另一个 agent 并行工作时，遇到了多次”任务依赖未满足”的错误。

AFAIK，CrewAI 的并发模型相对简单，不适合复杂的并行任务编排。

性能表现

• Token 消耗：中等（结构化任务减少了冗余对话）
• 执行时间：约 30 秒
• 错误恢复：中等（可重试任务，但状态恢复困难）

适用场景

✅ 快速原型开发、团队协作模拟、中小型工作流 ❌ 复杂状态机、生产环境高可用、精细的并发控制

LangGraph：最灵活，但学习曲线最陡

实现难度：⭐⭐⭐⭐⭐

代码量：约 180 行（不含辅助函数）

核心体验

LangGraph 是 LangChain 团队推出的状态机框架，核心思想是”Agent工作流 = 状态图”。学习曲线最陡，但一旦掌握，能力最强。

from typing import TypedDict, Annotated, Sequence
from operator import add
from langgraph.graph import StateGraph, END

# 定义状态
class AgentState(TypedDict):
    messages: Annotated[Sequence[str], add]
    research_result: str
    draft_report: str
    final_report: str
    error_count: int

# 定义节点函数
def research_node(state: AgentState) -> AgentState:
    # 调用 LLM 收集信息
    result = llm.invoke("收集资料...")
    return {"research_result": result}

def write_node(state: AgentState) -> AgentState:
    # 根据调研结果写作
    result = llm.invoke(f"根据以下调研结果撰写报告：{state['research_result']}")
    return {"draft_report": result}

def review_node(state: AgentState) -> AgentState:
    # 审核草稿
    result = llm.invoke(f"审核以下报告：{state['draft_report']}")
    if "通过" in result:
        return {"final_report": state['draft_report']}
    else:
        # 不通过，增加错误计数，回到写作节点
        return {"error_count": state['error_count'] + 1}

# 定义条件边
def should_retry(state: AgentState) -> str:
    if state['error_count'] > 3:
        return "give_up"
    else:
        return "rewrite"

# 构建图
workflow = StateGraph(AgentState)
workflow.add_node("research", research_node)
workflow.add_node("write", write_node)
workflow.add_node("review", review_node)
workflow.add_node("give_up", lambda s: {"final_report": "审核未通过超过3次，放弃"})

workflow.set_entry_point("research")
workflow.add_edge("research", "write")
workflow.add_edge("write", "review")
workflow.add_conditional_edges(
    "review",
    should_retry,
    {
        "rewrite": "write",
        "give_up": "give_up"
    }
)

# 编译并执行
app = workflow.compile()
result = app.invoke({"messages": [], "error_count": 0})

踩坑 1：状态管理逻辑复杂

LangGraph 的状态是完全显式的，每个节点必须返回状态更新。这看似清晰，但在实际开发中，我花了大量时间调试类型错误和状态遗漏。

比如，我一开始忘记在 write_node 中保留 research_result，导致下一个节点访问不到调研数据。错误信息是 KeyError: 'research_result'，排查了很久。

LangGraph 提供了 pydantic 验证，但错误提示依然不够友好。

踩坑 2：调试困难

LangGraph 的执行是图遍历，断点调试很难定位问题。我最终用 LangSmith（LangChain 的调试工具）才搞清楚状态流转。

另外，LangGraph 的可视化图导出功能在复杂场景下会变得很乱，难以阅读。

性能表现

• Token 消耗：最低（完全结构化，无冗余对话）
• 执行时间：约 35 秒（单线程）或 25 秒（并行）
• 错误恢复：最强（状态可追踪，可回滚）

适用场景

✅ 生产环境高可用、复杂状态机、精细的并发控制 ❌ 快速原型、学术研究、小团队项目

综合对比

维度	AutoGen	CrewAI	LangGraph
上手难度	⭐⭐⭐☆☆	⭐⭐☆☆☆	⭐⭐⭐⭐⭐
代码量	250 行	120 行	180 行
Token 消耗	高	中	低
执行时间	45 秒	30 秒	35 秒
灵活性	高（对话协议）	中（任务依赖）	最高（状态机）
生产可用性	低	中	高
调试友好度	中	高	低（需 LangSmith）
社区活跃度	中	高	高

选型建议

选 AutoGen 的场景

• 学术研究、论文实验
• 需要高度灵活的对话协议
• Agent 混合（人 + AI）协作场景
• 探索型任务，不确定具体流程

选 CrewAI 的场景

• 快速原型开发，1-2 天出 demo
• 团队协作模拟（比如模拟产品经理、开发、测试协作）
• 中小型工作流，不需要复杂状态管理
• LangChain 用户，需要更高层封装

选 LangGraph 的场景

• 生产环境，需要高可用和稳定性
• 复杂状态机，需要精细的并发控制
• 需要 LangChain 生态集成（工具、向量数据库等）
• 团队有一定技术积累，愿意投入学习成本

最后的话

框架不是万能的，选对比选重要。如果你的目标是快速验证想法，CrewAI 是最好的选择；如果要在生产环境长期运行，LangGraph 是最稳健的方案；如果是为了研究 agent 协作机制，AutoGen 是最合适的实验平台。

我踩完这些坑后的总结：没有最好的框架，只有最适合场景的框架。你的项目需要什么？

---

测试环境：GPT-4，Python 3.11，2026-03