LangGraph vs CrewAI vs AutoGen vs Hermes Agent：2026 年四大 Agent 框架的”状态机哲学”之争

Agent 框架的竞争正在从”谁能跑 Demo”进入”谁能扛生产”的阶段。

过去一年，几乎所有 Agent 框架都实现了基本功能：工具调用、多步推理、记忆管理。但到了生产环境，真正拉开差距的不是功能数量，而是状态管理的能力——

• 任务执行到第 8 步失败了，能从第 7 步恢复吗？
• 10 个 Agent 并行执行，你能看到每个 Agent 当前的状态吗？
• 一个 Agent 崩溃了，会不会拖垮整个任务链？

这篇文章从状态管理哲学的维度，对比四大主流 Agent 框架：

框架	版本	语言	状态模型
LangGraph	v0.4.x	Python	图论状态机
CrewAI	v0.100+	Python	角色接力状态
AutoGen	v0.4+	Python	对话状态漂移
Hermes Agent	v1.2+	Python	依赖驱动 DAG 状态

不列 feature matrix，只做三件事：定义测试任务、实测三个生产级指标、给出选型矩阵。

---

一、测试任务：15 步复杂任务链

为了公平对比，四个框架实现同一个 15 步任务，包含条件分支、循环重试、并行聚合三种复杂模式：

Step 1:  读取用户需求（初始输入）
Step 2:  分析需求，拆解为子任务
Step 3:  子任务 A → 查询数据库获取历史数据
Step 4:  子任务 B → 调用外部 API 获取实时数据 [并行]
Step 5:  子任务 C → 搜索知识库获取参考文档 [并行]
Step 6:  聚合 B+C 的结果
Step 7:  IF 数据完整度 > 80% → 进入 Step 8
         ELSE → 重新查询（最多重试 3 次）
Step 8:  生成分析报告草稿
Step 9:  自检：检查报告中的数据引用是否准确
Step 10: IF 自检失败 → 修正数据（最多重试 2 次）
         ELSE → 进入 Step 11
Step 11: 生成图表（数据可视化）
Step 12: 生成最终报告
Step 13: 人工审核（等待外部输入）
Step 14: IF 审核通过 → 发布
         ELSE → 回到 Step 8 修改
Step 15: 发布报告，记录执行日志

复杂度指标：

• 条件分支：3 个（Step 7、Step 10、Step 14）
• 并行节点：1 个（Step 4+5）
• 重试循环：2 个（Step 7、Step 10）
• 外部等待：1 个（Step 13）
• 状态持久化需求：全流程 15 步的中间状态需要可追溯

---

二、维度一：状态恢复能力

2.1 LangGraph：图论状态机

LangGraph 的核心数据结构是 StateGraph，每个节点代表一个操作，每条边代表状态转换。状态通过 State 对象传递：

from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
from langgraph.graph.message import add_messages

class AgentState(TypedDict):
    messages: Annotated[list, add_messages]
    analysis: str
    data_fetched: bool
    retry_count: int
    report: str

def build_workflow():
    workflow = StateGraph(AgentState)
    
    workflow.add_node("analyze", analyze_node)
    workflow.add_node("fetch_db", fetch_db_node)
    workflow.add_node("fetch_api", fetch_api_node)
    workflow.add_node("aggregate", aggregate_node)
    # ... 更多节点
    
    workflow.add_edge("analyze", "fetch_db")
    workflow.add_conditional_edges(
        "aggregate",
        check_completeness,
        {"complete": "generate_draft", "incomplete": "fetch_db"}
    )
    
    return workflow.compile()

状态恢复机制：LangGraph 内置 checkpointer，支持 MemorySaver（内存）、PostgresSaver、SqliteSaver 等后端。每次节点执行后，整个 State 对象被序列化并存储：

from langgraph.checkpoint.sqlite import SqliteSaver

