LangGraph 与 AutoGen 是构建多智能体系统最常用的两个框架，它们押下的设计赌注恰好相反。LangGraph 把工作流建模成一张你亲手掌控的显式图；AutoGen 则让智能体互相对话、任由结构涌现。抽象地说没有谁更好——正确的选择取决于你能事先把多少控制流写明。本文从架构和一个可运行示例两方面对比二者，再交代那些比框架选择本身更长久的生产考量。内容最后一次技术核验时间为 2026 年 7 月 16 日。由于这两个项目在大版本之间变化很快，本文的具体 API 请当作起点，并对照当前官方文档确认。

核心要点

  • LangGraph 把控制流写明（节点、边、一个共享状态对象）；AutoGen 让控制流涌现（智能体交换消息，直到满足终止条件）。
  • 工作流已知、需要确定性、状态可检视、需要人机介入检查点时选 LangGraph；任务开放、想快速做原型时选 AutoGen。
  • 两者都需要一个硬循环上限——默认情况下它们都不会自行停下。
  • 任何执行代码的 Agent 都必须在沙箱里运行——在持有真实凭据的主机上设 use_docker=False 是安全漏洞，而非图方便。
  • 框架不强制权限——真正约束的是每个 Agent 的工具范围和服务端访问控制。

为什么用多智能体，以及何时不该用

把一份工作拆给专职智能体确实有帮助：一个只写代码的编码 Agent 和一个只运行代码的测试 Agent，各自保持的上下文都比一个「全能」Agent 同时兜住一切要窄。当测试失败时，测试 Agent 可以把错误反馈给编码 Agent，形成一个自动修复闭环。

但要清醒看待其中的权衡。正如本系列的多智能体系统指南所主张的，拆成多个智能体之所以对得起协调成本，只在角色需要不同工具或权限、工作能真正并行、或不同的负责人评估不同步骤时成立。编码/测试闭环之所以合格，是因为测试 Agent 需要一个编码 Agent 不该拥有的执行工具——但一个仅仅「多步骤」的任务，往往用单个 Agent、甚至用路由环节里根本没有模型的确定性流水线，跑得更好。

两种架构

LangGraph：基于图的状态机

LangGraph 把工作流抽象为一张有向图：

  • **节点（Nodes）**是执行步骤——一个 Agent、一次工具调用，或一段普通函数。
  • **边（Edges）**定义流转，包括条件边（例如「若测试通过则结束，否则回到编码节点」）。
  • **状态（State）**是一个在节点间传递的单一对象。每个节点读取它，并返回一份更新。

其哲学是控制：流转由你绘制、状态可检视，你还能加入检查点和人工审批。这适合形态事先已知的工作流。

AutoGen：对话驱动的智能体

AutoGen 的核心是可对话智能体。智能体通过交换消息协作，任务推进依赖这段对话加上一个终止条件，而不是预定义的图。其哲学是灵活：定义好每个 Agent 的角色和工具，把它们放进一段对话，让交互自己找到路径。这适合开放、探索性的任务——代价是控制流更难预测。

用两个框架各实现一遍「编码-测试」闭环

我们构建同一个两 Agent 系统：一个编码 Agent 写 Python，一个测试 Agent 运行代码、把错误反馈回来，直到跑通。

LangGraph 实现

注意 llm 和 run_python_code 是你需要自行提供的占位符——尤其 run_python_code 必须在沙箱里执行（见下文）。should_continue 里的循环上限不是可选项；没有它，图可能永远循环下去。

python 
import os
from typing import TypedDict, Annotated
from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI
import operator

llm = ChatOpenAI(model=os.environ.get("OPENAI_MODEL", "gpt-4o"))

class AgentState(TypedDict):
    messages: Annotated[list, operator.add]
    code: str
    test_result: str
    iterations: int

def coder_node(state: AgentState):
    result = llm.invoke("编写或修复代码：\n" + str(state["messages"]))
    return {"code": result.content, "iterations": state["iterations"] + 1}

def tester_node(state: AgentState):
    # run_python_code 必须在沙箱里运行，绝不能直接跑在主机上
    result = run_python_code(state["code"])
    return {"test_result": result}

def should_continue(state: AgentState):
    if "SUCCESS" in state["test_result"]:
        return END
    if state["iterations"] > 3:  # 硬循环上限——必需
        return END
    return "coder"

