GoWork 定时任务通知会发到哪里？

如果你在 GoWork 里创建过定时任务，十有八九很快会遇到三个问题：这个提醒到底会发到哪里、为什么“我有哪些提醒”看到的是全局结果、以及有些任务为什么根本不该发通知。 先说结论：GoWork 里的“定时任务”和“通知目标”不是一回事；任务负责按时间触发，通知目标决定结果回到哪个会话，是否回传则要看任务类型和配置。

这也是 OmniGoAI 的 GoWork 和普通提醒器不太一样的地方。它不是简单在某个渠道里弹一条消息，而是把“触发任务”“在哪个会话回传结果”“是否只做后台执行”拆开处理。一旦把这三层混在一起，最常见的后果就是：该静默的任务乱通知，不该跨会话的结果发错地方，用户在查提醒时又误以为系统把数据搞混了。

如果你已经看过用 GoWork 定时任务做巡检、日报和自动跟进和聊天渠道上下文和运行上下文有什么区别，这篇文章会把问题进一步收窄到一个最常见、也最容易被误解的点：GoWork 的定时任务通知究竟发到哪里，scope 又为什么经常和用户直觉不一样？

先说结论：定时任务的“执行范围”和“通知范围”是两层不同概念

最短的理解方式可以记成下面三句话：

任务本身回答“什么时候触发、触发后做什么”；
通知目标回答“结果回到哪个会话”；
列表查询 scope回答“你现在是在看全局任务，还是只看当前聊天绑定的任务”。

很多误解，都是因为把这三件事当成同一件事。

例如，用户说“明天早上提醒我开会”，系统既要创建一个会在明早触发的任务，也要决定提醒回到哪个会话。用户再问“我有哪些提醒”，系统默认又应该展示自己当前生效的全部提醒，而不是只展示刚才这个聊天里的那一条。所以一个任务既可能只绑定当前会话通知，也可能在查询时出现在全局列表里，这并不矛盾。

什么决定定时任务的结果会发到哪里？

最直接的因素是通知目标，也就是任务完成后要把结果投递到哪些 conversation。

情况 1：默认绑定当前会话

这是最常见的场景。用户在某个聊天里说：

“今晚 8 点提醒我交周报”；
“明天早上 9 点提醒我跟客户确认合同”；
“每周一 10 点提醒我看排期”。

如果没有额外指定别的通知目标，GoWork 通常会把提醒绑定到当前会话。这样做的好处是最符合直觉：任务在这里创建，结果也回到这里。

这也是为什么很多用户会形成一个自然预期：我在这个聊天里建的提醒，就应该回这个聊天。 这个预期大多数时候是对的，但它只说明默认通知目标通常是当前会话，不代表系统里的任务可见性也只局限于当前会话。

情况 2：显式发到别的会话

有些任务不是给当前聊天自己看的，而是要把结果送去另一个会话、群或渠道。典型例子包括：

在网页端先配置一个日报任务；
到点后把摘要发去钉钉群；
或者把某条巡检结果统一回到团队群，而不是个人测试会话。

这时需要理解的是：任务是在当前会话里创建的，不代表通知一定也回当前会话。 创建入口和通知目标可以不同。

情况 3：静默后台执行

还有一类任务根本不需要每次都打扰用户，例如：

只是在后台轮询某个条件；
每次运行都写历史，但只有命中条件才需要通知；
或者某些定时维护动作只关心 run 记录，不关心实时消息。

这类任务可以不绑定通知目标，让它保持静默后台执行。它依然会运行，也依然会留下 run 历史，但不会每次触发都往聊天里发一条消息。

这个设计很重要，因为不是所有定时任务都应该表现成“聊天提醒”。很多用户以为“不通知就等于没运行”，其实并不是。在执行型系统里，运行和通知是可分离的。

为什么“我有哪些提醒”默认看到的是全局，而不是当前聊天？

这是另一个高频困惑点。

用户问“我有哪些提醒”时，真实意图通常不是“只看这个聊天里的提醒”，而是“把我现在还生效的提醒都列出来”。如果系统默认只查当前会话，经常会漏掉用户在别的会话、别的渠道里创建的任务。

所以更合理的默认是：

全局列表：回答“我整体有哪些还在生效的提醒/任务”；
当前会话列表：回答“这个聊天里绑定了哪些提醒”。

两者并不是一个谁对谁错的问题，而是回答的范围不同。

举个很典型的例子：

你在网页里建了一个巡检任务；
又在 Telegram 里建了一个明天早上的提醒；
再在钉钉群里建了一个工作日定时汇总。

这时你回到网页问“我有哪些提醒”，如果系统只返回当前网页会话里的那一个，反而更像漏数据。默认返回全局，才能符合大多数人的管理预期。只有当用户明确说“当前会话”“这个聊天里的提醒”时，才应该缩小查询范围。

notifyTargets、当前会话和静默运行，分别适合什么场景？

可以把它们理解成三种不同的协作意图。

1. 当前会话：适合个人提醒和就地回传

例如：

“明早 8 点提醒我开会”；
“每天下午 6 点提醒我发日报”；
“30 分钟后提醒我回来继续这个任务”。

这类任务最重要的是“在哪里说，就回哪里”。结果直接回当前会话，用户不用切地方找。

