当AI整理好询价内容、下一步需要产品负责人确认配置时，等待可能跨过一个工作日。程序不需要一直反复询问“确认了吗”，也不应在进程退出后丢掉前面的工作，让销售重新发起一次完整任务。

AWS在10月15日宣布Lambda Durable Execution SDK for Go正式可用，提供进度检查点、等待和回调等能力，支持包含人工审阅的多步流程。它适合已经开发这类应用的团队：运行到等待点时先暂停，收到对应外部结果后再继续处理。普通团队已有的人工任务清单，不必为了使用新SDK而重建。

等待不是持续计算，也不是任务结束

持续运行的循环与可恢复的等待，看起来都在“等回复”，实现上的责任却不同。循环依赖进程仍然存在，还需要自己保存进度与处理重启；持久等待则把暂停点和已完成结果留在执行记录中。界面可以显示“等待确认”，而不必让一段代码一直占着运行位置。

AWS的文档说明，恢复时程序会进行重放，从开头经过已完成的检查点，复用保存结果而跳过对应已完成操作。这不等于把每一步业务再做一次，也不是把任意一段旧代码加上“继续”按钮就能安全恢复。开发者需要把哪些操作纳入持久步骤设计清楚。

对询价协作，适合保存的内容包括这次任务指向的产品版本、已经整理的需求，以及交给负责人确认的那份草稿。等待结束后，应继续处理被审阅的同一份草稿。若重新让模型生成一版不同草稿，再把原来的批准套上去，表面上接着走了，实际批准对象已经换了。

回复到达以后，还要确认它批准了什么

一条“可以”必须能对应到具体任务与版本。它可能确认的是配置描述，也可能只是同意继续核查，并不一定批准对外发送报价。回调解决的是把回复送回等待中的流程；它不会替企业解释人的商业决定，更不能凭收到任意消息就打开所有后续动作。

等待期间，库存、交期或产品条件也可能变化。可以保留已完成的资料整理，但对需要当前事实的步骤重新读取或请求确认。不要把“复用旧检查点”理解成所有业务依据都无限有效。哪些字段需要刷新，应按这项工作的实际失效条件确定，而不是每次全部重做或全部沿用。

报价批注关闭后仍要核对正文，说明人的处理状态与最终文字可能不同。在等待流程里，类似的核对落在恢复点：确认回复、被确认的草稿和即将使用的正文是否一致，再进入下一步。

对会发消息、改业务记录的外部动作，还要按相应系统的接口能力安排防重与结果核对。工作流能保存进度，不意味着任何外部接口都自动获得“恰好执行一次”的保证。原始发送结果未知时，不能靠重新启动整条流程来猜测。

上线前可以在本地用模拟回复检查几个明确情境：回复迟到、重复到达、对象已经换版，或到期仍无人处理。SDK提供的durabletest支持本地完整流程测试；业务团队要补上的，是这些回复各自应当让任务继续、停留还是交给人处理。

人工确认本来就需要时间。系统值得做的，是把这段时间和正在执行的工作分开保存，让回复回来时仍然找得到它真正要决定的那件事。

参考来源