LangGraph常见WorkFlow-七种编排模式

上篇你跑通了 State / Node / Edge 。这篇是 LangGraph 专题第 03 篇——把「会画图」升级成「会点名模式」：七种常见 WorkFlow，谁控流、何时用、仓库锚在哪。

小明会画边了，却不会「点菜」

小明把天气/制度路由跑通后，产品又丢来三句需求：

「翻译→润色→质检要固定三步。」
「报告要拆多章并行写再汇总。」
「草稿不行就打回重写，直到过审。」

小明把条件边复制了三遍，图越贴越乱。他问老张：”是不是每种需求都要从零发明拓扑？”

老张摇头：”不用。LangGraph 值钱的不只是简单 Agent，而是用图灵活编排复杂工作流。业界已经沉淀出一批可复用模式。先分清两拨人：

左侧：流程你写死，LLM 嵌在步骤里   → 稳、可预期
右侧：LLM（或人）参与决定下一步     → 更智能、要约束

左边像流水线；右边像带导航的司机。七种模式，就是这两种哲学的具体菜谱。”

总览：七种模式一张表

先把本模块可验证产出摆桌上——读完再对照仓库：

组合例（加餐）：可控 RAG = Chaining + Routing → rag-workflow/。

1. Prompt Chaining：顺序链条

START → step_a → step_b → step_c → END

上一步输出写入 State，下一步接着用。适合你明确知道步骤顺序、不想让模型乱跳。

normalize → shout 就是无 LLM 的链式骨架；带模型时常见「起草 → 润色 → 合规检查」。

2. Parallelization：并行再汇聚

    ┌→ worker_a ─┐
START → ┼→ worker_b ─┼→ aggregate → END
    └→ worker_c ─┘

多节点同时干独立活（多模型投票、多文档切片），下游 aggregate 合并。LangGraph 用扇出边 + 带 reducer 的 State 键（如 Annotated[list, add]）收结果。

本课目录尚待建：course-langgraph 大纲标了 patterns/parallelization/。选型口诀：子任务互不依赖才并行；有先后依赖就退回 Chaining。

3. Routing：分类后走支路（仓库有码）

START → classify ┬─ weather → END
         ├─ policy  → END
         └─ chitchat → END

g.add_conditional_edges(
  "classify",
  pick_branch,
  {"weather": "weather", "policy": "policy", "chitchat": "chitchat"},
)

老张：”客服『制度走制度支』——这就是 Routing，不是再写三遍 Chaining。”

4. Orchestrator-Worker：动态拆派

START → orchestrator ──Send──► worker×N ──► synthesize → END

编排者按输入动态决定要几个 worker（章节数事先未知），常用 LangGraph Send API 做 map-reduce 式扇出。

仓库对照：courseware-langchain/multi-agent-writing/ 用 Orchestrator 串 Researcher→Writer→Editor——角色分工同一哲学，实现是顺序调度而非图上 Send。图版待建 day3d-orchestrator-send/。

小明：”和 Parallelization 啥区别？”

“并行：工人数量和边预先画死。Orchestrator-Worker：工人数量运行时才定。”

5. Evaluator-Optimizer：生成—评估环

START → generate → evaluate ┬─ pass → END
              └─ fail（带 feedback）→ generate

一个节点产出，一个节点打分；不达标就把意见写回 State，再生成。适合「没有一次成型」的质量门（文案、翻译、代码补丁）。

待建：patterns/evaluator-optimizer/。注意加最大轮次，避免无限循环烧钱。

6. Agent Tool Loop：模型选工具（仓库有码）

模式名就叫 Agent / Tool Loop：

START → agent ──tool_calls──► tools ─┐
      ▲              │
      └──────── loop ────────────┘
      └─ 无 tool_calls → END

g.add_conditional_edges("agent", should_continue, {"tools": "tools", "end": END})
g.add_edge("tools", "agent")

这是右侧「LLM 控流」的典型：下一步调不调工具，由模型决定；图只保证「有 tool_calls 必须进 tools，结果必须回 agent」。相对 create_agent：循环可见，易加限步、审核节点。

7. Human-in-the-Loop：停给人审

… → risky_action ──interrupt──► （人：approve/edit/reject）──► 继续或结束

高风险副作用（发信、转账、删数据）前暂停。对照课件用的是 LangChain Agent + HumanInTheLoopMiddleware（底层仍走 LangGraph interrupt 能力）：

HumanInTheLoopMiddleware(
  interrupt_on={
    "send_email": {"allowed_decisions": ["approve", "edit", "reject"]},
    "read_email": False,
  }
)

自建 StateGraph 时用 interrupt() + checkpointer + Command 恢复——细节放到客服项目篇。今天记住：HITL 是模式，不是插件彩蛋。

组合实战：可控 RAG = Chaining + Routing

老板要的「没命中必须拒答」，不是单模式能概括——它是 先检索（链）+ 有无命中再分流（路由）：

START → retrieve ┬─ has hits → generate → END
         └─ no hits  → refuse   → END

g.add_edge(START, "retrieve")
g.add_conditional_edges(
  "retrieve",
  route_after_retrieve,
  {"generate": "generate", "refuse": "refuse"},
)

 main.py --demo

Q: 年假有几天？怎么申请？
 hits: ['leave: 正式员工入职满 1 年享有 5 天...']
 A: （基于片段生成）

Q: 公司发不发水果零食？
 hits: []
 A: 根据现有资料无法确定（检索无命中）。

老张：”模式可以组合。点菜不是只能点一个菜。”

怎么选题：一张决策草图

步骤顺序固定、几乎无分支？   → Prompt Chaining
多路独立、要加速？       → Parallelization
按类型走不同专家？       → Routing
子任务数量要到运行时才知道？   → Orchestrator-Worker
要质量门、可打回重做？     → Evaluator-Optimizer
开放任务、主要是选工具？     → Agent Tool Loop
有不可逆副作用？         → 加上 HITL
要强制检索/拒答？         → Chaining + Routing（Day5）

验收建议：在纸上画出 Routing 与 Tool Loop 两张拓扑（大纲中期考核也盯这两张）。

总结

老张说：”第 03 篇不要求你把七种都写满代码——要求你能点名、能画两张图、能指认仓库锚点。”

“三个核心理解：

1. 两拨哲学 —— 预定义流程嵌 LLM（稳）vs LLM/人参与控流（智能）
2. 七种菜谱 —— Chaining / Parallel / Routing / Orchestrator-Worker / Evaluator-Optimizer / Tool Loop / HITL
3. 可组合 —— RAG = Chaining + Routing；生产常是 Graph 外壳拼多种模式”

LangGraph 专题进度：

01 介绍 → 02 三要素（Day1–4）
    ↓
03 常见 WorkFlow（本篇）
    ↓
04 客户支持 Email Agent（Think in LangGraph）

小明：”七模式表我钉墙上了。下篇用客服邮件把 Routing、检索、HITL 串成一张业务图。”

别从零发明拓扑。先点名模式，再组合；图是菜谱的盛器，不是每一道菜都要重新开灶。