⚠️ 过时提示（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 笨,而在于"写文案"根本不是一个动作,而是一连串动作:
- 校对事实——产品规格不能写错
- 挑选模板——不同平台不同风格
- 生成正文——根据卖点和模板写
- 塞营销信息——优惠券、活动语必须出现
- 合规审核——不能涉及医疗、绝对化用语
- 风格润色——口吻要和品牌调性一致
你硬要把这 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. 定义节点(每个节点是一个函数)
def classify_intent(state): ... # 判断意图
def query_database(state): ... # 查数据库
def write_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 工作流可观测性工具。
动手实践(由浅入深)
- 入门:在 Coze 或 Dify 上,搭一个最简单的"客服分诊机器人"——根据用户问题分流到不同的回答路径。
- 进阶:用 Dify 搭一个"博客自动写作工作流"——用户输入主题 → 大纲 → 分段写 → 润色 → 输出。
- 挑战:用 LangGraph 实现一个"翻译 + 审校"的工作流,带评估-优化循环——AI 翻译完后,自己当审稿人,不满意就重译。
- 生产级:把上面的工作流接入 LangSmith,跑 100 次看一下耗时分布、成本、错误率。
> 下一篇预告:第 11 篇我们将进入 AI Agent(智能体) 的世界——如果说工作流是"按菜谱做菜",Agent 就是"让大厨自由发挥"。我们会聊聊 Agent 是怎么"思考"的、它跟工作流到底差在哪里、什么时候才真的值得用 Agent,以及为什么 2025-2026 年 Agent 突然又火起来了。
声明：本博客内容素材来源于网络，文章由AI技术辅助生成。如有侵权或不当引用，请联系作者进行下架或删除处理。
