企业官网建设流程全解析

最近不少人在问多智能体协作到底用什么平台搭，这个问题我前前后后折腾了小半年，踩过的坑比吃过的饭还多。从最早用纯代码手写工作流，到后来试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 选型决策参考表

我把几个主流方案的对比整理成了表格，方便你根据自己的实际情况快速判断：

切记，这个表不是"哪个分高选哪个"，而是匹配你的真实约束。公司里没有专职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(temperature=0.3): return ChatOpenAI( model="gpt-4o", temperature=temperature, )

提示：在实际项目里，建议把模型名、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字段的解析。

然后是选题策划Agent：

def 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的工作流画布上：

1. 创建多个"Agent节点"。以"内容营销智能体集群"为例，先创建"任务分发Agent"，在它的Prompt里写明职责是判断内容类型。
2. 为每个Agent节点单独配置模型。注意不同节点的模型参数可以不同：任务分发用低温度，文案生成用稍高温度。
3. 画出连线。从"开始"节点连到"任务分发Agent"，然后根据Agenter的输出内容类型，设置分支条件（Dify里叫"条件分支"），把不同内容类型路由到不同的后续处理节点。
4. 使用变量传递。在Dify里，你可以把上一个节点的输出定义为变量，然后在下游节点的Prompt中引用，这就实现了Agent之间的消息传递。

用Dify的最大优势是能实时看到每个节点的输入输出，哪个环节出问题，在界面上点开就能检查，排查成本比写代码低很多。我甚至见过全无编程经验的运营同学，用半天时间就在Dify上搭出一个能跑的多Agent客服机器人。

4. 常见问题与排查技巧实录

4.1 Agent之间上下文传递丢失

这是我遇到最多的问题。某个Agent明明在上游已经生成了关键信息，下游Agent却像失忆一样完全没用到。大多数情况下，原因不是框架的问题，而是你在Prompt里没有明确要求Agent使用前置上下文。

比如writer节点里的Prompt如果只写了"根据选题写文章"，它确实不一定会去看素材。解决办法是在Prompt里增加硬性约束，比如"你必须在文章正文中引用至少两条上面提供的素材，不引用则任务失败"。另一种做法是在下游节点增加"前置信息核对"环节，让模型先复述一遍收到的重要信息，确认无误后再继续。

4.2 智能体对话陷入死循环

在自由对话式的多智能体系统（特别是AutoGen那种风格）中，两个Agent经常会出现"A让B做事，B反问A，A又让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的决策过程，比写一万行代码都管用。这一点，是你在任何平台的说明文档里都看不到的。