上个月有做电商运营的朋友找我张口就问了个很典型的问题他们想用多个AI分别负责商品文案、竞品价格监测和销售日报汇总再让这些AI互相协作形成一个“多智能体协作小组”最后问我用什么平台搭建最省事。这个问题听起来很具体但真回答起来却不简单。因为“多智能体协作”并不是你装一个软件就能跑起来的它是一组技术栈的组合甚至选型本身比后续写代码更影响最终效果。如果你团队里有会写Python的人和你完全没技术背景对应的方案完全不一样。这篇文章我会把多智能体协作平台的类型先盘清楚再拿我实际用过的 Dify 和 CrewAI 各做一套可落地的搭建流程最后分享几个真正花过钱才明白的避坑经验。无论你是准备给公司做内部工具还是自己搭一套智能体来玩应该都能在这篇里找到能直接抄作业的部分。1. 先厘清概念多智能体协作到底需要哪种“平台”1.1 多智能体协作的本质是“任务分配 上下文传递 结果校验”很多人一提多智能体就想到让两个AI像人一样聊天对话。但放到真实业务里多智能体协作更像一个公司里不同部门配合做事的样子老板编排者把任务拆分给不同角色策划岗Agent A产出内容再交给执行岗Agent B执行岗完成后质检岗Agent C对结果做校验最后所有人把成果汇总到老板手里。这里面的关键不是“聊天”而是任务怎么拆、上下文怎么传、工具怎么调、结果怎么校验。所以一个合格的多智能体协作平台至少要覆盖这几个能力角色定义每个Agent的身份、目标、知识边界、可用工具任务拆解系统可以把一个复杂请求自动或半自动地拆成多个子任务上下文传递上一个Agent的输出要能结构化地交给下一个Agent而不是把整段聊天记录都塞过去工具调用Agent能调用搜索、HTTP请求、数据库查询、代码执行等外部能力停止机制避免两个Agent陷入无限对话或反复确认必须有限制轮次和超时退出机制。把这些点放在一起看“平台搭建”这个问题的本质就变成了你该用哪种工具来满足上面这些能力并把它们组合成可运维的系统。1.2 平台选型的四个“挡位”别再混为一谈我在网上看热词时发现有人搜“spark集群搭建”“hadoop伪分布式搭建”以为多智能体协作需要一整套大数据集群。其实大部分Agent场景的数据量和计算量远没到那个程度所以第一件事就是别过度设计。目前市面上的“多智能体协作平台”大概分成四个挡位彼此之间不是替代关系而是可以叠加使用第一挡低代码可视化平台典型代表是 Dify 和扣子Coze。这类平台面向产品、运营、业务方通过拖拽节点就能拼出工作流内置了知识库、工具、Agent 节点适合快速验证和简单业务场景。优点是非常快一两天就能上线一个能用的智能体应用缺点是自定义逻辑受平台约束复杂的状态管理和深度的业务集成会吃力。第二挡代码级多智能体框架典型代表有 CrewAI、AutoGen、LangGraph、MetaGPT 等。这类框架给开发者提供了 Agent、Task、Process 这些编程原语你可以在代码里自由控制Agent的角色、工具、记忆和协作流程。优点是可扩展性和可维护性高适合作为后端服务集成到业务系统里缺点是需要写代码学习成本高。第三挡模型网关与API管理平台比如 one-api 这类开源网关负责统一封装各家大模型API做Key管理、限流、日志、多模型切换。多智能体协作往往要同时用到不同档次的模型比如规划Agent用强模型执行Agent用便宜模型所以一个API管理网关几乎是生产环境的标配。第四挡基础设施层包括服务器/云主机、容器环境、向量数据库、对象存储等。如果你的Agent需要长期记忆或知识库检索需要部署一个向量库如果只是文本标签、搜索、API调用一台普通的云主机就够了。另外提醒一下“机器人仿真平台选择”是另一个领域的事情。如果你做的是具身智能或机器人多机协作那需要 Gazebo、Isaac Sim 这类仿真环境来模拟物理世界而我们现在讨论的是基于大语言模型的Agent协作两者的技术栈完全不同别混在同一个问题里选型。2. 主流多智能体平台与框架横向对比照着选就行2.1 主流方案一张表看懂为了减少大家来回翻文档的时间我把目前最常见的几个方案放在一张表里。当然工具更新很快我尽量写它们多年不变的核心差异。方案类型上手难度扩展性适合人群主要坑Dify开源低代码LLMOps平台较低中有少量开发配合的业务团队、独立开发者复杂逻辑写起来不如纯代码顺手部分高级功能依赖插件扣子Coze商业低代码平台低中业务人员、快速做Demo自定义受限平台规则变化多私有化部署能力弱CrewAI代码级多智能体框架中高Python开发者版本更新快不同版本API差异较大AutoGen代码级多智能体框架较高高有经验的Python开发者对话流程容易发散需要花精力设计终止条件LangGraph基于图的状态编排框架较高高对状态图有概念的后端开发者学习曲线陡概念偏多适合做复杂的条件分支MetaGPT软件公司仿真多智能体框架较高高研发团队适合代码生成相关场景框架较重标准流程较重改造成本不低这表格看起来简单但选型时真正要看的不是“谁最火”而是“你的场景属于哪一类”。如果你要做的是一次性对外展示的Quick Demo扣子是选得最快的如果你要做内部工具并且未来要长期维护Dify做前端编排、CrewAI或LangGraph做后端逻辑是更稳的组合。2.2 我推荐的开源组合Dify CrewAI在我自己搭过的项目里最常用、最稳的组合是Dify CrewAI理由也很直接Dify负责“看得见的编排”让非技术同学也能参与进来调整Agent人设、拖拽工作流、管理知识库CrewAI负责“代码里的逻辑”当业务需要和公司内部API对接、做条件分支、处理复杂任务依赖时用Python代码控制整个流程两者都是开源的数据和代码都能自托管不会被某个平台绑死。可能有人会问既然CrewAI这么灵活为什么还要先用Dify我的体会是多智能体系统的关键是“不断调优”包括提示词、工具流程、角色划分。这个调优过程如果每次都要改代码重新部署效率太低了。Dify能让你在界面里直接试跑通了以后再把稳定的逻辑用CrewAI固化到生产代码里性价比很高。2.3 不同场景下的选型建议电商运营内容生成Dify 工作流 两个Agent节点就够不需要上CrewAI。企业内部业务系统集成CrewAI 或 LangGraph 作为服务嵌入后端配合one-api统一模型出口。自动化测试平台用CrewAI写个多Agent闭环一个Agent根据需求生成测试用例一个Agent执行并收集结果一个Agent评估覆盖率。研究探索型项目AutoGen 比较适合研究对话式多Agent协作因为它对自由对话和角色扮演支持多但上生产要谨慎。机器人/具身智能场景去看看Gazebo、Isaac Sim这类仿真平台但那是另一个知识体系不要和LLM Agent混用。3. 实操一用Dify快速搭建一个多智能体协作工作流3.1 环境准备部署Dify和配置DeepSeek模型Dify 是开源项目默认用 Docker Compose 部署对服务器要求不算高2核4G内存的云主机就可以跑起来。如果只做本地演示Windows电脑上装个 Docker Desktop 也能跑。有服务器的话一行命令直接拉项目git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d启动后等十几分钟浏览器访问http://服务器IP/就能进入Dify登录页。第一次进去会让你设置管理员账号记得用强密码。接着配置模型供应商。Dify 支持很多模型国内用 DeepSeek 的话成本低、效果也不错。到 DeepSeek 开放平台注册一个账号创建API Key然后在Dify后台的“设置-模型供应商”里选择 OpenAI-API-compatible 或者直接选择DeepSeek填上Key测试一下连通性。Dify 里也可以配置多个模型规划Agent用更强的模型执行Agent用便宜快速的模型这个在后面的Agent节点里可以分别选择。3.2 搭建“信息调研 内容撰写”双Agent工作流我们以一个非常典型的场景来演示输入一个行业关键词让第一个Agent去搜索整理行业信息第二个Agent根据这些信息生成产品推广文案。操作步骤大概如下第一步创建应用在Dify首页点击“创建空白应用”应用类型选择“工作流”。工作流和聊天助手的区别是工作流是明确的节点编排每一步都有输入输出适合固定流程。第二步设置开始节点开始节点里新增一个文本类型的输入变量比如叫topic用于接收用户输入的行业关键词。第三步添加第一个Agent节点这个Agent的身份是“信息调研员”。在Agent节点里填写系统提示词可以这样写你是一名行业研究员负责围绕{topic}查找最新的市场趋势和关键数据。请使用搜索工具获取信息输出结构化的调研要点每个要点后面标注来源。然后为它配置搜索工具。Dify 内置了一些工具比如可以接入搜索引擎API也可以通过自定义OpenAPI导入公司内部系统接口。给Agent配好工具后它就可以在节点内循环调用工具并整理结果。第四步添加第二个Agent节点在第一个Agent节点下面再拖入一个Agent节点名字叫“内容撰稿人”。它的系统提示词可以设计为你是一名资深文案基于上游调研员输出的行业要点写3条适合社交媒体传播的产品推广文案每条不超过50字语气自然口语化不要出现“根据调研”这类机器味词汇。然后在它的输入变量里把第一个Agent节点的最终输出引用进来。Dify 工作流里可以直接用{{节点ID.output}}的方式引用上游节点的结果这样第二个Agent看到的是结构化处理过的信息而不是原始对话记录。第五步连接结束节点把第二个Agent的输出接入结束节点这样前端调用工作流时得到的就是最终文案结果。第六步调试运行在Dify右上角点击“运行”输入一个测试行业词比如“精品咖啡”就能看到两个Agent按顺序执行的过程。如果第一个Agent搜索慢可以在节点配置里调大超时时间如果第二个Agent拿到的内容太长可以在第一个Agent的提示词里要求“只输出不超过5条要点”。3.3 低代码搭建时最值得关注的三个参数很多人以为低代码平台就是填几个框搁那儿点击就完事实际上有3个参数直接影响成败第一个Agent节点里的“最大迭代次数”Agent节点内部是“模型推理→调工具→再推理→再调工具”的循环。如果最大迭代次数设得太小比如默认只有5次而Agent需要搜索多次并总结很容易报“达到最大步骤限制”。建议先设到10到20次但也不要无限大否则一旦提示词不清晰它会在工具调用里兜圈子白烧Token。第二个模型温度和Top P写文案、头脑风暴这类创意任务温度设到0.7以上整理资料、抽取结构化信息温度设到0.2左右。温度太高会让事实类任务输出不稳定温度太低会让创意类任务死板。根据我的实测在两个Agent协作时上游Agent温度必须低因为它的输出会作为下游输入下游创意Agent可以适当高一点。第三个上下文的传递范围新手最容易犯的错是把整个对话历史都传给下一个Agent。Dify工作流里最好只引用上游节点的最终输出。多传一个字段Token就多一分爆炸风险而且还会引入噪音让下游Agent分不清重点。4. 实操二用CrewAI编写代码级多智能体协作流程4.1 CrewAI核心概念与最小可运行示例CrewAI 是一个很轻快的多智能体框架核心概念就四个Agent、Task、Process、Crew。你可以理解成这样Agent 是员工Task 是每个员工要完成的KPIProcess 是团队的协作方式顺序执行还是分层管理Crew 是把员工和KPI组在一起的团队。安装CrewAI很简单pip install crewai如果我们想用 DeepSeek 作为底层模型可以在环境变量里设置OpenAI兼容地址因为CrewAI底层通过 LiteLLM 兼容各种模型接口。下面是一个最小可运行示例和上面Dify的场景一样两个Agent协作完成“调研→写文案”import os from crewai import Agent, Task, Crew, Process # 设成DeepSeek兼容OpenAI的地址 os.environ[OPENAI_API_KEY] 你的DeepSeek Key os.environ[OPENAI_API_BASE] https://api.deepseek.com/v1 researcher Agent( role行业研究员, goal围绕{topic}写出最新的行业趋势要点, backstory你做过多年行业研究擅长把复杂信息压缩成结构化要点。, verboseTrue, allow_delegationFalse, llmdeepseek/deepseek-chat ) writer Agent( role内容撰稿人, goal根据行业研究员的输出写出朗朗上口的推广文案, backstory你是一名创意文案特别擅长把枯燥信息转化成用户愿意看的文字。, verboseTrue, allow_delegationFalse, llmdeepseek/deepseek-chat ) research_task Task( description找到关于{topic}的3个关键趋势列出要点每个要点带一个关键词来源。, expected_output不超过5行的分点要点每行包含一个趋势描述和来源关键词。, agentresearcher ) write_task Task( description根据调研要点写一段300字的市场洞察文案。, expected_output一段300字左右的中文短文语言自然。, agentwriter, context[research_task] # 表示writer需要依赖research_task的结果 ) crew Crew( agents[researcher, writer], tasks[research_task, write_task], processProcess.sequential ) result crew.kickoff(inputs{topic: 智能家居市场}) print(result)这段代码里最需要注意的是expected_output。很多人写Task只写description不写expected_output结果下游Agent拿到的内容乱七八糟。在CrewAI里上游Task只有明确给出了输出格式下游Task才有机会做结构化消费。另外context[research_task]是协作的关键。它告诉CrewAIwriter任务开始前需要先拿到research_task的结果这比直接在描述里说“根据上一次的结果”要规范得多。4.2 自定义工具与分层协作manager agent真实场景里的Agent很少只是“纯聊天”通常要调用外部API、数据库、搜索引擎等等。在CrewAI里给Agent装工具也比较简单写一个函数然后用tool装饰器包一下就行。from crewai_tools import tool tool(搜索行业资讯) def search_news(query: str) - str: 根据关键词搜索最新的行业资讯返回新闻标题和摘要。 # 这里可以接任何搜索API比如Serper、Bing Search、或公司内部搜索 return 示例搜索结果然后把这个工具传给Agentresearcher Agent( role行业研究员, goal围绕{topic}查找最新行业动态, backstory你习惯用搜索工具验证信息。, tools[search_news], verboseTrue, llmdeepseek/deepseek-chat )当任务之间的先后关系不确定时可以把Process.sequential换成Process.hierarchical。这时候CrewAI会自动创建一个“管理者Agent”来拆解任务、分派给其他Agent并汇总结果。管理者Agent的配置方式有两种显式传入manager_agent指定一个更强大的模型来当管理者不传manager_agentCrewAI会用一个默认的manager角色。我的建议是如果要用分层协作一定要显式配置manager_agent因为默认管理Agent在复杂任务里的调度能力不够稳定。而且分层模式更耗Token因为它每一步都要经过管理Agent“决策→派发→验收”所以只适合任务步骤多、动态变化大的场景。4.3 延伸玩法用多智能体搭自动化测试平台热词里有“自己搭建agent进行自动化测试”我用CrewAI做过类似的事情效果还不错。思路是这样的测试分析师Agent读取接口文档或需求描述输出测试用例列表执行Agent拿到测试用例后通过一个HTTP请求工具去真实调用接口把响应存下来质量审查Agent把响应和预期结果做比对输出通过/失败/告警结果。这样做的好处是需求文档一变测试用例和验证逻辑可以跟着自动更新而不是手工维护一堆固定脚本。要注意的是执行Agent必须配备真正的工具而不是让模型“想象”调用结果。你需要在代码里写好一个能发HTTP请求的函数注册成Agent的工具这样它才能真的去调接口。5. 平台搭建实战中的避坑指南5.1 五个高频坑每一个都花过钱第一个坑Agent之间职责边界模糊。我做过一个项目让A Agent负责收集用户反馈B Agent负责生成解决方案结果B经常自己脑补调研数据给出的方案看起来漂亮但底数全是编的。后来我在Task里强制要求A的expected_output必须包含数据来源并且B的任务描述里明确写“只允许基于给定数据输出不要自行补充未出现的案例”问题立刻改善。第二个坑上下文全量传递导致Token爆炸。多智能体协作最烧钱的地方不是模型贵而是你反复把大段历史记录传给下一个Agent。解决思路是让每个Agent只输出关键结论不输出完整思维链。在CrewAI里控制Task的expected_output规模在Dify工作流里只引用上游节点的最终输出。第三个坑Agent陷入死循环。两个Agent互相确认、反复修改一段文案看起来很智能实际上在无意义消耗。我现在的习惯是所有Agent节点都设最大迭代次数并且在提示词里写“如果任务已完成直接输出最终结果不要再重复润色”。第四个坑下游Agent盲信上游Agent的幻觉。多Agent系统会放大幻觉因为上游一旦出错下游会顺着错误继续发挥。比较好的做法是给每个Agent配一个“事实核查”步骤或者要求输出里保留引用来源。对于严肃业务可以在工作流最后加一个“质检Agent”专门审查前面的产出是否存在明显矛盾。第五个坑平台版本变动导致代码翻车。CrewAI 的 API 迭代很快网上很多教程用的是旧版本写法比如某些Agent参数在新版里已经改名。我建议你在安装后立刻用官方仓库里的示例代码跑一次确认版本语法有效再开始封装自己的代码。Dify 也存在类似情况不同版本节点配置项有差异所以部署时最好固定版本号别追新。5.2 常见问题排查速查表问题现象可能原因解决思路Agent A 的输出没有被 Agent B 使用Task 没有设置 context或 Dify 节点没有引用上游输出检查依赖关系适当打印中间结果调用搜索工具后报超时工具接口响应慢或API配额耗尽调大Agent节点超时时间检查API余额结果不稳定每次输出差别大温度设置偏高提示词不明确降低温度把输出格式写死两个Agent来回对话停不下来缺少停止条件没有最大迭代限制设置最大轮数增加“完成”标记词API调用频繁被限流网关层没做限流和缓存部署one-api类网关统一管理Key和限流模型经常返回空内容上下文太长输出token限制被占用压缩上游输出或调高max_tokens5.3 几个提高稳定性的体感技巧先分享一个最简单的给不同Agent分配不同模型。在Dify里每个节点可以单独选模型在CrewAI里每个Agent也可以指定不同llm。规划Agent、总结Agent用强模型格式整理、关键词抽取用便宜模型整体成本能降一半稳定性反而更好。第二个是用知识库隔离Agent的“世界知识”。如果两个Agent服务的领域完全不同不要把知识库堆在一起。Dify支持创建多个知识库你可以让“客服Agent”只挂客服语料“营销Agent”只挂产品素材这样有效减少相互污染。第三个是把Agent执行过程日志留全。Dify有日志查看界面CrewAI开启verboseTrue后会在终端打印每一步决策。这些日志不光是用来调试它还帮你搞清楚Agent的决策链路后面优化提示词才有依据。第四个是给工作流加回归测试。Dify发布后的API可以用脚本批量触发CrewAI也可以用pytest跑一组固定输入。多智能体系统最大的风险是“改了一个Agent另一个Agent行为变了”所以至少准备10到20条测试用例每次修改后跑一遍回归能兜住大部分低级错误。6. 平台选型的真实心得6.1 不要迷信“大而全”的多智能体平台市面上的平台功能和热词每天都在变今天这个带工作流明天那个带知识库后天又来个能编排Agent的。但真正到生产环境能稳定跑三个月以上的方案往往是用开源工具拼出来的组合而不是某一家闭源平台。我自己的经验是选平台先回答三个问题——能不能私有化能不能导出数据插件和API开放程度够不够这三个问题只要有一个不满足后面大概率会踩坑。6.2 从小闭环起步再逐步扩大规模如果你现在还没搭过多智能体协作系统我建议别一上来就想着做几十个Agent的大型系统。先拿一个最小业务闭环比如“调研Agent → 文案Agent → 审核Agent”用Dify跑通观察效果再逐步加节点。当需要处理更复杂的动态任务时再把Dify里的稳定流程迁移到CrewAI代码里或者引入LangGraph做状态控制。这种演进路线花费少、见效快而且每一步的结果都可控。我个人的体会是多智能体协作真正的难点从来不是某个平台会不会用而是你对自己业务流程的拆解能力。平台解决的是Agent之间怎么连接的问题而“哪些事该由哪个Agent负责”“它们之间交付什么格式的信息”才是决定系统是否好用的根本。先想清楚这两件事再用Dify、CrewAI这些工具把它落地你会少走很多弯路。
多智能体协作平台搭建实战：Dify与CrewAI选型与避坑指南
上个月有做电商运营的朋友找我张口就问了个很典型的问题他们想用多个AI分别负责商品文案、竞品价格监测和销售日报汇总再让这些AI互相协作形成一个“多智能体协作小组”最后问我用什么平台搭建最省事。这个问题听起来很具体但真回答起来却不简单。因为“多智能体协作”并不是你装一个软件就能跑起来的它是一组技术栈的组合甚至选型本身比后续写代码更影响最终效果。如果你团队里有会写Python的人和你完全没技术背景对应的方案完全不一样。这篇文章我会把多智能体协作平台的类型先盘清楚再拿我实际用过的 Dify 和 CrewAI 各做一套可落地的搭建流程最后分享几个真正花过钱才明白的避坑经验。无论你是准备给公司做内部工具还是自己搭一套智能体来玩应该都能在这篇里找到能直接抄作业的部分。1. 先厘清概念多智能体协作到底需要哪种“平台”1.1 多智能体协作的本质是“任务分配 上下文传递 结果校验”很多人一提多智能体就想到让两个AI像人一样聊天对话。但放到真实业务里多智能体协作更像一个公司里不同部门配合做事的样子老板编排者把任务拆分给不同角色策划岗Agent A产出内容再交给执行岗Agent B执行岗完成后质检岗Agent C对结果做校验最后所有人把成果汇总到老板手里。这里面的关键不是“聊天”而是任务怎么拆、上下文怎么传、工具怎么调、结果怎么校验。所以一个合格的多智能体协作平台至少要覆盖这几个能力角色定义每个Agent的身份、目标、知识边界、可用工具任务拆解系统可以把一个复杂请求自动或半自动地拆成多个子任务上下文传递上一个Agent的输出要能结构化地交给下一个Agent而不是把整段聊天记录都塞过去工具调用Agent能调用搜索、HTTP请求、数据库查询、代码执行等外部能力停止机制避免两个Agent陷入无限对话或反复确认必须有限制轮次和超时退出机制。把这些点放在一起看“平台搭建”这个问题的本质就变成了你该用哪种工具来满足上面这些能力并把它们组合成可运维的系统。1.2 平台选型的四个“挡位”别再混为一谈我在网上看热词时发现有人搜“spark集群搭建”“hadoop伪分布式搭建”以为多智能体协作需要一整套大数据集群。其实大部分Agent场景的数据量和计算量远没到那个程度所以第一件事就是别过度设计。目前市面上的“多智能体协作平台”大概分成四个挡位彼此之间不是替代关系而是可以叠加使用第一挡低代码可视化平台典型代表是 Dify 和扣子Coze。这类平台面向产品、运营、业务方通过拖拽节点就能拼出工作流内置了知识库、工具、Agent 节点适合快速验证和简单业务场景。优点是非常快一两天就能上线一个能用的智能体应用缺点是自定义逻辑受平台约束复杂的状态管理和深度的业务集成会吃力。第二挡代码级多智能体框架典型代表有 CrewAI、AutoGen、LangGraph、MetaGPT 等。这类框架给开发者提供了 Agent、Task、Process 这些编程原语你可以在代码里自由控制Agent的角色、工具、记忆和协作流程。优点是可扩展性和可维护性高适合作为后端服务集成到业务系统里缺点是需要写代码学习成本高。第三挡模型网关与API管理平台比如 one-api 这类开源网关负责统一封装各家大模型API做Key管理、限流、日志、多模型切换。多智能体协作往往要同时用到不同档次的模型比如规划Agent用强模型执行Agent用便宜模型所以一个API管理网关几乎是生产环境的标配。第四挡基础设施层包括服务器/云主机、容器环境、向量数据库、对象存储等。如果你的Agent需要长期记忆或知识库检索需要部署一个向量库如果只是文本标签、搜索、API调用一台普通的云主机就够了。另外提醒一下“机器人仿真平台选择”是另一个领域的事情。如果你做的是具身智能或机器人多机协作那需要 Gazebo、Isaac Sim 这类仿真环境来模拟物理世界而我们现在讨论的是基于大语言模型的Agent协作两者的技术栈完全不同别混在同一个问题里选型。2. 主流多智能体平台与框架横向对比照着选就行2.1 主流方案一张表看懂为了减少大家来回翻文档的时间我把目前最常见的几个方案放在一张表里。当然工具更新很快我尽量写它们多年不变的核心差异。方案类型上手难度扩展性适合人群主要坑Dify开源低代码LLMOps平台较低中有少量开发配合的业务团队、独立开发者复杂逻辑写起来不如纯代码顺手部分高级功能依赖插件扣子Coze商业低代码平台低中业务人员、快速做Demo自定义受限平台规则变化多私有化部署能力弱CrewAI代码级多智能体框架中高Python开发者版本更新快不同版本API差异较大AutoGen代码级多智能体框架较高高有经验的Python开发者对话流程容易发散需要花精力设计终止条件LangGraph基于图的状态编排框架较高高对状态图有概念的后端开发者学习曲线陡概念偏多适合做复杂的条件分支MetaGPT软件公司仿真多智能体框架较高高研发团队适合代码生成相关场景框架较重标准流程较重改造成本不低这表格看起来简单但选型时真正要看的不是“谁最火”而是“你的场景属于哪一类”。如果你要做的是一次性对外展示的Quick Demo扣子是选得最快的如果你要做内部工具并且未来要长期维护Dify做前端编排、CrewAI或LangGraph做后端逻辑是更稳的组合。2.2 我推荐的开源组合Dify CrewAI在我自己搭过的项目里最常用、最稳的组合是Dify CrewAI理由也很直接Dify负责“看得见的编排”让非技术同学也能参与进来调整Agent人设、拖拽工作流、管理知识库CrewAI负责“代码里的逻辑”当业务需要和公司内部API对接、做条件分支、处理复杂任务依赖时用Python代码控制整个流程两者都是开源的数据和代码都能自托管不会被某个平台绑死。可能有人会问既然CrewAI这么灵活为什么还要先用Dify我的体会是多智能体系统的关键是“不断调优”包括提示词、工具流程、角色划分。这个调优过程如果每次都要改代码重新部署效率太低了。Dify能让你在界面里直接试跑通了以后再把稳定的逻辑用CrewAI固化到生产代码里性价比很高。2.3 不同场景下的选型建议电商运营内容生成Dify 工作流 两个Agent节点就够不需要上CrewAI。企业内部业务系统集成CrewAI 或 LangGraph 作为服务嵌入后端配合one-api统一模型出口。自动化测试平台用CrewAI写个多Agent闭环一个Agent根据需求生成测试用例一个Agent执行并收集结果一个Agent评估覆盖率。研究探索型项目AutoGen 比较适合研究对话式多Agent协作因为它对自由对话和角色扮演支持多但上生产要谨慎。机器人/具身智能场景去看看Gazebo、Isaac Sim这类仿真平台但那是另一个知识体系不要和LLM Agent混用。3. 实操一用Dify快速搭建一个多智能体协作工作流3.1 环境准备部署Dify和配置DeepSeek模型Dify 是开源项目默认用 Docker Compose 部署对服务器要求不算高2核4G内存的云主机就可以跑起来。如果只做本地演示Windows电脑上装个 Docker Desktop 也能跑。有服务器的话一行命令直接拉项目git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d启动后等十几分钟浏览器访问http://服务器IP/就能进入Dify登录页。第一次进去会让你设置管理员账号记得用强密码。接着配置模型供应商。Dify 支持很多模型国内用 DeepSeek 的话成本低、效果也不错。到 DeepSeek 开放平台注册一个账号创建API Key然后在Dify后台的“设置-模型供应商”里选择 OpenAI-API-compatible 或者直接选择DeepSeek填上Key测试一下连通性。Dify 里也可以配置多个模型规划Agent用更强的模型执行Agent用便宜快速的模型这个在后面的Agent节点里可以分别选择。3.2 搭建“信息调研 内容撰写”双Agent工作流我们以一个非常典型的场景来演示输入一个行业关键词让第一个Agent去搜索整理行业信息第二个Agent根据这些信息生成产品推广文案。操作步骤大概如下第一步创建应用在Dify首页点击“创建空白应用”应用类型选择“工作流”。工作流和聊天助手的区别是工作流是明确的节点编排每一步都有输入输出适合固定流程。第二步设置开始节点开始节点里新增一个文本类型的输入变量比如叫topic用于接收用户输入的行业关键词。第三步添加第一个Agent节点这个Agent的身份是“信息调研员”。在Agent节点里填写系统提示词可以这样写你是一名行业研究员负责围绕{topic}查找最新的市场趋势和关键数据。请使用搜索工具获取信息输出结构化的调研要点每个要点后面标注来源。然后为它配置搜索工具。Dify 内置了一些工具比如可以接入搜索引擎API也可以通过自定义OpenAPI导入公司内部系统接口。给Agent配好工具后它就可以在节点内循环调用工具并整理结果。第四步添加第二个Agent节点在第一个Agent节点下面再拖入一个Agent节点名字叫“内容撰稿人”。它的系统提示词可以设计为你是一名资深文案基于上游调研员输出的行业要点写3条适合社交媒体传播的产品推广文案每条不超过50字语气自然口语化不要出现“根据调研”这类机器味词汇。然后在它的输入变量里把第一个Agent节点的最终输出引用进来。Dify 工作流里可以直接用{{节点ID.output}}的方式引用上游节点的结果这样第二个Agent看到的是结构化处理过的信息而不是原始对话记录。第五步连接结束节点把第二个Agent的输出接入结束节点这样前端调用工作流时得到的就是最终文案结果。第六步调试运行在Dify右上角点击“运行”输入一个测试行业词比如“精品咖啡”就能看到两个Agent按顺序执行的过程。如果第一个Agent搜索慢可以在节点配置里调大超时时间如果第二个Agent拿到的内容太长可以在第一个Agent的提示词里要求“只输出不超过5条要点”。3.3 低代码搭建时最值得关注的三个参数很多人以为低代码平台就是填几个框搁那儿点击就完事实际上有3个参数直接影响成败第一个Agent节点里的“最大迭代次数”Agent节点内部是“模型推理→调工具→再推理→再调工具”的循环。如果最大迭代次数设得太小比如默认只有5次而Agent需要搜索多次并总结很容易报“达到最大步骤限制”。建议先设到10到20次但也不要无限大否则一旦提示词不清晰它会在工具调用里兜圈子白烧Token。第二个模型温度和Top P写文案、头脑风暴这类创意任务温度设到0.7以上整理资料、抽取结构化信息温度设到0.2左右。温度太高会让事实类任务输出不稳定温度太低会让创意类任务死板。根据我的实测在两个Agent协作时上游Agent温度必须低因为它的输出会作为下游输入下游创意Agent可以适当高一点。第三个上下文的传递范围新手最容易犯的错是把整个对话历史都传给下一个Agent。Dify工作流里最好只引用上游节点的最终输出。多传一个字段Token就多一分爆炸风险而且还会引入噪音让下游Agent分不清重点。4. 实操二用CrewAI编写代码级多智能体协作流程4.1 CrewAI核心概念与最小可运行示例CrewAI 是一个很轻快的多智能体框架核心概念就四个Agent、Task、Process、Crew。你可以理解成这样Agent 是员工Task 是每个员工要完成的KPIProcess 是团队的协作方式顺序执行还是分层管理Crew 是把员工和KPI组在一起的团队。安装CrewAI很简单pip install crewai如果我们想用 DeepSeek 作为底层模型可以在环境变量里设置OpenAI兼容地址因为CrewAI底层通过 LiteLLM 兼容各种模型接口。下面是一个最小可运行示例和上面Dify的场景一样两个Agent协作完成“调研→写文案”import os from crewai import Agent, Task, Crew, Process # 设成DeepSeek兼容OpenAI的地址 os.environ[OPENAI_API_KEY] 你的DeepSeek Key os.environ[OPENAI_API_BASE] https://api.deepseek.com/v1 researcher Agent( role行业研究员, goal围绕{topic}写出最新的行业趋势要点, backstory你做过多年行业研究擅长把复杂信息压缩成结构化要点。, verboseTrue, allow_delegationFalse, llmdeepseek/deepseek-chat ) writer Agent( role内容撰稿人, goal根据行业研究员的输出写出朗朗上口的推广文案, backstory你是一名创意文案特别擅长把枯燥信息转化成用户愿意看的文字。, verboseTrue, allow_delegationFalse, llmdeepseek/deepseek-chat ) research_task Task( description找到关于{topic}的3个关键趋势列出要点每个要点带一个关键词来源。, expected_output不超过5行的分点要点每行包含一个趋势描述和来源关键词。, agentresearcher ) write_task Task( description根据调研要点写一段300字的市场洞察文案。, expected_output一段300字左右的中文短文语言自然。, agentwriter, context[research_task] # 表示writer需要依赖research_task的结果 ) crew Crew( agents[researcher, writer], tasks[research_task, write_task], processProcess.sequential ) result crew.kickoff(inputs{topic: 智能家居市场}) print(result)这段代码里最需要注意的是expected_output。很多人写Task只写description不写expected_output结果下游Agent拿到的内容乱七八糟。在CrewAI里上游Task只有明确给出了输出格式下游Task才有机会做结构化消费。另外context[research_task]是协作的关键。它告诉CrewAIwriter任务开始前需要先拿到research_task的结果这比直接在描述里说“根据上一次的结果”要规范得多。4.2 自定义工具与分层协作manager agent真实场景里的Agent很少只是“纯聊天”通常要调用外部API、数据库、搜索引擎等等。在CrewAI里给Agent装工具也比较简单写一个函数然后用tool装饰器包一下就行。from crewai_tools import tool tool(搜索行业资讯) def search_news(query: str) - str: 根据关键词搜索最新的行业资讯返回新闻标题和摘要。 # 这里可以接任何搜索API比如Serper、Bing Search、或公司内部搜索 return 示例搜索结果然后把这个工具传给Agentresearcher Agent( role行业研究员, goal围绕{topic}查找最新行业动态, backstory你习惯用搜索工具验证信息。, tools[search_news], verboseTrue, llmdeepseek/deepseek-chat )当任务之间的先后关系不确定时可以把Process.sequential换成Process.hierarchical。这时候CrewAI会自动创建一个“管理者Agent”来拆解任务、分派给其他Agent并汇总结果。管理者Agent的配置方式有两种显式传入manager_agent指定一个更强大的模型来当管理者不传manager_agentCrewAI会用一个默认的manager角色。我的建议是如果要用分层协作一定要显式配置manager_agent因为默认管理Agent在复杂任务里的调度能力不够稳定。而且分层模式更耗Token因为它每一步都要经过管理Agent“决策→派发→验收”所以只适合任务步骤多、动态变化大的场景。4.3 延伸玩法用多智能体搭自动化测试平台热词里有“自己搭建agent进行自动化测试”我用CrewAI做过类似的事情效果还不错。思路是这样的测试分析师Agent读取接口文档或需求描述输出测试用例列表执行Agent拿到测试用例后通过一个HTTP请求工具去真实调用接口把响应存下来质量审查Agent把响应和预期结果做比对输出通过/失败/告警结果。这样做的好处是需求文档一变测试用例和验证逻辑可以跟着自动更新而不是手工维护一堆固定脚本。要注意的是执行Agent必须配备真正的工具而不是让模型“想象”调用结果。你需要在代码里写好一个能发HTTP请求的函数注册成Agent的工具这样它才能真的去调接口。5. 平台搭建实战中的避坑指南5.1 五个高频坑每一个都花过钱第一个坑Agent之间职责边界模糊。我做过一个项目让A Agent负责收集用户反馈B Agent负责生成解决方案结果B经常自己脑补调研数据给出的方案看起来漂亮但底数全是编的。后来我在Task里强制要求A的expected_output必须包含数据来源并且B的任务描述里明确写“只允许基于给定数据输出不要自行补充未出现的案例”问题立刻改善。第二个坑上下文全量传递导致Token爆炸。多智能体协作最烧钱的地方不是模型贵而是你反复把大段历史记录传给下一个Agent。解决思路是让每个Agent只输出关键结论不输出完整思维链。在CrewAI里控制Task的expected_output规模在Dify工作流里只引用上游节点的最终输出。第三个坑Agent陷入死循环。两个Agent互相确认、反复修改一段文案看起来很智能实际上在无意义消耗。我现在的习惯是所有Agent节点都设最大迭代次数并且在提示词里写“如果任务已完成直接输出最终结果不要再重复润色”。第四个坑下游Agent盲信上游Agent的幻觉。多Agent系统会放大幻觉因为上游一旦出错下游会顺着错误继续发挥。比较好的做法是给每个Agent配一个“事实核查”步骤或者要求输出里保留引用来源。对于严肃业务可以在工作流最后加一个“质检Agent”专门审查前面的产出是否存在明显矛盾。第五个坑平台版本变动导致代码翻车。CrewAI 的 API 迭代很快网上很多教程用的是旧版本写法比如某些Agent参数在新版里已经改名。我建议你在安装后立刻用官方仓库里的示例代码跑一次确认版本语法有效再开始封装自己的代码。Dify 也存在类似情况不同版本节点配置项有差异所以部署时最好固定版本号别追新。5.2 常见问题排查速查表问题现象可能原因解决思路Agent A 的输出没有被 Agent B 使用Task 没有设置 context或 Dify 节点没有引用上游输出检查依赖关系适当打印中间结果调用搜索工具后报超时工具接口响应慢或API配额耗尽调大Agent节点超时时间检查API余额结果不稳定每次输出差别大温度设置偏高提示词不明确降低温度把输出格式写死两个Agent来回对话停不下来缺少停止条件没有最大迭代限制设置最大轮数增加“完成”标记词API调用频繁被限流网关层没做限流和缓存部署one-api类网关统一管理Key和限流模型经常返回空内容上下文太长输出token限制被占用压缩上游输出或调高max_tokens5.3 几个提高稳定性的体感技巧先分享一个最简单的给不同Agent分配不同模型。在Dify里每个节点可以单独选模型在CrewAI里每个Agent也可以指定不同llm。规划Agent、总结Agent用强模型格式整理、关键词抽取用便宜模型整体成本能降一半稳定性反而更好。第二个是用知识库隔离Agent的“世界知识”。如果两个Agent服务的领域完全不同不要把知识库堆在一起。Dify支持创建多个知识库你可以让“客服Agent”只挂客服语料“营销Agent”只挂产品素材这样有效减少相互污染。第三个是把Agent执行过程日志留全。Dify有日志查看界面CrewAI开启verboseTrue后会在终端打印每一步决策。这些日志不光是用来调试它还帮你搞清楚Agent的决策链路后面优化提示词才有依据。第四个是给工作流加回归测试。Dify发布后的API可以用脚本批量触发CrewAI也可以用pytest跑一组固定输入。多智能体系统最大的风险是“改了一个Agent另一个Agent行为变了”所以至少准备10到20条测试用例每次修改后跑一遍回归能兜住大部分低级错误。6. 平台选型的真实心得6.1 不要迷信“大而全”的多智能体平台市面上的平台功能和热词每天都在变今天这个带工作流明天那个带知识库后天又来个能编排Agent的。但真正到生产环境能稳定跑三个月以上的方案往往是用开源工具拼出来的组合而不是某一家闭源平台。我自己的经验是选平台先回答三个问题——能不能私有化能不能导出数据插件和API开放程度够不够这三个问题只要有一个不满足后面大概率会踩坑。6.2 从小闭环起步再逐步扩大规模如果你现在还没搭过多智能体协作系统我建议别一上来就想着做几十个Agent的大型系统。先拿一个最小业务闭环比如“调研Agent → 文案Agent → 审核Agent”用Dify跑通观察效果再逐步加节点。当需要处理更复杂的动态任务时再把Dify里的稳定流程迁移到CrewAI代码里或者引入LangGraph做状态控制。这种演进路线花费少、见效快而且每一步的结果都可控。我个人的体会是多智能体协作真正的难点从来不是某个平台会不会用而是你对自己业务流程的拆解能力。平台解决的是Agent之间怎么连接的问题而“哪些事该由哪个Agent负责”“它们之间交付什么格式的信息”才是决定系统是否好用的根本。先想清楚这两件事再用Dify、CrewAI这些工具把它落地你会少走很多弯路。