为什么常驻助理需要全局并发闸门

先说结论：常驻 AI 助理如果没有全局并发闸门，任务并行很容易退化成结果互相污染。 真正需要的不是“让所有 run 同时往前冲”，而是先判断：哪些动作彼此独立、哪些动作会争抢同一资源、哪些消息其实是在改当前任务方向。只有把这三类情况分开，assistant 才能既保持响应速度，又不把桌面、文件状态和任务结果搅乱。

这也是执行型产品和“只会回消息”的机器人之间的一条分水岭。OmniGoAI 的 GoWork 不是把每条新消息都粗暴塞进同一条流水线，而是先做更底层的调度判断：当前系统有没有资源冲突、有没有语义上的任务冲突、有没有只读查询可以立即回答。 没有这道闸门，所谓“并行”大多只是更快地产生混乱。

如果你已经读过 桌面任务排队不等于串行系统：GoWork 如何同时并行多任务又避免抢鼠标 和 “任务到哪了”和“停下别做了”为什么不能按同一种消息处理，这篇文章可以继续往前推进一步：为什么一个长期在线的助理系统，必须在入口层就有全局并发闸门。

什么是“全局并发闸门”

这里说的“闸门”，不是把所有任务都挡住不让跑，而是一个统一的决策层：当新消息、新定时任务或后台续跑同时到来时，系统先决定这次请求属于哪一类，再决定是否并行、排队、改向，还是只读回答。

一个可用的全局并发闸门，至少要回答四个问题：

1. 这是不是一个全新的目标？
2. 它会不会抢占某个独占资源，比如桌面或前台登录态？
3. 它是不是在纠正某个已经进行中的任务？
4. 它能不能先做不冲突的部分，再等待受限资源？

如果没有这层判断，系统最常见的失败方式就是：把“新消息”“状态问题”“停止指令”“纠正当前任务”“独立新任务”都按同一种入口处理，最后要么无意义互相取消，要么一起冲进同一资源，谁也说不清哪里错了。

为什么“支持并行”反而更需要闸门

很多人会误以为：只有串行系统才需要控制，真正并行就应该来什么跑什么。对执行型 AI 助理来说，情况恰好相反。

1. 并行增加的不只是吞吐，也增加了碰撞面

一个常驻助理同时接收的，可能有：

1. 用户发来的新请求；
2. 定时任务按点触发；
3. 长任务的自动续跑；
4. 用户对进行中任务的纠正消息；
5. 用户临时插入的“现在到哪了”这类状态问题。

这些消息的处理方式完全不同。真正的难点不是“能不能多开几个 run”，而是哪些 run 可以一起存在，哪些动作必须互斥。 如果没有统一闸门，每条消息都自顾自执行，最终会把系统逼成“表面全并行，实际全打架”。

2. 用户要的是结果连续，不是内部线程数好看

用户并不关心系统是不是同时开了 8 条 run。用户真正感受到的是：

• 新消息有没有被立即响应；
• 正在做的任务会不会莫名被打断；
• 回答“进度到哪了”时有没有重触发副作用；
• 最后结果能不能对应到明确的过程和证据。

全局并发闸门的价值，就是把“内部并发能力”翻译成“外部可理解的协作秩序”。

全局并发闸门到底在拦什么

它不是拦所有并发，而是拦下面三类高风险冲突。

1. 资源冲突

最典型的是桌面资源。鼠标、键盘、前台窗口、截图时看到的屏幕状态，本质上只有一份。两个任务同时点、输、截，就会互相污染。

但资源冲突不只发生在桌面。类似问题还包括：

• 同一个本地登录会话被两个流程同时推动；
• 同一份文件被多个步骤覆盖写入；
• 同一批发布目标在短时间内被重复触发。

闸门要做的不是禁止第二个任务，而是判断：它是不是应该排队、复用已有状态，或者先做不依赖这份资源的步骤。

2. 语义冲突

有些新消息不是新任务，而是在纠正旧任务。例如：

• “别用这个账号，换另一个。”
• “不要正式发布，先存草稿。”
• “选 64 位，不是 ARM。”

如果系统没有全局并发闸门，这些消息就可能被当成独立任务另起一条 run，结果不是纠正前一个动作，而是又开了一个竞争动作。最后旧任务继续错下去，新任务又在旁边启动一个新流程。

真正稳的做法是先拦一下：这是一条新目标，还是在改当前目标的方向？这个判断本身，就必须发生在全局入口层。

3. 只读查询被误当成执行请求

“任务到哪了”“刚才那个有没有失败”“我现在有哪些提醒”这类问题，很多时候只需要读状态，不需要再跑一遍任务。

如果没有全局并发闸门，系统很容易把所有消息都当作“要不要开始执行”。结果用户只是问一句状态，assistant 却真的去重开网页、重跑命令、重新抢桌面。这不仅慢，还会污染正在进行的任务。

所以并发闸门还有一个很重要的职责：把只读查询挡在副作用动作之前。

一个好的全局并发闸门，至少要做哪三层判断

第一层：先分消息类型

最先判断的不是资源，而是意图。常见至少要分成：

1. 状态查询；
2. 明确停止；
3. 对进行中任务的纠正或改向；
4. 全新的独立任务；
5. 定时触发或自动续跑。

只有先分出这几类，后面的资源调度才有意义。因为“停止一个任务”和“并行启动新任务”，看起来都像是来了新消息，但系统动作完全相反。

