[理论篇-10]AI 工作流（AI Workflow）—— 让 AI 像流水线一样干活 ⚠️ 已逐步被多 Agent 架构替代

⚠️过时提示（2026 更新）:本篇介绍的"AI 工作流（Workflow）"范式,正在被多 Agent（Multi-Agent）架构逐步替代。

• 工作流强调"人把流程画好,AI 按节点跑":每一步走哪条边、调哪个模型、用什么 Prompt,都是开发者预先设计好的。
• 多 Agent则把"怎么走"也交给模型自己决定:多个具备工具调用能力的 Agent 协作分工、动态规划、相互调用,流程不再是固定的 DAG,而是运行时"长出来"的。

随着模型推理能力、工具调用稳定性、长上下文与记忆机制在 2025—2026 年的快速进步,多Agent 在大多数复杂任务上已经反超工作流:更灵活、更易扩展、对新需求的适配成本更低。

本篇内容仍然有价值——它能帮你理解 AI 应用编排的底层思路,而且多 Agent 系统内部依然会用到工作流式的子结构。但如果你正在从零设计一个新系统,建议优先考虑多 Agent 架构,把工作流作为其中一种实现手段,而不是默认范式。关于多 Agent 的详细介绍,请见后续篇章。

本节目标:用最直白的话讲清楚什么是 AI 工作流、它和"扔给 AI 一个 Prompt"有什么本质区别、为什么 2025 年之后所有真正能落地的 AI 产品几乎都长成"工作流"的样子——不管你是开发者、产品经理、运营、还是只想自己搭一个 AI 助手的普通用户,这一篇读完都能看懂背后在发生什么。

一、先讲个故事:为什么"一句 Prompt"永远做不出真正靠谱的产品

1.1 一个看上去很美的小项目

想象你在一家电商公司做产品。老板跟你说:“我们能不能搞个 AI,自动写商品文案?”

你心想这还不简单。打开 ChatGPT,丢一句:

“帮我写一段商品描述,产品是儿童保温杯,卖点是 24 小时保温、防摔、三种颜色。”

效果还不错。你拿给老板看,老板眼睛一亮:“上线吧。”

一上线就出事了。

• 第二天有人投诉:文案里把"304 不锈钢"写成了"306"——AI 一时兴起编了个号码。
• 第三天又有问题:运营要求文案末尾必须带"双 11 满 199 减 30",AI 时灵时不灵地落了下来。
• 第五天市场部说:不同平台(京东、抖音、小红书)的语气要不一样,小红书要"姐妹们冲",京东要正经,AI 全部一个调调。
• 第七天客服爆炸:有个文案居然写了"建议睡前给孩子喝热水",家长上火,要求道歉。

老板把你叫到办公室:“这玩意儿是不是不行啊。”

你以为的 AI 应用: 用户输入 → Prompt + 模型 → 完美输出 ✨ 实际的 AI 应用: 用户输入 → Prompt + 模型 → ????? ↑ 有时候很好,有时候离谱 有时候漏要点,有时候编事实 有时候不合规,有时候踩红线

1.2 单一 Prompt 为什么注定不够用

回过头来看上面这个项目,问题其实不在于 AI 笨,而在于**"写文案"根本不是一个动作,而是一连串动作**:

1. 校对事实——产品规格不能写错
2. 挑选模板——不同平台不同风格
3. 生成正文——根据卖点和模板写
4. 塞营销信息——优惠券、活动语必须出现
5. 合规审核——不能涉及医疗、绝对化用语
6. 风格润色——口吻要和品牌调性一致

你硬要把这 6 件事一句 Prompt 全塞进去,就像让一个员工同时一边打电话一边写报告一边接客一边煮咖啡——他能做完,但每件事都做得马马虎虎。

让一个 Prompt 干 6 件事: "请为儿童保温杯写文案,要求保证规格正确、 适配小红书风格、加入双 11 优惠、 避免医疗用语、控制 200 字内、最后加号召……" ↓ AI 内心 OS:"老子先做哪一件来着?" 结果:每个要求都顾到了 60 分,综合 60 分以下

而真正能扛住业务的做法,是把这 6 件事拆开,一件一件来,每一步专门负责一件事。

拆开来做: ① 事实核查节点 → 保证规格无误 ↓ ② 平台路由节点 → 选对模板(小红书?京东?) ↓ ③ 文案生成节点 → 按选好的模板写 ↓ ④ 营销注入节点 → 把优惠信息塞进去 ↓ ⑤ 合规审核节点 → 过红线词检查 ↓ ⑥ 风格润色节点 → 调成品牌口吻 ↓ 输出 每一步只干一件事,做完再交给下一步 这就是"工作流"

