哪些只读工具该并行，哪些桌面动作必须串行

先说结论：只读工具应该尽量并行，桌面动作和有依赖关系的副作用步骤必须串行。 判断标准不是“这个工具快不快”，而是它会不会改变共享状态、会不会依赖上一步的结果、会不会让后续证据失真。对执行型 AI 助理来说，并行度不是越高越好；真正重要的是在速度和可验证性之间找到边界。

这也是为什么 OmniGoAI 的 GoWork 会鼓励把 read_file、stat_path、list_directory、web_search 这类只读动作成批发起，却要求桌面点击、输入、截图、等待页面变化按顺序推进。执行系统最怕的不是“慢一点”，而是把还没稳定的状态当成已验证结果。 一旦把读写边界搞混，后面所有判断都可能建立在被自己污染过的现场上。

如果你已经看过 为什么常驻助理需要全局并发闸门 和 桌面任务排队不等于串行系统：GoWork 如何同时并行多任务又避免抢鼠标，这篇文章要回答的是更落地的一层：到底哪些工具调用应该并行，哪些必须串行，为什么。

一个最实用的判断法：先看它会不会改变现场

判断工具该并行还是串行，最简单也最可靠的问题只有一个：这一步会不会改变后续步骤看到的现场？

如果答案是否定的，它通常适合并行；如果答案是肯定的，就应该默认串行，除非你能证明这些变化彼此独立、不会互相覆盖。

按这个标准，执行动作大致可以分成三类：

1. 纯只读探针：读取文件、看目录、查状态、搜网页、取历史记录；
2. 有副作用但独立的动作：改文件、发命令、创建记录、写日志；
3. 强依赖现场的交互动作：桌面点击、输入、截图、等待窗口、读取刚变化的页面。

真正适合大并发的是第一类；最容易出事故的是第三类。

为什么只读工具通常应该并行

1. 它们读的是现状，不会制造新状态

像 read_file、stat_path、list_directory、glob_search、grep_search、web_search、web_fetch 这类工具，本质是在做事实采样。只要查询对象彼此独立，同时发起通常不会改变结果。

比如要判断一个内容流水线任务是否可继续，assistant 往往需要同时知道：

1. 官网仓库是否存在；
2. topics.md 是否存在；
3. writing-guide.md 与 distribution.md 是否存在；
4. 最近运行日志长什么样。

这类信息之间没有前后依赖，分四轮慢慢读只会增加延迟，不会增加正确性。并行发起才是合理默认。

2. 并行只读能降低“等待性空转”

很多 agent 任务的第一阶段，本质上是把上下文拼完整。如果每次只读一个文件、等结果回来再想下一个，系统大部分时间都浪费在无意义等待上。

对用户来说，他们看到的是“明明只是看几个文件，为什么要拖这么久”；对系统来说，这还会放大上下文切换成本。只读工具并行，最大的收益不是炫耀吞吐，而是更快到达“可以做判断”的那个点。

3. 并行只读更适合做交叉验证

执行系统经常要避免错误探针。例如：

• 只看某个固定路径，不能证明软件没装；
• 只看 PATH，不能证明命令不存在；
• 只看单个状态字段，不能证明发布失败。

这时更稳的做法，往往是并行拉多个互补证据，再合并判断。比如同时看 stat_path、目录列表和历史日志，通常比单条探针更接近真实世界。

为什么桌面动作必须串行

1. 桌面只有一份前台现场

鼠标位置、键盘焦点、当前激活窗口、页面是否滚动到某处，这些都只有一个真实值。两个动作同时尝试改变它，本质上就是争用同一个现场。

所以桌面自动化里最危险的并行，不是“两个任务都在运行”，而是两个步骤都假设自己看到的是稳定前台。 一旦这个假设不成立，点击就会点错，输入就会输到别处，截图就会截到不该看的窗口。

2. 桌面验证依赖“动作之后的观察”

桌面任务通常不是“点一下按钮”就结束，而是：

1. 点击；
2. 等待界面变化；
3. 读取变化后的文本或截图；
4. 再决定下一步。

这说明每一步都依赖上一步刚刚制造出来的现场。如果把这些动作并起来跑，后面的观察就失去了因果关系：你已经无法确定这张截图到底是哪个点击带来的结果。

3. 串行不是保守，而是保护证据链

执行型 AI 助理必须能回答“你为什么认为这一步成功了”。桌面链路里，最可靠的证据通常就是：

• 点击了哪个控件；
• 等到了什么窗口；
• 截图里看到了什么文字；
• 后续页面出现了什么状态。

如果多个桌面动作交错执行，这条证据链就会断。结果不是单纯“更难 debug”，而是你根本无法诚实地说清成功依据。

有副作用的文件与命令，为什么也不该乱并行

桌面最明显，但并行边界不只发生在桌面。

1. 同一文件的多次改写必须串行

如果两个步骤都要改同一份文件，比如先生成文章骨架、再写正文、再补 frontmatter、再修正错别字，这些步骤通常有明确顺序。并行写回很容易出现后写覆盖前写，或者把基于旧版本算出的修改套到新版本上。

这也是为什么写完文件后，常见的合理节奏是：

1. 写入或替换；
2. 回读一次确认结果；
3. 再继续下一步。

这里的回读不是浪费，而是在副作用动作和后续依赖之间建立一个验证点。

2. 长命令的“已启动”必须靠后验证

