一个任务每秒上报心跳十分钟没完成任何步骤。另一个任务正在等待供应商生成视频三分钟没有新输出却仍在预期时长内。只凭“几秒没动静就重启”会把这两种情况混在一起。活着、前进、拥有写权限我会分别记三件事heartbeat_at说明进程仍能通信progress_at说明业务检查点确实前进generation决定谁有权提交结果。心跳不能续期业务进展日志刷屏也不能算完成步骤。Kubernetes 探针文档区分启动、存活和就绪。它们是进程管理背景不是业务任务完成度协议。任务层还需给各步骤定义正常等待区间例如“视频供应商处理中”和“结果已下载”是不同检查点。接管必须让旧 owner 失去提交资格下面用逻辑时间演示 fencing。它不是分布式租约实现真实系统要让数据库以条件更新原子地分配代次并在每次落库时验证代次。class Task: def __init__(self): self.owner, self.gen, self.progress A, 1, 10 self.step 0 def take(self, new_owner, now, timeout): if now - self.progress timeout: return None self.owner, self.gen new_owner, self.gen 1 self.progress now return self.gen def commit(self, owner, gen, step, now): if (owner, gen) ! (self.owner, self.gen) or step self.step: return False self.step, self.progress step, now return True t Task() assert t.take(B, 15, 10) is None assert t.take(B, 30, 10) 2 assert not t.commit(A, 1, 1, 31) assert t.commit(B, 2, 1, 32) print(early takeover denied; stale owner fenced; new owner committed)本地 Python 3 执行通过三项断言没有连接任务系统。这个实验把关键反例说清楚超时后旧进程可能恢复如果存储层不验代次它依然能覆盖新结果。应用里单独检查一次再写入会留下竞争窗口。慢依赖别用重启“治疗”每个检查点保存预期工作、最后进展证据和等待对象。超出观察窗口先检查供应商任务状态和本地积压确认需要接管后再撤销旧代次、分配新 owner。外部扣款、视频生成等副作用还要有稳定幂等键否则 fencing 只能保护本地写挡不住重复消费。十月的视频 Agent 热点适合用这个框架审视但本文不虚构某个平台耗时或重启收益。发布前应补齐真实依赖的等待上限、取消能力及幂等合同未核实前“卡住”只是待验证假设。