with SqliteSaver.from_conn_string("checkpoints.db") as checkpointer:
    graph = workflow.compile(checkpointer=checkpointer)
    
    # 执行到一半失败后，从最后一个 checkpoint 恢复
    config = {"configurable": {"thread_id": "task-001"}}
    result = graph.invoke(initial_state, config)
    
    # 如果中途失败，重新调用即可从断点继续
    result = graph.invoke(None, config)  # None = 从 checkpoint 恢复

优势：

• 状态恢复粒度精确到每个节点
• 支持时间旅行调试（查看任意历史状态）
• 状态持久化后端可插拔

劣势：

• 状态对象需要在编译时定义类型，修改字段需要重新编译图
• 大状态对象（含大量中间数据）的序列化开销明显

2.2 CrewAI：角色接力状态

CrewAI 的状态管理建立在角色（Agent）- 任务（Task）- 流程（Process） 三层模型上：

from crewai import Agent, Task, Crew, Process
from crewai.project import CrewBase, agent, task, crew

class DataAnalysisCrew(CrewBase):
    @agent
    def researcher(self) -> Agent:
        return Agent(
            role="Data Researcher",
            goal="Fetch and analyze data from multiple sources",
            tools=[db_tool, api_tool],
            llm=llm
        )
    
    @task
    def fetch_data(self) -> Task:
        return Task(
            description="Fetch historical data from database",
            expected_output="Structured data dictionary",
            agent=self.researcher()
        )
    
    @crew
    def crew(self) -> Crew:
        return Crew(
            agents=[self.researcher(), self.analyst()],
            tasks=[self.fetch_data(), self.analyze()],
            process=Process.sequential,  # 或 Process.hierarchical
            memory=True,
            cache=True
        )

状态恢复机制：CrewAI v0.100+ 引入了 TaskOutput 缓存和 memory 模块。任务执行结果被存储，但状态恢复的粒度是任务级别，不是步骤级别：

# CrewAI 的"恢复"本质上是重跑失败任务及之后的所有任务
# 不支持从任务内部的某个中间步骤恢复
crew = DataAnalysisCrew().crew()
result = crew.kickoff()

# 如果 Task 3 失败，重跑时需要重新执行 Task 1、2（除非缓存命中）

优势：

• 任务级别的状态缓存实现简单
• memory=True 自动在 Agent 之间共享上下文
• 代码组织清晰，角色-任务-流程的抽象直观

劣势：

• 不支持细粒度的步骤级恢复
• 条件分支需要通过 context 手动传递状态
• 并行任务的状态聚合不够灵活（只能顺序或层级）

2.3 AutoGen：对话状态漂移

AutoGen 的状态管理最”非传统”——它没有显式的状态机，状态隐含在多 Agent 对话历史中：

from autogen import AssistantAgent, UserProxyAgent, GroupChat, GroupChatManager

# 定义 Agent
researcher = AssistantAgent(
    name="Researcher",
    system_message="You are a data researcher.",
    llm_config=llm_config
)

analyst = AssistantAgent(
    name="Analyst", 
    system_message="You are a data analyst.",
    llm_config=llm_config
)

# GroupChat 管理对话状态
groupchat = GroupChat(
    agents=[researcher, analyst],
    messages=[],  # 对话历史 = 隐式状态
    max_round=15
)

manager = GroupChatManager(groupchat=groupchat, llm_config=llm_config)

# 启动对话
user_proxy.initiate_chat(manager, message="Analyze the database...")

状态恢复机制：AutoGen 的状态就是 messages 列表。保存对话历史即可”恢复”状态：

# 保存对话状态
import json
state = json.dumps([msg.to_dict() for msg in groupchat.messages])

# 恢复
groupchat.messages = [ChatMessage.from_dict(d) for d in json.loads(state)]

优势：

• 状态模型极简——就是对话历史
• 自然支持 Agent 之间的状态传递（通过对话）
• 调试直观：看对话记录就知道发生了什么

劣势：

• 状态漂移问题：随着对话轮数增加，关键信息被稀释在长对话中，Agent 可能”忘记”早期的重要上下文
• 没有结构化的状态对象，条件分支需要在对话中”暗示”而非显式编码
• 恢复状态需要重新序列化/反序列化整个对话历史，开销随对话长度线性增长