2. 指定通知目标：适合团队同步和跨渠道回传

例如：

“每天 9 点把巡检摘要发到团队群”；
“监控到页面恢复后，通知到值班群”；
“任务完成后把结果回到固定的项目会话”。

这里重点不在创建入口，而在送达目标。换句话说，任务的控制面和结果的展示面可以不是同一个会话。

3. 静默运行：适合监控、守护和不值得每次发消息的任务

例如：

每 5 分钟检查一次状态，只在条件命中时才需要回报；
后台做周期汇总，失败或异常时再通知；
某些定时数据处理任务只需要 run 历史，不需要实时 ping 人。

这类场景最怕的是“每次都通知”，因为那会把真正重要的信号淹没。静默运行的价值就在于把噪音拿掉，只在必要时把结果带回来。

为什么监控类任务尤其不能把“运行”和“通知”混为一谈？

因为监控任务的重点是持续观察，而不是持续发消息。

比如：

“每 5 分钟检查一次网页价格，降到 250 再告诉我”；
“盯着某条发布任务状态，一旦 completed 就通知我”；
“每 10 分钟看一次日志，有新的 ERROR 再告诉我”。

这些任务如果每次轮询都推送消息，很快就会变成骚扰；如果完全不回传结果，用户又会怀疑任务是否真的在跑。更稳的做法通常是：

后台定时执行；
正常情况下只留下 run 历史；
条件命中时再向通知目标发结论；
如果这是一个“盯到发生为止”的任务，命中后顺手结束或取消任务。

这也是为什么用 GoWork 定时任务做巡检、日报和自动跟进里会反复强调：监控不是“每天提醒一次”，而是“按频率检查，只在值得打扰时通知”。

为什么用户常常会误解 current conversation 和 all scope？

因为人脑默认是按“我现在在哪个聊天里”来思考，而系统管理任务时往往要按“我整体有哪些任务”来组织。

这会带来三个典型错觉。

错觉 1：在这个聊天里创建的任务，就只属于这个聊天

实际上，它可能默认通知回这个聊天，但从系统管理视角看，它仍然是一条全局任务记录，可以出现在你的全局任务列表中。

错觉 2：全局列表里出现别的任务，说明系统串会话了

也不一定。更常见的情况只是：你在别的会话里也建过任务，而“我有哪些提醒”默认本来就应该把这些一起列出来。

错觉 3：没有通知，就说明任务没执行

对静默任务尤其容易这样误判。事实上，很多任务根本设计成“只记 run，不发消息”，除非条件命中或者出现异常才通知。

一个实用判断：什么时候该查全局，什么时候只查当前会话？

可以用一个很简单的经验法则。

适合查全局的情况

当用户在问：

“我有哪些提醒？”
“我现在有几个定时任务？”
“哪些任务还在生效？”

这类问题通常应优先理解成全局盘点。

适合只查当前会话的情况

当用户明确说：

“这个聊天里的提醒有哪些？”
“当前会话绑定了哪些定时任务？”
“刚刚在这里建的那个提醒还在吗？”

这时重点才是会话内范围，而不是全局概览。

设计定时任务通知时，最容易踩的三个坑

坑 1：默认把所有任务都发消息

这会让监控、守护、轮询类任务产生大量噪音。执行系统一旦变成“每次都 ping 人”，用户很快就只想把通知关掉。

坑 2：把“查询范围”误当成“通知目标”

全局列表是给用户盘点任务用的；通知目标是任务完成后把结果送去哪里。两者不是同一个字段，也不该互相替代。

坑 3：没有区分创建入口和结果回传入口

任务可以在网页中创建，却把结果发去钉钉；也可以在定时任务专属沙箱里运行，但最终自动投递到用户可见会话。如果把“在哪创建”和“回到哪”当成同一件事，很多跨渠道协作都会解释不清。

常见问题

FAQ 1：我在当前聊天里创建的提醒，一定会只出现在这个聊天里吗？

不一定。默认通知目标通常会绑定当前会话，但当你查询“我有哪些提醒”时，系统更合理的默认是返回你的全局生效任务，而不是只返回这个聊天里的子集。

FAQ 2：为什么有些定时任务没有通知我，但它其实在运行？

因为有些任务本来就设计成静默后台执行。它们会留下 run 历史，只有条件命中、失败或出现异常时才需要回传结果。

FAQ 3：什么时候应该显式指定通知目标，而不是用当前会话？

当任务结果需要回到另一个团队群、另一个渠道，或者需要把控制面和展示面分开时，就应该显式指定通知目标，而不是默认回当前会话。

FAQ 4：为什么“我有哪些提醒”不默认只看当前会话？

因为大多数用户问这句话时，真正想知道的是“我整体还有哪些活跃提醒”。如果默认只查当前会话，反而容易漏掉在别的聊天、别的渠道里创建的任务。

如果你想把“定时任务会不会通知我”这件事理解透，最重要的不是把它当成单一提醒器，而是把它拆成“什么时候触发”“在哪里回传”“是否应该静默运行”三层来看。这样你再去设计日报、巡检、自动跟进或跨渠道回传时，就不容易把 scope、通知目标和执行方式混在一起。想亲自试试，可以从 GoWork 下载页开始，再配合 GoWork 助理能力文档看看一条定时任务是如何从触发一路走到结果回传的。