“任务到哪了”和“停下别做了”不能混着处理

先说结论：“任务到哪了”是状态查询，“停下别做了”是控制指令，两者不能按同一种消息处理。 前者的目标是读取已有进度、回答当前状态；后者的目标是改变系统状态，让正在运行的任务真正停止。执行型 AI 助理如果把这两类话混在一起，最常见的结果不是“理解得不够优雅”，而是要么为了答进度又误触发一次任务，要么在用户只是问情况时把任务直接掐掉。

这也是 OmniGoAI 的 GoWork 为什么要把“状态查询”“继续执行”“停止运行”明确拆开。对会读文件、跑命令、操作桌面、常驻并行执行任务的助理来说，用户每一句短消息都可能带来真实副作用。真正稳定的系统，不是看到“刚才那个”就统一当成同一种后续，而是先判断：用户现在是在要观测值，还是在发控制命令。

如果你已经看过用户只问“现在到哪了”时，为什么不该重跑任务和为什么工具调用前要先说意图，这篇文章可以继续往前走一步：为什么“问进度”和“要求停止”不只是语气不同，而是调度层面完全不同的两类输入。

先说结论：状态查询回答事实，停止命令改变事实

可以先记住一个最实用的判断：

“现在到哪了？”“还要多久？”“上面那个跑完没？”这类话，默认是在问当前事实；
“停下”“算了”“别做了”“取消这次”这类话，默认是在要求系统立刻改变当前执行状态；
前者最稳的处理方式是读 active run 的摘要、recent events、等待原因；
后者最稳的处理方式是定位目标 run，然后真的发出 cancel，而不是只在文字里说“好的我不做了”。

这条边界看起来简单，但它直接决定一个助理是“会协作”，还是“会误伤”。因为状态查询解决的是认知问题，停止命令解决的是控制问题。 它们需要命中的系统层完全不同。

为什么“任务到哪了”不能按“停下别做了”处理

因为用户要的是观测，不是干预

当用户问“现在到哪了”，通常真正关心的是：

已经完成了哪些步骤；
当前卡在哪一步；
是在运行、排队、等待审批，还是已经结束；
大概还需要多久；
有没有错误或外部阻塞。

这些问题的共同点是：用户要的是系统已经知道的执行事实。 这时最该做的，是读取现有状态，而不是去影响它。

如果助理把这种问题误判成停止信号，就会出现一种很糟糕的体验：用户只是来问进度，你却把任务取消了；用户本来只是想决定要不要继续，结果你替他做了决定。

因为状态问题默认应该是只读的

一个设计正常的执行系统，本来就该有这些状态证据：

当前 active run 的状态；
最近一次用户可见进度；
当前步骤标题、等待原因或失败摘要；
当前独占资源是否正被某个任务占用。

所以当用户问进度时，最合理的默认动作应该是：先读这些只读信号，再回答。 如果反而把它当成停止命令，相当于绕过了本来最适合回答这类问题的证据层。

为什么“停下别做了”也不能按“任务到哪了”处理

反过来，停止命令也不能只回一句状态概览了事。

因为用户不是在问系统看到了什么，而是在要求系统停止继续做

如果用户说：

“停”
“算了”
“别做了”
“取消刚才那个任务”

那他的真实意图不是“告诉我现状”，而是“请你对现状施加控制”。此时如果 assistant 只是回答：

“现在正在发布到第三个平台”；
“还剩 Git 提交和收录”；

这当然可能是对的，但没有完成用户的要求。因为只读回答并不会让任务真的停下来。

因为“口头答应停止”不等于系统已经停止

执行型助理里最危险的一类假完成，就是文字上说“已取消”，但底层 run 仍在继续跑。一个桌面任务可能还在点页面，一个后台命令可能还在构建，一个分发任务可能还在继续发布。如果不真的调用取消动作，只靠语言上的“好，我停下”，用户得到的是错觉，不是控制结果。

这也是为什么在 GoWork 这类系统里，明确停止通常应该：

先定位用户说的是哪一个正在运行的 run；
发出取消请求；
再把已完成的进度和当前真实状态告诉用户。

顺序不能反过来，更不能只做第三步。

这两类消息命中的系统层为什么不同

状态查询命中的是执行元数据层

状态查询通常依赖这些只读信息：

recent events；
latest summary；
waiting reason；
当前计划里的步骤状态；
资源占用与排队信息。

这些数据的价值在于：

只读，不会污染现场；
接近当前时刻，适合回答“现在”；
成本低，不用重跑桌面或命令；
可解释，能直接生成用户读得懂的进度说明。

停止命令命中的是任务控制层

停止命令则不同，它依赖的是：

哪个 run 还在运行；
用户说的“刚才那个”到底指哪一条；
cancel 是否真正成功；
取消后系统剩下什么状态。

