L4 总览：组织能暂停、恢复的工作流

工作流是一组有顺序、有条件的操作。例如客服处理退款：读取订单，核对退款条件，等待主管确认，再执行退款。每一步都有输入和结果，下一步根据结果继续。把步骤明确写进程序，就能回答“现在到哪一步了”“接下来做什么”。

L3 已经让 Agent 根据观察决定下一步。L4 把一整个任务组织起来：同时查两份资料时如何汇总，进程退出后如何继续，工具超时后怎样处理，以及等待人工确认时把状态保存到哪里。模型可以生成建议，程序安排步骤、保存进度。

用一次退款区分这两层：L3关注“读到订单后，下一步该查退货记录还是询问客户”；L4关注“订单和退货记录都查完后再生成草稿，草稿批准后才能提交退款，明天回来还能从等待审批的位置继续”。前者决定下一步动作，后者把这些动作放进一条有顺序、能保存进度的流程。

只有一项查询时，一个函数就很直观。步骤增加后，程序需要记住已完成什么、哪些结果还没回来、是否正在等人。工作流把这些安排集中写清楚，客服查看任务时就能知道它卡在哪一步。

用一份退款流程认识各个角色

假设客户留言：“订单已退货，请帮我退款。”程序先读取订单与退货记录，整理成退款草稿，再交给主管确认。主管批准后，退款服务接收一个稳定的业务编号，完成操作并返回退款单号。

可以把状态想成办事进度卡，把事件想成盖章记录。进度卡方便知道现在在哪里，记录方便追查怎样走到这里。内存里的变量随进程结束消失；写入文件或数据库后，另一进程才有机会取回它。

按这条路线学习十二个知识点

前四篇先把任务组织好，中间四篇处理执行与人工等待，最后四篇处理规模增加后的故障。

每篇先照着文件和命令运行，再对照结果读代码。演示使用固定输入，分支已经安排好；先感受数据怎样变化，再展开文末习题。

顺着一次超时看懂恢复

退款服务已经收到操作，但回复在路上丢失了。程序先用业务编号查询原操作：查到退款单就保存结果；服务支持同一编号去重时，可以按契约再次提交；需要额外核实的情况保存为待核对，交给人工。

恢复时，先读取状态，再处理尚未确认的操作。这样能具体定位从哪里继续，也便于向客服说明进度。LangGraph 持久化文档介绍了检查点与长期存储的不同用途；Temporal 工作流文档可以帮助继续了解持久工作流的执行方式。

把这些机制用在自己的 Agent 中

简单的查天气通常一两步就结束。生成日报、批量处理资料、经过主管审批的退款，持续时间更长：工作会积压，部分查询会失败，用户也可能中途取消。先画出正常步骤，再为等待、失败和取消加出口；每增加一个出口，写清保存的数据与继续条件。

从显式图、状态机与条件边开始。L4 保存执行过程；接下来的L5继续组织任务所用的资料、上下文和记忆。