Durable Task 的价值不在于取代所有后台工作器、消息队列或数据库，而在于组织那些持续时间较长、需要等待外部事件，或可能在部分步骤执行后中断的操作。.NET 博客使用 Durable Task .NET SDK 1.26.0 版本和 Durable Task Scheduler 展示了五个实际示例，并强调该工具保存的是协调历史，而不是恢复暂停的 CLR 执行栈。
核心理念是区分由工作流引擎协调的部分和仍由应用负责的部分。Durable Task 可以保存进度点，在不占用执行线程的情况下等待，并根据已记录的结果重新运行协调器代码。但它不会决定用户权限，不会保证外部副作用只执行一次，也不会自行确定哪些资源可以安全删除，或确定一笔支付是否确实到账。
人工审批不意味着停止工作器
在发票处理过程中，可以为每张发票运行一个独立的子协调。无需审核的发票继续执行，而需要人工批准的发票则等待外部事件和一个持久化的超时期限。如果工作器停止，另一个工作器可以重新运行协调器并返回等待点，而不必手动重建状态。
不过，审批事件只是一个信号。经过认证的端点必须先在应用存储中以原子方式记录最终决定，然后再发送信号；会计步骤还必须验证固定部署身份和不可变的请求指纹。如果会计分录已经接受，但活动确认丢失，仅凭 Durable Task 的历史记录不足以防止重复；还需要与会计系统进行对账协议。
配置 Azure 环境：ARM 的职责在哪里结束？
文章指出，对于部署特定资源，ARM 和 Bicep 可能已经足够，因为它们提供依赖关系排序、并行执行，以及使用固定身份重新应用所需状态。因此，如果 ARM 已经提供了部署图，添加 Durable Task 就不值得重新构建该部署图。
当流程超出资源部署范围，延伸到接受租户请求、通知进度、等待就绪，然后激活租户时，Durable Task 才会体现价值。示例建议将配置请求及其标识符与 outbox 一起保存到应用数据库中，然后使用协调流程连接网络、数据库、存储、应用、DNS 和就绪检查等阶段。至于 Azure 操作本身，仍然需要操作日志、固定身份，以及在响应丢失时进行对账。
文章警告，不要把补偿当作撤销按钮。存储失败后，Azure 可能仍在创建数据库。因此，必须阻止旧尝试启动新操作，检查此前已发送的操作，并在确认不存在可能重新创建资源的延迟操作后，删除完全属于该尝试的资源。如果无法证明状态或所有权，安全结果应是 NeedsIntervention，而不是猜测性删除。
支付超时不等于拒绝
在订阅周期中，支付提供商可能在接受操作后不再返回响应。立即重试可能导致重复扣款，而将其视为拒绝则可能发送误导性通知。示例建议将每个支付周期与周期标识符和固定支付密钥关联，然后使用持久化计时器、回调、定期检查以及明确的宽限期。
支付账本是 authoritative，负责记录 Unknown、Pending、Declined、Paid 和 NotCharged 状态。只有在确认收据并关闭当前周期后，流程才会进入下一个周期。如果宽限期结束时状态仍未确定，结果应为 NeedsReconciliation，而不是假定支付成功或失败。
延迟事件需要在目标端提供保护
在为新闻文章更新搜索索引时，版本 12 可能在版本 13 之后到达，或者索引操作可能以相反的顺序完成。durable 实体可以保存已见过的最高版本，并串行化其计数器更新，但它不会锁定外部索引，也不会阻止两个请求并行写入。
因此，目标端本身必须实施原子版本屏障，在较新版本固定后拒绝写入较旧版本。系统还需要可靠的 inbox、用于后续处理的分发器，以及与源系统进行定期对账。即使采用单一标识符的协调器模式，也无法为外部副作用提供只执行一次的保证。
这对人工智能代理意味着什么？
在事故助手工作流中，流程需要保存特定的模型建议，等待工程师批准，然后在可能发生中断后执行获批工具。这里的价值在于恢复审批路径和同一个决定，而不是在每次重新运行后重新生成一个建议。至于建议的身份、工具的有效性，以及阻止执行过期或重复请求，仍然是应用的责任。
五个示例得出的实际结论是：当保存“接下来会发生什么”本身成为一个系统时，Durable Task 才适合使用。如果应用已经拥有队列、计时器和清晰的对账日志，或者外部系统已经提供了可靠的协调能力（例如 ARM），那么该框架带来的复杂性可能超过其价值。此外，所有示例都依赖明确的外部边界：权威记录、幂等键、版本屏障、outbox 或对账协议。