最近不少人在问多智能体协作到底用什么平台搭这个问题我前前后后折腾了小半年踩过的坑比吃过的饭还多。从最早用纯代码手写工作流到后来试LangGraph、AutoGen、CrewAI再到Dify这类可视化平台基本上主流的方案都过了一遍。先说结论没有绝对最好的平台只有最匹配你场景的方案但选错平台的代价非常大轻则返工重写重则整个架构推倒重来。这篇文章我不打算讲太多天花乱坠的理论就围绕多智能体协作平台搭建这件事把我在实际项目中踩过的坑、验证过的选型思路、以及可直接抄作业的搭建过程全部摊开来讲。适合正在做AI应用落地、想搭建多智能体系统但还在纠结技术选型的开发者也适合已经在用某个框架但想对比其他方案的团队。1. 多智能体协作平台搭建前先搞清楚你到底在选什么1.1 多智能体系统不是多个大模型API的拼接很多人一听多智能体协作第一反应是不就是调好几个大模型的接口吗这个理解偏差是后续所有问题的根源。真实的多智能体协作系统核心难点在于协作两个字而不是智能体本身。我举个例子你让三个Agent分别扮演市场调研、文案撰写、视觉设计目标是产出一张宣传海报。如果只是分别调用三次大模型API你拿到的是三段孤立的输出市场调研的结果不会自动传给文案文案写的文案视觉设计根本看不到。真正的多智能体协作需要解决三个层面问题任务编排层谁先干活谁后干活哪些活可以并行哪些活必须等前置结果通信与状态层智能体之间怎么传递消息共享的状态存在哪里如何避免互相覆盖决策与路由层当前任务应该交给哪个智能体处理处理不了的时候如何升级或者回退所以搭建平台的时候你选的不只是调用大模型的工具而是一个能承载任务流转、状态管理、智能决策的运行时框架。1.2 用公司协作来理解多智能体平台的本质我自己跟别人解释多智能体协作平台时最喜欢用的一个类比是开一家公司。单一智能体相当于你雇了一个全能员工。你给他下指令他干完活把结果交给你。简单但一个人能力有限。多智能体协作系统相当于你开了一家公司。有CEO负责拆解目标有产品经理负责整理需求有工程师负责执行有测试负责质检。大家各司其职通过会议消息传递、文档共享状态、流程任务编排来协同。平台搭建的本质就是设计这家公司的组织架构和办公流程。有的平台像扁平化小团队所有Agent地位平等通过聊天互相协调比如AutoGen有的平台像科层制大公司有严格的主管和汇报关系比如LangGraph的图结构还有的平台像外包公司你只需要描述需求平台自动帮你组团队比如CrewAI的流程模式。想清楚你的业务场景更像哪种公司形态选型思路一下子就清晰了。这也是为什么我一再强调不要一上来就问哪个平台最强先问自己我的业务需要什么样的协作模式。1.3 平台搭建前的三个关键评估维度在我尝试过这么多方案之后总结出三个必须在动手前评估清楚的维度这三个维度直接决定你后面会不会返工第一业务过程的确定性。你的任务流程是固定不变的比如固定的采集→分析→生成报告三步走还是高度动态的AI需要自己决定下一步干什么流程固定优先考虑Dify这类可视化工作流平台流程动态、需要智能体自主决策那LangGraph这类图编排框架更合适。第二团队的维护能力。你们团队是纯业务背景、只想快速出效果还是有一批能写代码的工程师、愿意长期维护前者选低代码平台后者选代码框架。第三对可观测性的要求。多智能体系统最大的噩梦是不知道哪里出了问题。两个Agent来回对话八轮最终结果偏了到底是哪个环节理解错了这就需要在选型时特别关注平台提供的日志追踪、链路监控能力。这一点我后面会单独讲。2. 主流的几类多智能体协作平台到底怎么选2.1 代码框架类LangGraph、AutoGen、CrewAI我在项目里实际用过这三种代码框架说说我最真实的体感。LangGraph是我目前的主力选择。它的核心模型是图节点就是智能体要执行的动作边就是状态流转的方向。你可以非常精细地控制流程包括条件分支、循环、人工介入节点几乎能做到只要你想得到没有画不出来的流程。代价是学习曲线比较抖你需要理解State、Node、Edge、Checkpoint这些概念。AutoGen是微软出品的它的核心思路是对话驱动。多个Agent坐在一起通过自然语言对话来协作你可以设定对话的轮数上限、终止条件。它最出彩的地方是支持人机混合协作人可以在对话流里随时插一脚。但对于复杂业务流程纯靠对话驱动会有点飘容易出现对话发散、聊偏题的情况。CrewAI主打的是角色扮演任务委派概念非常直观你定义一个个带角色描述的Agent比如资深数据分析师文案达人然后定义Task再用Process把他们串起来。它的代码量非常少几乎可以用声明式的方式搭出一个小团队。我用CrewAI做过一个自动生成周报的Demo从零到跑通只用了不到两个小时。这三个框架之间的关系我建议这么理解AutoGen适合做自由讨论型任务CrewAI适合做快速原型和任务固定的场景LangGraph适合做生产级复杂流程的落地。2.2 可视化平台类Dify、FastGPT这类低代码方案如果你的团队里没有太多资深后端工程师又想在几天内看到一个能跑的多智能体应用那我强烈建议先看看Dify这类低代码平台。Dify目前的Agent编排能力已经相当成熟你可以在界面上拖拽出多个Agent节点配置每个人的Prompt、模型参数、工具调用权限再通过连线定义它们的上下游关系。它内置了知识库、工具调用、变量记忆、日志追踪这些模块省去了很多从零造轮子的工作。我用Dify给一个客户快速搭过一个售前客服售后技术支持的双Agent系统。售前Agent负责解答产品规格和报价问题一旦判定用户需要售后支持就把会话上下文透传给售后Agent售后Agent再带着用户的历史诉求继续处理。整个搭建过程全程界面操作没写一行后端代码。但低代码平台也有天花板一是复杂逻辑比如多层嵌套的循环、需要动态创建Agent实例在可视化界面上表达起来很吃力二是当你需要深度定制比如自定义Agent的推理策略、改写底层状态管理逻辑时平台不一定给你开口子。我的经验是快速验证、MVP阶段用低代码平台真正追求控制力和复杂度上限时回到代码框架。2.3 为什么我不建议完全从零手写一个编排平台还有一个常见的问题是我能不能不用这些框架自己写一套多智能体协作的平台。技术上当然可以我自己早期也这么干过但我用血泪教训告诉你如果不是搞科研或者锻炼架构能力千万不要。多智能体的编排看着简单实际要实现的东西很多消息路由、状态管理、重试机制、上下文窗口管理、模型调用限流、日志追踪、人工审核节点、异常恢复……这些每一项单独拎出来工作量不大合在一起就是一个中大型中间件项目。更麻烦的是多智能体系统有大量不可控的部分。模型返回的JSON格式偶尔会坏、Agent对话偶尔会陷入死循环、某一个子任务超时导致整个流程挂起。这些边界情况成熟的框架比如LangGraph和Dify已经帮你处理掉大半了而自己开发的框架遇到这些问题时只能一个一个填坑。因此我更推荐的做法是站在框架的肩膀上搭建但深入理解框架的底层机制。这样既有框架的稳定性又能在需要的时候对关键环节做手术。2.4 选型决策参考表我把几个主流方案的对比整理成了表格方便你根据自己的实际情况快速判断方案上手难度编排灵活性可视化支持生产可用性适合场景LangGraph中高高一般高复杂业务流程、需要精细控制AutoGen中中低中高对话式协作、人机混合CrewAI低中低中快速原型、任务流固定的场景Dify低中高高快速落地、非技术团队运维自研框架很高最高需自建视投入而定科研探索、极端定制需求切记这个表不是哪个分高选哪个而是匹配你的真实约束。公司里没有专职AI工程师那LangGraph的灵活性优势根本发挥不出来反而是Dify能让你当晚就上线。3. 实操详解手把手搭一个多Agent协作系统3.1 一个可落地的Demo内容营销智能体集群理论说得再多不如跑一个实际项目。我下面用LangGraph为例带大家搭建一个内容营销智能体集群用来演示多智能体协作的完整链路。选LangGraph不是因为它最完美而是因为我们这次任务的流程有明确分工、有条件分支、有并行处理还要支持后期维护调试这套需求正好是LangGraph的强项。先看这个系统的业务逻辑任务入口Agent项目经理接收用户原始需求判断任务类型决定调用哪个后续Agent选题策划Agent内容策略师根据需求产出一个内容选题素材采集Agent资料员围绕选题搜集关键信息、数据支撑文案生成Agent写手基于选题和素材生成文章初稿审核优化Agent主编对初稿进行质量审查如果质量不达标打回给文案Agent修改最多循环三次整个系统涉及条件分支任务类型判断、并行素材采集可以同时抓多个来源、循环审核打回修改是一个很典型的多智能体编排场景。3.2 环境准备与节点定义首先安装LangGraph建议在虚拟环境里操作pip install langgraph langchain langchain-openai然后定义系统的基础配置。注意这里我会把大模型的接入方式统一封装好方便后续切换不同模型服务。from typing import TypedDict, Annotated, Literal from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI # 定义Agent的共享状态结构 class AgentState(TypedDict): user_request: str # 用户原始需求 task_type: str # 任务类型 topic: str # 选题 materials: list # 素材列表 draft: str # 初稿 review_comment: str # 审核意见 review_count: int # 审核轮次 # 统一模型封装方便替换 def get_llm(temperature0.3): return ChatOpenAI( modelgpt-4o, temperaturetemperature, )提示在实际项目里建议把模型名、API Key、温度参数都统一放到配置文件里。我一开始图省事直接写死在代码中后来想换另一个模型服务时找参数找了半天非常狼狈。State是LangGraph里最核心的概念之一。你可以把它理解成整个团队共用的共享文档每个Agent在执行完自己的任务后把结果更新到这个文档里下一个Agent再读取。上面代码里定义的AgentState里topic、draft这些字段就是各个Agent之间协作的信息载体。3.3 实现五个Agent节点接下来我们逐个定义Agent节点函数。每个节点做的事本质上就是读State里需要的数据调用大模型把结果写回State。先来看任务入口Agent它负责判断任务类型为后面的流程分支提供依据。def entry_node(state: AgentState): 任务入口判断内容类型 llm get_llm(0.1) prompt f 你是内容项目管理经理。用户的需求是{state[user_request]} 请判断这个需求属于以下哪种内容类型技术教程、产品宣传、行业分析。 只输出一个类型词不要输出其他内容。 task_type llm.invoke(prompt).content.strip() return {task_type: task_type}这个节点我用了较低的温度参数0.1因为任务分类希望输出尽量稳定可控。这里一个容易被忽视的细节是Prompt里必须明确只输出一个类型词否则模型容易回答一大段废话影响后面节点对task_type字段的解析。然后是选题策划Agentdef topic_node(state: AgentState): 根据任务类型生成选题 llm get_llm(0.5) prompt f 你是资深内容策划。用户需求{state[user_request]} 内容类型{state[task_type]} 请给出一个具体可执行的选题名称30字以内。 topic llm.invoke(prompt).content.strip() return {topic: topic}素材采集Agent这里我为了演示并行执行把它拆成了两个节点分别从内部知识库和技术文档/新闻资料两个方向采集素材。LangGraph支持多个节点并行执行只要它们之间没有依赖关系def material_fetch_a(state: AgentState): 素材采集节点A内部数据 # 实际项目中这里你会调用知识库检索接口或数据库查询 llm get_llm(0.3) prompt f 你是资料员。围绕选题 {state[topic]}从内部数据视角搜集2-3条关键支撑信息。 以列表形式输出。 materials llm.invoke(prompt).content.strip() return {materials: [materials]} def material_fetch_b(state: AgentState): 素材采集节点B外部资料 # 实际项目中这里可以调用搜索API、爬虫服务或第三方数据接口 llm get_llm(0.3) prompt f 你是资料员。围绕选题 {state[topic]}从公开技术文档与行业新闻视角搜集2-3条关键支撑信息。 以列表形式输出。 materials llm.invoke(prompt).content.strip() return {materials: [materials]}这里需要强调一个LangGraph的合并规则如果两个并行节点都往同一个字段materials里写入内容默认情况下是覆盖而不是拼接。所以我在AgentState里把materials定义成list但并行节点返回的又都是字符串实际开发中需要写一个自定义的reducer函数来控制合并逻辑。这是LangGraph新手最容易踩的坑之一。文案生成Agent它会读取选题和两个素材来源的内容综合起来写初稿def writer_node(state: AgentState): 文案生成 llm get_llm(0.7) materials_text \n.join(state.get(materials, [])) prompt f 你是专业内容写手。 选题{state[topic]} 可用素材 {materials_text} 请基于上述素材撰写一篇结构完整的文章初稿。要求 1. 开头有引入 2. 中间有至少三个核心分段 3. 结尾有总结 直接输出正文。 draft llm.invoke(prompt).content.strip() return {draft: draft}最后是审核优化Agent这个节点是整个多智能体系统里最体现协作精髓的地方——它可以根据审核结果决定流程是走END结束还是打回给writer节点重新生成def reviewer_node(state: AgentState): 主编审核决定是否打回 llm get_llm(0.2) prompt f 你是严格的主编。阅读下面的文章初稿 {state[draft]} 从以下三个维度打分每个维度10分制 1. 结构完整性 2. 信息准确性 3. 可读性 如果平均分低于7分输出PASS:NO并给出修改意见。 如果平均分达到7分及以上输出PASS:YES。 result llm.invoke(prompt).content.strip() if PASS:YES in result: return {review_comment: 通过, review_count: state.get(review_count, 0) 1} else: return { review_comment: result, draft: , # 打回时清空草稿让写手重写 review_count: state.get(review_count, 0) 1, }这里需要特别注意我在打回时把draft字段清空了这是一个防止上下文污染的小技巧。如果不清空writer节点二次生成时会看到自己上次写的内容容易在原有思路上打转很难跳出原来的框架而清空后重新生成反而更容易产出不同质量的稿件。3.4 装配流程图与运行调试节点都定义好之后接下来就是把它们串成一张图。LangGraph的核心思想就是把节点和边组合成一张可执行的图边的定义方式决定了流程的分支和循环逻辑。from langgraph.graph import StateGraph, END graph StateGraph(AgentState) # 添加所有节点 graph.add_node(entry, entry_node) graph.add_node(topic, topic_node) graph.add_node(material_a, material_fetch_a) graph.add_node(material_b, material_fetch_b) graph.add_node(writer, writer_node) graph.add_node(reviewer, reviewer_node) # 定义入口和主线 graph.set_entry_point(entry) graph.add_edge(entry, topic) # 从选题节点并行分发给两个素材节点 graph.add_edge(topic, material_a) graph.add_edge(topic, material_b) # 两个素材节点都完成后汇聚到writer graph.add_edge(material_a, writer) graph.add_edge(material_b, writer) # writer写完后进入reviewer审核 graph.add_edge(writer, reviewer) # 审核结果的循环与退出逻辑 graph.add_conditional_edges( reviewer, lambda state: rewrite if state.get(review_count, 0) 3 and state.get(draft) else end, { rewrite: writer, end: END, } )这段代码里最关键的是最后这个add_conditional_edges。它就是一个智能路由如果审核没过review_count小于3且draft被清空了就回到writer节点重写如果审核通过或者达到最大重写次数就走向END结束。这里我限制了最多打回三次防止模型无限循环。你可能会问为什么不放到五次或者十次根据我的经验大模型重写在前两次往往质量提升明显但从第三次开始修改幅度会变得很小基本是为了改而改所以设置三次是一个性价比比较高的平衡点。图装配好之后用下面的代码编译并运行app graph.compile() def run_agent_cluster(user_request: str): result app.invoke({user_request: user_request, materials: [], review_count: 0}) return result # 测试运行 output run_agent_cluster(写一篇介绍RAG技术在企业落地的文章) print(output[topic]) print(output[draft]) print(output[review_comment])第一次跑通这个系统的时候你会明显感受到它与单Agent的本质差异不是一次调用就出结果而是经历了项目立项→策划→双线搜集素材→撰写→审核→可能打回重写的完整流水线。每个环节都有专门的Agent负责整体输出的文章质量比一个Agent单打独斗高出不少。3.5 Dify可视化搭建的对照方案如果你不想写代码也可以用Dify完成类似的事情这里给出界面操作的对照流程方便没有编程基础的读者参考。在Dify的工作流画布上创建多个Agent节点。以内容营销智能体集群为例先创建任务分发Agent在它的Prompt里写明职责是判断内容类型。为每个Agent节点单独配置模型。注意不同节点的模型参数可以不同任务分发用低温度文案生成用稍高温度。画出连线。从开始节点连到任务分发Agent然后根据Agenter的输出内容类型设置分支条件Dify里叫条件分支把不同内容类型路由到不同的后续处理节点。使用变量传递。在Dify里你可以把上一个节点的输出定义为变量然后在下游节点的Prompt中引用这就实现了Agent之间的消息传递。用Dify的最大优势是能实时看到每个节点的输入输出哪个环节出问题在界面上点开就能检查排查成本比写代码低很多。我甚至见过全无编程经验的运营同学用半天时间就在Dify上搭出一个能跑的多Agent客服机器人。4. 常见问题与排查技巧实录4.1 Agent之间上下文传递丢失这是我遇到最多的问题。某个Agent明明在上游已经生成了关键信息下游Agent却像失忆一样完全没用到。大多数情况下原因不是框架的问题而是你在Prompt里没有明确要求Agent使用前置上下文。比如writer节点里的Prompt如果只写了根据选题写文章它确实不一定会去看素材。解决办法是在Prompt里增加硬性约束比如你必须在文章正文中引用至少两条上面提供的素材不引用则任务失败。另一种做法是在下游节点增加前置信息核对环节让模型先复述一遍收到的重要信息确认无误后再继续。4.2 智能体对话陷入死循环在自由对话式的多智能体系统特别是AutoGen那种风格中两个Agent经常会出现A让B做事B反问AA又让B做事的死循环白白消耗API费用。解决思路有两个层面。第一层在Prompt里约定如果无法推进任务请输出FINAL_ANSWER并总结当前结论让Agent有主动终止的能力。第二层在系统层面设置兜底逻辑——就像我在LangGraph代码里加的那个审核次数上限一样给循环设置硬性阈值。我见过有人给每个Agent的对话轮次设上限为3轮超过就强制走人工介入节点这套机制在极端场景下很管用。4.3 API调用费用超出预期多智能体系统的Token消耗往往比单Agent调用高出一个数量级。因为光是每轮Agent之间传递上下文把前序结果塞进Prompt就会产生大量输入Token。我有一套控制成本的心法一是为不同环节选择不同规格的模型。复杂推理比如任务分发、审核用能力强的模型简单执行比如素材格式化用便宜的小模型整体成本能下降约40%。二是控制传给每个Agent的上下文长度。不是所有历史信息都要一股脑塞进去可以只传结论而不是全文——比如素材采集Agent返回给writer的不是原始素材的8000字而是经过提炼的500字要点。三是给每个Agent设置预算上限。在调用层做一个简单的计数器当某个Agent的累计消耗超过设定阈值时自动将其降级到更小的模型或终止任务。4.4 输出格式不稳定让大模型输出JSON的时候偶尔会出现格式错误进而导致下游节点解析失败。这个问题在多Agent系统中会沿链路放大一个节点解析失败整条流水线都停摆。我的解决套路有三层第一层是Prompt约束明确告诉模型只输出JSON不要输出任何其他文字。第二层是结构化输出LangChain和LangGraph都内置了with_structured_output方法直接指定一个Pydantic模型让框架去保证输出结构而不是靠模型自觉。第三层是异常兜底在解析JSON的地方包一层try/except解析失败时返回一个预设的默认结构并记录日志让流程不至于直接崩掉。4.5 平台选型后的平滑迁移最后聊聊一个经常被忽视的问题现在用Dify搭得爽后面发现满足不了需求要迁到LangGraph怎么办我的建议是在Dify里做验证的时候就要注意平台无关性设计把Agent的Prompt、工具定义、知识库内容尽量结构化地管理不要散落在界面各处。Dify本身支持导出工作流配置迁移时可以先把Agent节点和Prompt整理成文档再按照目标框架的规范重新实现。虽然做不到一键迁移但系统化的Prompt管理能让你少花一半的迁移时间。我在实际迁移过几次项目后现在的习惯是在初期验证阶段就会写好一套跟平台无关的Agent角色说明书里面定义清楚每个Agent的目标、输入、输出、约束和审核标准。不管换到哪个平台这套说明书都能直接用唯一变的只是配置方式。5. 我的结论与选型心法多智能体协作平台的搭建本质上是一个组织设计问题而不是单纯的技术选型问题。在动工之前一定要先想清楚业务链路够不够清晰、团队有没有维护能力、系统需要多强的可控性这些问题的答案直接指向最终的平台选择。如果再有人问我到底用什么平台搭建我会先反问三个问题你任务流程是固定还是动态团队有没有后端开发能力你准备在这个系统上投入多久的维护周期回答完这三个问题答案基本自己就浮现了——快速验证和小团队落地选Dify精细控制和复杂流程选LangGraph纯对话探索选AutoGen快速原型验证选CrewAI。我个人在项目中的习惯是两条腿走路业务部门用Dify快速搭建验证场景技术团队用LangGraph做需要深度定制的生产级系统。两套体系之间共享同一份Agent角色定义和Prompt资产既能保证业务迭代速度又能保证最终系统的稳定性和可控性。这套打法目前在我们的项目里跑得很顺你可以参考这个思路根据自己的实际情况调整。最后再分享一个细节多智能体系统上线后一定要安排一个人定期去翻日志。不是看有没有报错而是观察Agent之间的对话是不是在高效推进任务有没有出现无效沟通。我发现过不止一次系统运行稳定、没有报错但Agent输出的内容却慢慢偏了方向原因就是Prompt描述和实际业务目标之间出现了隐性偏差。定期复盘Agent的决策过程比写一万行代码都管用。这一点是你在任何平台的说明文档里都看不到的。 多智能体协作平台选型与实践：从LangGraph到Dify的完整指南
最近不少人在问多智能体协作到底用什么平台搭这个问题我前前后后折腾了小半年踩过的坑比吃过的饭还多。从最早用纯代码手写工作流到后来试LangGraph、AutoGen、CrewAI再到Dify这类可视化平台基本上主流的方案都过了一遍。先说结论没有绝对最好的平台只有最匹配你场景的方案但选错平台的代价非常大轻则返工重写重则整个架构推倒重来。这篇文章我不打算讲太多天花乱坠的理论就围绕多智能体协作平台搭建这件事把我在实际项目中踩过的坑、验证过的选型思路、以及可直接抄作业的搭建过程全部摊开来讲。适合正在做AI应用落地、想搭建多智能体系统但还在纠结技术选型的开发者也适合已经在用某个框架但想对比其他方案的团队。1. 多智能体协作平台搭建前先搞清楚你到底在选什么1.1 多智能体系统不是多个大模型API的拼接很多人一听多智能体协作第一反应是不就是调好几个大模型的接口吗这个理解偏差是后续所有问题的根源。真实的多智能体协作系统核心难点在于协作两个字而不是智能体本身。我举个例子你让三个Agent分别扮演市场调研、文案撰写、视觉设计目标是产出一张宣传海报。如果只是分别调用三次大模型API你拿到的是三段孤立的输出市场调研的结果不会自动传给文案文案写的文案视觉设计根本看不到。真正的多智能体协作需要解决三个层面问题任务编排层谁先干活谁后干活哪些活可以并行哪些活必须等前置结果通信与状态层智能体之间怎么传递消息共享的状态存在哪里如何避免互相覆盖决策与路由层当前任务应该交给哪个智能体处理处理不了的时候如何升级或者回退所以搭建平台的时候你选的不只是调用大模型的工具而是一个能承载任务流转、状态管理、智能决策的运行时框架。1.2 用公司协作来理解多智能体平台的本质我自己跟别人解释多智能体协作平台时最喜欢用的一个类比是开一家公司。单一智能体相当于你雇了一个全能员工。你给他下指令他干完活把结果交给你。简单但一个人能力有限。多智能体协作系统相当于你开了一家公司。有CEO负责拆解目标有产品经理负责整理需求有工程师负责执行有测试负责质检。大家各司其职通过会议消息传递、文档共享状态、流程任务编排来协同。平台搭建的本质就是设计这家公司的组织架构和办公流程。有的平台像扁平化小团队所有Agent地位平等通过聊天互相协调比如AutoGen有的平台像科层制大公司有严格的主管和汇报关系比如LangGraph的图结构还有的平台像外包公司你只需要描述需求平台自动帮你组团队比如CrewAI的流程模式。想清楚你的业务场景更像哪种公司形态选型思路一下子就清晰了。这也是为什么我一再强调不要一上来就问哪个平台最强先问自己我的业务需要什么样的协作模式。1.3 平台搭建前的三个关键评估维度在我尝试过这么多方案之后总结出三个必须在动手前评估清楚的维度这三个维度直接决定你后面会不会返工第一业务过程的确定性。你的任务流程是固定不变的比如固定的采集→分析→生成报告三步走还是高度动态的AI需要自己决定下一步干什么流程固定优先考虑Dify这类可视化工作流平台流程动态、需要智能体自主决策那LangGraph这类图编排框架更合适。第二团队的维护能力。你们团队是纯业务背景、只想快速出效果还是有一批能写代码的工程师、愿意长期维护前者选低代码平台后者选代码框架。第三对可观测性的要求。多智能体系统最大的噩梦是不知道哪里出了问题。两个Agent来回对话八轮最终结果偏了到底是哪个环节理解错了这就需要在选型时特别关注平台提供的日志追踪、链路监控能力。这一点我后面会单独讲。2. 主流的几类多智能体协作平台到底怎么选2.1 代码框架类LangGraph、AutoGen、CrewAI我在项目里实际用过这三种代码框架说说我最真实的体感。LangGraph是我目前的主力选择。它的核心模型是图节点就是智能体要执行的动作边就是状态流转的方向。你可以非常精细地控制流程包括条件分支、循环、人工介入节点几乎能做到只要你想得到没有画不出来的流程。代价是学习曲线比较抖你需要理解State、Node、Edge、Checkpoint这些概念。AutoGen是微软出品的它的核心思路是对话驱动。多个Agent坐在一起通过自然语言对话来协作你可以设定对话的轮数上限、终止条件。它最出彩的地方是支持人机混合协作人可以在对话流里随时插一脚。但对于复杂业务流程纯靠对话驱动会有点飘容易出现对话发散、聊偏题的情况。CrewAI主打的是角色扮演任务委派概念非常直观你定义一个个带角色描述的Agent比如资深数据分析师文案达人然后定义Task再用Process把他们串起来。它的代码量非常少几乎可以用声明式的方式搭出一个小团队。我用CrewAI做过一个自动生成周报的Demo从零到跑通只用了不到两个小时。这三个框架之间的关系我建议这么理解AutoGen适合做自由讨论型任务CrewAI适合做快速原型和任务固定的场景LangGraph适合做生产级复杂流程的落地。2.2 可视化平台类Dify、FastGPT这类低代码方案如果你的团队里没有太多资深后端工程师又想在几天内看到一个能跑的多智能体应用那我强烈建议先看看Dify这类低代码平台。Dify目前的Agent编排能力已经相当成熟你可以在界面上拖拽出多个Agent节点配置每个人的Prompt、模型参数、工具调用权限再通过连线定义它们的上下游关系。它内置了知识库、工具调用、变量记忆、日志追踪这些模块省去了很多从零造轮子的工作。我用Dify给一个客户快速搭过一个售前客服售后技术支持的双Agent系统。售前Agent负责解答产品规格和报价问题一旦判定用户需要售后支持就把会话上下文透传给售后Agent售后Agent再带着用户的历史诉求继续处理。整个搭建过程全程界面操作没写一行后端代码。但低代码平台也有天花板一是复杂逻辑比如多层嵌套的循环、需要动态创建Agent实例在可视化界面上表达起来很吃力二是当你需要深度定制比如自定义Agent的推理策略、改写底层状态管理逻辑时平台不一定给你开口子。我的经验是快速验证、MVP阶段用低代码平台真正追求控制力和复杂度上限时回到代码框架。2.3 为什么我不建议完全从零手写一个编排平台还有一个常见的问题是我能不能不用这些框架自己写一套多智能体协作的平台。技术上当然可以我自己早期也这么干过但我用血泪教训告诉你如果不是搞科研或者锻炼架构能力千万不要。多智能体的编排看着简单实际要实现的东西很多消息路由、状态管理、重试机制、上下文窗口管理、模型调用限流、日志追踪、人工审核节点、异常恢复……这些每一项单独拎出来工作量不大合在一起就是一个中大型中间件项目。更麻烦的是多智能体系统有大量不可控的部分。模型返回的JSON格式偶尔会坏、Agent对话偶尔会陷入死循环、某一个子任务超时导致整个流程挂起。这些边界情况成熟的框架比如LangGraph和Dify已经帮你处理掉大半了而自己开发的框架遇到这些问题时只能一个一个填坑。因此我更推荐的做法是站在框架的肩膀上搭建但深入理解框架的底层机制。这样既有框架的稳定性又能在需要的时候对关键环节做手术。2.4 选型决策参考表我把几个主流方案的对比整理成了表格方便你根据自己的实际情况快速判断方案上手难度编排灵活性可视化支持生产可用性适合场景LangGraph中高高一般高复杂业务流程、需要精细控制AutoGen中中低中高对话式协作、人机混合CrewAI低中低中快速原型、任务流固定的场景Dify低中高高快速落地、非技术团队运维自研框架很高最高需自建视投入而定科研探索、极端定制需求切记这个表不是哪个分高选哪个而是匹配你的真实约束。公司里没有专职AI工程师那LangGraph的灵活性优势根本发挥不出来反而是Dify能让你当晚就上线。3. 实操详解手把手搭一个多Agent协作系统3.1 一个可落地的Demo内容营销智能体集群理论说得再多不如跑一个实际项目。我下面用LangGraph为例带大家搭建一个内容营销智能体集群用来演示多智能体协作的完整链路。选LangGraph不是因为它最完美而是因为我们这次任务的流程有明确分工、有条件分支、有并行处理还要支持后期维护调试这套需求正好是LangGraph的强项。先看这个系统的业务逻辑任务入口Agent项目经理接收用户原始需求判断任务类型决定调用哪个后续Agent选题策划Agent内容策略师根据需求产出一个内容选题素材采集Agent资料员围绕选题搜集关键信息、数据支撑文案生成Agent写手基于选题和素材生成文章初稿审核优化Agent主编对初稿进行质量审查如果质量不达标打回给文案Agent修改最多循环三次整个系统涉及条件分支任务类型判断、并行素材采集可以同时抓多个来源、循环审核打回修改是一个很典型的多智能体编排场景。3.2 环境准备与节点定义首先安装LangGraph建议在虚拟环境里操作pip install langgraph langchain langchain-openai然后定义系统的基础配置。注意这里我会把大模型的接入方式统一封装好方便后续切换不同模型服务。from typing import TypedDict, Annotated, Literal from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI # 定义Agent的共享状态结构 class AgentState(TypedDict): user_request: str # 用户原始需求 task_type: str # 任务类型 topic: str # 选题 materials: list # 素材列表 draft: str # 初稿 review_comment: str # 审核意见 review_count: int # 审核轮次 # 统一模型封装方便替换 def get_llm(temperature0.3): return ChatOpenAI( modelgpt-4o, temperaturetemperature, )提示在实际项目里建议把模型名、API Key、温度参数都统一放到配置文件里。我一开始图省事直接写死在代码中后来想换另一个模型服务时找参数找了半天非常狼狈。State是LangGraph里最核心的概念之一。你可以把它理解成整个团队共用的共享文档每个Agent在执行完自己的任务后把结果更新到这个文档里下一个Agent再读取。上面代码里定义的AgentState里topic、draft这些字段就是各个Agent之间协作的信息载体。3.3 实现五个Agent节点接下来我们逐个定义Agent节点函数。每个节点做的事本质上就是读State里需要的数据调用大模型把结果写回State。先来看任务入口Agent它负责判断任务类型为后面的流程分支提供依据。def entry_node(state: AgentState): 任务入口判断内容类型 llm get_llm(0.1) prompt f 你是内容项目管理经理。用户的需求是{state[user_request]} 请判断这个需求属于以下哪种内容类型技术教程、产品宣传、行业分析。 只输出一个类型词不要输出其他内容。 task_type llm.invoke(prompt).content.strip() return {task_type: task_type}这个节点我用了较低的温度参数0.1因为任务分类希望输出尽量稳定可控。这里一个容易被忽视的细节是Prompt里必须明确只输出一个类型词否则模型容易回答一大段废话影响后面节点对task_type字段的解析。然后是选题策划Agentdef topic_node(state: AgentState): 根据任务类型生成选题 llm get_llm(0.5) prompt f 你是资深内容策划。用户需求{state[user_request]} 内容类型{state[task_type]} 请给出一个具体可执行的选题名称30字以内。 topic llm.invoke(prompt).content.strip() return {topic: topic}素材采集Agent这里我为了演示并行执行把它拆成了两个节点分别从内部知识库和技术文档/新闻资料两个方向采集素材。LangGraph支持多个节点并行执行只要它们之间没有依赖关系def material_fetch_a(state: AgentState): 素材采集节点A内部数据 # 实际项目中这里你会调用知识库检索接口或数据库查询 llm get_llm(0.3) prompt f 你是资料员。围绕选题 {state[topic]}从内部数据视角搜集2-3条关键支撑信息。 以列表形式输出。 materials llm.invoke(prompt).content.strip() return {materials: [materials]} def material_fetch_b(state: AgentState): 素材采集节点B外部资料 # 实际项目中这里可以调用搜索API、爬虫服务或第三方数据接口 llm get_llm(0.3) prompt f 你是资料员。围绕选题 {state[topic]}从公开技术文档与行业新闻视角搜集2-3条关键支撑信息。 以列表形式输出。 materials llm.invoke(prompt).content.strip() return {materials: [materials]}这里需要强调一个LangGraph的合并规则如果两个并行节点都往同一个字段materials里写入内容默认情况下是覆盖而不是拼接。所以我在AgentState里把materials定义成list但并行节点返回的又都是字符串实际开发中需要写一个自定义的reducer函数来控制合并逻辑。这是LangGraph新手最容易踩的坑之一。文案生成Agent它会读取选题和两个素材来源的内容综合起来写初稿def writer_node(state: AgentState): 文案生成 llm get_llm(0.7) materials_text \n.join(state.get(materials, [])) prompt f 你是专业内容写手。 选题{state[topic]} 可用素材 {materials_text} 请基于上述素材撰写一篇结构完整的文章初稿。要求 1. 开头有引入 2. 中间有至少三个核心分段 3. 结尾有总结 直接输出正文。 draft llm.invoke(prompt).content.strip() return {draft: draft}最后是审核优化Agent这个节点是整个多智能体系统里最体现协作精髓的地方——它可以根据审核结果决定流程是走END结束还是打回给writer节点重新生成def reviewer_node(state: AgentState): 主编审核决定是否打回 llm get_llm(0.2) prompt f 你是严格的主编。阅读下面的文章初稿 {state[draft]} 从以下三个维度打分每个维度10分制 1. 结构完整性 2. 信息准确性 3. 可读性 如果平均分低于7分输出PASS:NO并给出修改意见。 如果平均分达到7分及以上输出PASS:YES。 result llm.invoke(prompt).content.strip() if PASS:YES in result: return {review_comment: 通过, review_count: state.get(review_count, 0) 1} else: return { review_comment: result, draft: , # 打回时清空草稿让写手重写 review_count: state.get(review_count, 0) 1, }这里需要特别注意我在打回时把draft字段清空了这是一个防止上下文污染的小技巧。如果不清空writer节点二次生成时会看到自己上次写的内容容易在原有思路上打转很难跳出原来的框架而清空后重新生成反而更容易产出不同质量的稿件。3.4 装配流程图与运行调试节点都定义好之后接下来就是把它们串成一张图。LangGraph的核心思想就是把节点和边组合成一张可执行的图边的定义方式决定了流程的分支和循环逻辑。from langgraph.graph import StateGraph, END graph StateGraph(AgentState) # 添加所有节点 graph.add_node(entry, entry_node) graph.add_node(topic, topic_node) graph.add_node(material_a, material_fetch_a) graph.add_node(material_b, material_fetch_b) graph.add_node(writer, writer_node) graph.add_node(reviewer, reviewer_node) # 定义入口和主线 graph.set_entry_point(entry) graph.add_edge(entry, topic) # 从选题节点并行分发给两个素材节点 graph.add_edge(topic, material_a) graph.add_edge(topic, material_b) # 两个素材节点都完成后汇聚到writer graph.add_edge(material_a, writer) graph.add_edge(material_b, writer) # writer写完后进入reviewer审核 graph.add_edge(writer, reviewer) # 审核结果的循环与退出逻辑 graph.add_conditional_edges( reviewer, lambda state: rewrite if state.get(review_count, 0) 3 and state.get(draft) else end, { rewrite: writer, end: END, } )这段代码里最关键的是最后这个add_conditional_edges。它就是一个智能路由如果审核没过review_count小于3且draft被清空了就回到writer节点重写如果审核通过或者达到最大重写次数就走向END结束。这里我限制了最多打回三次防止模型无限循环。你可能会问为什么不放到五次或者十次根据我的经验大模型重写在前两次往往质量提升明显但从第三次开始修改幅度会变得很小基本是为了改而改所以设置三次是一个性价比比较高的平衡点。图装配好之后用下面的代码编译并运行app graph.compile() def run_agent_cluster(user_request: str): result app.invoke({user_request: user_request, materials: [], review_count: 0}) return result # 测试运行 output run_agent_cluster(写一篇介绍RAG技术在企业落地的文章) print(output[topic]) print(output[draft]) print(output[review_comment])第一次跑通这个系统的时候你会明显感受到它与单Agent的本质差异不是一次调用就出结果而是经历了项目立项→策划→双线搜集素材→撰写→审核→可能打回重写的完整流水线。每个环节都有专门的Agent负责整体输出的文章质量比一个Agent单打独斗高出不少。3.5 Dify可视化搭建的对照方案如果你不想写代码也可以用Dify完成类似的事情这里给出界面操作的对照流程方便没有编程基础的读者参考。在Dify的工作流画布上创建多个Agent节点。以内容营销智能体集群为例先创建任务分发Agent在它的Prompt里写明职责是判断内容类型。为每个Agent节点单独配置模型。注意不同节点的模型参数可以不同任务分发用低温度文案生成用稍高温度。画出连线。从开始节点连到任务分发Agent然后根据Agenter的输出内容类型设置分支条件Dify里叫条件分支把不同内容类型路由到不同的后续处理节点。使用变量传递。在Dify里你可以把上一个节点的输出定义为变量然后在下游节点的Prompt中引用这就实现了Agent之间的消息传递。用Dify的最大优势是能实时看到每个节点的输入输出哪个环节出问题在界面上点开就能检查排查成本比写代码低很多。我甚至见过全无编程经验的运营同学用半天时间就在Dify上搭出一个能跑的多Agent客服机器人。4. 常见问题与排查技巧实录4.1 Agent之间上下文传递丢失这是我遇到最多的问题。某个Agent明明在上游已经生成了关键信息下游Agent却像失忆一样完全没用到。大多数情况下原因不是框架的问题而是你在Prompt里没有明确要求Agent使用前置上下文。比如writer节点里的Prompt如果只写了根据选题写文章它确实不一定会去看素材。解决办法是在Prompt里增加硬性约束比如你必须在文章正文中引用至少两条上面提供的素材不引用则任务失败。另一种做法是在下游节点增加前置信息核对环节让模型先复述一遍收到的重要信息确认无误后再继续。4.2 智能体对话陷入死循环在自由对话式的多智能体系统特别是AutoGen那种风格中两个Agent经常会出现A让B做事B反问AA又让B做事的死循环白白消耗API费用。解决思路有两个层面。第一层在Prompt里约定如果无法推进任务请输出FINAL_ANSWER并总结当前结论让Agent有主动终止的能力。第二层在系统层面设置兜底逻辑——就像我在LangGraph代码里加的那个审核次数上限一样给循环设置硬性阈值。我见过有人给每个Agent的对话轮次设上限为3轮超过就强制走人工介入节点这套机制在极端场景下很管用。4.3 API调用费用超出预期多智能体系统的Token消耗往往比单Agent调用高出一个数量级。因为光是每轮Agent之间传递上下文把前序结果塞进Prompt就会产生大量输入Token。我有一套控制成本的心法一是为不同环节选择不同规格的模型。复杂推理比如任务分发、审核用能力强的模型简单执行比如素材格式化用便宜的小模型整体成本能下降约40%。二是控制传给每个Agent的上下文长度。不是所有历史信息都要一股脑塞进去可以只传结论而不是全文——比如素材采集Agent返回给writer的不是原始素材的8000字而是经过提炼的500字要点。三是给每个Agent设置预算上限。在调用层做一个简单的计数器当某个Agent的累计消耗超过设定阈值时自动将其降级到更小的模型或终止任务。4.4 输出格式不稳定让大模型输出JSON的时候偶尔会出现格式错误进而导致下游节点解析失败。这个问题在多Agent系统中会沿链路放大一个节点解析失败整条流水线都停摆。我的解决套路有三层第一层是Prompt约束明确告诉模型只输出JSON不要输出任何其他文字。第二层是结构化输出LangChain和LangGraph都内置了with_structured_output方法直接指定一个Pydantic模型让框架去保证输出结构而不是靠模型自觉。第三层是异常兜底在解析JSON的地方包一层try/except解析失败时返回一个预设的默认结构并记录日志让流程不至于直接崩掉。4.5 平台选型后的平滑迁移最后聊聊一个经常被忽视的问题现在用Dify搭得爽后面发现满足不了需求要迁到LangGraph怎么办我的建议是在Dify里做验证的时候就要注意平台无关性设计把Agent的Prompt、工具定义、知识库内容尽量结构化地管理不要散落在界面各处。Dify本身支持导出工作流配置迁移时可以先把Agent节点和Prompt整理成文档再按照目标框架的规范重新实现。虽然做不到一键迁移但系统化的Prompt管理能让你少花一半的迁移时间。我在实际迁移过几次项目后现在的习惯是在初期验证阶段就会写好一套跟平台无关的Agent角色说明书里面定义清楚每个Agent的目标、输入、输出、约束和审核标准。不管换到哪个平台这套说明书都能直接用唯一变的只是配置方式。5. 我的结论与选型心法多智能体协作平台的搭建本质上是一个组织设计问题而不是单纯的技术选型问题。在动工之前一定要先想清楚业务链路够不够清晰、团队有没有维护能力、系统需要多强的可控性这些问题的答案直接指向最终的平台选择。如果再有人问我到底用什么平台搭建我会先反问三个问题你任务流程是固定还是动态团队有没有后端开发能力你准备在这个系统上投入多久的维护周期回答完这三个问题答案基本自己就浮现了——快速验证和小团队落地选Dify精细控制和复杂流程选LangGraph纯对话探索选AutoGen快速原型验证选CrewAI。我个人在项目中的习惯是两条腿走路业务部门用Dify快速搭建验证场景技术团队用LangGraph做需要深度定制的生产级系统。两套体系之间共享同一份Agent角色定义和Prompt资产既能保证业务迭代速度又能保证最终系统的稳定性和可控性。这套打法目前在我们的项目里跑得很顺你可以参考这个思路根据自己的实际情况调整。最后再分享一个细节多智能体系统上线后一定要安排一个人定期去翻日志。不是看有没有报错而是观察Agent之间的对话是不是在高效推进任务有没有出现无效沟通。我发现过不止一次系统运行稳定、没有报错但Agent输出的内容却慢慢偏了方向原因就是Prompt描述和实际业务目标之间出现了隐性偏差。定期复盘Agent的决策过程比写一万行代码都管用。这一点是你在任何平台的说明文档里都看不到的。