2.4 Hermes Agent：依赖驱动 DAG 状态

Hermes Agent 使用 Kanban 任务板 + DAG 依赖图 管理状态：

from hermagent import kanban_create, kanban_complete

# 定义任务依赖图
t1 = kanban_create(
    title="分析需求",
    assignee="analyst",
    body="拆解用户需求为子任务"
)

# 并行任务
t2 = kanban_create(
    title="查询数据库",
    assignee="backend-eng",
    parents=[t1["task_id"]]  # 依赖 t1
)

t3 = kanban_create(
    title="调用外部API",
    assignee="backend-eng",
    parents=[t1["task_id"]]  # 依赖 t1，与 t2 并行
)

# 条件分支：检查数据完整度
t4 = kanban_create(
    title="检查数据完整度",
    assignee="analyst",
    parents=[t2["task_id"], t3["task_id"]]
)

状态恢复机制：每个任务的状态（pending、running、completed、failed、blocked）独立存储在 SQLite 中。失败任务的恢复是任务级别的：

# 任务失败后，Dispatcher 自动标记为 failed
# 可以手动重新调度
kanban_retry(task_id="task-003", reason="API timeout")

# 或者自动重试策略
kanban_create(
    title="查询数据库（重试）",
    assignee="backend-eng",
    parents=[t1["task_id"]],
    retry_of="task-002",  # 标记为重试
    max_retries=3
)

优势：

• 每个任务状态独立，失败隔离性好
• DAG 依赖天然支持条件分支和并行
• 状态持久化是默认行为（SQLite），不需要额外配置
• 支持任务级别的人工审核（kanban_block）

劣势：

• 任务粒度由开发者定义，过细会增加管理开销
• 条件分支需要显式创建多个任务节点
• 学习曲线略高于 CrewAI

2.5 状态恢复能力对比

指标	LangGraph	CrewAI	AutoGen	Hermes Agent
恢复粒度	节点级	任务级	对话级	任务级
恢复精度	⭐⭐⭐⭐⭐ 精确到单步	⭐⭐⭐ 整任务重跑	⭐⭐ 对话截断	⭐⭐⭐⭐ 任务级重试
恢复开销	低（增量 checkpoint）	中（任务缓存）	高（全对话序列化）	低（SQLite 查询）
时间旅行	✅ 任意历史状态	❌ 仅最终输出	⚠️ 仅对话历史	✅ 任务历史记录
外部等待支持	⚠️ 需手动中断/恢复	❌ 不支持	⚠️ 需人工介入	✅ 原生支持（block）

评分：LangGraph > Hermes Agent > CrewAI > AutoGen

---

三、维度二：调试可视化

3.1 LangGraph：LangSmith 深度集成

LangGraph 最大的调试优势是 LangSmith 生态：

LangSmith UI 展示：
┌─────────────────────────────────────────────┐
│  Trace: Data Analysis Pipeline               │
├─────────────────────────────────────────────┤
│  analyze        ✅ 1.2s  │ State: {...}      │
│  ├── fetch_db   ✅ 3.4s  │ State: {...}      │
│  ├── fetch_api  ❌ 0.8s  │ Error: timeout    │
│  └── fetch_api  ✅ 2.1s  │ State: {...}      │
│       retry ↑   (auto-retry)                 │
│  aggregate      ✅ 0.5s  │ State: {...}      │
│  generate_draft ✅ 4.2s  │ State: {...}      │
│                                             │
│  Total: 12.2s  │ Tokens: 45,200              │
│  Cost: $0.18                                 │
└─────────────────────────────────────────────┘

能力：

• 每个节点的输入/输出状态快照
• 执行时间、Token 消耗、成本追踪
• 自动重试可视化
• 支持回放整个执行过程

缺点：LangSmith 是付费服务（有免费额度），离线环境下无法使用。

3.2 CrewAI：内置日志 + CrewAI Studio

CrewAI 的调试工具相对轻量：