一句话总结这一节:单一 Prompt 是"独角戏",AI 工作流是"流水线"。让 AI 落地,99% 的情况下,你需要的不是更聪明的 Prompt,而是更清晰的流程拆分。

二、什么是 AI 工作流:流水线、菜谱、地铁线路

2.1 一句话理解

AI 工作流 = 把一个复杂任务拆成多个步骤,固定好顺序、规则、数据流转,让 AI 像流水线工人一样按部就班地完成。

┌───────────────────────────────────────────────────┐ │ AI 工作流 = 把一件大事拆成 N 件小事 │ │ + 规定好谁先谁后 │ │ + 规定好每个人接什么、给什么 │ │ │ │ 每个"工人"可以是 AI、可以是代码、可以是人 │ └───────────────────────────────────────────────────┘

2.2 三个生活化的比喻

比喻 1:餐厅的后厨

你去一家正经餐厅吃饭,从你点菜到菜上桌,中间发生了一长串事:

顾客点菜 ↓ 服务员录入系统 ↓ 后厨打印小票 ↓ 配菜师备菜 ──┐ ├→ 主厨炒菜 酱料师调汁 ──┘ ↓ 传菜员上菜 ↓ 结账

每一个岗位只做自己最擅长的那件事,但是配合起来,你就能在 15 分钟内吃到一盘像样的菜。如果让一个人从头到尾干完所有活——记单、备菜、炒菜、上菜、结账——那家店一晚上做不出 5 桌。

AI 工作流就是把这套"分工 + 流转"搬给 AI 用。每个节点是一个"岗位",有的岗位是 AI(比如生成文案),有的岗位是代码(比如查数据库),有的岗位甚至是人(比如审核)。

比喻 2:菜谱

红烧肉菜谱的步骤是固定的:焯水 → 上糖色 → 翻炒 → 加水炖 → 收汁。换个新厨子来,照着菜谱也能做个八九不离十。

AI 工作流就是给一类任务写一份"菜谱",写好之后,任何一个用户来了,都按这份菜谱给他端菜。不会因为今天 AI 心情好就多炒一道,明天忘了上糖色。这就是"可控、可预测"。

比喻 3:地铁线路图

一条地铁线路有起点、有终点、有固定的站。但有些站会换乘——到了某个站,你可以选择继续坐这条线,也可以换到另一条线。

AI 工作流也长这样:有的步骤是直走,有的步骤是分叉(根据情况选不同路径),有的步骤是回环(没做对就回去重做)。你画出这张图,工作流就成型了。

2.3 工作流和普通流程图有什么不一样

很多人会问:这不就是个流程图嘛,我用 Visio 早就画了。区别在哪?

┌───────────────────┬─────────────────────────────┐ │ 普通流程图 │ AI 工作流 │ ├───────────────────┼─────────────────────────────┤ │ 画给人看 │ 画完真的能跑 │ │ 指导人做事 │ 指导机器做事 │ │ 每个节点是岗位 │ 每个节点是函数/AI 调用 │ │ 数据靠人记 │ 数据自动在节点间流转 │ │ 分支靠人判断 │ 分支靠代码或 AI 判断 │ │ 改了重新印 │ 改了重新跑 │ │ │ │ │ 本质:文档 │ 本质:可执行的程序 │ └──────────────────┴─────────────────────────────┘

简单说,AI 工作流的图画完是能直接执行的——你不仅设计了流程,还把流程跑起来了。这就是它和"画在 PPT 上的方案"最本质的区别。

三、为什么 2025 年之后,所有人都在搭工作流

3.1 Anthropic 的一篇文章,让行业达成了共识

2024 年底,Claude 的母公司 Anthropic 发了一篇技术博客,标题叫《Building Effective Agents》(怎么构建好用的智能体)。这篇文章不长,但在整个 AI 圈里几乎被引用了一万次。它说了一件特别重要的事:

大多数生产级的 AI 应用,其实都不是真正的 Agent,而是工作流。

┌─────────────────────────────────────────────────┐ │ Anthropic 的核心洞察(2024-12) │ │ │ │ "在我们见过的成功案例中, │ │ 工作流(Workflow)比智能体(Agent) │ │ 用得多得多——而且效果好得多。" │ │ │ │ 原因: │ │ • 工作流可控、可调试、成本可预测 │ │ • Agent 听上去酷,但实际不可控、贵、慢 │ │ • 大部分业务问题不需要 Agent,工作流就够了 │ └─────────────────────────────────────────────────┘

