先说一个我这两年特别深的感触一听到多智能体协作用什么平台搭建这个问题我就知道提问者大概率还没把多智能体这四个字背后的东西想清楚。我自己刚接触这块时也是这个状态GitHub上收藏了十来个号称能编排多智能体的项目结果装完Demo跑通之后一问你的业务场景里到底要几个Agent、它们之间是什么协作关系瞬间就答不上来了。所以这篇文章我不打算直接甩一个用某某平台就对了的结论。我会把主流的框架和应用层平台都盘一遍再结合我实际搭过的项目聊聊选平台之前必须先搞清楚的事、真正决定选型的几个硬指标以及第一次落地时最容易踩的坑。无论你是有编程基础的开发者还是想用现成工具把业务跑起来的同学应该都能从里面找到能直接用的判断方法。1. 先别急着选平台把你的多智能体场景翻译成协作模式很多项目死得早不是因为平台选错了而是因为需求根本没定义清楚。多智能体协作不是把多个Prompt拼接在一起就完事它是一种架构设计。你先得想明白你的场景里为什么需要多个智能体它们之间是流水线关系、上下级关系还是平级讨论关系1.1 单智能体做不了才轮到多智能体上场我判断一个项目要不要上多智能体标准其实很朴素一个Agent手里攥着所有工具和上下文是不是已经解决不了了举个例子我之前接过一个企业内部知识库问答的活儿。最初方案很简单一个Agent接上向量检索工具用户提问Agent检索文档组织答案完事。但跑了一段时间发现三个问题第一不同部门文档的访问权限不一样人事的薪资制度不能给实习生看到第二回答技术问题时需要同时查代码仓库和内部Wiki两边的信息格式差异很大第三领导希望最终的答案能自动带上信息来源依据方便追溯。这些问题堆到一个Agent身上Prompt会变得极其臃肿工具列表也越挂越多最后模型经常该调A工具的时候调了B。拆成多智能体就很自然了一个权限管理Agent专门负责判断这个用户能不能看这批文档一个技术问答Agent只挂代码检索和Wiki工具一个法务合规Agent负责审核输出的答案里有没有敏感表述。每个Agent职责单一工具数量少Prompt也不臃肿整体效果反而更稳。反过来如果你的需求就是帮我总结一下这篇PDF一个Agent加一个文档解析工具足够了强行拆三个Agent属于给自己找罪受。多智能体是有成本的——调试难度指数级上升Token消耗成倍增长任何一个环节出问题都要从头查链路。你得让收益明显大于成本才值得上。1.2 你的业务场景对应哪种协作模式平台能力必须匹配我习惯把多智能体的协作模式粗分成三种每种对平台的要求不太一样。第一种叫管线式就是数据流依次经过多个Agent前一个Agent的输出直接作为后一个Agent的输入。典型场景比如编辑Agent先产出初稿校对Agent再检查错别字SEO Agent最后补关键词。这种模式最简单很多工作流引擎就能支持。第二种叫编排式有一个主控Agent负责拆解任务、调度其他Agent执行然后收集结果做最终汇总。注意这里的主控Agent不一定要比执行Agent更聪明它更像一个项目经理关键是具备任务规划和结果整合的能力。这种模式对平台的要求就高了因为主控Agent需要动态决定把任务分给谁这意味着平台要支持条件分支、循环、动态路由这些机制。第三种叫协商式多个Agent地位平等围绕一个目标通过多轮对话来得出结论。典型场景是红蓝对抗——一个Agent负责生成方案另一个Agent负责挑毛病来回几个回合后收敛出一个更可靠的版本。这种模式对平台的会话管理能力要求最高你得能控制对话的轮数上限、能处理Agent之间吵起来的情况。很多新人上来就买了一个编排式平台结果自己的业务明明是管线式就够用了白白增加了一堆配置成本。所以选平台第一步是先拿张纸把自己的场景标注出来我的系统需要几个Agent它们之间是哪种协作关系有没有动态调度的需求这个动作能帮你过滤掉一半不合适的平台。2. 主流平台盘点框架层和应用层的选择逻辑市面上的多智能体平台如果按抽象层级来分基本就是两大阵营一个是代码框架一个是应用平台。我见过太多人在这上面吃闷亏——明明不会写代码非要玩框架明明需要深度定制却选了个只能拖拽的平台最后被各种限制卡得死死的。2.1 框架层选手AutoGen、LangGraph、CrewAI、AgentScope框架层的共同特点是你得写代码但换来的是极大的自由度。这里我挑四个有代表性的从构建机制上对比一下。AutoGen是微软出的它的核心抽象是ConversableAgent两个Agent之间可以直接对话也可以让一个Manager Agent去协调多个Agent。它还支持群聊GroupChat你可以把多个Agent拉到一个群聊里有一个GroupChatManager来把控节奏。我最喜欢的是它的代码执行能力——Agent可以自动写Python代码并执行然后读取执行结果继续推理。这对处理数据分析、数学计算类的任务特别有用。但缺点是随着Agent数量增多对话轮次的Token开销会变得非常大而且调试时很难一眼看清这个Agent现在到底处于什么状态。LangGraph则是把整个多智能体系统当成一张图——节点是Agent或工具边是状态转移。你可以精确控制什么时候从A节点跳到B节点是否有循环是否有条件分支。它跟LangChain生态无缝衔接如果你已经用惯了LangChain理论上手成本很低。它的优势在于可控性和状态管理非常出色每一步都有明确的状态对象日志也清晰。但门槛也在这你必须用图的方式去思考问题连一个简单的顺序执行也得定义节点和边前期开发效率不算高。CrewAI是我目前见过把上手成本压得最低的框架之一。它引入了Role角色、Goal目标、Backstory背景故事这三个概念你定义好这些再定义Tasks和Process顺序执行或层级执行一套多Agent系统就搭起来了。它的名字起得也很贴切Crew是剧组的意思——每个Agent像剧组里的一个工种各自负责一块。适合快速原型验证和中小规模项目但深度定制能力不如LangGraph。AgentScope是阿里开源的一个分布式多智能体平台。它在消息通信层做了大量性能优化支持并行调度和分布式部署适合需要大规模Agent并发运行的场景。如果你要做的系统里Agent数量超过几十个而且对响应延迟有要求可以重点看看它。但它的社区生态相比前几个还是弱了一些能找到的中文参考资料有限。2.2 应用层选手Dify、FastGPT 这类可视化平台应用层平台最大的特点就是少写代码甚至不写代码。它们通常提供可视化的编排界面你拖拽节点、配置参数、连接工具就能搭出一个AI应用。Dify在这几年很火它的核心是Pipeline类型的工作流编排以及可以单独配置的Agent节点。你可以在工作流里放一个需求分析Agent节点节点的System Prompt定义好角色然后把它输出的变量传给下一个方案生成Agent节点。这种搭法本质上是把多个Agent节点通过工作流串联起来虽然协作模式上比较偏管线式但对于大多数业务场景已经够用了。FastGPT的思路类似它的知识库问答和多Agent编排也比较成熟。应用层的优势非常明显第一有界面配置了什么一清二楚老板和业务同事也能看懂第二内置了用户管理、权限、API发布、日志审计这些工程化能力不用自己造轮子第三大部分平台支持OpenAI、Claude、本地模型等多种模型接入不会被单一模型锁死。缺点也很要命灵活度有限。你很难在平台里实现非常复杂的动态编排和协商式多Agent协作一旦业务逻辑超出平台预设的节点类型就只能通过写自定义代码节点去绕绕来绕去反而比直接用框架更痛苦。2.3 一张表看清框架层和应用层的核心差异对比维度框架层AutoGen / LangGraph / CrewAI应用层Dify / FastGPT使用门槛需要写Python代码懂状态管理可视化编排配置为主协作模式支持管线、编排、协商都能做自由度极高管线式和部分编排模式最顺手调试体验强能读完整日志但需自己搭监控平台自带面板直观但粒度有限部署方式嵌入你自己的服务通常以独立服务方式部署并暴露API适合人群懂技术的开发团队需要深度定制产品和业务主导的团队快速落地典型场景复杂研究助手、自动化流程引擎、多智体辩论系统企业知识库问答、内容生成流水线、客服辅助二次开发成本低代码就是你的边界高遇到平台限制时比较难绕看到这里你应该发现了所谓用什么平台搭建本质上是一个从项目阶段和团队能力出发的选择题你要的是快速验证业务流程还是做一个长期演进的深度系统这两条路对应的是完全不同的平台生态。3. 选型真正看重的三个硬指标很多人在社区里对比平台时翻来覆去只看支持多少种模型能不能连数据库界面好不好看。这些当然重要但我实际用了大半年之后发现真正能决定项目生死的是另外三件事状态管理、可观测性、人工介入机制。平台只要有任何一个短板后面都会变成持续的折磨。3.1 状态管理能力决定了你的Agent协作是否记性好多智能体系统本质上是一个多轮信息交换系统。Agent A生成的结论Agent B要能基于这个结论继续做推理这里的结论如何存储、传递、更新就是状态管理要解决的问题。使用框架时你通常需要自己定义状态对象。比如LangGraph里的State你要明确哪些字段是节点间共享的哪些是节点私有的AutoGen里的对话历史就是一种隐性的状态但历史一长就会超过上下文窗口。使用应用平台时状态管理往往体现为变量系统——Dify里你可以设置一个全局变量Agent节点读它、写入它、传给下一个节点。我在实际中踩过的一个典型场景是一个多Agent内容生成系统客服Agent先确认用户意图销售Agent再推荐产品方案售后Agent最后输出保障说明。三个Agent之间的共享信息不仅包括用户原始问题还包括客服Agent的判断结果销售Agent推荐的产品ID。如果状态设计不好销售Agent就只知道用户问了一句话完全不知道客服已经判断出用户是高意向客户推荐自然很敷衍。所以选平台时我会重点看它的状态管理和变量传递是否显式清晰。隐式靠对话历史传递的方案短期能跑但Agent一多必乱。3.2 可观测性不在于能看日志而在于能不能还原链路的每一步多智能体系统的一大噩梦是结果错了但你不知道是哪一步错的。用户说你推荐的方案不合适到底是你意图理解错了、检索结果不对、还是生成最终方案时把信息给漏了没有可观测性的话整个排查过程就是瞎猜。可观测性不只是看日志。我理想中的多智能体可观测平台至少要能回答这四类问题用户消息进来之后路由到了哪个Agent这个Agent当时使用的System Prompt和工具列表是什么Agent调用了哪些工具每个工具返回了什么内容两个Agent之间传递的中间变量最终的值是什么框架层的方案一般需要自己接LangSmith这类工具来做trace追踪Dify这类平台本身就带详细的日志面板能看到每一个节点的输入输出。这也是我为什么建议非深度定制需求尽量用应用层平台——省下的可观测性搭建成本真不是一点半点。3.3 人工介入机制不是可选项是安全网多智能体系统跑在业务里迟早会遇到Agent自作主张的情况。可能是调了一个不该调的外部API也可能是给用户承诺了一个不存在的功能。所以平台必须提供可靠的人在环上Human-in-the-loop机制。这里说的不是简单加一个审批按钮而是要满足三个条件第一干预必须发生在执行过程中而不是事后看日志第二干预的粒度要细我能中断整个流程也能只修改某个Agent的中间输出然后放行第三要有审计能力谁在什么时间改了什么都能追溯。框架层里LangGraph对这一点支持得比较好你可以在图的某个节点上设置interrupt让流程暂停等待人工输入然后恢复执行。AutoGen也提供了用户代理UserProxyAgent的概念可以在关键时刻询问人类。应用层方面Dify在部分版本中加入了对话流中的人工接管节点即对话暂停/转人工但我仍然建议你在选型时先做一个人工介入原型验证别等到上线了才发现平台不支持你需要的干预方式。4. 第一次搭建怎么落地用Dify快速跑一个协作Agent流程不管你是技术还是出身第一次上手多智能体我都建议先用一个可视化平台把业务跑通再说。这么做不是为了省事而是为了让你先把协作逻辑理解清楚后面再决定要不要迁到代码框架。下面我以Dify为例给你一套可以直接照做的搭建过程。4.1 环境准备用Docker Compose拉起Dify服务Dify支持Docker Compose一键部署这是最省心的方式。前提是你机器上已经装好了Docker和Docker Compose插件。git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d部署完成后浏览器访问http://localhost/install设置管理员账号然后进入控制台。这里有个很容易被忽略的细节进入控制台后第一件事不是创建应用而是先去设置里把模型供应商接好。因为Dify本身的模型调用逻辑是应用 - 模型供应商 - 外部模型API你可以同时接入多个供应商比如同时接OpenAI和一个国产大模型然后在每个Agent节点里单独指定用哪个模型。提示.env里的SECRET_KEY字段建议改成一段随机字符串否则部署在公网服务器上会有安全风险。另一个常见问题是服务器内存低于4GB时Dify的多个容器容易启动失败最好用3GB以上内存的机器。4.2 创建应用用两个Agent节点模拟需求分析 - 方案设计协作在Dify控制台新建应用时选择Chatflow类型。Chatflow的核心特点是它是面向对话场景的工作流可以在节点里灵活穿插LLM节点、Agent节点、条件分支节点。这里我们做一个智能IT需求受理助手Demo用两个Agent节点协作帮用户把一句模糊的需求转成一份初步的技术方案。第一个节点拖入一个Agent节点命名需求分析Agent。它的System Prompt我建议这么写你是一名资深的IT需求分析师。用户会提出一个模糊的业务需求你需要结合自己的经验将需求拆解为清晰的功能列表。输出格式严格为Markdown列表每一条必须包含功能名称、功能描述、优先级高/中/低。不要输出任何其他内容。关键一步来了在这个Agent节点的高级设置里你可以给它挂工具比如获取用户资料。挂工具的意义在于让这个Agent具备执行动作的能力而不仅仅是聊天。如果是演示环境不挂工具也可以让Agent纯靠Prompt拆解需求。第二个节点拖入Agent节点命名方案设计Agent。它的输入不是直接从用户消息来而是读取上一个Agent的输出。在Dify里节点输出会被放到变量中假设需求分析Agent的输出字段是analysis_result那么方案设计Agent的System Prompt里就可以这样引用你是解决方案架构师。请基于以下需求分析结果设计一个技术实现方案\n\n{{#analysis_result#}}\n\n输出要求给出整体架构描述、推荐技术栈、实施步骤和预计工时。这样两个Agent的协作关系就成型了第一个Agent负责把模糊需求变成规范列表第二个Agent在列表基础上做技术推演。你可以先运行一次输入一句我想给公司做一个内部二手物品交换平台看看两个Agent各自的产出质量。4.3 关键细节变量传递和节点分支让协作真正闭环两个Agent串起来只是最基础的多智能体形态。真正让它活起来的是变量引用和条件分支。Dify的变量系统允许你在节点之间传递对象。比如用户在对话开头说了一句话这句话会被存到sys.query这个系统变量里你在需求分析Agent的输入中引用{{#sys.query#}}它就能知道用户原始问题。你也可以在方案设计Agent之后接一个条件分支节点IF/ELSE节点判断上一个节点的输出里是否包含失败两个字如果包含就转给一个人工处理节点否则就正常输给用户。这个能力对应了我前面说的编排式协作——不是所有任务都走同一条路而是根据中间结果动态决定走向。我在Dify里做过的较复杂的项目里甚至有五个Agent节点用两条分支线串成一个图跑起来之后看起来就是一个完整的多智能体小系统。5. 搭建过程中的典型坑与排查思路平台选好了流程也通了但你大概率不会第一次就跑顺。这里我把平时遇到最多的三类坑拎出来每一个都附上我能落地的排查思路。5.1 Agent之间循环对话停不下来这个问题在AutoGen这类框架里最常见。两个Agent一个扮演提出者一个扮演评审者理论上互相迭代几轮就该收敛但实际可能无限聊下去。原因通常出在停止条件上你只设置了最大对话轮数但没告诉Agent什么时候算结束。我的排查链路是这样的第一先查GroupChat或对话循环的控制逻辑里有没有设置明确的停止策略第二观察是不是其中一个Agent在每一轮都会输出我同意你的方案然后还继续发言——如果是说明它的System Prompt里缺少如果你没有新的不同意见必须输出TERMINATE这类结束语标记第三在代码里限制最大迭代次数并在达到上限时强行截断用最后一条非终止消息作为结果。在Dify这类偏管线的平台里不容易出现完全停不下来但会出现无意义地重复处理。比如方案设计Agent的输出又传回给需求分析Agent做复核复核Agent如果找不到问题也会硬憋一条我检查过了没有问题白白浪费一次模型调用。解法是删除这类无实质价值的复核节点或者在复核Agent的Prompt里明确如果没有需要修改的问题直接输出原始方案内容。5.2 上下文被截断导致协作信息断裂多智能体系统里后面的Agent经常拿不到前面的关键信息并不是代码bug而是上下文窗口被填满了。最典型的情况是Agent A的输出特别长Agent B在接收时消息历史的Token数量超过了模型限制中间部分就被静默截断了。Agent B看到的是一个残缺的输入自然给出一个残缺的输出。我在做长文档多Agent总结系统时遇到过这个问题。三个Agent分别总结文档的三个章节汇总Agent负责合并结果合并Agent产出的文档总是缺了最后一章的结论。排查时我用Trace日志逐一查看Agent的输入Token数量发现三个章节原文加起来已经有4万多Token汇总Agent的模型是8K上下文前半部分内容在进入上下文窗口前就已经被截断了。解决办法有两个方向一个是用摘要Agent先把每个章节压缩成几百字的摘要再交给汇总Agent处理减小输入体积另一个是选择支持更长上下文的模型或者调整消息历史的剪裁策略。Dify的LLM节点里可以设置记忆窗口大小你要确保这个值和模型本身的上下文限制匹配最好留出30%缓冲因为Agent节点的工具调用过程本身也会消耗Token。5.3 工具权限过大导致安全失控多智能体系统里每个Agent挂的工具是对外暴露的执行能力。权限设计不好可能A一个Agent本来只能查天气改个Prompt就让它拿到了数据库里的所有用户信息。这里的关键是最小权限原则——每个Agent只挂它完成本职任务绝对需要的工具不要图省事把所有工具都挂到一个Agent上。我之前见过一个惨案某团队把所有API工具都挂在了客服Agent上包括内部库存管理系统、订单退款接口、会员等级修改接口。结果客服Agent被用户套话试图让模型绕过权限限制直接改会员等级。虽然平台的模型供应商本身会有一定安全对齐但这种设计等于把一个高危操作窗口暴露给了一个面向外部用户的Agent。我的建议是平台选型时重点看两点一是工具粒度是否够细能不能做到同一个Agent在A场景能用工具X、B场景不能用工具X二是能不能在工具调用前加一道规则校验。Dify的自定义工具调用前你可以在工作流里用代码节点或条件判断节点做一次参数校验比如如果退款金额大于5000且当前用户不是管理员则终止流程。写在最后的经验我现在再看多智能体协作用什么平台搭建这个问题心态跟刚开始完全不一样了。平台永远只是工具真正值钱的是你对自己业务协作模式的判断力。如果你现在还在犹豫我的建议很简单先在Dify这类可视化平台上把Demo跑起来亲手把一个业务流程拆成两个、三个Agent节点你会很快理解状态传递、工具分配、分支控制意味着什么。跑通之后如果发现平台的灵活性不够你用再考虑用LangGraph或CrewAI重写也不迟。最怕的不是选错而是选了之后一直不落地停留在收藏和对比阶段。另外说句实在话多智能体系统的搭建和维护成本是真的高能用一个Agent解决的事别为了多智能体这三个字硬上一套系统。