工作流编排框架总览

摘要：从"一个 Prompt 调一次模型"到"检索 + 工具 + 多轮判断"的复合应用，需要编排层把步骤、分支、重试、人工介入组织起来。本文梳理四类编排方案（可视化平台 Dify、通用自动化 n8n、低代码画布 Flowise、代码框架 LangGraph）的能力边界与取舍，并给出生产选型决策树。Agent 相关基础见 Agent 架构模式与 Agent 框架对比（Agent 技能体系）。

四类方案的能力光谱

方案	形态	强项	弱项	定位
Dify	开源 LLM 应用平台（自托管/云）	应用模板、RAG 内置、Prompt 管理、发布即得 API	深度定制逻辑受画布表达力限制	LLM 应用一站式平台
n8n	通用工作流自动化（可视化）	400+ 现成集成（SaaS/DB/IM），定时/触发器成熟，AI 节点渐全	LLM 原生能力（评估、RAG 细粒度控制）弱于专用平台	与业务系统集成的胶水层
Flowise / Langflow	低代码画布	拖拽即可拼 LangChain 组件，原型极快	生产级治理（权限/审计/伸缩）需自建	快速原型、内部小工具
LangGraph	代码框架（Python/JS）	状态机语义、循环与人工介入（interrupt）一等公民、可测试	全代码，无可视化，门槛高	复杂 Agent、生产核心链路

[版本相关]：该领域演进快，各家能力随版本交叉渗透（Dify 加代码节点、n8n 加 AI Agent 节点、LangGraph 加 Studio 可视化），以官方文档现状为准。

可视化编排 vs 代码编排

这是选型的核心取舍，比"哪家功能多"更重要：

可视化（Dify/n8n/Flowise）赢在：非工程角色可参与；流程即文档；改流程不改代码。输在：复杂分支/循环的表达力上限；版本管理与 code review 天然弱（JSON 导出可缓解）；测试自动化困难。

代码编排（LangGraph/自研）赢在：单元测试、CI、渐进重构都按软件工程标准来；状态机语义显式，长流程的断点续跑与人工审批可建模。输在：迭代速度依赖工程师；业务人员无法自助调整。

混合策略是常态

成熟团队常见分工：对外核心产品链路用代码编排（可控、可测、可审计），内部运营工具与系统集成用 n8n/Dify（快、业务可自助）。两边通过统一的模型网关与知识库服务解耦（见 LLM 网关架构与价值）。

生产落地的共同要点

无论选哪个框架，上生产都要补齐这几块（平台自带的不等于配置对了）：

可观测：对接 Langfuse/OTel，每个节点一个 span，失败可下钻（见调用链追踪）；
幂等与重试：节点失败重试要有上限与预算约束，LLM 节点重试即双倍成本；
超时与降级：每个 LLM 节点显式设超时，下游不可用时的降级路径（兜底话术/人工接管）要在画布/状态机里画出来；
凭证管理：模型 API Key 用平台级密钥管理，不出现在流程定义 JSON 里（导出的流程文件常被忽略在 Git 里）；
版本发布：流程定义纳入版本控制，灰度切换新版本，支持回滚。

选型决策树

text

需求是什么？
├─ 内部工具/集成自动化为主，AI 只是环节之一 → n8n
├─ 标准 LLM 应用（客服、知识库、生成器）要快速上线 → Dify
├─ 原型验证，验证完会重写 → Flowise / Langflow
└─ 复杂 Agent / 核心产品链路，需要测试与审计 → LangGraph（或自研）

避免的反模式

① 用画布工具实现数百节点的巨型流程——迁移与排障成本指数增长；② 原型框架（Flowise）直接上生产承载外部流量；③ 自研编排从零造轮子——至少复用 LangGraph 的检查点与中断语义。

工作流编排框架总览 ​

四类方案的能力光谱 ​

可视化编排 vs 代码编排 ​

生产落地的共同要点 ​

选型决策树 ​

参考资料 ​

工作流编排框架总览

四类方案的能力光谱

可视化编排 vs 代码编排

生产落地的共同要点

选型决策树

参考资料