这篇文章一出,大量公司从"我们要做 Agent"转向了"我们先做工作流"。结果你看,2025 年至今,真正能跑出业务效果的 AI 产品——客服机器人、文档处理、报表生成、自动化邮件、AI 销售助理——几乎全是工作流的形态。

3.2 工作流 vs Agent:到底有什么本质区别

这个问题很多人搞不清楚。我们用一个特别直观的对比来讲:

┌──────────────────────┬──────────────────────────────┐ │ 工作流(Workflow) │ 智能体(Agent) │ ├──────────────────────┼──────────────────────────────┤ │ 路线由人提前画好 │ 路线由 AI 边走边决定 │ │ │ │ │ AI 只负责"在某一步" │ AI 不仅负责执行,还负责 │ │ 做好分配给它的事 │ 规划、决策、调整下一步 │ │ │ │ │ 执行 100 次,流程 │ 执行 100 次,可能走 100 条 │ │ 100 次都一样 │ 不同的路 │ │ │ │ │ 类比:照菜谱炒菜 │ 类比:让大厨自由发挥 │ │ 类比:导航软件按 │ 类比:在陌生城市自己看着办 │ │ 预设路线开 │ │ │ │ │ │ 优:稳、便宜、可调试 │ 优:灵活、能处理意外 │ │ 劣:遇到没考虑到的 │ 劣:慢、贵、有时候离谱 │ │ 情况就懵 │ │ └──────────────────────┴──────────────────────────────┘

举个例子让你感受一下:

任务:用户问"我那笔 1 月份的退款到账了吗?"

工作流的做法(预设路径): 1. 提取关键信息(订单号 / 时间)→ "1 月份, 该用户" 2. 查数据库找到对应订单 3. 查支付渠道的退款状态 4. 用 AI 把结果组织成自然语言 5. 返回给用户 每一步都是写死的,跑得快、查得准 Agent 的做法(自由发挥): AI 心想:用户在问退款。我应该…… 先查订单?还是先问用户给个订单号? 嗯,他说了"1 月份",我去数据库按时间查吧。 查到了 3 笔订单。哪一笔? 我反问用户?还是都列出来? …… AI 自己决定每一步,灵活但可能绕远

简单的判断方法:

• 如果你的任务步骤是固定的、可以提前画出来的→ 用工作流
• 如果你的任务每次都不一样、需要随机应变→ 用 Agent
• 80% 的业务场景其实是前者

划重点:别一上来就追求 Agent。Agent 是个看上去高大上但坑很多的东西,我们留到第 11 篇专门讲。生产环境里能跑稳的,90% 是工作流。

四、五种最常用的工作流模式

Anthropic 的那篇文章里给出了五种"模式",这五种模式现在已经成了行业事实标准。你以后看任何 AI 产品,几乎都能在这五种里找到对应的影子。我们一个一个讲,每个都配一个生活化场景。

4.1 模式一:Prompt 接力(Prompt Chaining)

核心思想:把一个大任务拆成几步,前一步的输出 = 下一步的输入,接力跑。

步骤A → 步骤B → 步骤C → 步骤D 提取 分析 生成 校验 信息 要点 报告 合规 每一步只干一件小事,做完递给下一棒

生活类比:工厂里的接力流水线。卷烟厂里,A 工位卷烟丝,B 工位贴标签,C 工位装盒,D 工位封箱。每一步只做一件事,做错了立刻能定位是哪一步。

典型场景:

• 写营销邮件:第一步生成草稿 → 第二步翻译成英文 → 第三步检查语法 → 第四步加个性化称呼。
• 法律文档处理:第一步识别合同类型 → 第二步抽取关键条款 → 第三步比对历史模板 → 第四步标注风险点。
• 写技术博客:第一步列大纲 → 第二步逐节扩写 → 第三步润色语气 → 第四步加配图建议。

它什么时候特别好用:任务能清楚地拆成几个先后有序的步骤,每一步的输出可以作为下一步的输入。

它什么时候不适合:任务步骤之间没有明显先后关系,或者中间任何一步出问题都会让后面全垮——这种链式结构很脆弱,一环错了下一环也跟着错。

4.2 模式二:路由(Routing)

核心思想:先判断这是个什么类型的任务,再分流到对应的处理路径。

用户请求 ↓ 分类节点(AI 判断) / | \ ↓ ↓ ↓ 问候 咨询 投诉 简单 走 RAG 转人工 回答 检索 或 走 知识库 特殊话术

生活类比:医院的分诊台。无论你是肚子疼、感冒还是骨折,先到分诊台,护士看一眼,告诉你去哪个科。骨科、内科、急诊各有各的处理流程,效率比"全部塞给一个全科医生"高得多。

典型场景:

