一、为什么需要多 Agent 框架一个 Agent 调几个工具能解决查天气算个税这种单步任务。但真实业务往往长这样用户帮我调研竞品 A写一份含技术对比和风险的报告 → 需要搜索 Agent 分析 Agent 写作 Agent 审核 Agent 协作问题不在能不能用一个 Agent 串完而在于可控性差Agent 跑偏了你拦不住状态难管理多步中间结果往哪放难调试黑盒循环出了问题不知道卡哪LangGraph 和 AutoGen 都为了解决这个问题但哲学完全不同。二、两种哲学LangGraph把流程变成图核心抽象是StateGraph节点是函数/LLM 调用边是转移条件整体是一个有状态的状态机。┌─────────┐ │ START │ └────┬────┘ ▼ ┌─────────┐ 条件 ┌─────────┐ │ 搜索Agent│────────▶│ 分析Agent│ └─────────┘ └────┬────┘ ▼ ┌─────────┐ 不满意 ┌─────────┐ │ 写作Agent│────────▶│ 审核Agent│ └────┬────┘ └─────────┘ │ 满意 ▼ ┌─────────┐ │ END │ └─────────┘特点流程显式、可控、可断点续跑适合流程比模型重要的场景。AutoGen把协作变成对话核心抽象是Agent GroupChat每个 Agent 有人设assistant/user/programmer它们像开会一样在群里发消息靠对话自然推进。UserProxy(你/代理) ──▶ 研究Agent: 我来搜 │ 编程Agent: 我跑代码验证 │ 汇报Agent: 我整理结论 │ ◀── UserProxy 决定继续还是停特点自然、省代码、探索性强适合让几个角色自由讨论出结果的场景。三、核心差异四维对比维度LangGraphAutoGen编程模型状态机/图显式流程多轮对话隐式涌现状态管理全局 State 对象类型安全消息列表靠对话上下文可控性高边可加条件/中断中靠终止条件/人类介入调试可可视化图、断点打印对话即可Human-in-loop原生interrupt_before原生 UserProxy 代理学习曲线稍陡要理解图/状态平缓像写对话适用生产 pipeline、可控流程探索式研究、快速原型一句话LangGraph 给你方向盘AutoGen 给你副驾聊天。四、实战同一个研究助手两种写法4.1 LangGraph 版from typing import TypedDict, Annotated from langgraph.graph import StateGraph, END import operator ​ class State(TypedDict): topic: str research: str report: str approved: bool ​ def search_node(s: State): s[research] f[搜索结果] 关于 {s[topic]} 的竞品资料... return s ​ def write_node(s: State): s[report] f[报告草稿] 基于研究{s[research]} return s ​ def review_node(s: State): # 简单规则报告含关键词才算通过 s[approved] 风险 in s[report] return s ​ def route(s: State): return write if not s[approved] else END ​ g StateGraph(State) g.add_node(search, search_node) g.add_node(write, write_node) g.add_node(review, review_node) g.add_edge(search, write) g.add_edge(write, review) g.add_conditional_edges(review, route, {write: write, END: END}) g.set_entry_point(search) app g.compile() ​ res app.invoke({topic: 竞品A, approved: False})流程完全由图决定每一步可单测、可中断。4.2 AutoGen 版from autogen import Agent, GroupChat, GroupChatManager, UserProxyAgent ​ user UserProxyAgent(user, code_execution_configFalse) researcher Agent(researcher, system_message你是竞品研究员负责搜索和整理资料) writer Agent(writer, system_message你是报告写手基于资料写含风险分析的报告) ​ chat GroupChat(agents[user, researcher, writer], messages[], max_round6) mgr GroupChatManager(chat, llm_config{model: gpt-4o}) ​ user.initiate_chat(mgr, message调研竞品A输出含风险分析的报告)几行代码就让三个角色开会。你user可以中途插话、叫停。五、选型决策树开始 │ ├─ 流程是否固定、要可审计/可回放 ──是──▶ LangGraph │ ├─ 是否需要频繁人工介入审核每一步 ──是──▶ LangGraph(interrupt) 或 AutoGen(UserProxy) │ ├─ 任务是探索式/开放式讨论 ──是──▶ AutoGen │ ├─ 团队已用 LangChain 生态 ──是──▶ LangGraph无缝衔接 │ └─ 想快速出原型、少写代码 ──是──▶ AutoGen经验法则生产环境、流程固化、要质量稳定 →LangGraph内部研究工具、快速验证想法 →AutoGen六、踩坑记录问题框架现象解决图无限循环LangGraph条件边写错死循环加max_iterations上限状态不更新LangGraph节点改了 State 但下游没看到函数必须 return 新 State对话跑飞AutoGenAgent 互相附和不出活收紧 system_message 降 max_round成本失控AutoGen群聊轮次多 token 爆炸设 max_round 用便宜模型做小角色难调试卡哪AutoGen不知道停在哪步开human_input_modeALWAYS逐步看类型不安全两者State 字段拼错LangGraph 用 TypedDict 强约束七、总结LangGraph 状态机驱动流程显式可控适合生产 pipelineAutoGen 对话驱动自然探索适合快速原型和研究两者不互斥很多团队用 LangGraph 做主流程编排内部某个节点调 AutoGen 做探索选型看流程重要还是探索重要别盲目跟风下一篇聊完 AI 应用编排回到大数据——消息队列是数据管道的血管周四我们 Pulsar vs Kafka 见高下。往期回顾Iceberg vs Hudi vs Delta Lake数据湖三引擎深度压测与选型RAG 架构设计 7 个关键决策从 Chunk 策略到 Reranker 的生产级方案用 RAGAS 科学量化你的检索增强系统