也就是说，它不是“读到什么就回答什么”，而是“先控制，再汇报”。这一步如果不碰任务控制层，任务就不会停。

最容易做错的地方：把简短口语一律当成同一种后续

现实对话里，用户很少总是说完整句子。真正高频的是这些短话：

“刚才那个呢？”
“现在呢？”
“停。”
“别弄了。”
“继续。”
“上面那个改一下。”

麻烦就在于：它们都很短，但执行含义差很多。

只读状态问题通常长这样

例如：

“现在到哪了？”
“还要多久？”
“刚才那个做完没有？”
“你卡在哪一步了？”

核心语义是：告诉我当前状态。

明确停止命令通常长这样

例如：

“停下。”
“算了，别做了。”
“取消这个任务。”
“上面那个不用继续了。”

核心语义是：让它停止。

真正棘手的是“像纠正，又像新任务”的消息

例如“选 64 位”“换个账号登”“不要博客园了”。这类消息看起来像在纠正正在进行的任务，但它们既不是纯状态查询，也不是纯停止。最稳的做法通常不是立刻 cancel，而是先确认：是要改当前任务，还是另开一个新任务。

这也是执行系统里一个很重要的边界：能改向，不代表应该先杀掉。

为什么把两类消息混为一谈会造成真实损失

1. 会制造不必要的中断

如果用户只是想问进度，你却把任务停了，之前已经完成的步骤可能白做了：

已构建但还没部署；
已登录但还没提交；
已排队但还没轮到；
已发布到一半但日志还没收尾。

这种损失不是回答得不够好，而是系统边界判断错了。

2. 会制造“以为停了，其实没停”的错觉

反过来，如果用户明确说停，你却只给状态摘要，不发 cancel，那么外部动作可能还在继续：

后台构建仍在跑；
桌面自动化还在占资源；
分发任务还会继续命中下一个平台。

这种错觉对用户伤害更大，因为他会以为系统已经服从控制指令。

3. 会让并发调度失真

GoWork 这种常驻助理会同时面对多个 run。状态查询类消息应该尽量只读回答，不去碰桌面；停止命令则应该精确命中对应 run。如果两者不分，系统要么会无端抢占独占资源，要么会停错任务。

对于并行任务环境，这不是小瑕疵，而是调度正确性的核心。

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

面对短消息时，可以按下面顺序判断：

先看这句话要的是观测值还是控制动作；
如果是观测值，先读 active run / recent events / waiting reason；
如果是明确停止，先定位目标 run 并 cancel；
如果像纠正或改向，不要直接停，先判断是不是要修改当前任务；
最后再用自然语言把真实状态告诉用户。

这个顺序的好处是，它把“读状态”和“改状态”分开了。只要这一步不混，系统就不容易在最基础的交互上犯大错。

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

用户很容易感知两件事：

我只是问一句进度，系统为什么擅自停了？
我已经明确说停，系统为什么还在继续？

一旦其中任何一种情况出现，用户就会同时失去两层信任：

对理解能力的信任：你到底有没有分清我在问什么；
对执行边界的信任：你会不会把一句短话误解成另一种动作。

对 GoWork 这类长期协作型助理来说，真正建立信任的，不是每次都显得“很积极”，而是该读状态时只读状态，该停任务时真的停任务。 这条边界越稳，用户越敢把持续运行的任务交给系统。

你可以在 GoWork 下载页体验这种执行边界；如果你还想继续看状态问答这一侧的细节，也可以读用户只问“现在到哪了”时，为什么不该重跑任务和为什么 AI 助理应该在聊天里回答“任务到哪了”。

常见问题

FAQ 1：如果用户只说“刚才那个”，算状态查询还是停止命令？

单看这四个字，不足以确定。要结合后面的动词判断：如果是“刚才那个到哪了”，更像状态查询；如果是“刚才那个别做了”，就是停止命令。只有在语义仍然不够时，才值得追问，而不是先做一个不可逆的猜测。

FAQ 2：用户说“停”，需要先汇报进度再取消吗？

不需要先汇报，应该先取消。因为用户的主要诉求是控制动作停止，而不是先听状态说明。取消成功后，再把当前已完成的步骤和停止后的真实状态简短告诉用户，顺序才是对的。

FAQ 3：如果系统里有多个正在运行的任务怎么办？

这时不能凭感觉停“最像的那个”。应该先根据当前会话里的 active runs、最近事件和用户指代去定位目标；如果仍有歧义，再确认用户要停的是哪一个。停止命令要求的是精确控制，不是模糊匹配。

FAQ 4：为什么“继续”和“停下”也不能对称处理？

因为它们改变系统的方向相反。继续意味着让当前任务沿原计划往前推进，停下意味着立刻终止后续动作。两者都属于控制类指令，但执行路径完全不同，不能因为都很短就复用同一套处理逻辑。