配置通知

本指南介绍如何配置通知，以及每一项设置实际控制的是什么。

通知经由两个界面送达。通知中心——标题栏里的铃铛——读取服务器上按工作区划分的持久信息流。操作系统 Toast 则是一条独立的、仅限桌面的路径，由服务器推送的实时帧供给。

打开或关闭各类别

前往 设置 → 你 → 通知
保持 启用通知 处于开启状态
切换你想要的类别。一共恰好十七个：

类别	触发时机
智能体已完成	智能体在你发起的运行中做出了回复，或运行失败
智能体在等你	智能体需要你批准、向你提出了问题，或因凭据问题而暂停
PR 已发布	智能体发布了一个 PR
PR 已合并	一个 PR 被合并
新消息	有人在空间中提及了你
在 pull request 中被提及	GitHub 的通知轮询发现你在某个 PR 中被提及
请求评审	有非草稿 PR 实际请求你评审
评审已过期	你已评审过的 pull request 上有了新提交
可合并	你创建的 pull request 变为可合并，或不再可合并
评审决定	评审者批准、请求变更，或批准被驳回
检查	你创建的 pull request 上 CI 失败或恢复
评审讨论串	你所在的讨论串里有人回复或解决了该讨论串
工单已分配	有工单被分配
工单状态已更改	有工单更改了状态
会议即将开始	日历会议已进入你的提前提醒窗口
日历已断开连接	已连接日历的 OAuth 令牌已过期
隔离舱动态	隔离舱被接管、回收或发生故障

不在此列表中的任何内容都无法通知或筛选——并不存在“其他全部”类别。

智能体在等你 在每次等待开始时触发一次：待处理的批准（包括沙盒执行授权和 Claude Code 工具批准）、一个 ask_user 问题，或因凭据无法为其提供服务而被挂起的运行。它会打开你需要作答的空间；如果你正在查看该空间，则不会提醒。

这些偏好设置跟随你的用户跨设备同步，因此手机和笔记本电脑保持一致。音量是有意保留的例外，按设备分别设置。

设置 Quiet hours

在同一页面上打开 Quiet hours
以 HH:MM 格式输入开始和结束时间（默认时间段为 22:00–08:00）

在 Quiet hours 期间，非紧急通知会被丢弃——不会排队留待稍后补发。

有两个类别属于紧急，始终送达，会绕过 Quiet hours 和专注模式：会议即将开始 和 PR 已发布。一场事后才看到的会议提醒毫无价值，这就是原因。

选择提示音

滚动到 通知声音
从十一种内置声音中挑选一种，或选择无
按下测试按钮试听，并用滑块调节音量

声音由应用自己播放；操作系统通知则静默送达，因此你不会听到两次。

设置会议提前提醒时间

滚动到 提醒提前量
选择 5、10、15 或 30 分钟

这就是 会议即将开始 通知在日历事件之前多久触发。默认为 5 分钟。

了解通知何时会被抑制

只要满足下列任一条件，通知就会被静默丢弃：

通知已被全局关闭，或该类别已被关闭
你已经处于它会带你前往的路由上——若是消息，则已身处该空间
专注模式已启用，且该类别不属于紧急
Quiet hours 已启用，且该类别不属于紧急

这些检查适用于操作系统 Toast。持久的铃铛仍会记录该事件。

还有两处抑制位于更上游，也就是决定服务器究竟发送什么：

来自其他人类、未提及你的消息永远不会变成通知
在共享空间中，智能体的回复只会通知发起该运行的人，而不是每位成员
智能体与智能体之间的空间在侧边栏中被静音，因此永远不会增加人类的未读徽标

在一个空间内没有安静的角落：每段对话都一视同仁地发出通知，讨论串也不例外。已读状态以空间为范围，因此未读数是跨空间内所有对话汇总的，而不是按对话分别跟踪。

查看并清空通知中心

点击标题栏中的铃铛

弹出面板会显示最近的活动，每个条目都深链到它所涉及的对象。打开它不会把所有内容标为已读——请使用顶部栏中的 全部标为已读，或单独标记某一条。已读状态跟随你的用户跨设备同步。

故障排查

macOS 上收不到操作系统通知

应用启动时会以原生方式请求授权。如果你拒绝了，请在系统设置 → 通知中重新启用 Control Center；应用内没有再次触发该请求的提示。

Web 构建上什么都收不到

属于预期行为——Web 构建没有操作系统通知管线。请使用铃铛。

铃铛徽标显示为零，但明显有新的活动

在连接后已读标记流解析完成之前，条目会按已读渲染，以避免徽标先闪现随即清空。标记加载完成后就会稳定下来。

智能体的运行已完成，但没有通知我

检查你是否已经身处该运行所在的空间——处于活动路由会抑制它自身的操作系统 Toast。在共享空间中，别人发起的运行会通知对方，而不是你。既没有回复也没有出错就结束的轮次不会发送任何通知。