• 客服机器人:用户消息进来 → 判断是查询?投诉?咨询?闲聊? → 分别走不同处理流程。
• 多语言翻译:先判断是什么语言 → 再调对应的翻译模型(英译中和日译中可能用不同模型)。
• 分级模型调度:简单问题用便宜的小模型,复杂问题用贵的大模型——节省成本。

它什么时候特别好用:输入种类差异很大、不同种类需要完全不同的处理——把它们硬塞到一个 Prompt 里只会两边都不讨好。

关键点:分类节点本身要稳。如果分类错了,后面所有事都白做。所以这一步的 Prompt 要好好打磨,有时候甚至要专门微调一个小分类模型来做。

4.3 模式三:并行(Parallelization)

核心思想:几件事互相不依赖,就让它们同时干,最后一起汇总。

用户提问 ╱ | ╲ ↓ ↓ ↓ 搜网页 查数据库 查知识库 ╲ | ╱ ╲ | ╱ ↓ ↓ ↓ 合并 / 汇总 ↓ 生成最终回答

生活类比:你要做晚饭,让一个人同时洗菜、煮饭、炒菜、摆盘?他得忙到崩溃。但如果家里 4 个人,洗菜、煮饭、炒菜、摆盘各自分头干,半小时上桌。这就是并行。

典型场景:

• 多源信息聚合:同时去 Google、Bing、内部 wiki 搜资料,然后把结果合并。
• 多角度评审:让 AI 同时从"安全角度"“法律角度”"市场角度"分别评审一份合同,最后汇总。
• 多个语言版本:把一篇产品介绍同时翻译成英文、日文、西班牙文,而不是排队一个一个翻。

并行还有一种常见用法叫"投票":同一件事让 AI 干 3 次,然后选出现频率最高的那个答案。这是个很巧妙的做法,可以提升结果的稳定性——尤其在需要做判断、容易"瞎编"的场景下。

它什么时候特别好用:几个子任务不依赖彼此的输出,可以独立完成。

它什么时候不适合:任务之间有强依赖——后面那步要等前面那步的结果,这种就只能串行,不能并行。

4.4 模式四:编排-执行(Orchestrator-Workers)

核心思想:有一个"项目经理"角色,先看任务、做规划、把活分给若干"工人"、最后再把结果汇总。

用户大任务 ↓ ┌──────────┐ │ 项目经理 │ ← 由一个 AI 充当 │ (规划者) │ 决定:这事要分几步、 └──────────┘ 每步交给谁 / | \ / | \ ↓ ↓ ↓ 工人A 工人B 工人C (AI) (AI) (代码) \ | / \ | / ↓ ↓ ↓ ┌──────────┐ │ 项目经理 │ ← 再回到项目经理 │ (合成者) │ 把每个工人的结果 └──────────┘ 合并成最终答案 ↓ 输出

生活类比:装修房子。项目经理(包工头)先评估你家户型 → 然后决定今天叫水电工来干这个、明天叫木工来干那个、后天叫漆工。每个工人只做自己擅长的事,包工头负责调度。

典型场景:

• 写一篇综合研究报告:经理 AI 先列大纲(分成"市场"“技术”“竞品”"趋势"四节)→ 分给四个研究员 AI 各写一节 → 经理 AI 收回来串成完整报告。
• 复杂代码任务:经理 AI 看到任务后,把代码分成"前端"“后端”"数据库迁移"三块 → 分给三个写代码 AI → 最后整合成 PR。
• 多步推理问题:经理 AI 拆解"这道数学题需要先算 X 再算 Y" → 分别求解 → 合并答案。

它什么时候特别好用:任务复杂、且子任务的内容/数量在事前不一定能完全规定死。需要一个"统筹者"现场决定怎么拆。

它和"链式接力"的区别:接力是先后顺序固定的;编排是怎么拆、拆几个由经理 AI 临场决定的——更动态。

4.5 模式五:评估-优化(Evaluator-Optimizer)

核心思想:写完不是终点。让 AI 自己当评委评一遍,不行就拿着评语再写一版,直到过关。

┌────────────┐ │ 生成者 AI │ 写一版 └────────────┘ ↓ ┌────────────┐ │ 评估者 AI │ 打分,给意见 └────────────┘ ↓ 够好了吗? ╱ ╲ 不够好 够好 ↓ ↓ 回去再写 输出最终结果 ↑ 带着评语回去

生活类比:你写了篇论文,先自己读一遍发现问题,改一版;再读一遍,再改;直到自己觉得 OK 了再交给老师。或者你做了道菜,自己尝一口,咸了加水、淡了加盐,反复调整。

典型场景:

