1. 多智能体框架选型的核心逻辑1.1 为什么单Agent不够用刚开始接触AI应用开发那会儿我和大多数人一样觉得一个LLM加上一套提示词模板就能包打天下。写个客服机器人、做个文档问答确实够用。但当你真正要把AI塞进一个业务流程里比如自动完成一份行业调研报告问题就全暴露出来了。单Agent的瓶颈非常明显。它要同时扮演“搜索资料的人”“分析数据的人”“撰写报告的人”和“审校质量的人”所有角色挤在一个上下文窗口里。结果就是提示词越写越长模型注意力被稀释前面搜到的资料到后面写报告时已经忘得差不多了。更麻烦的是你没法给不同环节配置不同的模型——搜索环节需要快速响应写作环节需要强推理能力审校环节需要严谨判断一个模型很难同时满足。我踩过最典型的一个坑让一个Agent先搜集十篇资料再写总结结果它写到第三段就开始编造数据因为原始资料在上下文里已经被挤到边缘了。这不是模型能力问题是架构问题。多智能体框架解决的就是这个“角色分工”的问题。把一个大任务拆成若干子任务每个子任务交给一个专门的Agent每个Agent有自己的系统提示词、自己的工具集、甚至自己的模型。Agent之间通过消息传递来协作就像一个团队而不是一个全能选手。1.2 Autogen和LangGraph的定位差异Autogen和LangGraph是目前多智能体领域最常被拿来对比的两个框架但它们的设计哲学其实差别很大。Autogen来自微软研究院核心抽象是“对话式协作”。它把多智能体系统看作一群可以互相发消息的实体每个Agent有名字、有系统提示词、有可调用的工具。Autogen帮你处理的是“谁该在什么时候说话”这个问题。它内置了多种对话模式比如两个Agent互相聊天、多个Agent按顺序发言、或者由一个管理者Agent来调度。你只需要定义好每个角色的职责Autogen会自动驱动对话流程。LangGraph来自LangChain团队核心抽象是“状态图”。它把多智能体系统看作一个有向图节点是Agent或工具边是状态转移条件。你需要显式地定义图的拓扑结构从哪个节点开始、什么条件下走到哪个节点、什么时候结束。LangGraph帮你处理的是“状态怎么在节点之间流转”这个问题。打个比方Autogen像是一个圆桌会议你告诉每个人该聊什么他们自己会聊起来LangGraph像是一条流水线你设计好每个工位做什么、什么条件下传到下一个工位。前者更灵活但可控性稍弱后者更可控但需要你设计得更细致。1.3 选型决策的关键维度那到底该选哪个我总结了一个简单的决策表基于几个关键维度维度AutogenLangGraph核心抽象对话式协作状态图学习曲线较平缓定义角色即可较陡峭需理解图结构流程可控性中等依赖对话驱动高显式定义转移条件适合场景头脑风暴、辩论、协作写作流程自动化、条件分支、循环状态管理对话历史即状态显式状态对象人机交互支持但需额外配置原生支持中断和恢复调试难度对话流不易追踪图结构清晰易调试我的经验是如果你的任务更像“一群专家讨论出一个结论”选Autogen如果任务更像“按步骤执行一个有分支的流程”选LangGraph。当然两者也可以结合使用——用LangGraph做流程编排在某个节点里嵌入Autogen的对话组。2. Autogen核心机制与实操拆解2.1 安装与基础环境搭建Autogen的安装很直接但有几个版本坑需要注意。目前Autogen已经拆分为两个包autogen-agentchat是核心的Agent对话框架autogen-ext是扩展工具集。如果你看到网上教程里直接pip install pyautogen那是旧版本的用法新项目建议用新包。pip install autogen-agentchat autogen-ext[openai]这里[openai]是可选依赖装了之后可以直接用OpenAI兼容的模型接口。如果你用的是其他模型服务也可以不装这个extra手动配置客户端。环境变量方面我习惯把模型配置放在.env文件里不要硬编码在代码中OPENAI_API_KEYyour_key_here OPENAI_BASE_URLyour_base_url_here注意如果你用的是兼容OpenAI接口的第三方模型服务base_url一定要确认是否支持function calling因为Autogen的工具调用依赖这个能力。我遇到过一些服务声称兼容但实际不支持工具调用导致Agent一直无法正确调用函数。2.2 定义你的第一个AgentAutogen里最核心的类是AssistantAgent和UserProxyAgent。前者是AI助手后者是用户代理——它既可以代表人类发言也可以自动执行代码或调用工具。from autogen_agentchat.agents import AssistantAgent, UserProxyAgent from autogen_ext.models.openai import OpenAIChatCompletionClient model_client OpenAIChatCompletionClient( modelgpt-4o, api_keyyour_key, base_urlyour_base_url ) assistant AssistantAgent( nameanalyst, model_clientmodel_client, system_message你是一名资深数据分析师擅长从数据中提炼洞察。 ) user_proxy UserProxyAgent( nameuser, description代表用户发起任务并审核结果 )这里有个细节值得展开system_message的写法直接决定了Agent的行为质量。我见过很多人把系统提示词写得很笼统比如“你是一个有用的助手”然后抱怨Agent表现不好。实际上系统提示词应该包含三个要素角色定位、能力边界、输出格式要求。比如上面这个数据分析师更好的写法是system_message你是一名资深数据分析师擅长从结构化数据中提炼商业洞察。 你的能力包括描述性统计、趋势识别、异常检测、归因分析。 你的输出必须包含核心发现不超过3条、数据支撑、建议行动。 你不做预测性建模如果用户要求预测请建议转交建模专家。这样写的好处是Agent知道自己该做什么、不该做什么、输出长什么样。在多智能体协作中这一点尤其重要因为其他Agent需要根据你的输出来决定下一步动作。2.3 双Agent对话模式实战最简单的多智能体模式就是两个Agent对话。一个负责生成一个负责审核循环往复直到达成共识。from autogen_agentchat.teams import RoundRobinGroupChat from autogen_agentchat.conditions import TextMentionTermination writer AssistantAgent( namewriter, model_clientmodel_client, system_message你是一名科技专栏作者负责撰写初稿。 ) reviewer AssistantAgent( namereviewer, model_clientmodel_client, system_message你是一名严格的主编负责审核稿件。 如果稿件质量达标回复APPROVED。 如果不达标给出具体修改意见。 ) termination TextMentionTermination(APPROVED) team RoundRobinGroupChat( participants[writer, reviewer], termination_conditiontermination, max_turns10 ) result await team.run(task写一篇关于多智能体框架的科普短文300字左右。)这段代码跑起来之后writer先写一版reviewer审核并给出意见writer根据意见修改如此循环直到reviewer说出“APPROVED”或者达到最大轮次。我实测下来这种模式在写作类任务上效果很好但有几个调优点第一max_turns一定要设。我最初没设结果两个Agent陷入无限循环——writer改一版reviewer说还不行writer再改reviewer又说还不行。设了10轮之后即使没达成一致也会强制停止避免浪费token。第二终止条件的关键词要选好。用“APPROVED”这种明确的词比用“好的”“可以了”要可靠得多因为后者可能出现在正常对话中导致误终止。第三reviewer的系统提示词里要明确“给出具体修改意见”否则它可能只说“不够好”而不说哪里不好writer就无从下手。2.4 多Agent协作与角色分工当任务复杂度上升两个Agent就不够了。比如做一个行业调研报告至少需要搜索员搜集资料、分析师提炼观点、撰写员组织成文、审校员检查质量。searcher AssistantAgent( namesearcher, model_clientmodel_client, system_message你负责搜集资料每次输出3-5条关键信息附来源。 ) analyst AssistantAgent( nameanalyst, model_clientmodel_client, system_message你负责分析搜到的资料提炼3个核心观点。 ) writer AssistantAgent( namewriter, model_clientmodel_client, system_message你负责将分析结果组织成一篇800字的报告。 ) reviewer AssistantAgent( namereviewer, model_clientmodel_client, system_message你负责审校报告达标回复APPROVED否则给出修改意见。 ) team RoundRobinGroupChat( participants[searcher, analyst, writer, reviewer], termination_conditionTextMentionTermination(APPROVED), max_turns15 )RoundRobin模式会按顺序让每个Agent发言。searcher先搜集资料analyst基于资料分析writer基于分析写报告reviewer审核。如果reviewer不通过下一轮又从searcher开始——但这时候searcher会看到之前的对话历史知道需要补充资料。这里有个实战经验Agent的顺序很重要。我试过把reviewer放在writer前面结果reviewer对着空气审核完全没法工作。顺序应该遵循信息流的自然方向先收集、再分析、再产出、最后审核。另外每个Agent的输出会进入共享的对话历史后面的Agent都能看到。这意味着如果searcher输出了大量无关信息会挤占后面Agent的上下文空间。所以我在searcher的提示词里加了“每次输出3-5条关键信息”控制输出量。2.5 工具调用与代码执行Autogen的一个强大之处是Agent可以调用工具甚至直接执行代码。UserProxyAgent默认可以执行Python代码这在数据处理场景下非常实用。from autogen_ext.tools.code_execution import PythonCodeExecutionTool code_tool PythonCodeExecutionTool() analyst AssistantAgent( nameanalyst, model_clientmodel_client, system_message你负责数据分析可以编写Python代码来处理数据。, tools[code_tool] )当analyst需要计算时它会生成Python代码UserProxyAgent执行代码并把结果返回给analyst。这个闭环让Agent具备了实际的计算能力而不只是“说”。但这里有个安全注意事项代码执行是在你的本地环境跑的如果Agent生成了危险代码比如删除文件后果是真实的。生产环境中一定要用沙箱环境或者限制可执行的代码范围。我在开发阶段会用一个独立的虚拟环境并且定期检查Agent生成的代码。提示如果你不想让Agent执行代码可以只用AssistantAgent而不配UserProxyAgent的代码执行能力。但这样Agent就只能“说”不能“做”适合纯文本生成任务。3. LangGraph状态图构建与实操拆解3.1 安装与核心概念LangGraph的安装同样简单pip install langgraph langchain-openaiLangGraph的核心概念有三个State状态、Node节点、Edge边。State是一个共享的数据结构所有节点都能读写Node是一个函数接收State并返回State的更新Edge定义了节点之间的流转关系可以是固定的也可以是基于条件的。和Autogen的“对话驱动”不同LangGraph是“状态驱动”。每个节点执行完后State被更新然后根据Edge决定下一步去哪个节点。这种模式更适合有明确流程的任务。3.2 定义State和第一个节点先定义一个State它就是一个TypedDict或者Pydantic模型from typing import TypedDict, Annotated from langgraph.graph import StateGraph, START, END import operator class ReportState(TypedDict): topic: str research: Annotated[list[str], operator.add] analysis: str draft: str review: str approved: bool这里Annotated[list[str], operator.add]的意思是当多个节点都往research里写数据时用加法列表拼接来合并而不是覆盖。这是LangGraph处理并发更新的方式。然后定义节点函数def research_node(state: ReportState): # 模拟搜索 results [f关于{state[topic]}的资料{i} for i in range(1, 4)] return {research: results} def analysis_node(state: ReportState): analysis f基于{len(state[research])}条资料的分析结论 return {analysis: analysis} def draft_node(state: ReportState): draft f报告草稿{state[analysis]} return {draft: draft} def review_node(state: ReportState): if len(state[draft]) 10: return {review: 通过, approved: True} return {review: 需要修改, approved: False}每个节点函数接收完整的State返回一个字典表示要更新的字段。LangGraph会自动把返回值合并到State中。3.3 构建图与条件边定义好节点之后用StateGraph把它们串起来graph StateGraph(ReportState) graph.add_node(research, research_node) graph.add_node(analysis, analysis_node) graph.add_node(draft, draft_node) graph.add_node(review, review_node) graph.add_edge(START, research) graph.add_edge(research, analysis) graph.add_edge(analysis, draft) graph.add_edge(draft, review) def should_continue(state: ReportState): if state[approved]: return END return draft graph.add_conditional_edges(review, should_continue) app graph.compile()这里add_conditional_edges是关键。review节点执行完后根据approved字段决定是结束还是回到draft节点重新修改。这就形成了一个循环直到审核通过。跑起来result app.invoke({topic: 多智能体框架对比, research: [], approved: False}) print(result[draft])3.4 人机交互与中断恢复LangGraph有一个Autogen没有原生支持的能力中断和恢复。你可以在某个节点前设置断点让流程暂停等人类输入后再继续。from langgraph.checkpoint.memory import MemorySaver memory MemorySaver() app graph.compile(checkpointermemory, interrupt_before[review]) config {configurable: {thread_id: report-001}} # 第一次运行会在review前暂停 result app.invoke({topic: 测试, research: [], approved: False}, config) # 人类检查draft后继续执行 result app.invoke(None, config)这个能力在实际项目中非常有用。比如自动生成的报告需要人工审核后才能发布就可以在review节点前中断等人工确认后再继续。thread_id保证了同一条流程的状态可以被恢复。我做过一个合同审核的流程就是在“生成审核意见”节点前中断让法务人员确认AI的意见是否合理确认后再继续到“发送通知”节点。这种人在回路的设计在LangGraph里实现起来非常自然。3.5 多Agent在LangGraph中的编排LangGraph也可以编排多Agent。每个Agent是一个节点Agent之间的消息传递通过State来完成。class TeamState(TypedDict): messages: Annotated[list, operator.add] next_agent: str def agent_a_node(state: TeamState): # Agent A处理逻辑 response Agent A的处理结果 return {messages: [{role: agent_a, content: response}], next_agent: agent_b} def agent_b_node(state: TeamState): response Agent B的处理结果 return {messages: [{role: agent_b, content: response}], next_agent: end} def router(state: TeamState): return state[next_agent] graph StateGraph(TeamState) graph.add_node(agent_a, agent_a_node) graph.add_node(agent_b, agent_b_node) graph.add_edge(START, agent_a) graph.add_conditional_edges(agent_a, router, {agent_b: agent_b, end: END}) graph.add_conditional_edges(agent_b, router, {agent_a: agent_a, end: END})这种模式下每个Agent是一个独立的节点Agent之间的流转由router函数控制。相比Autogen的RoundRobinLangGraph给了你更精细的控制——你可以根据Agent的输出内容来决定下一步找谁而不是简单地按顺序轮转。4. 常见问题与排查技巧实录4.1 Autogen常见问题速查问题现象可能原因解决方法Agent一直重复相同的话终止条件未触发检查termination_condition设置max_turns工具调用失败模型不支持function calling换用支持工具调用的模型对话历史过长导致超token未控制输出长度在系统提示词中限制输出字数Agent不按预期角色发言系统提示词太笼统明确角色、能力边界、输出格式代码执行报错环境缺少依赖在代码执行前安装所需包4.2 LangGraph常见问题速查问题现象可能原因解决方法图编译报错节点名称重复或边指向不存在的节点检查add_node和add_edge的名称一致性状态更新丢失未使用Annotated定义合并方式对列表类型字段用operator.add条件边不生效路由函数返回值与映射不匹配确保返回值在映射字典的key中中断后无法恢复未配置checkpointer编译时传入MemorySaver循环无法退出条件判断始终为真检查路由逻辑设置最大迭代次数4.3 我踩过的三个典型坑第一个坑Autogen的对话历史无限增长。我做一个长流程任务时跑了20轮对话后发现token消耗惊人。原因是每一轮的所有消息都保留在上下文中。后来我在系统提示词里加了“每轮只输出核心结论不超过100字”并且定期用ClearConversation清理历史token消耗降了60%。第二个坑LangGraph的状态字段被覆盖。我定义了一个messages字段想累积所有消息但每次节点返回新消息时旧消息就没了。后来查文档才知道需要用Annotated[list, operator.add]来声明合并方式。这个点在官方文档里写得很隐蔽我是翻源码才找到的。第三个坑两个框架混用时状态不同步。我试过在LangGraph的节点里调用Autogen的对话组结果Autogen内部的对话历史和外部的LangGraph状态是两套东西导致流程判断出错。后来我的做法是Autogen只负责生成内容生成完把结果写回LangGraph的State由LangGraph统一管理流程状态。两者职责分清问题就解决了。4.4 性能优化的几个实操技巧模型分级使用。不是所有Agent都需要用最强的模型。搜索员可以用快速模型分析师和撰写员用强推理模型审校员用中等模型。我实测下来这样配置能省40%左右的成本效果几乎无损。缓存重复调用。如果某个Agent对相同输入会产出相同输出可以加一层缓存。LangGraph可以用checkpointer实现Autogen可以自己包一层缓存函数。控制上下文长度。多智能体系统里上下文很容易膨胀。我的做法是每个Agent只保留最近3轮的相关消息更早的消息压缩成摘要。这个策略在长流程任务中效果显著。并行化独立节点。LangGraph支持并行执行没有依赖关系的节点。比如搜索员和资料整理员可以同时工作最后合并结果。用add_edge的时候注意不要形成环否则会死锁。5. 从框架到落地我的选型建议5.1 什么场景选Autogen如果你的任务符合以下特征Autogen是更好的选择任务边界模糊需要Agent之间反复讨论才能收敛角色分工明确但流程不固定需要快速原型验证不想花太多时间在设计流程上。比如内容创作、头脑风暴、方案评审这类任务Autogen的对话式协作非常自然。你定义好角色它们自己会聊出结果。5.2 什么场景选LangGraph如果任务符合以下特征LangGraph更合适流程有明确的步骤和分支条件需要人在回路中审核需要精确控制状态流转需要中断和恢复能力。比如审批流程、数据处理管道、多步骤决策系统LangGraph的状态图模型更贴合。5.3 混合使用的架构模式实际项目中我更多是混合使用。外层用LangGraph做流程编排定义好“搜索→分析→撰写→审核→发布”的主流程在“撰写”这个节点里嵌入一个Autogen的对话组让撰写员和润色员互相打磨内容。这样既有流程的可控性又有对话的灵活性。架构大概是这样的def writing_node(state: ReportState): # 在LangGraph节点内启动Autogen对话组 writer AssistantAgent(namewriter, ...) polisher AssistantAgent(namepolisher, ...) team RoundRobinGroupChat([writer, polisher], max_turns5) result await team.run(taskf基于以下分析写报告{state[analysis]}) return {draft: result.messages[-1].content}这种模式的关键是Autogen负责“生成”LangGraph负责“流转”。生成结果写回State由LangGraph决定下一步去哪。两者各司其职不会互相干扰。5.4 后续可以扩展的方向这套框架搭好之后可以往几个方向扩展。一是加入更多专业Agent比如事实核查员、合规检查员、格式排版员让流程更完整。二是接入外部工具比如数据库查询、API调用、文件读写让Agent能真正操作业务系统。三是加入评估机制用另一个Agent对输出质量打分低于阈值就触发重做。我在实际项目里还加了一个“成本追踪”节点每次Agent调用后记录token消耗超过预算就自动降级到更便宜的模型。这个在实际运营中非常有用避免了一个流程跑下来账单爆炸。多智能体框架的选型没有绝对的对错关键是理解每个框架的设计哲学然后根据任务特征来匹配。Autogen像是一个灵活的团队协作工具LangGraph像是一个精密的流程引擎。用对了地方两者都能大幅提升AI应用的可靠性和可维护性。