桌面被占用时怎么办：resource holders 与自动排队的正确用法

先说结论：当桌面正被别的任务占用时，最稳的做法通常不是取消旧任务，也不是拒绝新任务，而是让需要桌面资源的动作自动排队。 resource_holders 的作用，是告诉助理“当前哪种独占资源已经被别的 run 占着”；桌面队列的作用，是在不互相抢鼠标键盘的前提下，把多个需要桌面操作的任务串起来执行。对执行型 AI 助理来说，这不是调度细节，而是能不能同时支持并行任务、又不把现场搞乱的基本能力。

这也是 OmniGoAI 的 GoWork 为什么把“并行跑任务”和“独占桌面串行化”分开处理。一个系统可以同时跑很多互不冲突的任务，比如写文件、读日志、查网页、整理报告；但只要某一步要碰同一套鼠标、键盘和屏幕，它就必须遵守独占边界。真正靠谱的协作体验，不是“桌面忙了就什么都别做”，而是能并行的继续并行，必须独占的自动排队。

如果你已经看过 为什么“任务到哪了”和“停下别做了”不能混着处理 和 哪些只读工具该并行，哪些桌面动作必须串行，这篇文章会把其中最容易让人误判的一层讲清楚：当系统已经告诉你桌面正被占用时，正确动作为什么是排队，而不是抢占、重跑或误取消。

先说结论：resource holders 负责暴露占用事实，队列负责消化冲突

可以先记住这四条：

1. resource_holders 说的是现在谁占着独占资源，不是“系统报错了”；
2. 桌面资源被占用，只说明后续桌面动作需要排队，不说明整个任务必须停止；
3. 不需要桌面的步骤应该照常并行推进，只有真正要碰桌面的动作才进入串行队列；
4. 最危险的误判，是把“桌面当前不可立即使用”理解成“新任务不能做”或“旧任务必须取消”。

这条边界为什么重要？因为它直接决定系统是“并行但有秩序”，还是“表面并发、实际上互相干扰”。

resource_holders 到底在表达什么

它表达的是“当前独占事实”

当系统返回某个资源持有者时，最关键的信息不是“失败了”，而是：

• 哪个资源正在被占用；
• 是被哪个其它 run 占用；
• 新来的动作是不是也需要同一种资源。

对桌面任务来说，最常见的就是 desktop 这类独占资源。因为真实的鼠标、键盘、屏幕只有一套。一个 run 正在点浏览器登录，另一个 run 又去拖窗口、输入文字、截图识别，这两边如果同时执行，结果通常不是“更快”，而是互相把现场打乱。

它不是“遇到冲突就立即报错”的暗示

很多系统在设计不成熟时，会把资源占用直接包装成失败：桌面忙了，于是新任务就失败；或者更糟，后来的任务为了“能立刻做事”，先把前一个任务强行停掉。这样表面上看像是快速响应，实际上是在把调度问题转嫁给用户。

resource_holders 更合理的用途，是让助理知道：这里存在冲突，但冲突是可管理的。 它的职责是告诉你现场情况，而不是替你做过度激进的控制决定。

为什么桌面任务不能像普通只读工具那样直接并行

因为桌面不是可复制资源

读文件、查状态、搜索网页这类动作，通常可以天然并行：

1. 它们多半是只读；
2. 即使同时运行，也不会争抢同一套物理输入设备；
3. 一个请求的观测行为不会轻易破坏另一个请求的现场。

桌面操作不是这样。桌面自动化依赖的是：

• 当前前台窗口；
• 当前光标位置；
• 当前焦点控件；
• 当前屏幕上可见的像素状态。

这些条件都是全局共享的，而且会被别的桌面动作立刻改变。所以两个桌面 run 同时推进，本质上是在争同一个现场。

因为桌面动作强依赖上下文连续性

桌面任务经常是多步链条：

1. 打开窗口；
2. 等页面加载；
3. 识别按钮；
4. 点击；
5. 再看结果。

如果第 3 步和第 4 步之间，另一个 run 把窗口切走、把焦点抢走、或者把页面滚到了别处，那么前一个 run 后续所有判断都可能失效。也就是说，桌面冲突不是简单的“谁先谁后”，而是会破坏整段操作的语义连续性。

为什么正确动作通常是排队，而不是取消

因为资源冲突不等于目标冲突

新来的任务需要桌面，不代表它和当前任务在业务上互相排斥。很多时候，它们只是都要用同一套物理资源，但目标完全不同。例如：

• 一个任务在登录平台后台；
• 另一个任务要截图下载页；
• 第三个任务在后台读文件和生成报告。

这里真正冲突的只有前两个桌面动作，第三个任务完全可以继续。即便前两个也只是资源使用时机冲突，不是“只能二选一”。这类场景下，最稳的做法就是让后来的桌面动作排队，等前面的 run 释放资源后再接着做。

因为擅自取消会破坏用户原本允许的并行性

用户把常驻助理交给系统时，通常默认接受的是：互不冲突的任务可以并行推进。要是系统一看到桌面占用，就把新任务取消或把旧任务停掉，那相当于把“系统内部的资源协调成本”变成“用户必须手动重试”的成本。

这类取消尤其容易造成两种损失：

1. 前一个桌面任务本来快做完了，却被中途打断；
2. 后一个任务本来只需要等几十秒，却被错误地当成无法执行。

这不是保守，而是过度干预。

自动排队到底解决了什么问题

它把“同时到来”变成“有序上场”