CrewAI 输出：
[Researcher] Starting task: Fetch data from database
[Researcher] Tool call: db_query(sql="SELECT...")
[Researcher] Tool output: 1,234 rows returned
[Researcher] Task completed: Data dictionary generated

[Analyst] Starting task: Analyze data
[Analyst] Analysis complete: 3 insights found

CrewAI Studio（v0.100+ 新增）提供了 Web UI 查看任务执行流程，但功能有限：

• 只能看到任务级别的状态
• 没有单步调试
• 不支持时间旅行

3.3 AutoGen：对话回放

AutoGen 的调试就是看对话：

User: Analyze the database...
Researcher: I'll fetch the data first. [calls db_query tool]
Researcher: Found 1,234 rows. Let me analyze...
Analyst: Based on the data, I see 3 patterns...

调试方式：

• 直接阅读对话历史
• 可以通过 termination_msg 查看终止原因
• 没有结构化的调试工具

缺点：对话超过 50 轮后，调试效率急剧下降——你需要在大量对话中找到关键信息。

3.4 Hermes Agent：Kanban Board + 审计日志

Hermes Agent 的调试基于 Kanban 任务板：

┌─────────────────────────────────────────────┐
│  Kanban Board: Data Analysis Project         │
├──────────┬──────────┬──────────┬────────────┤
│ Pending  │ Running  │ Completed│ Blocked    │
├──────────┼──────────┼──────────┼────────────┤
│          │ 调用API  │ 分析需求 │ 等待审核   │
│          │ (3.2s)   │ (1.1s)  │ (2h 等待)  │
│          │          │ 查询DB  │            │
│          │          │ (2.8s)  │            │
│          │          │ 聚合数据│            │
│          │          │ (0.5s)  │            │
└──────────┴──────────┴──────────┴────────────┘

Audit Log:
[06:01:00] task-001 (analyze) → completed by analyst
[06:01:02] task-002 (fetch_db) → started, assigned to backend-eng
[06:01:02] task-003 (fetch_api) → started, assigned to backend-eng (parallel)
[06:01:05] task-002 (fetch_db) → completed
[06:01:05] task-003 (fetch_api) → completed
[06:01:06] task-004 (aggregate) → started
...

能力：

• 任务板实时状态
• 完整的审计日志（时间戳 + 操作 + 结果）
• 失败任务的自动标记和手动重试
• 支持人工审核阻塞点（kanban_block）

缺点：没有 LangSmith 级别的可视化深度（如 Token 消耗追踪、成本分析）。

3.5 调试可视化对比

能力	LangGraph	CrewAI	AutoGen	Hermes Agent
执行流程可视化	⭐⭐⭐⭐⭐ LangSmith	⭐⭐⭐ CrewAI Studio	⭐⭐ 对话回放	⭐⭐⭐⭐ Kanban Board
单步调试	✅	⚠️ 任务级	❌	⚠️ 任务级
Token/成本追踪	✅ LangSmith	❌	❌	❌
审计日志	✅ 详细	⚠️ 基础	⚠️ 对话即日志	✅ 详细
离线可用性	❌ 需联网	✅	✅	✅

---

四、维度三：失败隔离

4.1 实验设计

在 15 步任务链中，故意让 Step 4（API 调用） 超时失败，观察各框架的行为：

4.2 LangGraph

# LangGraph 的失败隔离：节点级
# fetch_api 节点失败 → 通过条件边进入重试路径
# 不影响 fetch_db 节点（如果是并行的话）

# 但默认情况下，一个节点失败会中断整个图
# 需要显式定义重试逻辑或异常处理节点
def fetch_api_with_retry(state):
    for attempt in range(3):
        try:
            return call_api()
        except Exception as e:
            if attempt == 2:
                return {"error": str(e), "fallback": True}
    return {"error": "max retries exceeded"}

隔离性：⭐⭐⭐⭐ — 节点级隔离，但需要手动定义异常处理逻辑。如果不定义，一个节点失败会中断整个图。

4.3 CrewAI