• AI 翻译润色:翻译 → 评估忠实度和流畅度 → 不行就重译。
• 代码生成 + 自动测试:AI 写代码 → 跑测试 → 不通过就把测试错误返还 AI → AI 改 → 再测,直到通过(或达到最大重试次数)。
• 文案生成 + 合规审核:写文案 → 合规审核 AI 检查 → 不合规就返回去改。

它什么时候特别好用:输出质量很难一次性达标,但是又容易判断好坏——比如代码能不能跑、翻译流不流畅、合规不合规,这些都是有明确标准的。

核心要素是"可评估":如果你连"什么是好结果"都说不清楚,这个模式就用不起来。

4.6 五种模式的速查表

┌──────────────┬─────────────────┬──────────────────────┐ │ 模式 │ 核心特点 │ 什么时候用 │ ├──────────────┼─────────────────┼──────────────────────┤ │ Prompt 接力 │ 步骤固定先后 │ 大任务能拆成顺序步骤 │ │ Routing │ 分诊→不同分支 │ 输入类型差异大 │ │ Parallelize │ 同时干→汇总 │ 子任务相互独立 │ │ Orchestrator │ 项目经理临场拆 │ 任务复杂、拆法不固定 │ │ Evaluator │ 写完→评→重写 │ 质量要求高,有评估标准 │ └──────────────┴─────────────────┴──────────────────────┘ 实际项目里,这五种很少单独用, 通常是组合在一起—— 比如:Routing + Prompt 接力 + Evaluator

五、人在回路(Human-in-the-Loop):AI 不能什么都自己做主

5.1 完全自动化是个陷阱

很多人第一次设计工作流时,会想着"全自动,完全不需要人"。这是新手最容易犯的错。

全自动化听起来很美: 用户输入 → AI 全程处理 → 自动执行 → 完成 但实际上往往是: 用户输入 → AI 全程处理 → 自动执行 → 灾难 ↑ 发出去的邮件错了, 转出去的钱错了, 删掉的数据没了…… 没人审一眼就执行了

任何高风险动作前,都应该让一个人看一眼。这不是不信任 AI,这是工程上的常识——就像火箭发射前要有最后的"取消"按钮,医生开刀前要有"双签确认"。

5.2 哪些场景必须有人介入

┌──────────────────────────────────────────────────┐ │ 必须人介入的"红线"场景 │ ├──────────────────────────────────────────────────┤ │ • 涉及钱:转账、退款、下单、付款审批 │ │ • 涉及法律责任:合同生效、保险理赔 │ │ • 涉及隐私:发邮件给客户、对外披露信息 │ │ • 涉及不可逆:删数据、关停系统、停服务 │ │ • AI 自己拿不准:置信度低、意图模糊 │ │ • 监管要求:金融、医疗、教育的关键决策 │ └──────────────────────────────────────────────────┘

5.3 怎么把"人"嵌入工作流

最常见的做法,就是在工作流里设置一个审批节点——到了这一步,工作流不会自动往下走,而是暂停,等待某个人在后台点"通过"或"拒绝",再继续。

AI 起草邮件 ↓ AI 自动审一遍合规 ↓ ┌──────────────┐ │ 人工审核节点 │ ← 这里暂停,等运营点确认 │ ⏸️ 等待中 │ └──────────────┘ ↓ (审批通过) 发送邮件

这种"暂停 + 等待"的能力,在工程上有个专门的术语叫interrupt(中断)或breakpoint(断点)。所有像样的工作流框架都内置了这个能力。LangGraph 用interrupt_before,Dify 在节点上有"等待人工"开关,n8n 直接有Wait节点。

5.4 一个有意思的进阶玩法:置信度路由

更聪明的做法是让 AI 自己判断"这个我有把握吗":

AI 处理一个客服问题 ↓ AI 给自己的回答打个置信度分 ↓ 分数高?(>0.9) ╱ ╲ 是 否 ↓ ↓ 直接发 给人工审一眼 "我有把握的事自动干,没把握的事请人来看。" 这样既保证了效率,又控住了风险。

这就是 2025 年很多客服系统的标准做法——70% 的简单问题 AI 全自动答完,30% 的复杂问题转人工,每个月省下来一大笔成本。

六、搭工作流的工具盘点(2026 年最新)

讲了这么多概念,现在来看实战:真要搭一个工作流,用什么工具?

工具大致分三派:写代码派、拖拽派、通用自动化派。我们一派一派看。

6.1 写代码派:LangGraph

