多智能体协作最近确实是讨论度最高的话题之一但大部分人卡在第一步到底用什么平台搭搜索引擎一开Dify、Coze、LangGraph、AutoGen、CrewAI、PydanticAI、MCP一堆名词砸过来越查越乱。这篇我不会给你列一个“全网最强排名”而是从实际搭建的角度把问题拆开聊聊我在不同场景下用这些平台和框架的真实感受以及一个能跑通的多智能体协作示例最后讲讲从Demo到业务落地你一定会遇到的坑。1. 先想清楚多智能体“协作”到底发生在哪一层选平台之前我建议先回答一个问题你要的协作是哪种协作这一步想不清楚后面选型一定纠结因为市面上这些平台根本不属于同一类东西。1.1 按协作层次拆解需求我习惯把多智能体协作分成四个层次选型时先对号入座提示词层的角色分工多个Agent共享同一套上下文靠系统提示词规定“你是分析师”“你是程序员”然后在一个会话里轮流发言。最典型的代表是AutoGen的群聊模式、ChatDev那样的虚拟公司。这种层次协作最浅适合头脑风暴、文档生成但状态管理弱复杂流程容易失控。流程编排层的任务分解由调度器把任务拆成子任务按有向图或状态机的方式分给不同Agent执行执行结果汇合后再决定下一步。LangGraph、CrewAI的Process、Dify的工作流画布都属于这一层。它的特点是可控性强适合有明确步骤的业务场景。协议层的服务协作Agent不再共享运行时而是通过标准协议比如MCP、ANP、A2A互相发现、调用工具和服务。这更像是微服务架构里的服务编排。多智能体协作如果想跨进程、跨团队、跨系统必须走到这一层。学习层的自适应协作Agent通过强化学习或进化算法在环境里自主学会分工策略多见于多智能体强化学习MARL和机器人集群仿真。这一层属于研究向生产系统里极少直接用。1.2 选平台本质上是选“协作形态”先弄明白这三件事再决定平台优先级你的任务能否稳定拆成子步骤如果业务流程清晰优先考虑流程编排类平台如果任务开放、方向上不明确框架类的图结构更适合你随时调整。Agent之间是否需要共享状态只是开会讨论用群聊式框架就行需要分阶段产出就必须有状态管理能力。协作范围是否超出单个服务只在代码库内部跑框架自带的工作流就够跨团队、跨系统调用工具就得引入协议层。所以搜索引擎里那些“XX平台能不能做多智能体”的问题其实大多是在用平台类的产品思考框架类的问题牛头不对马嘴。2. 主流搭建方式实测框架、平台、协议三选一我真正上手用过的多智能体搭建方式大概可以分成三类下面是我自己实际体验后的判断不是抄文档。2.1 框架类适合要写代码的人LangGraph是目前我用下来状态管理最清晰的一个。它把多智能体协作建模成图节点就是Agent动作边就是状态流转中间有一个全局State对象传来传去。好处是你能精确控制“谁先做、什么条件下轮到谁”这在复杂业务流程里非常重要。缺点是学习曲线陡小任务用它属于杀鸡用牛刀。AutoGen微软出品的群聊式框架。它的核心概念是ConversableAgent谁都能发言调度器决定什么时候终止。适合玩“角色扮演”式协作——让几个Agent扮演产品经理、代码评审、测试工程师互相PK。但对话轮次一多Token成本飞涨而且容易跑题需要靠max_consecutive_auto_reply硬性限制。生产环境里我一般不太建议直接用它做核心链路。CrewAI它主打“角色扮演流程”。定义Role、Goal、Backstory再用Process指定顺序执行或层级执行。上手速度比LangGraph快很多适合快速做原型。但实际跑复杂业务时它对状态的精细控制不如LangGraph流程一旦复杂配置会变得很笨重。PydanticAI这个框架比较新但我在做纯后端Agent服务时很喜欢用。它基于Pydantic做类型安全的输入输出校验Agent返回的数据能直接映射到数据模型天然适配业务代码。如果你想用Python写一个能和公司内部API无缝集成的Agent服务它比LangGraph轻得多。2.2 平台类适合业务同学和快速落地Dify目前中文圈子里最热门的智能体平台之一。它能可视化编排工作流把大模型调用、知识库检索、工具调用都拖到画布上。多智能体协作在Dify里通常表现为“多步骤工作流节点”每个节点调用不同模型或工具。它的优势是免费开源可私有化部署、集成度高劣势是复杂条件分支和动态循环不如代码灵活平台锁定风险也存在。Coze/扣子平台零代码起手插件市场丰富个人做Bot或者快速验证想法非常爽。但真要对接企业内部系统、做复杂权限控制平台能力会受限。它适合做ToC场景的流量入口不适合做ToB的复杂业务系统。n8n这类通用自动化平台也能沾边搭多智能体——把HTTP请求节点、AI节点连起来。但它缺少专门针对多智能体状态管理的抽象本质上还是工作流自动化不是专职Agent平台。2.3 协议层容易被忽略却是未来的关键框架和平台解决的是“单个进程内多个Agent怎么协作”但如果Agent要跨系统、跨团队呢这时候你需要协议。目前最火的MCPModel Context Protocol解决的是“大模型如何安全地调用外部工具和数据源”而Agent之间互相通信的协议比如A2A、ANPAgent Network Protocol还在快速演进中。一个形象一点的类比协议层是语言框架是语法规范平台是IDE。你用IDE写代码但不代表语言不重要——恰恰相反当Agent需要走出这个IDE去别的系统里办事时语言协议才是能让它们交流的通用底座。2.4 三类方案对比一览维度框架类平台类协议类典型代表LangGraph、CrewAI、AutoGenDify、Coze、n8nMCP、A2A、ANP上手成本需要写代码可视化拖拽中等需理解接口标准状态控制精细视觉化但复杂逻辑受限依赖协议定义的状态适用场景复杂流程、深度定制快速落地、业务人员参与跨系统、跨团队协作部署方式嵌入你的代码库独立部署或云服务每个Agent独立接入3. MCP为什么从“可选项”变成了“必选项”在聊多智能体的所有技术架构里MCP是绕不开的。而且它和我前面说的多智能体协作有直接关系——多个Agent要协作光会聊天没用它们得能干活而干活就涉及“调用工具”“查数据”“写结果”MCP恰好解决了这个问题。3.1 MCP解决的是什么问题在没有MCP之前每个Agent接一个工具就要写一套自定义的调用逻辑和时间处理逻辑接Slack写一套接数据库写一套接内部CRM又写一套。MCP把“工具接入”做成了标准化协议服务端暴露工具客户端也就是Agent运行环境通过统一接口调用。可以理解为给各种外部工具装了一个USB-C的接口。3.2 一个最小的MCP服务有多简单用FastMCP框架几十行代码就能把一个内部工具暴露成MCP服务。下面这个示例是一个简单的数据库查询服务from mcp.server.fastmcp import FastMCP mcp FastMCP(db-service) mcp.tool() def query_user_orders(user_id: str) - str: 根据用户ID查询最近订单 # 这里替换成你实际的数据库查询逻辑 rows db.fetch(fSELECT * FROM orders WHERE user_id {user_id} LIMIT 20) return \n.join(str(row) for row in rows) if __name__ __main__: mcp.run(transportstdio)服务端跑起来之后Agent客户端只需要通过MCP客户端SDK连接这个服务就可以像调用本地函数一样调用query_user_orders而不用关心数据库连接串、鉴权方式这些细节。3.3 在LangGraph里挂接MCP工具更实际的做法是在LangGraph或CrewAI里通过tool节点直接挂接MCP服务from langchain_mcp_adapters.client import MultiServerMCPClient client MultiServerMCPClient( { db: { url: http://mcp-service:8000/mcp, transport: sse, }, search: { url: http://search-service:9000/mcp, transport: sse, }, } ) # 把MCP的工具注入到Agent的tool节点 tools await client.get_tools()这样做的好处非常直接你的Agent团队可以按需接入不同领域的工具每个工具服务独立迭代谁出问题都互不影响。这才是多智能体能落地到企业业务中的前提。3.4 版本兼容与TypeScript同样可以玩MCP的生态更新很快不同框架和SDK的版本兼容性要留意尤其是Python的mcp库和l合框架的适配器版本。另外如果你前端技术栈是TypeScript推荐直接用TypeScript的SDK来写MCP服务Node.js生态里集成反而更顺滑。4. 一个能跑通的三人团队基于LangGraph的协作示例标题里最核心的问题“多智能体协作用什么平台搭建”要落到实处我给你一个可以直接改的示例。这里用LangGraph来搭一个三人小团队CEO负责拆解任务产品经理负责出方案开发负责产出代码。实际跑一遍就能直观理解多智能体协作是怎么转起来的。4.1 定义Agent状态和角色先定义协作状态所有Agent共享这个结构from typing import TypedDict, Annotated from langgraph.graph import StateGraph, START, END class AgentState(TypedDict): task: str # 总任务描述 plan: str # CEO拆分后的计划 spec: str # 产品经理的方案 code: str # 开发的产出 messages: list # 过程消息记录三个Agent分别定义这里用OpenAI兼容接口示例from langchain_openai import ChatOpenAI model ChatOpenAI(modelgpt-4o-mini, temperature0.2) def ceo_node(state: AgentState): prompt f你是CEO请把任务拆解成可执行的计划供产品和开发执行。任务{state[task]} resp model.invoke(prompt) return {plan: resp.content, messages: [fCEO: {resp.content}]} def pm_node(state: AgentState): prompt f你是产品经理基于CEO的计划输出详细需求方案。计划{state[plan]} resp model.invoke(prompt) return {spec: resp.content, messages: [fPM: {resp.content}]} def dev_node(state: AgentState): prompt f你是开发工程师根据方案编写代码直接输出代码。方案{state[spec]} resp model.invoke(prompt) return {code: resp.content, messages: [fDEV: {resp.content}]}4.2 编排流程用StateGraph把流程串起来CEO先拆解PM出方案DEV写代码最终汇合graph StateGraph(AgentState) graph.add_node(ceo, ceo_node) graph.add_node(pm, pm_node) graph.add_node(dev, dev_node) graph.add_edge(START, ceo) graph.add_edge(ceo, pm) graph.add_edge(pm, dev) graph.add_edge(dev, END) app graph.compile()运行result app.invoke({task: 写一个Python函数计算斐波那契数列前N项, messages: []}) print(result[code])4.3 加一个动态条件路由上面的顺序执行其实和单Agent调用差不了太多多智能体的真正能力在于“根据中间结果走不同分支”。比如加一个“验收”节点代码不合格就退回给开发重写def review_node(state: AgentState): prompt f你是代码评审检查以下代码是否有问题回答APPROVE或REVISE\n{state[code]} resp model.invoke(prompt) return {messages: [fREVIEW: {resp.content}]} def after_review(state: AgentState) - str: if APPROVE in state[messages][-1]: return end return dev graph.add_node(review, review_node) graph.add_edge(dev, review) graph.add_conditional_edges(review, after_review, {end: END, dev: dev})这个过程非常直观地体现了LangGraph这类框架和平台的差别图的边和节点都是可编程的逻辑复杂了你可以随时扩展。这个模式就是目前生产环境最常见的“ReAct人工/自动验收”循环。5. 从Demo到业务落地状态、观测、成本三个绕不开的问题很多人在本地跑通了上面的示例就觉得多智能体搞定了。但真正放到业务里三个问题立刻暴露出来而且平台选型怎么选也取决于你怎么回答这三个问题。5.1 状态与记忆会话状态不能全放内存上面的示例里Graph状态都在内存里。But应用一重启状态全没了。业务系统里Agent之间的协作往往是长时任务——执行到一半可能要等审批、等外部回调。这时你必须把图的状态持久化到Redis、PostgreSQL或对象存储里。LangGraph的Checkpointer就是干这个的每个节点执行后自动做快照断点恢复、人工介入都有基础。另外Agent之间的对话历史也要有策略地管理。把所有消息都发给所有AgentToken消耗会呈指数级上涨。更实际的做法是每个Agent只接收自己需要的最小上下文其他信息通过结构化字段传递。这样既省钱又不会让模型被无关信息干扰。5.2 可观测性多智能体的“黑盒”问题被放大了单个Agent调试时输入输出很直观。多Agent协作后问题可能出在任何一个环节——CEO拆解错了PM理解偏了开发跑偏了……没有一套完整的追踪系统排查问题会变成灾难。LangSmith是目前最成熟的LangGraph配套追踪方案每个节点的输入输出、Token消耗、延迟都有记录。如果不想上云服务至少要在代码里加日志埋点。强烈建议在State的messages里加上每个节点的耗时和Token数这样至少能从业务角度回溯链路。5.3 成本失控多Agent默认会烧钱这是最容易被忽略的。三个Agent各自调用模型和单Agent完成同样任务相比Token消耗可能是3到5倍。有几个控制手段我实际验证过用小模型处理简单节点拆解计划、生成摘要这类任务用gpt-4o-mini或更便宜的模型就够最终生成关键产出时再上强模型。限制重试轮次上面示例里的REVISE循环如果不限制次数模型会无限自我纠结。用recursion_limit或自定义计数器硬性限制3次以内超时人工接管。对Agent能看到的内容做裁剪每个节点的context里不要带着全量代码和历史记录裁剪到必要内容再送进模型。5.4 人机回环不是所有决策都该让Agent自己做多智能体系统里一个常见的误区是所有环节都想自动化。实际上生产系统里效果最好的模式是“Agent干活人审关键节点”。比如代码生成后安排一个需要人工点击确认的审批节点涉及金额、权限的操作强制走人工环节。技术上是给图加一个interrupt等待人输入后继续执行Dify这类平台里通常体现为“人工确认”节点。6. 我把主流平台用过一圈后踩过的坑和最终选型建议最后说点大实话也是我在不同项目里真实掉过的坑。6.1 坑一用LangGraph写所有场景导致过度设计有一段时间我迷信图编排不管什么功能都用LangGraph画一个大图结果维护成本高到怀疑人生。后来反思如果业务里只有两三个决策节点直接用普通Python代码串多个Agent调用反而更清晰。LangGraph的图编排优势要放在复杂流程里才体现出来小任务用大框架纯粹自找麻烦。6.2 坑二AutoGen的群聊很容易“礼貌性内耗”AutoGen多个Agent开会看着很热闹但实际效率经常很低。几个Agent互相“你说得对”“我也这样认为”一轮一轮空转Token烧得飞快。解决办法是给对话设硬性轮数上限同时在系统提示词里明确“不要寒暄直接给结果”。6.3 坑三Dify平台能跑通但复杂逻辑迟早会卡住Dify做MVP确实快但业务复杂到一定程度后画布上的条件分支会变得非常难维护。有一次我在Dify里做一个带多层嵌套判断的Agent流程调试一个分支要来回切节点最后实在受不了干脆用代码重写。所以我的原则是业务还在探索期用Dify快速验证模式跑通后如果复杂度上来了果断迁到代码框架。6.4 最终选型建议根据“协作发生在哪一层”的逻辑我给你一个可以直接抄的选型表你的场景推荐方案理由做一个聊天机器人带插件和知识库Coze / Dify零代码快速上线企业内部知识库问答工作流自动化Dify私有化部署数据不出内网复杂业务流程多角色分工需要精细状态控制LangGraph MCP图编排工具标准化快速验证Agent原型的角色扮演CrewAI上手快配置简单企业内部大量API需要被Agent调用MCP服务层标准化接入不绑定框架纯后端业务Agent追求类型安全和集成度PydanticAI与现有Python服务融合好6.5 我的一个固执的看法多智能体平台现在确实没有统一答案甚至可以说“没有银弹”。但我观察到一个趋势平台层的差异化会逐渐收敛到协议层和工具生态上谁能让Agent更方便地接入企业真实数据和服务谁就更有生命力。因此我建议你花时间把MCP这套机制吃透它对未来无论用哪个框架、哪个平台都有实实在在的好处。最后分享一个实操习惯——拿到任何新平台不要先看文档先跑通一个最小多智能体项目比如上面那个三人团队然后追问三个问题状态能不能持久化链路能不能追踪成本能不能控制这三个答案基本就决定了这个平台能不能进你的技术选型。踩过几次坑之后你就会发现平台之争远不如“把协作逻辑想清楚”来得重要。