run_shell_command 跑构建、下载、安装、dev server、GUI 启动时，如果预期运行很久，就该转后台并轮询真实输出。把多个启动命令一股脑前台并行丢出去，最大的风险不是慢，而是你会误把“超时被杀”当成“启动成功”。

在执行系统里，命令返回了不等于结果已经稳定存在。 真正能宣称“已启动”“已成功”的证据，应该来自后续的进程、窗口、文件或 HTTP 可达性验证。

3. 发布、提交、通知这类动作天然带顺序

内容发布流程里，官网部署、收录提交、多平台分发、更新日志、Git 提交，看起来都属于“调用工具”。但它们不是独立球体，而是一条有顺序的业务链：

1. 文章先通过质检；
2. 再部署官网；
3. 再拿正式 URL 做收录；
4. 再引用官网链接做平台分发；
5. 最后再更新状态文件和提交仓库。

如果把这些动作并行化，最常见的后果就是后一步引用了还不存在或尚未验证的状态。

哪些情况最适合“并行只读 + 串行执行”

这是执行系统里最常见也最好用的组合模式。

场景 1：任务开始前的上下文收集

适合并行读取：

• 配置文件；
• 目标目录是否存在；
• 历史日志；
• 最近运行记录；
• 相关参考文档。

读取完之后，再按顺序执行真正的改动。

场景 2：写入前的多源核验

例如准备发布文章前，可以并行做：

• 查账号状态；
• 查平台能力；
• 查最近是否已发过同一 slug；
• 查本地生成文件是否齐全。

这些检查本身不改状态，但能显著降低后面串行发布时的失败率。

场景 3：失败后的重新判断

某一步失败后，不应该立刻把另一个有副作用的补救动作也丢上去。更稳的做法往往是先并行补足只读探针：

• 看错误输出；
• 看目标文件现状；
• 看历史记录里同类失败怎么发生；
• 看依赖项是否真的存在。

先把“到底哪里坏了”读清楚，再决定下一个写操作。

哪些情况绝对不该并行猜

1. 依赖上一步输出的动作

如果 B 步要用到 A 步生成的文件、URL、ID、窗口状态、recordId，那么 A 和 B 就不该并行。否则你只是把“未准备好”变成一种概率事件。

2. 需要实时观察反馈的交互动作

任何“做一下再看看结果”的动作，本质上都是串行交互。例如点击按钮后看页面有没有报错，发布后看有没有公开链接，登录后看是否到了已登录态。这里并行化几乎只会损失可解释性。

3. 共享同一个对象所有权的动作

如果两步都在改同一文件、同一发布记录、同一桌面窗口、同一后台会话，就要先明确谁拥有这份状态。没有所有权，所谓并行只是碰运气。

一个实用标准：决定并行前先问这四句

在真正放行并行之前，assistant 至少该先问自己四个问题：

1. 这一步会改变别人随后要观察的现场吗？
2. 后续步骤是否依赖它的输出？
3. 如果两个动作同时发生，我还能说清每个结果来自哪一步吗？
4. 出现异常时，我能否把责任定位到某一个动作，而不是一团交错状态？

只要其中有一个答案是否定的，就应该更偏向串行。

为什么这条边界会直接影响用户体验

用户表面上只会感知到两件事：快不快、稳不稳。但真正决定“稳不稳”的，恰恰是并行边界画得对不对。

• 边界画对了：用户会觉得系统反应快，而且结果可信；
• 边界画错了：用户会看到莫名其妙的误点、重跑、覆盖写、状态误判。

执行型 AI 助理最忌讳的一种错觉，就是把“同时调用很多工具”误当成“执行能力强”。很多时候，更成熟的表现恰恰是：该并行的地方毫不犹豫地并行，该串行的地方老老实实一步一步做。

如果你们团队正在设计会写文件、会跑命令、会操作桌面、还要回答状态问题的常驻助理，可以把这条边界理解成一个底层原则：先并行收集事实，再串行改变世界。 你可以继续看 GoWork 下载页、为什么常驻助理需要全局并发闸门 和 用户只问“现在到哪了”时，为什么不该重新操作桌面或重跑任务 来把这套原则放到更完整的执行架构里。

常见问题

FAQ 1：只读工具并行，会不会读到彼此不一致的状态？

会有这种可能，所以前提是这些查询对象彼此独立，或你知道这种轻微时差不会影响决策。若查询结果高度依赖同一瞬时状态，就该缩小并行范围。

FAQ 2：桌面任务既然会自动排队，为什么还强调串行？

因为排队解决的是资源占用，不等于你可以在一个桌面流程内部同时猜多步动作。流程内部仍然需要“动作—观察—判断”的串行节奏。

FAQ 3：写完文件后再读一遍，会不会显得低效？

不会。对有副作用的步骤来说，回读一次通常是最便宜的验证手段。少这一步，后面一连串动作都可能建立在错内容上，返工更贵。

FAQ 4：能不能把多个发布动作一起并行发出去？

只有在你确认它们互不依赖、目标对象不同、且每个平台返回结果都能独立核验时才适合。只要它们共享同一份发布参数、同一 recordId 语义或同一登录会话，就要更谨慎。

FAQ 5：一句话概括这条边界，最准确的说法是什么？

可以。读取事实尽量并行，改变现场默认串行；凡是会影响证据链的动作，都不要贪并发。