小林确认创建服务单后，投屏故障并不会在一个网页请求里结束。现场人员可能稍后受理、联系她确认情况、更新处理结果。若 Agent 一直占着浏览器连接“等待工单完成”，页面超时、进程重启或员工关闭窗口都会让任务状态变得混乱。企业服务台需要把长任务拆成可持久化的阶段，让请求尽快返回，同时在后续事件到来时继续。本篇用小林的工单追踪说明异步任务、检查点和断点续跑的设计。这里的“续跑”不是把模型上次生成到一半的文字接着补齐，而是从已确认的业务阶段恢复，并先核实外部操作是否已经发生。示例展示一个最小的 SQLite 检查点，不把它冒充完整的分布式任务队列。文章目录哪些任务不该一直占着一次请求从页面请求转为可恢复任务的流程图检查点应记录哪些事实恢复时先看证据，不看“上次跑到哪一行”总结哪些任务不该一直占着一次请求检索一条指引通常可以在当前请求内完成，等待人工受理却可能持续数十分钟。两者若都写在同一个同步函数里，浏览器连接与服务器工作线程会被长期占用；员工重新打开页面时也不知道原流程是否还在运行。长任务应该尽早返回可理解的状态，例如“服务单已创建，等待受理”，后续由事件、轮询或工作人员动作推进。服务台活动是否适合当前请求内完成后续如何获知进展校验字段、追问连接方式适合立即返回待补信息查询小段知识资料通常适合，但应有超时失败时返回明确状态创建普通故障单可在确认后调用，但要有结果不明处理回读真实工单号等待人员受理与现场检查不适合占住请求工单事件或定时回查批量核对一批资料可异步执行保存分批进度与失败项“异步”不等于后台无限运行。每个长任务都需要明确的拥有者、当前阶段、最后进展、下一次可执行时间、最大重试次数及终止状态。小