Appearance
🐣 小a的新疑问
学会了 Loop、也搞懂了 RAG,小a又听说还有 Workflow 和 LangGraph。"这些和咱们的 Loop 是一回事吗?"
老z:"是三种不同的'活法'。 Loop 让模型自己选路,Workflow 把路写死,Graph 画一张地图让模型按图走。这一章我们对比后两种——它们更适合'流程固定'的任务。"
14.1 三种范式的全景
🧙 先看清三种范式,它们的核心区别是"谁决定下一步":
| 范式 | 谁决定下一步 | 特点 | 适合 |
|---|---|---|---|
| Loop(前面学的) | 模型自主 | 灵活、不可预测 | 写代码、debug、探索 |
| Workflow(本章) | 开发者预先写死 | 可控、固定 | 审批流、ETL、订单处理 |
| Graph(本章) | 开发者画图,模型在节点里跑 | 复杂路由、可控 | 多分支、需条件判断的任务 |
这三种不是互相替代的"工具",而是面对不同任务的"思路"。 选错范式,事倍功半。
14.2 Workflow:把任务拆成固定步骤
是什么
🧙 Workflow(工作流)把任务拆成固定的、预先定义的步骤序列,一步步执行。每一步可能用模型,也可能不用,但步骤的顺序和分支是开发者写死的。
老z打比方:
- Loop = 出租车(司机/模型自己选路)
- Workflow = 地铁(路线固定,到站必停)
一个例子:请假审批
步骤1:员工提交请假申请
↓ (固定)
步骤2:用模型判断"请假理由是否合理"
↓ (固定)
步骤3:经理审批
↓ (固定)
步骤4:HR 备案
↓
结束注意:每一步顺序写死,不会变成"先 HR 备案再经理审批"。模型可能在步骤 2 参与(判断理由),但整体路线开发者控制。
优缺点
🧙 优点:
- 可控:路线确定,好测试、好审计
- 稳定:同样输入,走同样路线
- 可插拔:某一步换模型/换逻辑,不影响整体
缺点:
- 不灵活:遇到没预料的情况,无法临场调整
- 设计成本高:得预先想清楚所有步骤和分支
14.3 Graph:画一张"任务地图"
从 Workflow 到 Graph:加"路由"
Workflow 是"一条线"(步骤1→2→3→4)。但如果任务有多种可能的路线,需要根据条件分支,Workflow 就不够了——这时候要 Graph。
🧙 Graph(图编排)是什么?
Graph 把任务拆成节点(node),节点之间用边(edge)连接,形成一个图。执行时按图走,可以根据条件路由到不同节点。
老z打比方:
- Workflow = 地铁(一条线,顺序停站)
- Graph = 地铁线路图(多条线,可换乘,根据目的地选路线)
代表框架:LangGraph(把 agent 编排做成图)
一个例子:智能客服
[开始:用户提问]
↓
[理解意图] ← 节点
↓
┌─条件分支─┐
↓ ↓
[查订单节点] [查 FAQ 节点] ← 根据意图路由
↓ ↓
└────┬─────┘
↓
[生成回答] ← 节点
↓
┌──满意吗?──┐
↓ ↓
[结束] [转人工] ← 又一个分支每个节点可能跑一个模型/工具,边上的条件决定走哪条路。Graph 能表达复杂的多分支逻辑。
优缺点
🧙 优点:
- 能表达复杂路由:多分支、条件判断、循环回路都能画
- 可视化:图本身就是文档,能看懂流程
- 可控 + 灵活的平衡:路线开发者画,但节点内模型有自由度
缺点:
- 设计成本极高:得把所有节点、边、条件都想清楚
- 过度工程:简单任务上 Graph 是杀鸡用牛刀
- 调试复杂:图越大,出问题越难定位
14.4 三种范式对比(全书最重要的对比之一)
可控性高 ←────────────────────────────→ 灵活性高
Workflow Graph Loop
(路线写死) (画图路由) (模型自主)
─────────────────────────────────────────────
适合: 适合: 适合:
固定流程 复杂多分支 探索性任务
审批/ETL 智能客服 写代码/debug
─────────────────────────────────────────────
一句话: 一句话: 一句话:
开发者铺铁轨, 开发者画地铁图, 模型当司机,
模型在车上 模型按图换乘 自己选路怎么选?
🧙 选范式的决策框架:
任务的可预测性? │ ├─ 步骤固定、可预见 → Workflow │ ├─ 步骤多变、条件分支多 → Graph │ └─ 完全自由探索、模型自主 → Loop关键:预测性越高,越该用可控的(Workflow/Graph);越不可预测,越该让模型自主(Loop)。
14.5 pi 为什么选 Loop
🐣 小a问:"那 pi 为啥不用 Workflow/Graph?写代码不也有分支吗?"
🧙 "写代码的分支是模型现场决定的,不是开发者预先画的。 Graph 要求开发者预先画出所有可能的分支——但写代码的分支千变万化(这次要查这个文件,下次要改那个函数),预先画图不现实。
pi 让模型自己『走一步看一步』(Loop),反而更贴合写代码的真实节奏。 选 Loop 不是因为它最先进,而是因为写代码这个场景,自由探索 > 固定流程。"
14.6 范式是光谱,不是三选一:混合编排
"最后破除一个误解。"老z说,"这三种范式不是互斥的选项,而是一条光谱——成熟系统常常混合着用。"
🧙 三种混合的玩法:
玩法一:Workflow/Graph 里嵌 Loop
固定流程的某一步,可能是"让模型自由发挥"的 agent 节点:
电商客服 Workflow: 识别意图 → [诊断订单问题:这里嵌一个 Loop,让模型自己查、自己分析] → 给出方案 → 结束流程固定,但"节点内"可以完全交给模型。
玩法二:Loop 外面套流程(路由)
反过来——先由路由决定"这个请求该走哪条路":
请求进来 → 路由判断: ├─ 固定流程类(查订单)→ 走 Workflow ├─ 知识问答类 → 走 RAG(第 13 章) └─ 开放任务类(写代码)→ 走 Loop这个"路由"本身可以是模型判断(一次分类调用)。现代框架里这叫『路由到 Agent(router)』,是 Graph 思想最典型的应用。
玩法三:Graph 的节点就是 Agent
LangGraph 这类图框架里,每个节点可以是一个完整的 agent(Loop)——"把 Agent 嵌进流程,把流程交给 Agent",两层结构自由组合。
🐣 小a:"所以不是选一个范式用到死,而是该固定处固定、该自由处自由?"
🧙 "对!这就是范式的正确用法:它们是搭积木的模块,不是非此即彼的单选题。 判断每一段任务:可预测就写死(Workflow/Graph),不可预测就放养(Loop),把它们拼起来——这比死守单一范式强得多。"
本章小结
🐣 小a的路线图课
┌──────── Workflow vs Graph ────────┐ │ │ │ • Workflow = 固定步骤(地铁) │ │ 可控/稳定,但不灵活 │ │ │ │ • Graph = 画图路由(地铁线路图) │ │ 复杂多分支,但设计成本高 │ │ │ │ • Loop = 模型自主(出租车) │ │ 灵活,但不可预测 │ │ │ │ • 选范式看可预测性: │ │ 越固定→Workflow/Graph │ │ 越自由→Loop │ │ │ │ • pi 选 Loop = 写代码场景适配 │ │ │ │ • 光谱不是三选一: │ │ 流程里嵌 Loop / 路由到 Agent / │ │ Graph 节点就是 Agent │ └────────────────────────────────────┘
关键认知:Workflow 和 Graph 是"让 AI 按路线图干活"的范式——一个写死步骤,一个画图路由。选范式看任务可预测性:固定流程用 Workflow/Graph,自由探索用 Loop。但它们是光谱不是单选题,成熟系统把三者拼起来用。
课后实验
- 判断范式:三个场景(自动周报/智能客服/代码 review)该用 Workflow/Graph/Loop 哪个?
- 画 Graph:把一个"电商下单"流程画成图(节点+条件分支)。
- 对比体验:同一个任务,分别用 Workflow 和 Loop 实现,对比可控性和灵活性。
- 设计路由:给一个系统设计"路由到 Agent"的入口:哪类请求走 Workflow、哪类走 RAG、哪类走 Loop,各给一个例子。
下一章:会读会写会执行命令的 Agent,没有保险栓就是一把上了膛的枪。最后一课,给它装保险。 → 第 15 章 · 给 Agent 上保险