四个框架的设计取向不同,没有谁绝对更好,只有谁更适合你的场景

四个框架的定位

框架出品方主要定位
LangGraphLangChain基于状态图的 Agent 编排
AutoGenMicrosoft多 Agent 对话框架
CrewAI独立项目基于角色的多 Agent 协作
OpenHandsAll Hands AI(前 OpenDevin)软件工程专用 Agent 系统

四个框架解决的问题部分重叠,但出发点和抽象层级不同。


LangGraph

核心抽象:状态图(State Graph)

LangGraph 把 Agent 流程建模成一个有向图:节点是 Agent 或工具调用,边定义转移条件,状态在节点间流动。

from langgraph.graph import StateGraph

class AgentState(TypedDict):
    messages: list
    next_action: str

graph = StateGraph(AgentState)

graph.add_node("planner", planner_node)
graph.add_node("executor", executor_node)
graph.add_node("reviewer", reviewer_node)

graph.add_edge("planner", "executor")
graph.add_conditional_edges(
    "executor",
    lambda state: "reviewer" if state["next_action"] == "review" else "planner"
)

app = graph.compile()

设计取向:

  • 显式控制流:每个节点和边都要明确定义
  • 状态可观测:每一步的状态变化可以追踪
  • 适合复杂的、有明确步骤的流程

适合场景:

  • 工作流明确、步骤可预先规划的任务
  • 需要细粒度控制 Agent 行为的场景
  • 已经在用 LangChain 生态的项目

主要限制:

  • 图的复杂度增加后维护成本高
  • 状态定义需要前置设计
  • 学习曲线相对陡

AutoGen

核心抽象:可对话的 Agent

AutoGen 把每个 Agent 建模成一个能收发消息的对象,多 Agent 协作通过对话完成。

from autogen import AssistantAgent, UserProxyAgent

assistant = AssistantAgent(
    name="coder",
    llm_config={"model": "gpt-4"}
)

user_proxy = UserProxyAgent(
    name="user",
    code_execution_config={"work_dir": "coding"}
)

user_proxy.initiate_chat(
    assistant,
    message="写一个快速排序的 Python 实现"
)

设计取向:

  • 对话作为协作的统一形式
  • Agent 间的交互通过消息驱动
  • 内置代码执行能力(UserProxyAgent 可以执行代码)

适合场景:

  • 多 Agent 协作(程序员 + 审查员 + 测试员)
  • 需要快速原型验证的研究性项目
  • 任务可以自然地拆解为对话回合

主要限制:

  • 对话回合数难以控制,容易陷入循环
  • 大规模生产部署需要额外的稳定性工程
  • 文档和最佳实践还在演进中

AutoGen 0.4 版本(2024 年底)做了较大架构重构,事件驱动模型替代了直接对话调用。如果是新项目,建议直接看 0.4+ 的文档,老版本的资料可能不再适用。


CrewAI

核心抽象:角色(Agent)+ 任务(Task)+ 流程(Process)

CrewAI 强调角色分工。每个 Agent 有自己的目标、背景描述、可用工具。任务被分配给角色,按预定流程执行。

from crewai import Agent, Task, Crew

researcher = Agent(
    role="研究员",
    goal="找出关于 X 主题的最新进展",
    backstory="你是该领域的专家...",
    tools=[search_tool, summarize_tool]
)

writer = Agent(
    role="技术作家",
    goal="把研究结果写成清晰的报告",
    backstory="你擅长把复杂技术解释清楚...",
    tools=[edit_tool]
)

research_task = Task(
    description="收集 X 的最新论文",
    agent=researcher
)

writing_task = Task(
    description="基于研究结果写一份报告",
    agent=writer,
    context=[research_task]
)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, writing_task],
    process=Process.sequential
)

result = crew.kickoff()

设计取向:

  • 角色 + 任务的概念直观,类似团队协作
  • 约束 Agent 行为靠角色描述(prompt engineering)
  • 默认顺序执行,可配置层级或并行流程

适合场景:

  • 任务可以清晰地拆给不同"角色"
  • 流程相对固定的工作流
  • 非技术用户也能上手定义 Agent

主要限制:

  • Agent 间的交互精度依赖 prompt 质量
  • 调试不直观(Agent 在角色驱动下的行为有时难以预测)
  • 不适合需要细粒度控制流的场景

OpenHands

核心抽象:软件工程任务的 Agent 系统