workflow = StateGraph(AgentState)
workflow.add_node("coder", coder_node)
workflow.add_node("tester", tester_node)
workflow.set_entry_point("coder")
workflow.add_edge("coder", "tester")
workflow.add_conditional_edges("tester", should_continue)

app = workflow.compile()

AutoGen 实现

AutoGen 版本更声明式——你定义好 Agent 并启动对话。最重要的一行是执行配置：让生成的代码在 Docker 里运行，而不是直接跑在主机上。

python 
import os
from autogen import AssistantAgent, UserProxyAgent

config_list = [{"model": os.environ.get("OPENAI_MODEL", "gpt-4o")}]

coder = AssistantAgent(
    name="Coder",
    llm_config={"config_list": config_list},
    system_message=(
        "你是一个高级 Python 工程师。请编写代码以满足需求。"
        "如果测试员报告错误，请修复后重新输出。"
    ),
)

tester = UserProxyAgent(
    name="Tester",
    human_input_mode="NEVER",
    max_consecutive_auto_reply=3,  # 硬循环上限——必需
    is_termination_msg=lambda x: x.get("content", "").rstrip().endswith("TERMINATE"),
    code_execution_config={
        "work_dir": "coding",
        "use_docker": True,  # 沙箱化生成的代码；生产环境不要关闭
    },
)

tester.initiate_chat(
    coder,
    message="请编写一个计算斐波那契数列的函数，并包含断言测试。",
)

AutoGen 的 API 在大版本间变动过——上面的导入和配置形态匹配经典的 autogen 包，但请对照你实际安装的版本确认。

比框架选择更长久的生产考量

框架决定的是使用体验；下面这些决定的是系统能否安全运行。

  • **凡是执行代码的都要沙箱化。**编码/测试闭环从设计上就会生成并运行不可信代码。把它放进一个没有生产凭据的隔离容器里。开发笔记本上设 use_docker=False 是一回事；生产环境里同样的设置就是一个远程代码执行面。
  • **处处给循环设上限。**LangGraph 需要 should_continue 里的迭代检查；AutoGen 需要 max_consecutive_auto_reply。再加上墙钟时间和成本上限——按 Token 计费的 Agent 会在一个死循环里烧光预算。
  • **框架不强制权限。**图的一条边或一段系统提示词都不能限制 Agent 能触达什么。把每个 Agent 的工具收敛到其角色所需，并在服务端、每次调用时强制对象级和租户级的访问控制。
  • **把工具返回值和 Agent 间消息当作不可信输入。**一段测试日志、一个工具结果、或另一个 Agent 的消息，都可能夹带为操纵模型而构造的文本。要校验并标注出处，绝不让它充当带授权的指令。

如何选择

适合 LangGraph 的情形：

  • 工作流定义清晰且大体固定（接入 → 意图识别 → 检索 → 生成回复）。
  • 你需要状态检视和类似时间旅行的回溯。
  • 你需要在特定节点引入人工审批。
  • 你已经深度投入 LangChain 生态。

适合 AutoGen 的情形：

  • 任务具有探索性、开放性（多个 Agent 讨论一套方案）。
  • 你想快速做原型，不愿编写显式的状态管理。
  • 你需要灵活的组网拓扑——嵌套群聊、动态选举发言人。

想在这两者之外更全面地了解基于角色的框架，参见 CrewAI 工作流指南。

常见问题

两者如何处理失控循环？

它们都不会自行停下。AutoGen 依赖 max_consecutive_auto_reply 切断无尽的来回；LangGraph 依赖共享状态里的迭代计数，在条件边中检查。把两者都当作必需，并在其上叠加成本和时间预算。

能混用吗？

能——任一方都可以被封装成对方内部的一个节点或工具。一种常见模式是用确定性的 LangGraph 外壳，在某个探索性子步骤里调用一段 AutoGen 群聊，从而让整体流程保持可控。

哪个「更好」？

都不是。LangGraph 是一条精密流水线，AutoGen 是一场开放研讨会。真正的问题是你能事先写明多少控制流——而且无论选哪个，你是否已经准备好沙箱、循环上限和每个 Agent 的权限边界。

总结

LangGraph 和 AutoGen 位于同一光谱的两端：显式控制 vs 涌现对话。选那个赌注与你任务匹配的框架；当两种多智能体权衡都不适用时，用单个 AI Agent 或一条确定性流水线；并记住框架是最容易的部分——沙箱化执行、硬循环上限、最小权限，才是让系统安全的东西，没有框架会免费送给你。

一手资料