桌面队列最核心的价值，是把多个都需要桌面的动作，从“争抢现场”变成“排队进入现场”。这意味着：

• 不需要你手工协调哪个任务先来；
• 不需要助理为了腾桌面而取消别的 run；
• 不需要把“现在不能立刻点鼠标”误判成“整个目标做不到”。

系统只需要保证一件事：同一时刻只有一个 run 在真正操作桌面。 一旦这条被守住，多个桌面任务就能以串行但可预期的方式完成。

它保留了任务级并行，只把冲突步骤串行化

这里最重要的一个观念是：被串行化的应该是资源冲突步骤，不是整个任务生命期。

例如一个长任务可能包含：

1. 读取配置文件；
2. 生成要提交的内容；
3. 等待轮到桌面；
4. 打开浏览器并点击；
5. 再写日志和汇报结果。

其中真正需要排队的，往往只有第 4 步附近的一小段。前后的读写、计算、整理、日志记录，完全可以不占桌面地继续推进。一个好的系统不会因为中间有一段桌面动作，就把整个任务都锁死成串行。

最常见的错误：把“桌面被占用”理解成三种错误结论

错误一：桌面忙 = 新任务不能开始

这是最常见的误判。实际上，新任务通常仍然可以先做很多事：

• 解析用户意图；
• 读相关文件；
• 查现有状态；
• 生成计划；
• 准备稍后要用的数据。

只有在它真的马上要碰桌面时，才需要进入等待队列。把整个任务一开始就否掉，等于把“部分步骤暂时不能执行”误判成“全流程不能执行”。

错误二：桌面忙 = 必须取消正在运行的任务

这同样不成立。除非用户明确说“停下那个”，否则系统没有理由为了给新任务腾资源而取消旧任务。资源冲突是调度问题，不该默认升级成控制动作。

如果每个新来的桌面任务都能把前一个挤掉，最终得到的不是并发，而是持续互相打断。这样的系统最不值得信任，因为它看起来响应很快，实际上谁都做不完。

错误三：队列存在 = 系统不支持并行

这也是个常见误解。真正的并行系统，并不是要求所有步骤都同时执行，而是能并行的地方并行，必须串行的地方只串行那一小段。 桌面队列的存在，恰恰说明系统承认物理世界有独占边界，而不是假装“一切都能同时点”。

用户应该收到怎样的反馈才算靠谱

当桌面正被别的 run 占用时，最好的用户反馈通常包含三层信息：

1. 当前桌面资源正被别的任务占用；
2. 这个新任务会排在后面，前一个释放后自动开始；
3. 除了桌面步骤之外，其它不冲突的准备工作会照常推进。

这种反馈很重要，因为它既没有制造“任务失败了”的错觉，也没有夸大成“我现在马上就在点”。它给用户的是真实状态：正在排队，不是被放弃。

一个更稳的处理顺序是什么

面对需要桌面的新任务时，可以按下面顺序处理：

1. 先判断当前目标里哪些步骤真的需要桌面；
2. 查看 resource_holders，确认桌面是否被其它 run 占用；
3. 能并行做的只读/准备步骤先继续做；
4. 真正进入桌面动作时，交给系统队列排队；
5. 前一个 run 释放后，再继续执行后续桌面步骤；
6. 只有用户明确要求停止某个任务时，才进入取消流程。

这个顺序的关键，在于它把“资源协调”和“任务控制”分开了。只要这两件事不混，系统就不会因为一个暂时的独占冲突，把本来可以顺利完成的任务搞成中断或误停。

为什么这条边界会直接影响用户信任

用户真正关心的通常不是“底层有没有队列”，而是两件更直观的事：

1. 我新发的任务会不会因为别人正在用桌面就被忽略？
2. 我正在跑的任务会不会因为新消息进来就被擅自打断？

如果系统能稳定做到“新任务排队而不丢、旧任务不中途被误停”，用户就会很快建立一种预期：这个助理虽然同时接很多活，但不会抢鼠标，也不会乱改执行顺序。对 GoWork 这种长期协作型助理来说，这种预期比“表面上很积极地同时动很多窗口”更重要。

你可以在 GoWork 下载页 体验这种并发与队列边界；如果你还想继续看并行调度里的相邻话题，也可以读 为什么“任务到哪了”和“停下别做了”不能混着处理 和 为什么每次工具调用前都该先说一句。

常见问题

FAQ 1：桌面被占用时，助理是不是就该什么都不做？

不是。很多准备步骤并不需要桌面，例如读取文件、整理参数、查询状态、生成后续要提交的内容。真正该等待的，只有依赖鼠标键盘屏幕的那一段动作，而不是整个任务。

FAQ 2：如果新任务更紧急，系统应该自动抢占桌面吗？

默认不应该。是否打断当前任务，属于控制决策，不该由资源冲突自动推导出来。除非用户明确要求停止或改向当前任务，否则最稳的默认动作仍然是排队等待。

FAQ 3：桌面队列会不会让系统失去并发能力？

不会。它只会串行化真正冲突的桌面步骤，不会把所有读写、搜索、整理、汇报都一起锁死。能并行的部分仍然应该并行推进。

FAQ 4：resource_holders 和队列有什么分工？

可以把它们理解成“观测层”和“执行层”。resource_holders 负责告诉你谁正在占用独占资源；队列负责在这个事实之上安排后来的桌面动作按顺序进入。前者回答“现在是什么情况”，后者负责“接下来怎么安全执行”。