★ FEATURED ARTICLE 先交代一个真实背景我过去一年里用 LangGraph 做过复杂的客服工作流拿 AutoGen 跑过多代理辩论式的分析用 CrewAI 搭过内容生产流水线也把 Microsoft Agent Framework 的预览版拉起来玩过一阵子。所以这篇文章不是抄文档而是把这些框架放在同一个业务场景里反复折腾之后的对比记录。如果你最近在选型或者被“Agent 框架哪个好”这个问题卡住了希望这篇能帮你节省至少两周的试错时间。这个标题里的四个名字代表着四种完全不同的 Agent 组织方式LangGraph 的核心是“图”AutoGen 的核心是“对话”CrewAI 的核心是“角色”而 Microsoft Agent Framework 的核心是“企业级编排”。它们在文档里都宣称自己能构建多代理系统但实际用起来写代码的思路、调试的方式、上线后遇到的坑完全是不同的路数。下面我从架构原理、代码写法、生产落地三个角度逐一掰开讲。1. 四个框架的设计哲学与适用定位1.1 LangGraph把 Agent 当作一张有状态的状态机图LangGraph 是 LangChain 生态里专门做 Agent 编排的框架它的底层思想非常朴素把你想要 Agent 执行的每一个步骤建模成图里的节点node节点之间有向边edge连接整个执行过程就是沿着图从起点走到终点。听起来像是回到了大学数据结构课但正是这种“把事情显式化”的设计让 LangGraph 成为四个框架里可控性最强的那个。比如一个典型的 ReAct Agent在 LangGraph 里会被拆成“调用模型节点”“调用工具节点”“条件路由节点”三个部分。模型节点负责决定下一步是直接回答还是需要调用工具如果要调用工具就跳转到工具节点执行执行完之后再回到模型节点做下一轮推理。这个循环用代码写出来就是add_node和add_edge的组合你随时能画出一张清晰的执行流程图这在复杂业务里是巨大的优势——汇报架构、排查故障、做性能分析都有据可查。另一个关键设计是 State状态。LangGraph 要求你显式定义一个状态对象所有节点读写这个状态对象来共享信息。这个状态可以被持久化到数据库里意味着你的 Agent 进程崩了、重启了还能从上次中断的地方接着跑。我做的客服工单系统里用户可能上传一张图片、经过多次人工复核才走完流程这种长流程如果没有状态持久化几乎没法交付。LangGraph 的 checkpointer 机制解决的正是这个问题这也是它和很多纯函数式框架拉开差距的地方。不过成也可控败也可控。图的每个节点、每条边都要自己写导致代码量是四个框架里最大的。如果你只是做一个小 demo或者想让几个模型自由对话跑个脑暴用 LangGraph 就是杀鸡用牛刀写节点和边的时间比调 prompt 的时间还长。1.2 AutoGen多个 Agent 围在一张桌子上聊天AutoGen 是微软开源的多代理对话框架核心概念是 ConversableAgent。它把所有 Agent 之间的协作建模为“对话”一个 Agent 发消息另一个 Agent 接收并回复消息在多个 Agent 之间循环传递直到某个终止条件满足。这种设计像极了办公室里几个专家开会讨论问题特别适合需要多角度分析、辩论、质疑的场景。我用 AutoGen 做过一个“技术方案评审 Agent”一个架构师 Agent、一个安全 Agent、一个成本控制 Agent三个角色围绕同一个需求反复讨论最后产出综合意见。这种用法很自然因为 AutoGen 设计上就是让每个 Agent 扮演不同的 system prompt在对话上下文中不断交换意见。它还内置了 GroupChat 和 GroupChatManager可以管理三个以上 Agent 的发言顺序甚至能设定“主持人”来控制话题方向。但对话模式有天然隐患上下文长度会飞快增长。每个 Agent 的回复都会追加到共享的对话历史里几轮讨论下来可能就上万 token 了。另一个问题是“跑偏”三个 Agent 聊着聊着话题可能从“方案评估”滑到“某行代码的写法”不回拉的话整场讨论就废了。我在实际项目中必须给 GroupChat 设置明确的 speaker selection 规则和 max_round相当于给讨论加了主持人和时间限制。AutoGen 还提供了 stateflow 和 graph 模式来约束流程但这就等于说它也在往 LangGraph 的方向靠拢。还有一个值得注意的变化AutoGen 现在已经整体并入了 Microsoft Agent Framework 的生态作为其中的底层多代理运行时。如果你今天才第一次接触 AutoGen我建议直接以 Microsoft Agent Framework 为新起点但 AutoGen 的对话式思想仍然值得学习因为你会在很多 Agent 系统里看到“对话/反驳”的影子。1.3 CrewAI像组建一支项目团队一样组建 AgentCrewAI 是我个人觉得最“好懂”的框架它对标的是真实团队协作每个 Agent 有明确的 role、goal、backstory你就是这个团队的负责人。你定义好需要哪些角色比如“市场分析师”“文案写手”“编辑”把任务拆解后分配给对应角色然后通过 Crew 来编排它们按顺序或按层级执行。这种设计让业务同学很容易理解整个系统在干什么。我做个内容生成流水线时只要把“收集素材→写初稿→优化SEO→最终校对”的任务链条写好非技术人员看代码也能猜出每个 Agent 在负责什么。CrewAI 的 Process 支持 sequential顺序执行和 hierarchical层级管理由一个 manager Agent 管理其他 Agent后者在任务边界不清晰时特别好用相当于你招了一个项目经理来派活。CrewAI 的短板在于灵活度。它的“角色化”抽象虽然好用但也把执行流程给固化了你很难像 LangGraph 那样细粒度控制每一步的条件跳转遇到需要异常恢复、人工确认、并行子任务的复杂场景CrewAI 的表达能力就不够。另一个实际问题是它高度依赖底层 LLM 的“自觉性”——Agent 是否真的会按你设定的角色约束去执行完全取决于模型能力。我在测试中经常发现模型在简单任务上能严格扮演角色但一旦任务复杂角色的边界就模糊了。1.4 Microsoft Agent Framework面向企业的一体化解决方案Microsoft Agent Framework简称 MS Agent Framework是 2025 年由微软推出的开源企业级 Agent 开发框架融合了 AutoGen 和 Semantic Kernel 的沉淀。它提供了一套统一的工作流抽象包括 Agent、Workflow、Policy 等核心概念并且围绕企业落地做了大量工程化设计内置可观测性、运行时长驻、集群部署、与 Azure AI Foundry 的整合甚至在宣传里把“多代理协议 A2A 支持”放进了路线图。我用下来感觉它像是一把“瑞士军刀”。它既支持像 LangGraph 那样的显式工作流编排也支持像 AutoGen 那样的对话式多代理还提供了统一的 Agent 运行环境来管理生命周期、追踪 token 消耗、保存运行状态。对于既要快速验证、又要稳定上线的团队来说这种一体化体验是很舒服的。它的 API 风格和 OpenAI Agents SDK 有相似之处定义 Agent给它 instructions 和 tools然后直接 run。上手门槛明显比 LangGraph 低。但一个很现实的考量是这套框架太新社区生态和第三方集成还在快速变化中。你随便搜一个问题LangGraph 可能已经有几十篇踩坑帖子微软这套框架的参考资料就少得多。另外企业级架构往往意味着更多的概念和抽象层小项目引入它可能会觉得“过度设计”。我的建议是如果你想评估 Microsoft Agent Framework先把微软官方的 Agent 开发概述读一遍再对比你团队实际需要用到多少企业级特性不要一上来就套全套。2. 同一个业务场景四个框架分别怎么写2.1 场景定义与准备为了不空谈概念我挑一个比较有代表性的业务场景来对比商品评论的智能客服处理。输入一段用户评论系统需要完成三个子任务先提炼评论中的关键信息然后判断用户情感倾向最后生成一段给用户的回复建议。这个场景不大不小既涉及单 Agent 的工具调用也涉及多 Agent 的分工协作适合展示四个框架的写法差异。开始之前先统一环境下面所有代码用 Python 写LLM 统一假设为 OpenAI 兼容接口模型使用gpt-4o-mini。实际开发时你完全可以用其他模型厂商的接口四个框架都支持自定义模型客户端只是细节配置略有不同。2.2 LangGraph 实现显式画出执行流程在 LangGraph 里我先定义一个 AgentState 来承载整个流程的数据from typing import TypedDict, Annotated from langgraph.graph import StateGraph, START, END from langchain_openai import ChatOpenAI class AgentState(TypedDict): comment: str # 原始评论 key_points: str # 提炼后的关键信息 sentiment: str # 情感判断结果 reply: str # 生成的回复建议 def extract_points(state: AgentState): llm ChatOpenAI(modelgpt-4o-mini, temperature0.2) prompt f你是客服运营人员请从用户评论中提炼3-5个关键信息点。\n评论{state[comment]} result llm.invoke(prompt) return {key_points: result.content} def analyze_sentiment(state: AgentState): llm ChatOpenAI(modelgpt-4o-mini, temperature0) prompt f请判断用户评论的情感倾向肯定、否定还是中性。只要输出一个词。\n评论{state[comment]} result llm.invoke(prompt) return {sentiment: result.content.strip()} def generate_reply(state: AgentState): llm ChatOpenAI(modelgpt-4o-mini, temperature0.7) prompt ( f根据以下信息生成一条给用户的回复建议。\n f关键信息点{state[key_points]}\n f情感倾向{state[sentiment]}\n f原始评论{state[comment]} ) result llm.invoke(prompt) return {reply: result.content} builder StateGraph(AgentState) builder.add_node(extract, extract_points) builder.add_node(sentiment, analyze_sentiment) builder.add_node(reply, generate_reply) builder.add_edge(START, extract) builder.add_edge(extract, sentiment) builder.add_edge(sentiment, reply) builder.add_edge(reply, END) graph builder.compile() result graph.invoke({comment: 物流太慢了等了一周才到不过产品质量还不错}) print(result[reply])这段代码最清晰的地方在于整个流程是肉眼可见的。extract → sentiment → reply三条边一写架构图就画出来了。如果你后续想改成“情感为否定时先走安抚节点再生成回复”只需要加一个条件边而不是改一堆逻辑。这就是 LangGraph 的核心价值——复杂流程的可控性。实际开发中我通常会再加一个 checkpointer 参数把每次运行的状态保存到 SQLite 或 Postgres这样用户中途刷新页面、Agent 进程重启都能恢复上下文继续执行。这个特性和“电商订单售后”这种天然长流程的业务非常搭。2.3 AutoGen 实现让两个 Agent 协作完成分析如果用 AutoGen我不需要手动定义状态机而是创建两个各司其职的 ConversableAgentfrom autogen import ConversableAgent llm_config { model: gpt-4o-mini, api_key: YOUR_API_KEY, } analyzer ConversableAgent( nameanalyzer, system_message( 你是评论分析助手。你的职责是提炼用户评论的关键信息 并判断情感倾向肯定/否定/中性。 ), llm_configllm_config, ) replier ConversableAgent( namereplier, system_message( 你是客服回复助手。你会收到评论分析结果然后生成一条得体、 有针对性的用户回复建议。回复结束后请输出 TERMINATE。 ), llm_configllm_config, ) result analyzer.initiate_chat( replier, message物流太慢了等了一周才到不过产品质量还不错, max_turns3, ) print(result.chat_history)AutoGen 的自由度体现在对话流程上analyzer 生成分析结果后replier 会基于这个消息继续生成回复如果 max_turns 设成 4甚至可以再来一轮“replier 质疑分析不准确、analyzer 重新分析”的循环。这种迭代式讨论在“需要多角度质疑”的场景里非常好用比如让两个 Agent 分别从技术和成本角度辩论最后得到更周全的方案。我踩过的坑是对话偏离主题。在没有约束的情况下两个 Agent 很可能在第三轮就聊到“你今天的 prompt 是什么”这种无聊话题。解决办法是在 system_message 里明确要求回复必须以TERMINATE结束同时在initiate_chat里设置max_turns。如果你的业务需要三个以上 Agent 参与可以使用GroupChat和GroupChatManager但那需要制定更严格的发言顺序规则否则会出现一个 Agent 连续抢话、其他人被冷落的局面。2.4 CrewAI 实现定义角色然后直接开工CrewAI 的写法在四个框架里最接近“自然语言描述工作流程”from crewai import Agent, Task, Crew, Process analyzer Agent( role评论分析员, goal准确提炼用户评论的核心信息和情感倾向, backstory你是一名经验丰富的电商客服运营擅长从用户反馈中快速抓住重点。, llmgpt-4o-mini, ) replier Agent( role客户回复专员, goal生成人性化且专业的用户回复建议, backstory你是品牌官方客服风格温和、语气专业擅长维护品牌口碑。, llmgpt-4o-mini, ) task1 Task( description提炼以下评论的关键信息并判断情感倾向肯定/否定/中性{input_comment}, agentanalyzer, ) task2 Task( description基于上一任务的分析结果生成一条用户回复建议。尽量体现品牌温度。, agentreplier, ) crew Crew( agents[analyzer, replier], tasks[task1, task2], processProcess.sequential, verboseTrue, ) result crew.kickoff(inputs{input_comment: 物流太慢了等了一周才到不过产品质量还不错}) print(result)这种代码风格在演示和 MVP 阶段非常有优势——你几乎是把业务需求翻译成了 Agent 定义。CrewAI 会让 task1 的输出自动作为 task2 的可用上下文Agent 之间不需要手写“传递消息”的逻辑。Process.sequential 保证它们按声明顺序执行。但要注意如果你只定义了角色而没有充分约束它们CrewAI 的 Agent 可能会“自由发挥”。我在测试时发现replier 偶尔会把分析员的输出当成最终回复直接输出跳过“生成新回复”这一步。解决方法是把 Task 的 description 写得足够具体甚至可以在 description 里加上“必须包含两个部分感谢用户反馈 针对物流问题的处理建议”。这个框架更适合“把常见工作流程化”的团队不适合需要动态决策分支的项目。2.5 Microsoft Agent Framework 实现统一 Agent 与内置工具Microsoft Agent Framework 的官方 Python 包名是microsoft-agent-framework起步写法非常简洁import asyncio from microsoft_agent_framework import Agent, Runner from microsoft_agent_framework.tools import FunctionTool FunctionTool def extract_key_points(text: str) - str: 简单版关键信息提取实际项目中可接入 LLM 或关键词算法。 return text[:50] FunctionTool def detect_sentiment(text: str) - str: 简单版情感判断这里只做演示。 return positive if 不过 in text else neutral agent Agent( namecomment_agent, instructions( 你是一名电商客服智能助手。请判断用户评论的情感倾向 并生成一条友好的回复建议。可以使用提供的工具辅助分析。 ), tools[extract_key_points, detect_sentiment], modelgpt-4o-mini, ) async def main(): result await Runner.run( agent, input物流太慢了等了一周才到不过产品质量还不错, ) print(result.final_output) asyncio.run(main())微软这套框架用我比较舒服的一点是它的 Agent 和工具概念很干净Agent 负责理解任务、决定是否调用工具工具负责执行具体函数。你可以在instructions里只写目标把具体方法论交给模型去组合工具。它内部还封装了运行状态追踪、Token 统计、策略控制Policy等能力适合往企业环境里部署。不过这套框架目前更适合“单 Agent 工具”的业务形态。虽然它也支持多 Agent 工作流但相关的稳定性和社区资料还不像 LangGraph 那么成熟。如果你今天要做一个需要精细控制节点跳转的复杂流程单靠 MS Agent Framework 的默认 SDK 会写得比较别扭可能还得绕到 workflow 子模块去手动建模。3. 关键指标对比与选型建议3.1 一张表看懂四个框架的差异我把自己在项目里最关心的 8 个维度整理成了表格方便你一眼找到差异维度LangGraphAutoGenCrewAIMicrosoft Agent Framework核心编排思想图/状态机多代理对话角色化任务派发统一 Agent 运行时上手难度中高较低最低中等细粒度流程控制最强较弱弱中多代理协作模式手动建图编排自由对话/群聊顺序/层级对话工作流状态持久化内置 checkpointer强依赖外部实现依赖外部实现内置面向企业生产可观测性中可自行集成中较弱强社区生态最丰富丰富但已并入微软体系较丰富起步阶段典型适用团队复杂流程开发团队研究探索/讨论型项目内容团队/低代码需求企业平台团队从这张表能看出一条规律越灵活的框架学习成本越高越易用的框架掌控力越弱。这不是框架的问题而是取舍问题。你团队里如果有很强的 prompt 工程和流程建模能力LangGraph 会是长期的效率保障如果只是想快速把多个 Agent 跑起来看效果CrewAI 或者 MS Agent Framework 会更合适。3.2 不同业务场景的选型建议先说说我的经验结论金融、政务、企业级复杂工单这类“流程不能错、状态必须能恢复”的业务优先考虑 LangGraph。这些场景对异常恢复、人工介入、步骤审计的要求极高LangGraph 的显式图和持久化状态几乎是天然匹配。我做的客服系统就是因为线上出现过一次流程中断才从早期选择改用 LangGraph。如果业务场景更像“头脑风暴”“多角色评审”“研究报告生成”AutoGen 的对话式模型更合适。比如让一个研发团队 Agent 讨论技术方案本来就是几个角色来回碰撞AutoGen 的自由度反而是优点。这里我提醒一句如果是生产环境里用 AutoGen 做长期运行的 Agent一定要把对话轮次和 token 预算卡死否则成本会失控。内容流水线、自动化运营、流程固定的场景可以直接看 CrewAI。比如“从选题→写稿→配图→发布”这类步骤不变、角色明确的工作CrewAI 的代码量最少、维护成本最低。它特别适合团队里没有专职 AI 工程师的部门稍微培训一下就能让业务同学改 Agent 描述。至于 Microsoft Agent Framework我会把它推荐给计划把 Agent 能力平台化的团队。比如你们公司要建设统一 AI Agent 平台需要对接 Azure 生态、统一身份认证、统一监控微软这套框架确实是目前最“正统”的选择。小团队做小项目先跳过它等生态成熟了再上车也不迟。4. 实际开发中我踩过的坑4.1 上下文失控与多代理跑偏这是我用 AutoGen 时遇到最频繁的问题。三个 Agent 聊得兴起几轮过后对话历史直接飙到几万 token后面对话质量明显下降因为有效信息被淹没在闲聊里了。解决思路有两个一是把大任务拆成多个小对话每个小对话只聚焦一个子问题比如先做单 Agent 信息提取再做双 Agent 讨论而不是让所有 Agent 从零开始瞎聊二是在系统提示里写清楚“每个回复必须控制在三句话内”利用格式约束来限制上下文膨胀。CrewAI 的跑偏问题则体现在“角色扮演”失效。模型在简单任务里还能维持人设一旦任务步骤变多它会开始忽略 role 设定直接输出最笼统的答案。我给的意见是把所有关键约束写进 Task 的 description 里而不是 Agent 的 backstory 里——Task 是模型必须执行的backstory 很多时候只是模型的金字塔顶背景噪音。4.2 Agent 安全问题工具权限要收敛Agent 开发领域这两年最热门的话题就是 Agent 安全。你在给 Agent 挂工具时不要天真地把所有能力都暴露给它。比如 CrewAI 的某些示例会开启allow_code_execution让 Agent 能在容器里执行脚本这个能力如果被 prompt injection 利用后果很严重。我自己的原则是最小权限 白名单。Agent 需要什么工具就只给什么工具凡是能执行系统命令、访问文件系统、调用外部 API 的工具都要单独做授权最好由人先审批再执行。LangGraph 因为图结构透明相对容易做 audit——每个节点执行了什么操作都能被记录。AutoGen 和 CrewAI 的对话式结构里工具调用的触发更隐晦所以你要在工具层额外加一层校验函数。MS Agent Framework 内置 Policy 概念可以把“工具使用策略”集中管理这一点对企业用户是实打实的加分项。4.3 调试方式差异巨大调试 LangGraph 时我习惯用它的get_graph().draw_mermaid_png()把图结构可视化节点和边的走向一目了然出问题时能快速判断是哪条边跳错了。AutoGen 调试则要打开 verbose 模式观察 Agent 之间完整的 message 流转更像是“看聊天记录”。CrewAI 有verboseTrue能看到每个 Task 的中间输出但跨 Agent 的上下文传递不够透明。说实话四个框架里调试体验最让我满意的还是 LangGraph。它把每个 node 的输入输出都暴露在 state 里你可以用 LangSmith 或自定义中间件记录每次 state 变化这在排查“某个节点返回了异常格式”时比看纯 LLM 聊天记录高效得多。4.4 Agent 记忆与长流程状态要保持很多项目都会遇到“记忆”需求也就是 Agent 需要记住用户之前的偏好、历史交互。LangGraph 内置 state checkpointer天然适合做这种记忆AutoGen 和 CrewAI 则需要在外部自己维护一个 memory 对象在每次对话启动时注入上下文。MS Agent Framework 里有 Workflow 和 Agent 生命周期管理记忆功能会更体系化但具体用法还在频繁迭代中你要做好跟随官方文档调整代码的心理准备。另外一个更底层的建议不要什么都往记忆里塞。长流程里放太多历史信息反而会干扰模型判断我一般的做法是只保留“结构化摘要”比如用户偏好标签、未完成事项、关键结论而不是把几万字的历史消息原封不动传给模型。这样既省 token又不容易跑偏。5. 我的最终建议做选型决策时别听别人说“XX 框架最好”先问自己三个问题你的业务流程是否需要细粒度控制你能接受的 prompt 和代码维护成本是多少你的团队有没有专门做 Agent 工程化的人如果让我凭实际体验给一句话追求流程可控和生产稳定选 LangGraph追求快速演示和内容类项目选 CrewAI追求讨论型 Agent 应用选 AutoGen 的思路考虑企业级平台化选 Microsoft Agent Framework。这四个框架不是简单的“谁替代谁”而是代表了 Agent 应用的不同组织形态。最后再分享一个小技巧无论选哪个框架第一版先别上复杂多代理用单个 Agent 把核心链路跑通再逐步加节点、加角色。我见过太多项目一上来就搞四个 Agent 协作结果一半时间都花在厘清它们之间的关系上。Agent 开发和你学过的任何工程一样复杂系统的地基永远是从一个最简可用的版本开始夯实的。
阅读完成 · 觉得有帮助？
