常见的工作流编排模式有哪些？各适合什么场景？

简化版

常见的有五种：链式（上一步的输出作为下一步的输入，适合能拆成固定步骤的任务）、路由（先分类，再按类别进入不同的处理链，适合输入差异大的任务）、并行（把任务拆成互不依赖的几块同时做再汇总，或者同一任务做几次再投票，适合要提速或要多角度的任务）、编排—工作者（由模型动态拆出子任务、派发、汇总，适合子任务事先数不清的任务）、评估—优化（一个角色产出、另一个角色按标准评审，不合格就带着意见重做，适合有明确验收标准的任务）。选型从最简单的链式开始，只有在它解决不了时才加复杂度；五种模式可以组合，一个真实系统往往同时用到好几种。

详细版

模式	结构	适合	主要代价
链式	A → B → C，中间可加代码检查	步骤固定、每步更简单	延迟按步数累加
路由	分类 → 走对应分支	输入类型差异大，各类要不同处理	分错类就全盘走错
并行	拆块同时做 → 汇总；或多次投票	子任务独立、要提速或要多角度	汇总逻辑复杂，成本按份数增加
编排—工作者	模型拆任务 → 派发 → 汇总	子任务个数和内容事先不确定	最难控制和调试
评估—优化	生成 ↔ 评审，直到合格或到上限	有明确的验收标准	调用次数成倍增加，必须设上限

几个判断要点：

• 前四种的区别在「任务怎么拆」：链式按先后拆、路由按类别拆、并行按独立的块拆、编排—工作者让模型临场拆；
• 评估—优化关注的是「做得够不够好」，常作为其他模式里的一个环节；
• 这五种都属于工作流：流程结构由代码定义，模型在节点里干活；如果连下一步去哪都交给模型，就进入 Agent 的范畴。

完整版教学

一、为什么要有「模式」这层抽象

一次模型调用能做的事是有限的：输入太长会被截断、指令太多会顾此失彼、一次写完没有机会检查。编排模式就是把一个大任务拆成多次调用的几种固定套路，每种套路回答一个问题：任务按什么维度拆、拆完怎么合、中间怎么检查。

有了模式，设计讨论就能从「这个需求怎么做」收敛到「这是哪几种模式的组合」。比如「生成一份营销文案并做合规检查」是链式；「按投放渠道写不同风格的文案」是路由；「同时写三版挑最好的」是并行加评估。说清楚模式，也就说清楚了延迟、成本和风险落在哪里。

记忆钩子：五种模式按「怎么拆」记：按先后拆是链式，按类别拆是路由，按独立块拆是并行，让模型临场拆是编排—工作者；「够不够好」单独一种，叫评估—优化。

二、链式：最常用，也最该先考虑

链式把任务拆成几个顺序步骤，上一步的输出是下一步的输入。它的价值在于每一步都变简单了：提取卖点只管提取，写文案只管写，起标题只管起标题。步骤之间还可以插一道代码检查（gate），不合格就停，不让错误往下传。

商品信息 → [提取卖点] → 卖点列表 → [代码检查：至少 3 条] → [写文案] → 文案 → [起标题]
                                        └ 不满足：直接结束并报错

代价是延迟累加：3 步、每步平均 4 秒，总共约 12 秒。如果某一步的输入不依赖上一步，就不该硬串在链上，这正是并行模式要解决的。

三、路由：先分类，再各走各的路

输入之间差异很大时，一套提示词难以兼顾所有情况。路由先做一次分类，再按类别进入专门的处理链：

用户问题 → [分类] ─┬─ 退款类 → 退款处理链（查订单、查规则、生成答复）
                   ├─ 技术类 → 技术支持链（查文档、生成排查步骤）
                   └─ 其他   → 通用答复链

分类可以由模型做，也可以由规则做（关键词、表单字段、业务状态）。能用规则就先用规则，因为规则确定、可测试；输入是自然语言、规则写不全时再用模型分类。路由的主要风险是分错类：分类准确率 95% 时，每 100 个请求就有约 5 个走进错误的分支，所以要为「分不清」留一个兜底分支，并统计各分支的命中情况。

四、并行：拆成独立的块，或者多做几次

并行有两种形态：

形态	做法	例子
分块（sectioning）	把任务拆成互不依赖的几块同时做，最后汇总	长文档按段分别提取要点，再合并成一份
投票（voting）	同一个任务做几次，比较结果或取多数	同一段内容让三个评审分别判断是否违规

用一个算例看提速效果：三个子任务分别耗时 4、5、6 秒，串行执行要 15 秒；并行执行取最慢的 6 秒，再加汇总 3 秒，共 9 秒。token 成本不会减少，并行省的是时间。分块模式在工程上也可以顺序执行，比如逐段提取、最后一次合并，这时省不了时间，但解决了「一次放不下」的问题。

串行： 4 + 5 + 6         = 15 秒
并行： max(4, 5, 6) + 3  =  9 秒（汇总 3 秒）

并行的难点在汇总：几块结果有重叠要去重，有冲突要裁决；子任务部分失败时，要决定是重试、跳过还是整体失败。

五、编排—工作者：让模型临场拆任务

并行要求事先知道拆成哪几块。有些任务做不到，比如「修改代码库里所有受影响的文件」，受影响的文件有几个、是哪些，要读了代码才知道。编排—工作者让一个编排者模型先分析任务、动态生成子任务，派发给工作者执行，再汇总结果。