┌─────────────────────────────────────────────┐ │ LangGraph(LangChain 团队出品) │ │ │ │ 定位:用 Python/JavaScript 写工作流的 │ │ 代码框架 │ │ │ │ 核心概念: │ │ • State(状态):节点间共享的笔记本 │ │ • Node(节点):一个处理函数 │ │ • Edge(边):节点之间的连线 │ │ │ │ 适合: │ │ ✓ 需要严格的代码控制 │ │ ✓ 要做复杂的条件、循环 │ │ ✓ 要嵌入到现有 Python/JS 项目里 │ │ ✓ 团队是工程师为主 │ └─────────────────────────────────────────────┘

LangGraph 是目前生产环境用得最多的代码级工作流框架,大公司用得尤其多。它的好处是灵活、可控、能进版本管理——每次改流程都是改代码,清清楚楚地走 PR、code review、CI/CD,工程化程度很高。

下面是一个最简化的伪代码,让你感受它长什么样(完整代码不重要,知道结构就行):

# 1. 定义共享状态(像一个共享笔记本)state={"user_message":"我的快递到哪了","intent":None,"answer":None,}# 2. 定义节点(每个节点是一个函数)defclassify_intent(state):...# 判断意图defquery_database(state):...# 查数据库defwrite_answer(state):...# 生成回答# 3. 把节点连起来,画图graph.add_edge("classify_intent","query_database")graph.add_edge("query_database","write_answer")# 4. 跑起来result=graph.run(state)

LangGraph 还内置了你可能想要的高级能力:循环、条件分支、断点暂停、人工介入、状态持久化——这些都不用自己造轮子。

类似的还有LangChain Expression Language (LCEL)、Microsoft AutoGen、Anthropic Claude Agent SDK(2025 年新出,我们在第 21 篇会细讲)。它们各有侧重,但思路都差不多——用代码描述图、然后执行图。

6.2 拖拽派:Dify、Coze、FastGPT、n8n AI Studio

┌─────────────────────────────────────────────┐ │ 拖拽派工作流平台 │ │ │ │ 定位:可视化界面,拖拖拽拽就能搭工作流 │ │ │ │ 适合: │ │ ✓ 不会写代码的产品/运营/业务 │ │ ✓ 需要快速验证创意 │ │ ✓ 给非技术同事自己搭工具 │ │ ✓ 中小企业、内部工具 │ └─────────────────────────────────────────────┘

Dify(开源,可私有部署)

特点: • 开源、自部署、数据全在自己手里 • 视觉化的工作流编辑器 • 内置 RAG、知识库、Agent • 支持几乎所有主流 LLM(国内外) • 一键发布为 API、聊天界面、嵌入网页 适合场景: • 企业内部工具、数据敏感不能上云 • 需要 RAG + 工作流组合 • 团队里既有产品也有工程师

Dify 现在(2026 年)是国内外都很火的开源 AI 平台之一。如果你想搭一个内部的 AI 助手,而且数据不能传到第三方,Dify 几乎是首选。

Coze(扣子)(字节跳动出品)

特点: • 字节出品,有海量插件市场 • 一键发布到飞书、微信、抖音、Discord • 国内版叫"扣子",国际版叫 Coze • 免费额度比较慷慨 • 不需要部署,即开即用 适合场景: • 个人开发者、小团队 • 想快速做一个聊天机器人 • 不想折腾服务器

Coze 的最大优势是生态——它的插件市场里有几千个现成的插件,从查天气到查股票,直接拖进来就用。坏处是数据托管在字节那边,涉及商业敏感数据要谨慎。

FastGPT(国产开源,RAG 强项)

特点: • 国产开源,中文支持非常好 • 偏 RAG 知识库 + 工作流的组合 • 视觉化工作流编辑 • 私有部署友好 适合场景: • 国内中小企业搭知识库问答 • 客服、内部知识查询

n8n + AI 节点(自动化老牌玩家进军 AI)

n8n 本来是做通用工作流自动化的,2024-2025 年加了一堆 AI 节点(OpenAI、Anthropic、Ollama 等等),变成了"AI + 自动化"的混合体。它的特点是400+ 第三方系统的现成集成——Slack、GitHub、Notion、各种数据库、各种邮箱——拖几下就能把 AI 接进你的现有业务系统。

┌─────────────────────────────────────────────┐ │ 拖拽派四个工具速选 │ ├──────────────┬──────────────────────────────┤ │ Dify │ 开源、自部署、企业内部首选 │ │ Coze │ 字节生态、免部署、快上线 │ │ FastGPT │ RAG+工作流、中文场景 │ │ n8n │ 跨系统集成、现有业务接 AI │ └──────────────┴──────────────────────────────┘

6.3 通用自动化派:Zapier、Make、微软 Power Automate

