那天处理桌面自动化时，我先关心的是一个很具体的体验问题：一个任务用完应用以后，应该马上退出，还是留在后台，等下一个任务接着用？应用每次启动都要花时间，既然已经打开，留着似乎更快。可当我把问题往前推一步，真正的风险就出现了：如果此刻不止一个任务在使用同一个应用，谁有权决定它什么时候退出？
旧流程里有一个“启动前清理已有应用”的选项。它的本意是避免旧状态干扰新任务，执行时会优雅地退出已经打开的应用。单独看，这个动作很合理；放到多个自动化会话同时工作的环境里，它却可能变成一次无知的抢占。任务甲刚准备开始，看到应用已经存在，于是发出退出；任务乙也许正在里面处理自己的草稿，却没有机会解释。
共享桌面应用不是一个可以随手重启的普通进程，而是一项需要被明确交接的受保护资源。
先看到的，不一定是可以关闭的
我一开始把问题理解成“怎样让应用更快回到首页”。因此注意力放在快捷键、窗口隐藏和后台等待上，想找一种成本更低的收尾方式。后来排查启动路径才发现，速度不是最先要解决的问题，所有权才是。
旧路径在启动时可以带上“终止已有实例”的选择。它只判断应用是否存在，却没有判断是否有别的会话持有界面使用权。于是，“应用正在运行”被错误地等同于“应用可以被我接管”。这两个判断看起来只差一步，后果却完全不同。
如果不处理，最坏的情况不是一次启动慢几秒，而是一个任务在不知情时关闭另一个任务的工作环境。对方可能已经打开了草稿、完成了一段耗时操作，甚至正等待应用返回一个结果。关闭以后，表面上只剩一次失败；实际上，失败原因已经被破坏性动作掩盖了。后面的重试也未必能补回原来的状态。
这件事让我重新意识到，桌面自动化的危险常常不在“点击错了”，而在于动作之前少问了一句：现在是谁在使用？只要这个问题没有进入流程，任何看起来温和的退出动作都可能越权。
租约把“正在使用”变成可判断的状态
这时最容易误判的，是把租约理解成又加了一层复杂管理。其实它解决的是一个很朴素的问题：当多个会话都能发出操作时，应用本身不会替我们判断谁应该继续留下。我们需要把“我正在使用它”写成其他会话能够看到、能够检查、也能够等待的状态。
仓内已经有生命周期守卫和界面租约存储，所以我没有另造一套仲裁机制。已有能力足以表达持有者、有效期限和释放状态。复用它的好处不只是少写代码，更重要的是，启动、操作和退出可以沿着同一套生命周期理解，不会出现一条路径认租约、另一条路径绕过去强退的情况。
租约可以看成一张短期通行证。任务拿到它，说明自己暂时拥有操作共享桌面的资格；租约带有有效期限，说明资格不会无限期占用；任务在运行中持续续期，说明它还活着、还需要这项资源；任务结束时主动释放，说明下一个任务可以接手。
租约的价值不在于让所有任务同时操作，而在于让“谁可以操作”成为一个可验证、可过期、可交接的事实。
正确顺序比关闭动作更重要
修复时，关键不是把退出命令删掉，而是调整它在流程中的位置。启动前先检查是否存在他方租约；确认没有冲突后，当前任务获取自己的租约；只有在自己的租约已经成立以后，才决定是否需要关闭应用、回到首页或继续复用。
这个顺序看似保守，实际上是在给每一个破坏性动作加边界。没有租约时，任务没有资格改变共享应用的状态；有了自己的租约，任务才可以按照当前车道的规则继续。即使最终仍然需要关闭某个旧草稿，动作也不再是“我看见它了所以我关掉”，而是“我已经确认资源归我，再按生命周期完成交接”。
我选择把获取租约放在可能关闭应用之前，是因为关闭本身会改变其他会话能够观察到的世界。任何会影响他人状态的操作，都应该发生在所有权确认之后。反过来，如果先关闭、再申请租约，申请失败时已经来不及恢复，系统只能留下一个无法解释的中间状态。
这也是为什么不能只在收尾时释放租约。收尾释放解决的是“我用完以后让出资源”，启动前检查解决的是“我开始以前不要撞上别人”。两者缺一不可。
运行中续期，退出时释放
短期租约还有一个现实问题：任务可能卡住、崩溃，或者被外部终止。如果只在开始时写一次持有记录，正常任务也许能工作，异常任务却会把资源永久锁住。下一个会话看到这条记录，只能一直等，最后有人又会忍不住绕过守卫，直接强退应用。
所以租约需要后台心跳续期。只要任务还在正常运行，就不断把有效期往后推；如果任务已经失去执行能力，心跳停止，租约在期限到达后自然失效。这不是为了把异常变得完美，而是为了让异常最终回到可恢复状态。
正常退出时，流程登记释放；异常退出时，也要有释放登记或过期清理。这里的“登记”很重要，因为释放不是一句口头约定，而是下一个任务能读到的状态变化。只有释放真正写入存储，交接才算完成。
当然，TTL 不是万能保险。系统时钟、后台线程、进程被强制终止，都可能让续期出现延迟。因此判断持有关系时，不能只看“记录存在”，还要看它是否仍在有效期内；处理边界时，也要避免把刚刚续期的租约误判成残留。
冲突时要停下来，而不是碰运气
多个会话竞争时，最容易采用的错误捷径是：先尝试关闭，失败了再重试；或者发现应用被占用，就不断循环启动，希望某一次恰好成功。这种做法把冲突当成偶发故障，却没有改变所有权关系。重试越积极，越可能叠加对正在工作的会话的干扰。
我更愿意让冲突以明确状态结束：发现他方持有租约，就返回可诊断的退出码，不关闭应用，也不做无脑重试。调用方因此知道任务没有获得资源，用户也知道应该等待、改用其他车道，或者检查持有者是否已经结束。失败被保留下来，才有机会被正确处理。
共享资源发生冲突时，安全的默认答案不是“再试一次”，而是“先不改变他人的状态，并把冲突说清楚”。
这件事表面上是在保护一个应用，实际上是在保护任务之间的因果关系。一个任务失败，应该因为它没有拿到租约而失败，而不是因为它先把别人的应用关掉以后才失败。前者可以诊断和重排，后者会把现场一起抹掉。
从桌面应用推广到其他共享资源
把这套方法抽象出来，流程可以压缩成4个动作：启动前检查，操作前持有，运行中续期，退出时释放。检查回答“别人是否正在用”；持有回答“我是否获得资格”；续期回答“我是否仍然活着”；释放回答“下一个任务何时可以接手”。
它不只适用于桌面应用。浏览器、模拟器、摄像头、串行设备、单例服务，只要多个自动化任务可能碰到同一个资源，就值得先问有没有清晰的占用边界。尤其是那些不能安全并行、也不能随便重启的资源，更应该把租约放在业务动作之前，而不是出了事故以后才补日志。
一个流程成熟的标志，不是它顺利时能多快打开应用，而是它遇到竞争时能不能稳住。测试也应该覆盖互斥、续期和释放后的交接：两个会话同时申请时只能有一个成功；持有者持续运行时租约不会误过期；释放以后，等待者能够接手；冲突时应用保持原状，返回值足以说明发生了什么。
这些测试不是为了证明某次点击成功，而是为了证明系统没有把“资源归谁”交给运气。真正要保留的不是某个快捷键或某次窗口切换，而是动作背后的判断链。
下次我会怎么做
下次再设计多个 Agent 共用桌面应用的流程，我会先把应用当成受保护资源，而不是当成随时可以重启的背景进程。第一步检查他方租约，第二步拿到自己的短期租约，第三步才执行打开、切页或关闭等会改变状态的动作。运行过程中让心跳续期，正常退出主动释放，异常退出依靠过期机制回收。
如果发现他方已经持有，我会让当前任务带着明确状态退出，不强退、不绕过、不靠重试碰运气。只有当所有权关系清楚以后，速度优化才有意义；否则所谓的复用，只是把一次冲突藏到下一次启动里。
我更愿意把租约看成一种工作习惯：先确认自己是否有资格改变共享环境，再去追求更快、更省事的操作。
这件事也给我留下一个更宽的提醒。自动化真正难的不是让一个任务完成，而是让多个任务在彼此不知道全部细节时仍然能够共存。租约把这种共存从临场默契变成可检查的规则，应用可以留在后台，任务也可以继续提速，但前提始终是：谁在使用，谁持有；谁结束，谁释放；发生冲突，就先保护现场。