Agent 编排与状态持久化
前面几篇，你的 Agent 都是一个「个体户」——一个循环，扛下所有事。它能跑通简单任务，但一遇到复杂任务就露怯：上下文爆满、步骤纠缠、一出错全盘乱。
这一篇回答两个核心问题：怎么把一个复杂任务拆给多个 Agent 协作，以及怎么让协作过程「断了能续、关键步有人把关」。 前者叫编排（Orchestration），后者叫状态持久化（Persistence）。读完你会发现，真正的分水岭不在「拆了几个 Agent」，而在「状态存没存、人能不能介入」。
1. 从「个体户」说起
1.1 单 Agent 的上限，不是聪明，是「装不下」
单 Agent 能干的事，上限不是它聪不聪明，而是它一个「脑子」（上下文）+ 一个「循环」（loop）装得下多少东西。
一旦任务变复杂——要查资料、调多个工具、分好几个阶段推进——单 Agent 就会「上下文爆仓、任务纠缠、职责不清」。这不是模型不够强，是架构到了瓶颈：你把「规划、执行、检查」全塞进一个循环里，它就顾此失彼。
一句话心智模型：编排 = 把一个大任务拆成多个小角色，各司其职、有节奏地协作；状态持久化 = 给这个协作过程装上「存档点」，断了能接着跑。
打个比方：单 Agent 是一个全能但会累的「个体户」，多 Agent 是一支有分工的「小团队」——有人规划、有人执行、有人检查。团队里每个人只做好自己那一摊，整体反而更可控。但团队也有团队的代价：要传话（传状态）、要协调（编排）、要防跑偏——这正是编排要解决的问题。
2. 为什么需要多 Agent
2.1 单 Agent 的三条死路
当一个 Agent 扛下所有事，迟早撞上这三堵墙：
死路一：上下文爆仓。 所有中间结果、所有工具返回都堆进同一个对话窗口。任务一复杂，窗口很快塞爆，模型就开始「失忆」——把前面查到的关键信息给忘了，输出质量断崖下跌。
死路二：任务纠缠。 规划、执行、纠错混在同一个循环里。一步错，全盘乱，而且很难定位「到底哪一步崩了」——因为所有步骤纠缠在一坨，没有清晰的边界。
死路三：职责不清。 一个 prompt 要同时约束「怎么规划 + 怎么干活 + 怎么检查」，约束越多，模型越容易顾此失彼。人类自己都很难在一句话里同时扮演好三个角色，何况是模型。
取舍（诚实交代代价）：把这些「角色」拆开，换来「每步可控、可定位、可独立测试」，代价是「多 Agent 之间要传状态、要协调」——这本身又是个新难题。所以本文才有第二个主角：状态持久化，它就是来解决「拆分带来的协调成本」的。
2.2 为什么「持久化」是 demo → 生产的分水岭
demo 里的 Agent 跑一遍就结束，状态丢不丢无所谓。但生产里的 Agent，有两个刚性要求，demo 根本不用考虑：
刚性一：长任务会中断。 网络抖动、模型超时、进程重启、部署发布……一个跑 20 分钟的长任务，跑到第 18 分钟断了怎么办？没有存档点，就得从头再来，前面 18 分钟全白费。
刚性二：人要能介入。 Agent 执行到「要花钱」「要删数据」这种关键步骤，得能暂停、等人确认、再继续，而不是一路狂奔到底。
这就是「持久化」存在的理由：把 Agent 每一步的状态存下来，让它能断点续跑、能人工介入。没有它，Agent 永远只能是「跑一次看效果」的玩具。持久化不是高级优化，是生产 Agent 的及格线。
3. 四种编排范式，按复杂度选
编排不是「方案越多越好」，而是一个「按需升级」的阶梯。先看清四种范式，再讲怎么选：
| 范式 | 结构 | 适合 |
|---|---|---|
| 单 Agent（ReAct） | 一个循环：思考→调工具→观察→再思考 | 简单、单步任务 |
| Plan-and-Execute | 先规划出一份步骤清单，再逐步执行 | 步骤明确、可预见的任务 |
| Supervisor（监督者） | 一个「总监」调度多个「专员」，动态分配 | 任务多变、需要灵活分工 |
| Multi-Agent（网状） | 多个 Agent 平等协作、互相调用 | 复杂、需多角色自由协作 |
3.1 四种范式的本质差异
用「谁在做决定」来看，四种范式呈现一个清晰的演进：
- 单 Agent：一个脑子做所有决定，最简单、最可控。
- Plan-and-Execute：把「决定」拆成两段——先一个「规划者」做整体计划，再一个「执行者」照着清单干。关键改进是「先想清楚再动手」，避免边干边想导致跑偏。
- Supervisor：引入一个「总监」角色，它不亲自干活，只负责动态地把任务分配给合适的专员。适合「任务类型多样、需要灵活调配」的场景。
- Multi-Agent：去掉「总监」，多个 Agent 平等地互相调用，像一支没有老板的团队。最灵活，也最难调试——因为控制流是网状发散的，很难预测下一步谁会被调用。
3.2 一条黄金法则
能用简单的，就别上复杂的。
绝大多数真实任务，单 Agent 或 Plan-and-Execute 就足够；只有明确出现「多角色并行」「动态分工」的需求，才值得上 Supervisor / Multi-Agent。
原因很朴素：多一个 Agent，就多一份失控的风险和调试的成本。 一个单 Agent 你能逐行 debug，一个网状 Multi-Agent 出了问题，你往往连「是哪个 Agent 先跑偏的」都难定位。架构的复杂度，必须被真实需求「逼」出来，而不是预先「炫」出来。
4. 状态持久化：LangGraph 的图与检查点
Python 生态里，LangGraph 用「图」抽象编排，用「检查点（checkpoint）」抽象持久化。把这三个核心概念吃透：
节点 Node —— 一个角色/一个动作（查资料、调工具、总结…）
边 Edge —— 节点之间的流转（做完 A 再去 B，或条件分支）
状态 State —— 在节点间传递的"共享记忆"4.1 持久化做的事：每走一步，存一份快照
持久化的本质，是每执行一个节点，就把 State 存一份快照（checkpoint）。这一个简单动作，解锁了两个关键能力：
- 断点续跑：任务跑到一半断了，从最近的检查点恢复，不必从头重来。
- 人工介入：在关键节点前挂一个「中断点」，执行到这里就暂停、等人审批，批了再放行继续。
这两件事，正是 2.2 节说的「生产 Agent 两个刚性要求」的答案。
4.2 一个「带持久化 + 人工介入」的骨架
用伪代码把「下单前人工确认」这个经场景搭出来（重点是结构，不是语法）：
# 一个需要在"下单"前人工确认的 Agent
graph = StateGraph(状态) # 1. 建图
graph.add_node("查库存", 查库存函数) # 2. 定义节点：查库存
graph.add_node("下单", 下单函数) # 定义节点：下单
graph.add_node("人工确认", HumanInTheLoop) # 3. 关键节点前置：人工确认
graph.add_edge("查库存", "人工确认") # 4. 连边：查完库存 → 去人工确认
graph.add_edge("人工确认", "下单") # 确认通过 → 才去下单
graph.compile(checkpointer=数据库或内存) # 5. 关键：接上检查点，每步自动存快照
# 跑到"人工确认"节点会暂停，返回给用户确认；批了再继续跑到"下单"
graph.invoke("帮我下单 100 件商品")这段代码的灵魂在两个点：
checkpointer——一行参数，就把「每步存快照」的能力接通了。没有它，这个图就是「跑一遍就完」的 demo；有了它，就是「能断点续跑、能暂停等待审批」的生产骨架。人工确认是一个显式的节点——HumanInTheLoop不是躲在某个if里，而是图上的一个独立节点，嵌在「查库存」和「下单」的必经之路上。这意味着：人工把关是「结构性」的，绕不过去，而不是「靠模型自觉」。
这也是第 05 篇讲的「图让控制流显式化」的具体体现——因为控制流是显式的，你才能精确地在「查完库存」和「下单」之间，插入一个人工关卡。
4.3 一个判断：持久化的及格线
「持久化 + 人工介入」不是加分项，是生产 Agent 的及格线。 一个没有 checkpointer 的 Agent，无论它的 prompt 写得多漂亮、模型多强，都过不了「长任务会断」「关键步要人把关」这两关。所以从你写第一个多步骤 Agent 开始，就把 checkpointer 接上——不是「以后再补」，是「一开始就有」。
5. 容易踩的几个坑
- 一上来就上 Multi-Agent —— 任务其实一个 ReAct 就能解决，偏要拆成三四个 Agent。根因：误把「多 Agent」当「高级」。正确姿势：先用最简范式跑通，复杂度被真实需求「逼」出来再拆。
- 状态全塞一个 dict，越滚越大 —— 所有中间结果都往 State 里堆，最后 State 比上下文还大。根因：把 State 当垃圾桶。正确姿势：State 只存「必要的、下一步要用的」，用完就丢。
- 没设检查点就上生产 —— 长任务一旦中断全部白跑。根因：demo 思维惯性。正确姿势：从第一次写就接上 checkpointer。
- 关键动作没挂人工确认 —— 让 Agent 全自动「下单、删库、群发」。根因：追求「全自动」的爽感。正确姿势：任何「不可逆、高代价」动作前，强制 HumanInTheLoop。
- 把「人工介入」做成 prompt 请求，而不是图上的节点 —— 靠一句「请用户确认后再执行」来约束，模型可能「忘了」确认。根因：把硬约束做成了软约束。正确姿势：人工确认必须是图上绕不过去的节点，执行到就硬性暂停。
6. 记住这一句
单 Agent 是「个体户」，多 Agent 是「团队」；能用个体户就别开公司。真正的分水岭不是拆几个 Agent，而是「断了能不能续、关键步有没有人把关」——这是持久化要解决的，也是 demo 和生产的区别。人工把关要做成图上绕不过的节点，而不是 prompt 里的一句请求。
下一篇预告：多 Agent 协作解决了「复杂度」，但所有这些 Agent——无论几个——还都记不住事。活干得再漂亮，下次用户再来，它照样一片空白。这就到了 08 · Memory 长期记忆。