┌─────────────────────────────────────────────┐ │ 通用自动化派 │ │ │ │ 定位:本来就是做"软件之间互相打通"的, │ │ 现在加了 AI 节点 │ │ │ │ 适合: │ │ ✓ 工作流的核心是"在 N 个系统间流转" │ │ ✓ AI 只是其中的一两步,不是主角 │ │ ✓ 业务流程驱动,不是 AI 驱动 │ └─────────────────────────────────────────────┘

举个例子:你想要"每天早上 9 点,从 Salesforce 拉昨天新增的客户,让 AI 写一封欢迎邮件,然后通过 Outlook 发出去,同时记一行日志到 Notion"。

这种串联多个 SaaS 系统、AI 只是一个小环节的场景,Zapier、Make、Power Automate 这类工具最舒服。它们已经接入了几千个常见的 SaaS,你不需要写一行 API 调用代码,拖一拖就好。

6.4 怎么选:一张表帮你定

┌────────────────────┬──────────────────────────────────┐ │ 你的情况 │ 推荐 │ ├────────────────────┼──────────────────────────────────┤ │ 程序员主力,生产级 │ LangGraph / Claude Agent SDK │ │ 内部工具,数据敏感 │ Dify(自部署) │ │ 快做个聊天机器人 │ Coze(扣子) │ │ 搞知识库问答 │ FastGPT / Dify │ │ 接现有 SaaS 系统 │ n8n / Make / Zapier │ │ 不会写代码,业务方 │ Coze / Dify(可视化) │ │ 最大复杂度的项目 │ LangGraph(代码控制最强) │ └────────────────────┴──────────────────────────────────┘

小贴士:实际项目中,这些工具经常组合使用——比如核心工作流用 LangGraph 写,但业务方临时要的小工具就用 Dify 让运营自己搭;或者外层用 n8n 做调度,中间塞一个 LangGraph 的服务做复杂逻辑。没有谁取代谁,各有所长。

七、避坑指南:工作流不是"越复杂越牛"

7.1 坑一:为了用 AI 而用 AI

你看到很多教程会展示"用 AI 做 XX"、“用 LLM 优化 XX”,看完热血沸腾,回去把整个流程的每一步都换成了 AI 调用。

❌ 反例: 用户上传发票 ↓ AI 识别上面的金额(其实 OCR 就行) ↓ AI 检查金额格式(其实正则就行) ↓ AI 把金额加总(其实 sum() 就行) ↓ AI 生成 Excel(其实 pandas 就行) 结果:每一步都贵、慢、还可能算错

AI 应该用在它真正擅长的地方——理解模糊语义、生成自然语言、做开放式判断。能用确定性代码搞定的事,不要丢给 AI。这条铁律省下来的钱和稳定性都是巨大的。

✅ 正确做法: 用户上传发票 ↓ OCR 识别(确定性程序) ↓ 正则校验金额格式(确定性程序) ↓ AI 判断"这是发票还是收据"(模糊判断,AI 擅长) ↓ sum() 加总(确定性程序) ↓ AI 写一段总结说明(自然语言生成,AI 擅长)

7.2 坑二:节点切得越细越好?不一定

新手设计工作流时,经常过度拆分——什么都想拆一个独立节点。结果工作流的图变成一张密密麻麻的网,几十个节点。

❌ 反面教材: 写一封邮件被拆成 12 个节点 ↓ 开头节点 → 称呼节点 → 过渡节点 → 正文节点1 → 正文节点2 → 正文节点3 → 落款节点 → 表情节点 → 校对节点 → …… 问题:每个节点都是一次 LLM 调用 12 次调用 = 12 倍延迟 + 12 倍成本 而且节点之间反而协调不好

经验法则:一个节点的责任应该既不太大也不太小。判断标准是:这件事用一两段 Prompt 能不能讲清楚?如果能,放一个节点;如果讲不清楚,才拆分。

7.3 坑三:不做可观测性,出了问题两眼一抹黑

工作流跑起来之后,经常会遇到这种情况:

用户:“刚才的回答不对啊。”
你:“哪里不对?让我看看……”
你:(打开后台,啥也没有,不知道哪一步出错)

这就是**没有可观测性(Observability)**的痛苦。

工作流出问题时,你必须能回答这些: • 哪个节点执行失败了? • 每个节点收到了什么?返回了什么? • 每个节点用了多长时间? • 这次跑总共烧了多少 token?多少钱? • 这种问题之前有没有出现过?

主流工具都内置了这种能力,一定要打开:

• LangGraph配合LangSmith——每次执行都全程录像,在网页上像看流水账一样查每一步。
• Dify自带运行日志面板。
• Coze有调试器,能看每一步的输入输出。
• n8n每次执行都有完整的执行历史。