第二层：再看资源是否冲突

当请求被判定为独立新任务后，才需要继续判断它会不会抢占独占资源。

比如：

• 改一个文档，同时另一个任务在跑桌面发布：通常可并行；
• 读取运行历史，同时桌面被别的任务占着：应立即回答；
• 两个任务都要操作同一套桌面：应排队，不该互相取消；
• 两个任务都要改同一文件：要么合并到同一流程，要么先后串联。

这一步决定的是资源串联方式，不是任务是否存在的资格。

第三层：最后决定执行策略

同样是“新请求来了”，实际可落的动作可能完全不同：

1. 立即并行执行；
2. 先做非冲突部分，冲突资源排队；
3. 不新开 run，而是把消息视为当前任务的修正；
4. 直接只读回答，不触发执行；
5. 按用户指令取消某个 run。

很多系统之所以越做越乱，不是因为不会执行，而是因为所有请求最后都只会落到一种策略上。

为什么这件事对常驻助理尤其重要

1. 常驻意味着消息会在任何时刻进来

一次性问答模型大多只有“一问一答”这一种节奏，而常驻助理没有这个奢侈条件。用户可能在你部署网站时插一句“顺便帮我看下提醒”，也可能在定时任务自动发文时突然问“刚才那个任务别做了”。

如果没有全局并发闸门，系统就会把“任何时刻到来的消息”都视为同一类事件。结果是：要么过度保守，什么都串行；要么过度激进，什么都并发。

2. 常驻意味着旧任务不会自动消失

一个发布流程、桌面登录流程、长时间构建，往往不会在用户发来下一条消息之前结束。也就是说，系统默认总是带着未完成状态继续活着。

这就是为什么常驻助理不能只看“当前这条消息”，而必须看“当前系统里已经有哪些 run、谁占着什么资源、有没有未完成的等待态”。全局并发闸门的意义，就是把这些已有状态纳入入口判断，而不是假装每条消息都发生在真空里。

什么时候不该用“并发”去解决问题

并发不是默认正确答案。下面几种情况，真正需要的是别的动作。

1. 用户在改向，而不是加任务

如果用户说“换账号登”“别点那个”“用草稿模式”，最常见的正确动作不是新开一个 run，而是把它视为对当前任务的改向信息。

2. 用户在问状态，而不是催执行

如果用户说“现在到哪了”，正确动作通常是读最近事件并回答，而不是“为了确认状态”再去执行一遍。

3. 新请求只是共享了一个目标对象

比如两个任务都要改同一篇文章、同一份配置、同一个发布记录。这里最大的问题不是能不能并行，而是有没有统一的状态所有权。如果没有，结果通常是后写覆盖前写。

一个实用标准：判断是否该放行并发，先问这四句

在入口层，系统至少该先问自己：

1. 这个请求是在创建新目标，还是纠正旧目标？
2. 它是否需要某个独占资源？
3. 它能否先做不冲突的部分？
4. 如果现在放行，会不会破坏已有进度或证据链？

这四句问完，很多“看起来要复杂推理”的并发判断，其实会变得很清楚。

这条设计最后影响的是什么

表面上看，全局并发闸门是在做调度；实际上，它保护的是三件更底层的东西：

1. 结果的可验证性：动作和证据不脱钩；
2. 任务的连续性：新消息不会随便冲掉旧进度；
3. 协作的可理解性：用户能听懂为什么这次是并行、排队、改向或只读回答。

一个没有全局并发闸门的常驻助理，往往会在“很努力地同时做很多事”里失去可信度；而一个把入口分类、资源冲突和执行策略分开的系统，才更有可能在长期协作里既快又稳。

如果你们团队已经遇到这种典型场景：助理一边在跑桌面发布、登录或下载流程，一边又要回答“现在到哪了”、接收临时纠正、顺手改文件和处理定时任务，那真正需要补上的，通常不是“更多并发”，而是先把并发闸门设计对。你可以从 GoWork 下载页、桌面任务排队不等于串行系统 和 聊天渠道上下文和运行上下文有什么区别 继续往下看 GoWork 是怎么把这些边界落到真实执行里的。

常见问题

FAQ 1：有了全局并发闸门，是不是系统就不够并行了？

不是。闸门的作用不是减少并行，而是把该并行的工作放行，把会互相污染的动作串联起来。没有闸门，表面并行往往只是更快地出错。

FAQ 2：桌面排队本身，不就是全局并发闸门吗？

不是。桌面排队只是资源层的一部分规则；全局并发闸门还要处理消息分类、任务改向、停止指令和只读查询，范围更大。

FAQ 3：为什么不能所有新消息都先新开一个 run，再让后面自己收敛？

因为很多冲突发生在入口。如果用户其实是在纠正当前任务方向，晚一步识别就可能已经点错按钮、发错账号、改错文件。入口层判断越晚，回滚成本越高。

FAQ 4：状态查询为什么也要经过并发闸门？

因为它最容易被误当成执行请求。正确的闸门会先把这类消息识别成只读问题，直接读取当前状态回答，而不是重触发副作用动作。

FAQ 5：什么信号最能说明你们真的需要这道闸门？

如果你们已经反复遇到这几种情况——新消息一来旧任务就丢进度、只是问状态却重跑了一遍、两个流程抢同一桌面或同一份文件、用户改口却被当成新任务——那几乎可以确定，问题不在执行器，而在缺少全局并发闸门。