# CrewAI 的失败隔离：任务级
# 一个 Task 失败，整个 Crew 流程中断（默认行为）
# 需要设置 allow_delegation=True 和 human_input=True 来增加容错

@task
def fetch_data(self) -> Task:
    return Task(
        description="Fetch data...",
        expected_output="...",
        agent=self.researcher(),
        allow_delegation=True,  # 失败时委托给其他 Agent
    )

隔离性：⭐⭐⭐ — 任务级隔离，支持委托机制。但委托的粒度较粗，一个任务失败会阻塞后续依赖任务。

4.4 AutoGen

# AutoGen 的失败隔离：几乎没有
# 一个 Agent 出错（如 API 超时），错误会传播到对话中
# 其他 Agent 可能继续执行，但基于错误的数据
# 没有内建的失败隔离机制

隔离性：⭐⭐ — 依赖对话中的错误处理。如果 Agent 不主动检测和处理错误，错误会静默传播。

4.5 Hermes Agent

# Hermes Agent 的失败隔离：任务级 + 依赖自动阻断
# task-003 (fetch_api) 失败 → 自动标记为 failed
# 依赖 task-003 的后续任务不会启动
# 不依赖 task-003 的并行任务（如 task-002 fetch_db）正常完成

# Dispatcher 自动处理依赖图：
# - 父任务失败 → 子任务标记为 blocked
# - 可以配置自动重试策略
# - 也可以人工介入处理

隔离性：⭐⭐⭐⭐⭐ — 任务级隔离 + 依赖自动阻断。失败不会污染其他并行任务，也不需要手动定义异常处理路径。

4.6 失败隔离对比

场景	LangGraph	CrewAI	AutoGen	Hermes Agent
单节点失败影响范围	中断整个图（默认）	中断整个流程	错误传播到对话	仅阻断下游依赖
自动重试	需手动定义	需手动定义	不支持	✅ 内置
并行任务隔离	✅ 独立节点	⚠️ 取决于 Process	❌ 对话共享	✅ 任务独立
人工介入点	⚠️ 需自定义	✅ human_input	⚠️ 对话中介入	✅ kanban_block

---

五、综合评分与选型矩阵

5.1 三维度总评

维度	LangGraph	CrewAI	AutoGen	Hermes Agent
状态恢复能力	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐	⭐⭐⭐⭐
调试可视化	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐	⭐⭐⭐⭐
失败隔离	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐	⭐⭐⭐⭐⭐
综合	4.7	3.0	2.0	4.3

5.2 选型矩阵

场景	推荐框架	理由
需要精细的状态控制 + 生产级调试	LangGraph	节点级状态恢复 + LangSmith 生态无可替代
快速原型 + 团队不熟悉状态机概念	CrewAI	角色-任务-流程抽象最直观，上手最快
研究多 Agent 对话行为	AutoGen	对话驱动的状态模型最适合对话场景研究
长期运行的复杂任务 + 需要人工审核	Hermes Agent	DAG 依赖 + 任务独立状态 + 原生人工审核
需要离线部署 + 审计日志	Hermes Agent	SQLite 持久化 + 完整审计日志，不依赖云服务
需要成本追踪 + Token 监控	LangGraph	LangSmith 是唯一提供完整成本追踪的工具

5.3 一句话总结

• LangGraph：生产环境的状态管理标杆，但需要付费服务才能发挥全部能力。
• CrewAI：快速上手的首选，但生产环境的容错和调试能力有限。
• AutoGen：对话研究的利器，但生产环境的状态管理能力最弱。
• Hermes Agent：长期复杂任务的最佳选择，任务独立 + DAG 依赖 + 人工审核的组合拳，在失败隔离方面表现最优。

---

数据来源：LangGraph v0.4.0 / CrewAI v0.100+ / AutoGen v0.4+ / Hermes Agent v1.2.0 官方文档 + 实测 测试时间：2026-05-29 至 2026-05-30 测试环境：Python 3.12 / 统一使用 Qwen3.6-Plus 作为 LLM 后端