它和并行的区别在于子任务是运行时由模型决定的，因此灵活性最高，也最难控制：子任务数量没有上界时成本失控，编排者拆错了后面全错。工程上至少要限制子任务个数、给每个子任务设超时，并把拆出来的计划落库，方便事后查「它当时为什么这么拆」。

六、评估—优化：生成和评审分开

评估—优化由两个角色组成：一个负责产出，一个按标准评审并给出意见；不合格就带着意见重做，直到合格或达到轮数上限。它适合两个条件同时成立的场景：有清楚的验收标准，而且带着具体意见重做确实能改好。

生成 → 评审 ─┬─ 合格 → 结束
   ↑         └─ 不合格 → 把问题清单交回生成（第 N 轮）
   └──────────────────────── N 达到上限 → 按规则收尾

每多一轮就多两次调用，上限为 3 轮时最多 6 次调用。评审可以是模型，也可以是代码规则，设计要点见「评估—优化循环怎么设计？为什么必须有轮数上限，用完了交付哪一版？」。

七、怎么选、怎么组合

选型从简单往复杂走，每加一层都要能说出「上一层解决不了什么」：

你遇到的问题	考虑的模式
一次调用做不好，但步骤很清楚	链式
不同类型的输入需要完全不同的处理	路由
输入太长，或者几个子任务互不依赖	并行（分块）
需要更可靠的判断	并行（投票）
子任务数量和内容要看了才知道	编排—工作者
有验收标准，一次写不达标	评估—优化

真实系统里模式是嵌套的：一条链的某一步内部是并行分块，链的最后一步是评估—优化，链的入口有一个路由。设计时把每一层用的模式标出来，延迟、成本和失败点也就跟着清楚了。这五种都属于工作流，流程结构由代码定义；如果连「下一步去哪」都交给模型临场决定，就进入 Agent 的范畴，两者的分界见「AI Agent 与 Workflow 有什么区别？应该如何选型？」。

八、常见误区与追问

• 误区：模式越复杂效果越好。 每多一层就多一份延迟、成本和失败点，能用链式解决就不要上编排—工作者。
• 误区：并行能省钱。 并行省的是时间，token 用量不变，投票模式反而按份数成倍增加。
• 误区：路由一定要用模型分类。 能由规则、表单字段、业务状态判断的，用规则更确定、更好测。
• 误区：评估—优化不用设上限，直到合格为止。 有的问题怎么改都过不了，没有上限就会无限循环，必须规定轮数用完后怎么收尾。
• 误区：编排—工作者就是并行。 并行的子任务事先确定，编排—工作者的子任务由模型在运行时拆出来。
• 追问：链式的中间检查应该用代码还是模型？ 能写成规则的（条数、格式、字段是否齐全）用代码；需要理解语义的才用模型，而且要设上限。
• 追问：分块处理长文本，汇总这一步要注意什么？ 各块结果可能重复或冲突，汇总时要去重和裁决；只有一块时不需要再汇总一次。

九、加强记忆

五种编排模式按「怎么拆」记：链式按先后拆，每步更简单、延迟累加，步骤间可加代码检查；路由按类别拆，能用规则就不用模型，要留兜底分支；并行按独立块拆或多做几次投票，省时间不省 token，难在汇总；编排—工作者让模型临场拆，最灵活也最难控，要限子任务个数；评估—优化管「够不够好」，要有明确标准和轮数上限，每轮两次调用。选型从链式往上加，每加一层说清上一层解决不了什么；真实系统是多种模式嵌套，把每层的模式标出来，延迟、成本、失败点就一目了然。

项目实战落地

项目里怎么做的

《AI Agent智能会议纪要辅助系统》从一段录音到一份定稿纪要，一路用了三种模式：

转写（异步任务）──成功──▶ 生成纪要（异步任务）──草稿/已确认──▶ Agent 自检（反思环）
                         ├ 分段提取 × N 段                     ├ 审查 → 不通过 → 重写 → 复审
                         └ 多于一段时再合并一次                  └ 没到轮数上限就回到审查

• 链式 + 关卡：三段各是一个独立的后台任务，各有自己的状态，由用户在页面上逐段发起；只有转写成功的任务才有「生成纪要」按钮，接口里也会再判一次；只有草稿或已确认的纪要才能发起自检；
• 分块（顺序执行）：长转写按片段边界切段，每段调一次分段提取模板，多于一段再调一次合并模板把各段的结构化结果合成一份；各段是逐段调用的，不是并发；
• 评估—优化：自检是一张 LangGraph 状态图，审查判定不通过就把问题清单交给重写，没到轮数上限就回到审查。

《AI企业流程编排系统》的分支是按规则路由：示例客服流程里条件节点算出「回复是否有效」，两条出边各带一个条件表达式，有效走 HTTP 节点记录工单，无效直接到结束节点。

为什么这样取舍

• 三段分开而不是一条链跑到底：每段都有自己的状态、进度和失败原因，转写失败在转写页重试，纪要生成失败在纪要页重试；纪要不满意，可以基于同一个已成功的转写任务重新生成，不必从转写重来。
• 分支用规则：判断回复是否为空不需要理解语义，写成表达式就能确定地判。

面试官还会追问

• 发起纪要生成前，为什么要先检查分段提取和合并两条模板都已启用？
• 同一场会议已经有一份纪要正在生成，这时再点「生成纪要」会怎样？
• 纪要自检跑满轮数上限仍未通过时，修订稿会自动写回纪要吗？

学完《AI Agent智能会议纪要辅助系统》，上面这些追问你都会迎刃而解。