LangGraph vs AutoGen：状态图与对话式多 Agent 框架深度对比

当一个 Agent 任务需要「多个角色协作」或「复杂工作流」时，单 Agent 框架（如直接用 OpenAI API + tool calling）很快就会力不从心。2024-2025 年，开源生态里最成熟的两个多 Agent / Agent 编排框架是：

• LangGraph（LangChain 团队）：用显式状态图（State Graph）描述 Agent 流程，把 Agent 当作图的节点，把状态转移当作边。
• AutoGen（微软研究院）：用对话驱动（Conversation-Driven）的方式让多个 Agent 互相发送消息、自主决定下一步。

两个框架的设计哲学完全相反：LangGraph 让人类显式编排，AutoGen 让 Agent 自主协商。选错会让你的项目要么「失控」、要么「过度僵化」。

一、问题：单 Agent 为什么不够

在 LLM 应用早期，主流范式是「单 Agent + 工具调用」：一个 LLM 循环调用工具直到任务完成。这种范式在三类场景下失灵：

1. 复杂工作流：研究一个学术问题需要「搜索 → 总结 → 验证 → 撰写」四步，且每步可能要循环或回退。
2. 多角色协作：写代码需要「产品经理（PRD）→ 架构师（设计）→ 开发者（实现）→ 测试（验证）」多个角色的输出。
3. 状态管理：长任务需要在多轮对话中保留中间状态（已经查到了什么、已经写到了哪里），而不是把全部历史塞进 prompt。

LangGraph 和 AutoGen 分别用「状态图」和「对话机制」回答了这些问题。

二、架构抽象：状态图 vs 对话

LangGraph：图就是编排

LangGraph 的核心抽象是 StateGraph——一个有向图，节点是函数/Agent，边是状态转移条件：

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

class ResearchState(TypedDict):
  messages: Annotated[list, add_messages]
  findings: list[str]
  report: str

# 节点函数
def search_node(state: ResearchState):
  # 调用搜索工具，把发现写入 state
  return {"findings": state["findings"] + [search(state["messages"][-1].content)]}

def summary_node(state: ResearchState):
  # 总结当前 findings
  summary = llm.invoke(f"总结以下发现：{state['findings']}")
  return {"findings": state["findings"] + [summary]}

def write_node(state: ResearchState):
  # 生成报告
  report = llm.invoke(f"基于 {state['findings']} 撰写报告")
  return {"report": report}

def should_continue(state: ResearchState):
  if len(state["findings"]) < 3:
    return "search"
  return "write"

# 构建图
graph = StateGraph(ResearchState)
graph.add_node("search", search_node)
graph.add_node("summary", summary_node)
graph.add_node("write", write_node)
graph.add_edge(START, "search")
graph.add_edge("search", "summary")
graph.add_conditional_edges("summary", should_continue, {"search": "search", "write": "write"})
graph.add_edge("write", END)

app = graph.compile()

关键特性：

• 显式状态：State 是 TypedDict，每个节点读写 State 的字段。
• 循环与分支：add_conditional_edges 让图能循环（多次搜索）或分支（不同情况走不同路径）。
• Checkpointer：可以挂载 MemorySaver、Postgres 等持久化后端，让长任务跨进程恢复。
• 可视化：graph.compile().get_graph().draw_png() 可以画出图结构。

这种「图就是编排」的哲学让 LangGraph 控制粒度极高——每一步发生什么、状态怎么流转都是开发者写死的。

AutoGen：对话就是编排

AutoGen 的核心抽象是 Agent + 消息传递——多个 Agent 互相发送消息，Agent 自己决定下一步做什么：

from autogen_agentchat.agents import AssistantAgent, UserProxyAgent
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_ext.models.openai import OpenAIChatCompletionClient

model_client = OpenAIChatCompletionClient(model="gpt-4o")

# 定义多个角色 Agent
planner = AssistantAgent(
  name="planner",
  model_client=model_client,
  system_message="你是产品规划师，输出 PRD。"
)

architect = AssistantAgent(
  name="architect",
  model_client=model_client,
  system_message="你是系统架构师，根据 PRD 输出技术方案。"
)

developer = AssistantAgent(
  name="developer",
  model_client=model_client,
  system_message="你是开发者，根据技术方案写代码。"
)

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

# 让 Agent 们轮流对话
team = RoundRobinGroupChat([planner, architect, developer, user_proxy])
await team.run(task="设计并实现一个 TODO 应用")

关键特性：

• 对话驱动：Agent 之间通过 message 互相通讯，没有显式的「下一步做什么」。
• Group Chat：多种聊天模式（RoundRobin、Selector、Swarm）决定谁发言。
• Human-in-the-Loop：UserProxyAgent 让人类随时介入对话。
• 工具执行：AssistantAgent 内置 function call 支持，可以执行代码、调用 API。

这种「对话就是编排」的哲学让 AutoGen 控制粒度极低——开发者只定义「有哪些角色」，具体交互由 Agent 自主决定。

三、关键维度对比

维度	LangGraph	AutoGen
核心抽象	StateGraph（节点 + 边 + 状态）	Agent + GroupChat
编排方式	显式定义（开发者写死的图）	对话驱动（Agent 自主决定）
控制粒度	高（每步可控）	低（自主协商）
多 Agent	通过节点组合	原生多 Agent 对话
学习曲线	中（理解图、状态、边）	低（写 Agent 类即可）
状态管理	内置 Checkpointer（内存/Postgres/Redis）	需要自己实现或用 ConversationMemory
可视化	原生 draw_png	Studio（商业）
可观测性	LangSmith（深度集成）	OpenTelemetry + 自定义
调试难度	中（图结构清晰）	高（对话动态变化）
Human-in-the-Loop	通过 interrupt 机制	原生 UserProxyAgent
代码执行	通过工具节点	原生支持（Docker/script）
流式输出	原生（stream mode）	原生（stream mode）
部署	自托管 / LangGraph Platform	自托管 / AutoGen Studio
社区生态	LangChain 生态（200+ 集成）	微软生态 + 独立开源

