最近在好几个开发者社群里我都被同一个问题反复提问LangGraph、AutoGen、CrewAI到底该选哪个每次看到这种问法我都会先反问一句你手里的Agent任务到底是流程控制重要还是角色协商重要原因很简单这三个框架虽然都顶着“Agent编排”的名头但它们的底层思想几乎不是一类东西。这篇文章是我自己做的一次完整对比实践记录同一个“素材分类简报”任务分别用LangGraph、AutoGen、CrewAI各实现一遍再放到工程落地的维度去审视框架本身。如果你正在纠结框架选型或者刚入门Agent开发想搞清楚不同框架的适用边界这篇应该能帮你省下不少走弯路的时间。1. 三个框架的出发点决定它们根本没法“差不多”1.1 LangGraph把Agent执行变成一张可暂停、可恢复的图LangGraph的核心不是“给你一个Agent”而是“给你一张图”。你要把自己的业务画成节点和边节点是任何一段业务操作比如调一次模型、查一次数据库、执行一个工具边是节点之间的跳转关系条件边允许你运行时根据状态判断下一步去哪里。所有这些节点共享一个状态字典这个状态就是整张图的“数据库”。为什么这么设计因为LLM应用一旦跑起来最大的风险就是不确定性模型会根据前文输出改变后续路径你没法用普通的Python顺序代码来控制。图模型把每个决策点显式暴露出来让你在编译图的时候就能检查从入口到出口的所有路径合理吗某个中间节点失败后应该回退到哪里这种可编译、可校验的能力是纯顺序脚本给不了的。但它的代价也很明显所有可能的分支你得提前想清楚。如果需求本身是探索性的根本没有固定流程硬画一张图会非常痛苦。所以LangGraph不是一个“能让Agent更聪明”的框架而是一个“能把Agent流程钉在工程框架里”的框架。1.2 AutoGen把Agent协作变成一场多角色对话AutoGen的底层想象完全不同。它把Agent的任务推进看作一场对话每个Agent有自己的名字、系统提示词、模型配置大家在一个共享的聊天历史里发言。任务进行到哪一步不靠你定义图而靠对话的轮转——一个Agent说完之后另一个Agent根据上下文决定接下来做什么。为了在这种松散结构里保持秩序AutoGen加了一个GroupChatManager角色类似对话里的主持人负责决定每轮让谁发言。这种模型的优点是灵活。对于流程不清晰的场景比如“让算法专家Agent和产品经理Agent讨论一个系统设计最终让某个Agent汇总方案”AutoGen不需要你提前定义步骤模型会自动在不同角色之间推进。缺点也来自同一设计控制流是隐式的。如果你需要“先分类、再判断、再决定是否继续执行某一步”这种精确控制对话可能会绕来绕去模型也可能遗忘之前的结论。所以使用AutoGen通常要花不少精力处理终止条件和上下文长度。它不是不能做流程控制而是流程控制藏在对话语义里没有图结构那么直观。1.3 CrewAI把Agent组织成一个按职责分工的虚拟团队CrewAI是三者中最贴近“岗位职责”的表达。它让你把Agent当成一个个有明确职务的成员每个Agent通过role定义岗位通过goal定义这个岗位要达成的目标通过backstory给模型一些背景设定。然后用Task描述一件具体工作指定交给哪个Agent做定义期望的输出格式。最后Crew把这些Agent和Task组合起来按照顺序流程或层级流程执行。用CrewAI写代码的体验很像在写一份“团队分工表”。在业务上如果能天然拆成岗位和交接流程比如“数据采集员、摘要编辑、审核员”这种流水线CrewAI的表达几乎和业务文档一一对应翻译成本极低。但它有天花板任务之间的跳转基本是线性的一个Task接一个Task想要做复杂的条件循环、并行汇聚、中途人工审批就需要借助外部逻辑或者改变流程模式否则会在CrewAI的语义里绕得很别扭。1.4 出发点差异总结维度LangGraphAutoGenCrewAI组织模型有向状态图多角色对话虚拟团队与任务分工核心调度机制边、条件边、状态更新GroupChatManager选择发言者顺序流程或层级流程流程控制力可编程、可细粒度控制靠对话自然推动控制弱任务顺序定义较线性状态形态显式State结构对话消息列表任务输入输出字典典型优势可恢复、可观测、适合生产化灵活、探索性强语义清晰、上手快从表格能看出LangGraph关心的第一个问题是“流程如何被精确控制”AutoGen关心的是“多个角色如何自然协作”CrewAI关心的是“工作如何按岗位拆解并流转”。这三个问题的答案不是同一个东西所以选型的关键不是盲目比较功能而是先看清手里的需求更像哪种形态。下一节我直接用同一个任务在三套框架里各写一版实现让你体会这种差异落到代码上是什么感受。2. 同一个“简报Agent”任务三套框架的实际实现与代码形态2.1 任务设定从一堆原始素材里生成结构化简报为了不空对空我设计了一个很小的、但包含“分类、分支、汇总”三个必要元素的Demo。输入是一段包含多条信息的原始文本——几条新闻、几条个人笔记、几条待办事项混在一起。要求输出一份结构化简报每条内容先打上标签news/note/task然后把相同标签的内容聚合到同一小节里。输入素材示例1. 明天下午三点项目周会。 2. 某团队发布了新的图像识别模型在公开测试集上刷新了纪录。 3. 记得回复客户关于合同的邮件。 4. 最近读的一篇论文提到小模型配合大量语法数据也能达到不错效果。 5. 周五前要提交季度总结。期望输出news - 某团队发布新的图像识别模型 note - 一篇关于小模型与语法数据结合的论文笔记 task - 项目周会明天下午三点 - 回复客户邮件 - 提交季度总结这个任务体量不大但涉及模型判断、标签分类、跨节点汇总足够看出一个框架的流程表达能力和上下文处理方式。2.2 LangGraph版本状态机驱动的控制流from typing import TypedDict, List from langgraph.graph import StateGraph, END class BriefingState(TypedDict): materials: List[str] labels: List[str] briefing: str def classify(state: BriefingState): # 模型逐条打标签省略具体提示词 labels [] for m in state[materials]: labels.append(classify_one(m)) # 返回 news/note/task return {labels: labels} def assemble(state: BriefingState): brief generate_briefing( materialsstate[materials], labelsstate[labels], ) return {briefing: brief} def route(state: BriefingState): # 条件边如果分类结果为空回到分类节点重试 if not state[labels]: return classify return assemble graph StateGraph(BriefingState) graph.add_node(classify, classify) graph.add_node(assemble, assemble) graph.set_entry_point(classify) graph.add_conditional_edges( classify, route, {classify: classify, assemble: assemble}, ) graph.add_edge(assemble, END) app graph.compile() result app.invoke({materials: raw_materials})这里有四个关键设计点节点函数返回的是部分状态不是全部状态。LangGraph会把返回的字典合并到全局State里节点之间靠这个State通信而不是靠函数返回值传递。这正是它能做到“任何节点失败后从断点恢复”的基础。条件边是流程控制的核心。route函数返回一个字符串框架根据映射表决定下一步进哪个节点。你往回走、往前走、走到END都是在这里控制的。这也是我想强调的LangGraph里没有“模型自己决定流程”这回事流程的每个分叉都要你显式定义。Reducer决定了同名字段的合并策略。默认情况下节点返回同名字段是覆盖如果需要追加消息、累加计数得声明聚合逻辑。很多人第一次用LangGraph时数据莫名丢失多半是Reducer没设置。编译后可以挂checkpointer。实际生产里可以给compile()传入一个持久化存储这样每次节点执行后都会保存完整的State快照。任务中断后你不仅能恢复到最近一次成功状态还能回放每一步这在长任务和人工审批场景里非常有用。2.3 AutoGen版本对话管理驱动的协作流import autogen config_list [{model: 你配置的模型, api_key: ...}] classifier autogen.AssistantAgent( nameclassifier, system_message( 你负责为每条输入素材打标签。 只输出 news/note/task 三种标签不要写解释。 ), llm_config{config_list: config_list}, ) writer autogen.AssistantAgent( namewriter, system_message你根据标签汇总生成结构化简报。, llm_config{config_list: config_list}, ) user_proxy autogen.UserProxyAgent( nameuser_proxy, human_input_modeNEVER, code_execution_configFalse, max_consecutive_auto_reply5, ) group_chat autogen.GroupChat( agents[user_proxy, classifier, writer], messages[], max_round12, ) manager autogen.GroupChatManager(groupchatgroup_chat) user_proxy.initiate_chat( manager, message对以下素材分类并生成简报\n raw_text, )AutoGen实现这个任务核心是从“定义流程”变成“定义参与者和规则”。我只需要告诉分类Agent怎么输出、写作Agent怎么汇总再交给GroupChatManager去协调发言顺序。任务能不能完成依赖的是模型在对话中是否理解了分工而不是依赖某个图结构里的边。这里值得注意的地方max_round不能设得太小。如果两个Agent在澄清格式或来回确认几轮就用完了结果还没产出。但设得太大又可能空转烧token。我在实际项目里通常会配一个Termination条件比如检测到“简报已生成”的标记就提前结束而不是单纯依赖轮数上限。工具函数接入很顺滑。如果分类需要调外部API注册function_map后模型会在对话中主动决定何时调用。但这种“模型主动决定”也是一种控制权让渡遇到复杂链路时要小心。对话记录本身就是状态。恢复任务通常指把历史messages重新灌进一个新的GroupChat。它非常简单但没有图模型那种细粒度的断点回放能力。2.4 CrewAI版本角色与任务驱动的执行流from crewai import Agent, Task, Crew, Process classifier Agent( role信息分类员, goal把每条素材准确标记为 news/note/task, backstory你擅长信息整理维护了一套稳定的分类规则。, llm你配置的模型, ) writer Agent( role简报撰写员, goal根据分类结果输出一份标题清晰、分组的简报, backstory你是资深内容编辑擅长把零散信息结构化成文档。, llm你配置的模型, ) classify_task Task( description分析输入的每条素材输出三行分类结果。, expected_output每行一条格式为 标签: 原始内容, agentclassifier, ) write_task Task( description读取上一步分类结果生成最终简报。, expected_output带层级标题的结构化简报文本, agentwriter, ) crew Crew( agents[classifier, writer], tasks[classify_task, write_task], processProcess.sequential, ) result crew.kickoff(inputs{raw_materials: raw_text})CrewAI写出来的代码一眼就能看出“谁在干活、按什么顺序干”。第二个任务会自动拿到第一个任务的输出作为上下文expected_output字段也会作为模型输出格式约束和校验依据。这里的关键体验“提示词即编排”是它的核心机制。Agent的role、goal、backstory本质上都是在用提示词约束模型行为任务顺序则直接对应列表里Task的先后顺序。因此它不是在图层面控制流程而是在语义层面控制流程。想加条件分支会比较绕。如果我想表达“分类失败就重试一次”在顺序流程里没有这种环的概念。一般做法是拆成多个子任务或者在Task内部让模型自己决定是否修正但也意味着把控制权交给了模型。并行能力在版本更新后逐步增强。可以给某个Task设置async_executionTrue让多个任务并行跑但粒度是任务级不是节点级。2.5 同样跑通背后机制的四点差异对比点LangGraphAutoGenCrewAI流程在哪定义代码里的图和条件边系统提示词和对话轮转Task顺序与Agent绑定状态放在哪节点间共享的State字典对话消息历史前序任务的输出加一个“循环直到条件满足”条件边指向自己或上游很简单加终止条件或重试机制较绕需要拆任务或写外部控制工具函数接入节点内任意Python调用function_map便捷注册Tool类注册从代码形态上已经能明显感受到三者的气质差异。但这种差异只有放到工程落地视角下才会真正影响你的交付质量和维护成本。3. 工程落地视角状态持久化、并行能力、调试成本上的分化3.1 状态管理与断点续跑生产环境里Agent任务经常跑几十秒甚至几分钟中途可能遇到模型限流、API超时、数据格式异常。这时候“从失败点恢复”就非常重要而不是把整个任务重跑一遍烧掉大量token。LangGraph在这一点上做得最重也最完整。它每一步执行后都会通过checkpointer保存状态快照你可以随时暂停、恢复、重放甚至从某个历史节点分叉出一条新路径。这对后台长任务、需要人工审批的任务是刚需能力。AutoGen没有统一的状态容器整场对话本身就是上下文。恢复任务通常就是把历史消息重新加载到新的对话里能用但比较原始无法精确到某个中间步骤。CrewAI的任务级上下文更简单一个Task失败后一般就是整个Crew重跑或者靠外部数据库保存任务输出来兜底。所以如果你的核心诉求是“长任务一定要稳”LangGraph的架构优势是无法绕开的。3.2 并行执行能力AI应用里的并行很常见一段长文本拆成多个段落并行做摘要一份列表中的多个用户请求并行处理又或者是一个主流程里同时调用多个不同的工具。LangGraph天然支持节点的扇出和扇入。一个节点执行完多个下一节点可以并行执行同一个State可以被多个分支同时读取最后在一个汇聚节点合并结果。这种能力写起来非常自然。CrewAI的新版本支持任务级异步执行可以同时运行多个Task但本质上还是任务层面做不到图节点级别的灵活汇聚。AutoGen的多Agent并行则取决于你开几个独立的对话组单组对话内部的并行能力很弱因为它本质是一条串行的发言线。如果你的业务里存在大量“把一个输入切给多个处理单元再合并结果”的模式可以优先考虑LangGraph。3.3 调试与可观测性调试Agent比调试普通代码难因为中间状态都是模型生成的文本不好断言对错。这时候框架能不能让你“看见中间发生了什么”就特别关键。LangGraph的编译对象可以直接检查图结构每个节点执行完的状态也能随时读取。配合checkpointer你甚至可以定位到某一次错误的具体输入输出拿到当时的全场快照。AutoGen的调试基本靠对话记录好处是整个过程复古且可读坏处是消息一多就难定位。CrewAI会返回每个Task的完整输出因此能定位到是哪个Task失败了但内部提示词冲突或角色漏传的排查远不如状态机直观。我的习惯是先看框架能不能给出“哪一步、用的什么输入、产生了什么输出、为什么会跳到这里”如果只能给一句“最终结果不对”调试地狱就不远了。3.4 部署与生态三个框架的部署门槛都不高本质上都是Python库加模型调用真正的成本在模型本身和调用链路的稳定性。LangGraph因为偏工程化周边配套成熟适合被嵌入已有的后台任务、API服务、工作流引擎。AutoGen胜在轻一个脚本就能跑通适合快速验证和半自动化的交互式场景。CrewAI的团队语义清晰在做面向业务方展示的Agent系统时表达成本最低。至于平台化的托管能力、可视化运维、监控对接这些属于生态服务会随版本快速变化选型时只要确认框架本身没有锁死这些能力就行不用太纠结当前版本的具体模块名。4. 选型决策项目、团队和经验三方面综合考虑4.1 按场景特征快速定位我根据多次实际项目的踩坑经验把选型判断浓缩成下面这张表决策问题推荐方向业务流程事先能画清楚分支明确LangGraph需要多角色多轮协商流程本来就模糊AutoGen步骤能拆成清晰岗位类似流水线交接CrewAI需要中途人工审批、暂停、恢复长任务LangGraph 明显领先团队刚接触Agent编程想两天内出可演示DemoAutoGen 或 CrewAI任务较长、token消耗敏感LangGraph 显式流程更可控这不是说AutoGen不能做精细流程也不是说CrewAI不能做复杂分支而是说每个框架都有自己“顺手”的区间。硬用AutoGen去精确编排一个审批流你会花大量精力在写终止条件和提示词约束上硬用CrewAI去做动态图跳转你会绕回外部状态。选框架的第一原则是让框架的默认路径贴近你的需求主线。4.2 混合编排LangGraph当骨架AutoGen/CrewAI当节点框架之间不是互斥关系。我现在的项目里最常用的套路是以LangGraph为外层骨架把AutoGen的多角色对话封装成一个节点或者把CrewAI的某个Task作为子流程调用。这样一来外层拥有可控制、可恢复的流程能力内层保留对话协商或角色分工的灵活性。反过来也成立如果你正在用CrewAI管理业务团队分工但某个任务内部需要精细的状态推进可以让这个任务内部再嵌套一个LangGraph子流程。这种混合编排在真实工程里出现的频率远比“只用单一框架”高得多。不要被框架名限制住它们都是可以互相嵌套的工具。4.3 团队与运维的现实考量选型不能只看技术还得看谁维护、谁扩展、谁来Debug。如果团队偏向后端工程熟悉状态机、工作流、消息队列LangGraph的图思维几乎零成本但需要补提示词的坑。如果团队偏向数据分析或算法验证AutoGen的对话式开发更友好但后续接生产可能要求重写一部分控制逻辑。如果团队和业务方沟通密集CrewAI的岗位式写法让双方对齐需求特别快适合快速迭代原型。运维侧要考虑的还有监控和告警。三个框架本身都不带完整的生产运维能力但LangGraph的状态快照易于对接日志系统AutoGen的对话记录易于落库回放CrewAI的任务输出易于结构化存储。选型时顺手把“失败后怎么告警、怎么人工介入、怎么恢复”想清楚比纠结具体API更有价值。4.4 踩坑记录这几种情况容易翻车我把自己在三个框架里真实踩过的坑列一下这些在教程和示例代码里通常不会写LangGraph里没配Reducer导致数据被覆盖。默认同名字段返回是覆盖如果多个节点往同一个字段写不同内容不声明合并策略最后留下的可能是最后一次写入值前面算出来的全部白费。解决方案是状态字段使用带Reducer的注解比如对话消息就用add_messages。AutoGen的max_round卡在业务未完成时。设小了对话被截断结果格式不完整设大了对话空转烧token。我后面改成用“完成标记Termination条件”来控制停止效果比单纯调轮数好得多。CrewAI的backstory写太长反而影响效果。一开始我以为角色背景越详细越精确结果模型频繁被无关背景带偏输出格式不稳定。压缩到两三句话之后效果提升明显token也省了。模型超时重试策略没设好整个编排卡死。这是三个框架共有的坑。上游模型一旦抖动调用层的默认超时和重试可能不可靠一定要在模型客户端统一配置超时时间和重试次数再在编排层做兜底。4.5 我的做法先画流程草图再选框架最近我做Agent相关项目时已经养成了一个固定习惯不管最终用什么框架先拿一张纸把业务流程画出来。这个流程从头到尾有多少个环节哪里会出现分支哪个分支需要人来确认哪儿段需要并行把这些问题搞清楚之后再回头看框架选型答案往往自己就浮出来了。如果这个流程的分支超过三个或者存在明确的环回、审批、并行汇聚我会默认选LangGraph。如果流程本身就是要几个角色互相博弈、讨论出结论我会直接考虑AutoGen。如果任务能被清晰地拆成“谁负责什么做完交给谁”CrewAI会让我最省心。框架本身只是工具真正决定项目成败的是你对自己业务的理解程度。先把流程画明白再让框架去适配这个流程而不是反过来让业务凑合框架的默认能力。这样无论你最后选了哪个至少不会因为“选错了”而半途重来。
最近在好几个开发者社群里我都被同一个问题反复提问LangGraph、AutoGen、CrewAI到底该选哪个每次看到这种问法我都会先反问一句你手里的Agent任务到底是流程控制重要还是角色协商重要原因很简单这三个框架虽然都顶着“Agent编排”的名头但它们的底层思想几乎不是一类东西。这篇文章是我自己做的一次完整对比实践记录同一个“素材分类简报”任务分别用LangGraph、AutoGen、CrewAI各实现一遍再放到工程落地的维度去审视框架本身。如果你正在纠结框架选型或者刚入门Agent开发想搞清楚不同框架的适用边界这篇应该能帮你省下不少走弯路的时间。1. 三个框架的出发点决定它们根本没法“差不多”1.1 LangGraph把Agent执行变成一张可暂停、可恢复的图LangGraph的核心不是“给你一个Agent”而是“给你一张图”。你要把自己的业务画成节点和边节点是任何一段业务操作比如调一次模型、查一次数据库、执行一个工具边是节点之间的跳转关系条件边允许你运行时根据状态判断下一步去哪里。所有这些节点共享一个状态字典这个状态就是整张图的“数据库”。为什么这么设计因为LLM应用一旦跑起来最大的风险就是不确定性模型会根据前文输出改变后续路径你没法用普通的Python顺序代码来控制。图模型把每个决策点显式暴露出来让你在编译图的时候就能检查从入口到出口的所有路径合理吗某个中间节点失败后应该回退到哪里这种可编译、可校验的能力是纯顺序脚本给不了的。但它的代价也很明显所有可能的分支你得提前想清楚。如果需求本身是探索性的根本没有固定流程硬画一张图会非常痛苦。所以LangGraph不是一个“能让Agent更聪明”的框架而是一个“能把Agent流程钉在工程框架里”的框架。1.2 AutoGen把Agent协作变成一场多角色对话AutoGen的底层想象完全不同。它把Agent的任务推进看作一场对话每个Agent有自己的名字、系统提示词、模型配置大家在一个共享的聊天历史里发言。任务进行到哪一步不靠你定义图而靠对话的轮转——一个Agent说完之后另一个Agent根据上下文决定接下来做什么。为了在这种松散结构里保持秩序AutoGen加了一个GroupChatManager角色类似对话里的主持人负责决定每轮让谁发言。这种模型的优点是灵活。对于流程不清晰的场景比如“让算法专家Agent和产品经理Agent讨论一个系统设计最终让某个Agent汇总方案”AutoGen不需要你提前定义步骤模型会自动在不同角色之间推进。缺点也来自同一设计控制流是隐式的。如果你需要“先分类、再判断、再决定是否继续执行某一步”这种精确控制对话可能会绕来绕去模型也可能遗忘之前的结论。所以使用AutoGen通常要花不少精力处理终止条件和上下文长度。它不是不能做流程控制而是流程控制藏在对话语义里没有图结构那么直观。1.3 CrewAI把Agent组织成一个按职责分工的虚拟团队CrewAI是三者中最贴近“岗位职责”的表达。它让你把Agent当成一个个有明确职务的成员每个Agent通过role定义岗位通过goal定义这个岗位要达成的目标通过backstory给模型一些背景设定。然后用Task描述一件具体工作指定交给哪个Agent做定义期望的输出格式。最后Crew把这些Agent和Task组合起来按照顺序流程或层级流程执行。用CrewAI写代码的体验很像在写一份“团队分工表”。在业务上如果能天然拆成岗位和交接流程比如“数据采集员、摘要编辑、审核员”这种流水线CrewAI的表达几乎和业务文档一一对应翻译成本极低。但它有天花板任务之间的跳转基本是线性的一个Task接一个Task想要做复杂的条件循环、并行汇聚、中途人工审批就需要借助外部逻辑或者改变流程模式否则会在CrewAI的语义里绕得很别扭。1.4 出发点差异总结维度LangGraphAutoGenCrewAI组织模型有向状态图多角色对话虚拟团队与任务分工核心调度机制边、条件边、状态更新GroupChatManager选择发言者顺序流程或层级流程流程控制力可编程、可细粒度控制靠对话自然推动控制弱任务顺序定义较线性状态形态显式State结构对话消息列表任务输入输出字典典型优势可恢复、可观测、适合生产化灵活、探索性强语义清晰、上手快从表格能看出LangGraph关心的第一个问题是“流程如何被精确控制”AutoGen关心的是“多个角色如何自然协作”CrewAI关心的是“工作如何按岗位拆解并流转”。这三个问题的答案不是同一个东西所以选型的关键不是盲目比较功能而是先看清手里的需求更像哪种形态。下一节我直接用同一个任务在三套框架里各写一版实现让你体会这种差异落到代码上是什么感受。2. 同一个“简报Agent”任务三套框架的实际实现与代码形态2.1 任务设定从一堆原始素材里生成结构化简报为了不空对空我设计了一个很小的、但包含“分类、分支、汇总”三个必要元素的Demo。输入是一段包含多条信息的原始文本——几条新闻、几条个人笔记、几条待办事项混在一起。要求输出一份结构化简报每条内容先打上标签news/note/task然后把相同标签的内容聚合到同一小节里。输入素材示例1. 明天下午三点项目周会。 2. 某团队发布了新的图像识别模型在公开测试集上刷新了纪录。 3. 记得回复客户关于合同的邮件。 4. 最近读的一篇论文提到小模型配合大量语法数据也能达到不错效果。 5. 周五前要提交季度总结。期望输出news - 某团队发布新的图像识别模型 note - 一篇关于小模型与语法数据结合的论文笔记 task - 项目周会明天下午三点 - 回复客户邮件 - 提交季度总结这个任务体量不大但涉及模型判断、标签分类、跨节点汇总足够看出一个框架的流程表达能力和上下文处理方式。2.2 LangGraph版本状态机驱动的控制流from typing import TypedDict, List from langgraph.graph import StateGraph, END class BriefingState(TypedDict): materials: List[str] labels: List[str] briefing: str def classify(state: BriefingState): # 模型逐条打标签省略具体提示词 labels [] for m in state[materials]: labels.append(classify_one(m)) # 返回 news/note/task return {labels: labels} def assemble(state: BriefingState): brief generate_briefing( materialsstate[materials], labelsstate[labels], ) return {briefing: brief} def route(state: BriefingState): # 条件边如果分类结果为空回到分类节点重试 if not state[labels]: return classify return assemble graph StateGraph(BriefingState) graph.add_node(classify, classify) graph.add_node(assemble, assemble) graph.set_entry_point(classify) graph.add_conditional_edges( classify, route, {classify: classify, assemble: assemble}, ) graph.add_edge(assemble, END) app graph.compile() result app.invoke({materials: raw_materials})这里有四个关键设计点节点函数返回的是部分状态不是全部状态。LangGraph会把返回的字典合并到全局State里节点之间靠这个State通信而不是靠函数返回值传递。这正是它能做到“任何节点失败后从断点恢复”的基础。条件边是流程控制的核心。route函数返回一个字符串框架根据映射表决定下一步进哪个节点。你往回走、往前走、走到END都是在这里控制的。这也是我想强调的LangGraph里没有“模型自己决定流程”这回事流程的每个分叉都要你显式定义。Reducer决定了同名字段的合并策略。默认情况下节点返回同名字段是覆盖如果需要追加消息、累加计数得声明聚合逻辑。很多人第一次用LangGraph时数据莫名丢失多半是Reducer没设置。编译后可以挂checkpointer。实际生产里可以给compile()传入一个持久化存储这样每次节点执行后都会保存完整的State快照。任务中断后你不仅能恢复到最近一次成功状态还能回放每一步这在长任务和人工审批场景里非常有用。2.3 AutoGen版本对话管理驱动的协作流import autogen config_list [{model: 你配置的模型, api_key: ...}] classifier autogen.AssistantAgent( nameclassifier, system_message( 你负责为每条输入素材打标签。 只输出 news/note/task 三种标签不要写解释。 ), llm_config{config_list: config_list}, ) writer autogen.AssistantAgent( namewriter, system_message你根据标签汇总生成结构化简报。, llm_config{config_list: config_list}, ) user_proxy autogen.UserProxyAgent( nameuser_proxy, human_input_modeNEVER, code_execution_configFalse, max_consecutive_auto_reply5, ) group_chat autogen.GroupChat( agents[user_proxy, classifier, writer], messages[], max_round12, ) manager autogen.GroupChatManager(groupchatgroup_chat) user_proxy.initiate_chat( manager, message对以下素材分类并生成简报\n raw_text, )AutoGen实现这个任务核心是从“定义流程”变成“定义参与者和规则”。我只需要告诉分类Agent怎么输出、写作Agent怎么汇总再交给GroupChatManager去协调发言顺序。任务能不能完成依赖的是模型在对话中是否理解了分工而不是依赖某个图结构里的边。这里值得注意的地方max_round不能设得太小。如果两个Agent在澄清格式或来回确认几轮就用完了结果还没产出。但设得太大又可能空转烧token。我在实际项目里通常会配一个Termination条件比如检测到“简报已生成”的标记就提前结束而不是单纯依赖轮数上限。工具函数接入很顺滑。如果分类需要调外部API注册function_map后模型会在对话中主动决定何时调用。但这种“模型主动决定”也是一种控制权让渡遇到复杂链路时要小心。对话记录本身就是状态。恢复任务通常指把历史messages重新灌进一个新的GroupChat。它非常简单但没有图模型那种细粒度的断点回放能力。2.4 CrewAI版本角色与任务驱动的执行流from crewai import Agent, Task, Crew, Process classifier Agent( role信息分类员, goal把每条素材准确标记为 news/note/task, backstory你擅长信息整理维护了一套稳定的分类规则。, llm你配置的模型, ) writer Agent( role简报撰写员, goal根据分类结果输出一份标题清晰、分组的简报, backstory你是资深内容编辑擅长把零散信息结构化成文档。, llm你配置的模型, ) classify_task Task( description分析输入的每条素材输出三行分类结果。, expected_output每行一条格式为 标签: 原始内容, agentclassifier, ) write_task Task( description读取上一步分类结果生成最终简报。, expected_output带层级标题的结构化简报文本, agentwriter, ) crew Crew( agents[classifier, writer], tasks[classify_task, write_task], processProcess.sequential, ) result crew.kickoff(inputs{raw_materials: raw_text})CrewAI写出来的代码一眼就能看出“谁在干活、按什么顺序干”。第二个任务会自动拿到第一个任务的输出作为上下文expected_output字段也会作为模型输出格式约束和校验依据。这里的关键体验“提示词即编排”是它的核心机制。Agent的role、goal、backstory本质上都是在用提示词约束模型行为任务顺序则直接对应列表里Task的先后顺序。因此它不是在图层面控制流程而是在语义层面控制流程。想加条件分支会比较绕。如果我想表达“分类失败就重试一次”在顺序流程里没有这种环的概念。一般做法是拆成多个子任务或者在Task内部让模型自己决定是否修正但也意味着把控制权交给了模型。并行能力在版本更新后逐步增强。可以给某个Task设置async_executionTrue让多个任务并行跑但粒度是任务级不是节点级。2.5 同样跑通背后机制的四点差异对比点LangGraphAutoGenCrewAI流程在哪定义代码里的图和条件边系统提示词和对话轮转Task顺序与Agent绑定状态放在哪节点间共享的State字典对话消息历史前序任务的输出加一个“循环直到条件满足”条件边指向自己或上游很简单加终止条件或重试机制较绕需要拆任务或写外部控制工具函数接入节点内任意Python调用function_map便捷注册Tool类注册从代码形态上已经能明显感受到三者的气质差异。但这种差异只有放到工程落地视角下才会真正影响你的交付质量和维护成本。3. 工程落地视角状态持久化、并行能力、调试成本上的分化3.1 状态管理与断点续跑生产环境里Agent任务经常跑几十秒甚至几分钟中途可能遇到模型限流、API超时、数据格式异常。这时候“从失败点恢复”就非常重要而不是把整个任务重跑一遍烧掉大量token。LangGraph在这一点上做得最重也最完整。它每一步执行后都会通过checkpointer保存状态快照你可以随时暂停、恢复、重放甚至从某个历史节点分叉出一条新路径。这对后台长任务、需要人工审批的任务是刚需能力。AutoGen没有统一的状态容器整场对话本身就是上下文。恢复任务通常就是把历史消息重新加载到新的对话里能用但比较原始无法精确到某个中间步骤。CrewAI的任务级上下文更简单一个Task失败后一般就是整个Crew重跑或者靠外部数据库保存任务输出来兜底。所以如果你的核心诉求是“长任务一定要稳”LangGraph的架构优势是无法绕开的。3.2 并行执行能力AI应用里的并行很常见一段长文本拆成多个段落并行做摘要一份列表中的多个用户请求并行处理又或者是一个主流程里同时调用多个不同的工具。LangGraph天然支持节点的扇出和扇入。一个节点执行完多个下一节点可以并行执行同一个State可以被多个分支同时读取最后在一个汇聚节点合并结果。这种能力写起来非常自然。CrewAI的新版本支持任务级异步执行可以同时运行多个Task但本质上还是任务层面做不到图节点级别的灵活汇聚。AutoGen的多Agent并行则取决于你开几个独立的对话组单组对话内部的并行能力很弱因为它本质是一条串行的发言线。如果你的业务里存在大量“把一个输入切给多个处理单元再合并结果”的模式可以优先考虑LangGraph。3.3 调试与可观测性调试Agent比调试普通代码难因为中间状态都是模型生成的文本不好断言对错。这时候框架能不能让你“看见中间发生了什么”就特别关键。LangGraph的编译对象可以直接检查图结构每个节点执行完的状态也能随时读取。配合checkpointer你甚至可以定位到某一次错误的具体输入输出拿到当时的全场快照。AutoGen的调试基本靠对话记录好处是整个过程复古且可读坏处是消息一多就难定位。CrewAI会返回每个Task的完整输出因此能定位到是哪个Task失败了但内部提示词冲突或角色漏传的排查远不如状态机直观。我的习惯是先看框架能不能给出“哪一步、用的什么输入、产生了什么输出、为什么会跳到这里”如果只能给一句“最终结果不对”调试地狱就不远了。3.4 部署与生态三个框架的部署门槛都不高本质上都是Python库加模型调用真正的成本在模型本身和调用链路的稳定性。LangGraph因为偏工程化周边配套成熟适合被嵌入已有的后台任务、API服务、工作流引擎。AutoGen胜在轻一个脚本就能跑通适合快速验证和半自动化的交互式场景。CrewAI的团队语义清晰在做面向业务方展示的Agent系统时表达成本最低。至于平台化的托管能力、可视化运维、监控对接这些属于生态服务会随版本快速变化选型时只要确认框架本身没有锁死这些能力就行不用太纠结当前版本的具体模块名。4. 选型决策项目、团队和经验三方面综合考虑4.1 按场景特征快速定位我根据多次实际项目的踩坑经验把选型判断浓缩成下面这张表决策问题推荐方向业务流程事先能画清楚分支明确LangGraph需要多角色多轮协商流程本来就模糊AutoGen步骤能拆成清晰岗位类似流水线交接CrewAI需要中途人工审批、暂停、恢复长任务LangGraph 明显领先团队刚接触Agent编程想两天内出可演示DemoAutoGen 或 CrewAI任务较长、token消耗敏感LangGraph 显式流程更可控这不是说AutoGen不能做精细流程也不是说CrewAI不能做复杂分支而是说每个框架都有自己“顺手”的区间。硬用AutoGen去精确编排一个审批流你会花大量精力在写终止条件和提示词约束上硬用CrewAI去做动态图跳转你会绕回外部状态。选框架的第一原则是让框架的默认路径贴近你的需求主线。4.2 混合编排LangGraph当骨架AutoGen/CrewAI当节点框架之间不是互斥关系。我现在的项目里最常用的套路是以LangGraph为外层骨架把AutoGen的多角色对话封装成一个节点或者把CrewAI的某个Task作为子流程调用。这样一来外层拥有可控制、可恢复的流程能力内层保留对话协商或角色分工的灵活性。反过来也成立如果你正在用CrewAI管理业务团队分工但某个任务内部需要精细的状态推进可以让这个任务内部再嵌套一个LangGraph子流程。这种混合编排在真实工程里出现的频率远比“只用单一框架”高得多。不要被框架名限制住它们都是可以互相嵌套的工具。4.3 团队与运维的现实考量选型不能只看技术还得看谁维护、谁扩展、谁来Debug。如果团队偏向后端工程熟悉状态机、工作流、消息队列LangGraph的图思维几乎零成本但需要补提示词的坑。如果团队偏向数据分析或算法验证AutoGen的对话式开发更友好但后续接生产可能要求重写一部分控制逻辑。如果团队和业务方沟通密集CrewAI的岗位式写法让双方对齐需求特别快适合快速迭代原型。运维侧要考虑的还有监控和告警。三个框架本身都不带完整的生产运维能力但LangGraph的状态快照易于对接日志系统AutoGen的对话记录易于落库回放CrewAI的任务输出易于结构化存储。选型时顺手把“失败后怎么告警、怎么人工介入、怎么恢复”想清楚比纠结具体API更有价值。4.4 踩坑记录这几种情况容易翻车我把自己在三个框架里真实踩过的坑列一下这些在教程和示例代码里通常不会写LangGraph里没配Reducer导致数据被覆盖。默认同名字段返回是覆盖如果多个节点往同一个字段写不同内容不声明合并策略最后留下的可能是最后一次写入值前面算出来的全部白费。解决方案是状态字段使用带Reducer的注解比如对话消息就用add_messages。AutoGen的max_round卡在业务未完成时。设小了对话被截断结果格式不完整设大了对话空转烧token。我后面改成用“完成标记Termination条件”来控制停止效果比单纯调轮数好得多。CrewAI的backstory写太长反而影响效果。一开始我以为角色背景越详细越精确结果模型频繁被无关背景带偏输出格式不稳定。压缩到两三句话之后效果提升明显token也省了。模型超时重试策略没设好整个编排卡死。这是三个框架共有的坑。上游模型一旦抖动调用层的默认超时和重试可能不可靠一定要在模型客户端统一配置超时时间和重试次数再在编排层做兜底。4.5 我的做法先画流程草图再选框架最近我做Agent相关项目时已经养成了一个固定习惯不管最终用什么框架先拿一张纸把业务流程画出来。这个流程从头到尾有多少个环节哪里会出现分支哪个分支需要人来确认哪儿段需要并行把这些问题搞清楚之后再回头看框架选型答案往往自己就浮出来了。如果这个流程的分支超过三个或者存在明确的环回、审批、并行汇聚我会默认选LangGraph。如果流程本身就是要几个角色互相博弈、讨论出结论我会直接考虑AutoGen。如果任务能被清晰地拆成“谁负责什么做完交给谁”CrewAI会让我最省心。框架本身只是工具真正决定项目成败的是你对自己业务的理解程度。先把流程画明白再让框架去适配这个流程而不是反过来让业务凑合框架的默认能力。这样无论你最后选了哪个至少不会因为“选错了”而半途重来。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