LangSmith 追踪面板长这样: ┌─ 工作流执行 #4823(总耗时 3.6s,成本 $0.002) │ ├─ classify_intent (1.2s, 150 tokens) │ IN: "我的快递到哪了?订单 12345" │ OUT: "query" │ ├─ query_database (0.1s) │ IN: intent="query" │ OUT: "订单 12345 已发货" │ └─ generate_answer (2.3s, 320 tokens) IN: "基于以下信息..." OUT: "您的订单 12345 已发货,预计明天到达。"

有了这个,出问题第一时间就能定位是哪一步。这一步省不得。

7.4 坑四:把工作流当 Agent 来用

最后一个常见错误:期待工作流处理它没设计过的情况。

工作流的本质是"预设好的路径"。如果用户的问题超出了你设计的路径,工作流要么走错路,要么直接懵。这时候不要试图把工作流改得越来越复杂去覆盖每种情况——那条路是无底洞。

正确的做法是:把"不在预设路径里的情况"识别出来,要么交给人,要么交给 Agent。这就回到了我们前面说的"工作流 + Agent + 人"三者结合的思路。

常见问题(80%) → 工作流处理(快、稳、便宜) 罕见问题(15%) → Agent 处理(灵活但慢) 棘手问题(5%) → 转人工

八、本篇小结

┌────────────────────────────────────────────────────┐ │ 本篇知识地图 │ │ │ │ AI 工作流 = 把复杂任务拆成多步,固定流程, │ │ 让 AI 像流水线一样按部就班地完成 │ │ │ │ 为什么需要工作流(而不是单一 Prompt): │ │ • 拆分清楚的步骤更可控 │ │ • 每步只做一件事,质量更高 │ │ • 出问题更容易定位 │ │ │ │ 工作流 vs Agent: │ │ • 工作流:路线由人设计,稳定可控 │ │ • Agent: 路线由 AI 决定,灵活但不稳 │ │ • 80% 业务用工作流就够了 │ │ │ │ 五种核心模式(Anthropic 共识): │ │ ├── Prompt 接力:步骤接力 │ │ ├── Routing:分诊台 │ │ ├── 并行:同时干→汇总 │ │ ├── Orchestrator:项目经理调度 │ │ └── Evaluator:写完→评→改 │ │ │ │ Human-in-the-Loop:重要操作必须有人介入 │ │ │ │ 工具三大派: │ │ ├── 写代码派:LangGraph、Claude Agent SDK │ │ ├── 拖拽派: Dify、Coze、FastGPT │ │ └── 自动化派:n8n、Zapier、Make │ │ │ │ 避坑要点: │ │ • 别为了用 AI 而用 AI │ │ • 节点别切太细 │ │ • 一定要做可观测性 │ │ • 别期待工作流处理预设外的情况 │ └────────────────────────────────────────────────────┘

九、扩展学习资源

必读

• Anthropic: Building Effective Agents —— 工作流和 Agent 选择的权威讨论,2024 年底发布,影响了整个行业。强烈建议每个做 AI 应用的人读完。
• LangGraph 官方文档 —— 最主流的代码级工作流框架,文档质量高、例子多。
• Dify 官方文档 —— 开源 AI 应用平台,可视化工作流的代表。

推荐

• Coze 开发文档 —— 字节跳动 AI 平台,适合快速搭聊天机器人。
• FastGPT 文档 —— 国产开源,RAG + 工作流强项。
• n8n 文档 —— 通用工作流自动化平台,适合 AI 接入现有业务系统。
• LangSmith 文档 —— 专业的 AI 工作流可观测性工具。

动手实践(由浅入深)

1. 入门:在 Coze 或 Dify 上,搭一个最简单的"客服分诊机器人"——根据用户问题分流到不同的回答路径。
2. 进阶:用 Dify 搭一个"博客自动写作工作流"——用户输入主题 → 大纲 → 分段写 → 润色 → 输出。
3. 挑战:用 LangGraph 实现一个"翻译 + 审校"的工作流,带评估-优化循环——AI 翻译完后,自己当审稿人,不满意就重译。
4. 生产级:把上面的工作流接入 LangSmith,跑 100 次看一下耗时分布、成本、错误率。

下一篇预告:第 11 篇我们将进入AI Agent(智能体)的世界——如果说工作流是"按菜谱做菜",Agent 就是"让大厨自由发挥"。我们会聊聊 Agent 是怎么"思考"的、它跟工作流到底差在哪里、什么时候才真的值得用 Agent,以及为什么 2025-2026 年 Agent 突然又火起来了。

声明：本博客内容素材来源于网络，文章由AI技术辅助生成。如有侵权或不当引用，请联系作者进行下架或删除处理。