四、控制粒度：可预测 vs 自主

这是两个框架最本质的差异。

LangGraph 的可预测性：图结构是开发者定义的，每次执行走的是相同路径。这意味着：

• 同样的输入会得到同样的执行序列（除非 conditional edges 里的判断条件变化）
• 适合需要「严格流程」的场景（合规、审计、生产任务）
• 调试容易：通过 trace 看图上每条边的触发

AutoGen 的自主性：对话是 Agent 自主决定的，每次执行的对话流可能不同。这意味着：

• 同样的输入可能得到完全不同的执行序列
• 适合需要「头脑风暴、研究探索」的场景
• 调试困难：对话分支不可预测，需要大量日志回溯

五、典型场景适配

LangGraph 更适合的场景

• 生产级 Agent 工作流：需要严格流程控制（合规、审计、CI/CD）。
• 复杂状态管理：长任务需要跨进程恢复（客服多轮对话、审批流）。
• 可视化编排：PM/分析师需要能看懂流程图。
• 与 LangChain 生态集成：已经在用 LangChain / LlamaIndex。
• RAG Pipeline：检索 → 重排 → 生成 → 验证的标准 pipeline。

AutoGen 更适合的场景

• 多角色协作研究：让「研究员 + 程序员 + 测试员」一起讨论问题。
• 快速原型：探索性任务，团队愿意接受不可预测的输出。
• 代码生成 + 执行一体化：让 Developer Agent 直接执行代码看效果。
• Human-in-the-Loop 探索：开发者想随时介入对话调整方向。
• 微软生态：已经在用 Azure OpenAI、Semantic Kernel、.NET。

六、生产可维护性

LangGraph 的可维护性优势

• 图结构即文档：get_graph().draw_png() 输出的图就是最好的文档。
• Checkpointer 标准化：内置 Postgres/Redis Checkpointer，长任务跨进程恢复开箱即用。
• LangSmith 深度集成：trace、metric、feedback 一体化。
• 状态可序列化：每个 State 都是 TypedDict，可以版本控制。

AutoGen 的可维护性挑战

• 对话分支爆炸：一次执行可能产生数十种对话分支，难以测试。
• 调试工具弱：虽然有 OpenTelemetry，但 trace 可读性不如 LangGraph。
• 状态管理需要自己实现：需要自己挂 ConversationMemory 才能跨任务保留状态。
• 生产案例较少：相比 LangGraph，AutoGen 在大规模生产环境的公开案例偏少。

七、性能与成本

LangGraph 的性能可控

• token 消耗可预测：因为图结构固定，每次执行的 LLM 调用次数基本确定。
• 可优化空间大：可以用条件边跳过不必要的节点，可以用批处理合并多次 LLM 调用。
• 典型成本：复杂 5 节点图的单次执行约 5-15 次 LLM 调用。

AutoGen 的性能波动

• token 消耗不可预测：对话可能无限循环（需要设 max_turns），可能提前终止。
• 优化空间小：因为流程不固定，难以做批处理。
• 典型成本：多 Agent 对话可能消耗 20-100 次 LLM 调用。

八、决策树

任务结构清晰、流程固定 → LangGraph。任务探索性强、需要头脑风暴 → AutoGen。需要严格控制每步 → LangGraph。可以接受 Agent 自主决策 → AutoGen。需要跨进程状态恢复 → LangGraph（Checkpointer）。需要 Human-in-the-Loop 频繁介入 → AutoGen（UserProxyAgent 更原生）。已经在用 LangChain → LangGraph。已经在用 Azure / 微软生态 → AutoGen。

九、常见陷阱

1. LangGraph = 简单流程图：LangGraph 的图可以包含循环、条件分支、子图，实际表达能力很强。但不要试图用它做所有事——复杂决策逻辑还是让 LLM 决定。
2. AutoGen = 完全自主：AutoGen 的对话也是可以配置的（GroupChat 模式、max_turns、termination conditions）。但默认配置容易让对话跑飞，需要仔细调参。
3. 两个框架性能差不多：很多人误以为 AutoGen 因为「多 Agent 对话」会显著消耗 token，实际上 LangGraph 的图执行也是多次 LLM 调用。关键差异是「可预测性」而不是「性能」。
4. LangGraph 不能多 Agent：LangGraph 完全支持多 Agent（每个节点是一个 Agent），只是开发者要显式编排。
5. AutoGen 不能做流程：AutoGen 也可以通过 SelectorGroupChat 让对话流程可控，但不如 LangGraph 显式。

十、未来趋势

Agent 编排框架的下一步突破点在三个方向：

• 可视化协作：两个框架都在做可视化（LangGraph 的 draw_png、AutoGen 的 Studio），未来会让非工程师也能设计 Agent 流程。
• 可观测性：LangSmith 模式的 trace + metric + eval 平台会成为标配。
• 混合架构：用 LangGraph 编排主流程，用 AutoGen 处理流程中的「探索性子任务」（如让 AutoGen 帮 LangGraph 做研究子任务）。

最后一句话：没有「更好的多 Agent 框架」，只有「更适配你任务形态的框架」。流程可控、生产可维护 → LangGraph；多角色协作、探索性强 → AutoGen。最佳实践是组合使用——LangGraph 编排主流程，AutoGen 处理流程中的开放性子任务。