OpenHands 不是通用 Agent 框架,而是一个完整的软件工程 Agent 系统。包含:

  • Agent(基于 CodeAct 思想)
  • 沙箱化执行环境(Docker 容器)
  • 工具集(文件操作、浏览器、终端)
  • 前端 UI(VS Code 风格界面)
# 启动 OpenHands
docker run -it --rm \
  -p 3000:3000 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  --name openhands \
  docker.all-hands.dev/all-hands-ai/openhands

在浏览器里打开 localhost:3000 就能用——给定任务后,Agent 在容器里写代码、运行、调试。

设计取向:

  • 端到端的产品,不是库
  • 针对软件工程优化
  • 默认包含沙箱、权限控制、人工审批等生产化考虑

适合场景:

  • 想直接用一个软件工程 Agent,不想自己组装
  • 自动修 bug、生成功能等明确的开发任务
  • 需要安全隔离的环境

主要限制:

  • 不是框架,难以深度定制
  • 资源消耗大(每个会话一个容器)
  • 不适合非软件工程的通用 Agent 场景

横向对比

维度LangGraphAutoGenCrewAIOpenHands
抽象层级流程图对话角色完整系统
灵活性低(专用)
学习曲线平(用户)/ 陡(定制)
适合的复杂度
多 Agent 支持通过节点原生原生单 Agent 为主
生产化程度
代码执行通过工具内置通过工具核心能力
调试体验较好(状态可见)一般一般较好(UI 可视)

选型的几个问题

任务类型是什么?

软件工程任务(写代码、修 bug)→ OpenHands 直接可用 通用任务(研究、写作、数据处理)→ 看下面几个问题

流程是否预先明确?

明确 → LangGraph(显式定义节点和边) 不明确 → AutoGen 或 CrewAI(让 Agent 自主协作)

有几个 Agent?

单 Agent → LangGraph 或直接用 OpenAI Assistant API 多 Agent 协作 → CrewAI 或 AutoGen

对控制的需求?

强控制(每步都可干预)→ LangGraph 弱控制(设定目标让 Agent 自由发挥)→ CrewAI

生态依赖?

已经用 LangChain → LangGraph 微软 / Azure 生态 → AutoGen 独立项目 → CrewAI 或 LangGraph


各自的实际坑

LangGraph

  • 图的复杂度涨得很快,5 个节点还好,20 个节点就难维护
  • 状态对象设计不当会让所有节点都需要修改
  • 调试时需要熟悉 LangSmith 等周边工具

AutoGen

  • GroupChat 模式下对话回合容易失控,需要严格的终止条件
  • 0.2 和 0.4 版本 API 差异大,老资料容易误导
  • 代码执行环境的安全配置需要额外注意

CrewAI

  • Agent 表现高度依赖 role / backstory 的 prompt 质量
  • 顺序流程下,前置任务的输出格式不稳定,会让后续任务受影响
  • 复杂任务依赖关系不好表达

OpenHands

  • Docker 资源占用不小,本地跑长任务可能吃满 CPU
  • 自定义 Agent 行为需要改源码或写插件
  • 文件系统的持久化策略需要根据使用场景调整

框架之外的选择

值得提一下:不用框架也是一种选择

如果任务足够简单,直接用 OpenAI / Anthropic 的官方 SDK 加几个 Python 函数就够了。框架的价值在于复杂任务的组织和复用,简单任务用框架反而是负担。

判断标准:如果你的 Agent 逻辑用 200 行普通 Python 能写清楚,就先用普通 Python 写。等到代码超过 1000 行、流程开始难以维护,再考虑引入框架。


小结

四个框架的设计哲学不同,没有绝对的优劣。

  • LangGraph 适合需要细粒度控制的复杂工作流
  • AutoGen 适合多 Agent 对话场景和研究项目
  • CrewAI 适合可清晰角色化的任务
  • OpenHands 适合直接使用的软件工程 Agent

实际选型先想清楚自己的任务长什么样,再去匹配框架。框架的"先进"不一定等于"适合你"。简单任务用简单方案,复杂任务再用框架,这个判断比框架选择本身更重要。

版权声明: 如无特别声明,本文版权归 sshipanoo 所有,转载请注明本文链接。

(采用 CC BY-NC-SA 4.0 许可协议进行授权)

本文标题:19. Agent 框架横向对比:LangGraph、AutoGen、CrewAI、OpenHands

本文链接:https://www.sshipanoo.com/blog/ai/code-agent-harness/19-Agent框架对比/

本文最后一次更新为 天前,文章中的某些内容可能已过时!