租约与Fencing

限制同一可变执行状态的有效写入者并拒绝旧worker。

租约表示某个worker在一段时间内拥有执行资格；fencing token用来拒绝已经过期的旧worker。只设置超时并不够：进程可能因网络暂停错过续租，随后恢复并继续工作。系统需要一个可比较的代次，确保新owner接管后旧代次不能再提交状态。

领取任务时可原子增加执行代次，之后的状态更新携带该token。数据库或工具网关在真正写入点检查它是否仍有效。若仅在worker开始时检查一次，长工具执行期间租约失效仍可能产生竞态。时间比较应由权威服务完成，不能依赖客户端时钟声明租约有效。

fencing不自动解决外部副作用。目标系统如果不认识token，旧worker已发出的邮件、工单或交易请求仍可能生效。应在网关提交前重新核验，并结合稳定业务操作ID、接收端幂等和外部read-back。对于无法查询且无法幂等的高风险操作，宁可暂停人工对账，也不要因为租约换了owner就自动重放。

并非所有对象都需全局锁。独立资源可以并行，单个Session或可变记录可用单写者、compare-and-swap或资源级锁。测试故意暂停旧worker、让租约过期、新worker接管后再恢复旧进程，观察本地提交、工具调用与外部结果是否都符合约束。否则“有锁”只是一项实现描述，不是重复效果不会发生的证据。

可在日志中记录worker身份、token、取得和失效时间，以及每次提交被接受或拒绝的原因。运行代次是控制信息，不需要交给模型自由填写。对于多个资源的联动更新，单个Run租约还不够；资源版本、数据库事务或明确补偿流程仍然必要，不能把执行owner唯一误认为业务更新原子。

同一token的多次提交仍需业务去重。控制执行资格和控制动作次数是互补机制，不应互相替代。

实践重点：租约带单调token，在网关或目标写入点核验；外部副作用仍需幂等。

验证抓手：制造租约过期后旧worker复活，检查写入和外部调用。

常见误区：只锁本地状态，却认为旧worker不可能继续调用外部工具。

Temporal：执行状态与外部副作用；DeepSeek Harness：事件日志驱动循环。