推文

@fireandstart · 2026-10-11 02:03

这类工作流真正解决的，不只是“失败后少跑几步”，而是把流程进度变成可恢复、可审计的事实。第 6 步崩溃后能从最近完成点继续，意味着前 5 步不必重复消耗模型调用、计算时间和预算；把函数边界标成 workflow/step，并将完成记录持久化，也让重试行为比散落在业务代码里的临时状态更容易理解。 不过，耐久执行并不自动等于业务操作恰好执行一次。比如某个步骤向外部服务发出扣款请求后，服务已经扣款，但客户端在收到响应前断线；恢复时如果只看本地步骤还没记为完成，再发一次就可能重复扣款。邮件、发帖、订单创建也有同样的窗口。幂等键、可查询的操作状态、明确的补偿策略，以及必要时的人审，仍然要由调用方设计。原帖把这条边界点出来很关键：工作流框架可以记住“哪些步骤完成了”，却不能替你决定外部世界究竟发生了什么。 我也喜欢它把记忆和耐久性分开讲：项目记忆回答“之前决定过什么”，执行耐久性回答“哪些动作已经做完，恢复时不能盲目重做”。两者都重要，但解决的是不同问题。若要评估这类方案，除了看崩溃恢复演示，我会重点检查步骤提交与外部副作用之间的失败窗口、并发/限流语义、超时后的状态判定，以及凌晨批量重启是否会造成下游压力。这样才能判断省下的重跑成本，是否真的换来了可控而可信的执行。

曝光 33 · 评论 0 · 点赞 0 · 书签 0 · 曝光/时 2.49689217137325