最近和好朋友聊天时遇到一个很小但很真实的问题。
平时我会发很多 spontaneous thoughts。想到什么就说什么，频率高，密度大，但多数不需要立刻回复。对方把我 mute，是合理的注意力保护。
问题出现在另一种状态：我们已经开始对话了。
比如她刚回完我，我隔了 3–5 分钟再回。如果她继续 mute，就只能反复打开 app，看我有没有回复；如果她解除 mute，又会重新暴露在我平时那些低紧急度消息里。
表面上这是一个 notification UX 小问题。实际暴露的是一个更底层的抽象错误：
现有 mute 把长期注意力策略和短期对话状态压成了同一个开关。
## **Mute 不是对人的评价，而是对 interruption 的授权**
现在大多数 notification control 都围绕静态单位展开：
- app：这个应用能不能通知我；
- person：这个人能不能通知我；
- group/channel：这个群能不能通知我；
- thread：这个话题串能不能通知我；
- Focus mode：当前状态下允许哪些人或 app 打扰我。
这些单位都合理，但都缺一层：**conversation session**。
同一个人，在不同 interaction state 下，对我注意力的合理占用完全不同：
|**状态**|**消息性质**|**合理通知策略**|
|---|---|---|
|ambient stream|高频、低紧急度、可异步消费|静音，进 inbox|
|active exchange|已经进入来回对话，需要维持同步感|轻提醒|
|coordination|现实事务正在协调，延迟成本高|更高优先级|
|focus / sleep / class / work|receiver 当前不可打断|压制，除非接收者预先授权例外|
|exceptional ping|少量真正需要突破的情况|限额、可撤销、receiver-authorized|
所以 mute 不该被理解成“我不想听这个人说话”。更准确的定义是：
我不允许这个 sender 在默认状态下打断我。
这给 session-aware mute 留出了空间：默认 mute 仍然成立，但当接收者自己参与了一段对话，系统可以临时恢复轻量提醒。这个临时提醒不是 sender 获得了新权力，而是 receiver 刚刚用行为表达了一个短时 intent：**这段互动暂时是 active 的**。
## **IM 的核心难点：它不是同步，也不是异步**
Instant messaging 不是电话，也不是 email。它是 semi-synchronous medium。
电话默认假设双方同时在场；email 默认假设可以延迟处理。IM 的奇怪之处在于，它允许几秒钟内快速来回，也允许几分钟、几小时甚至一天后再回。Avrahami、Fussell 和 Hudson 的 _IM Waiting_ 研究本身就把问题放在 “timing and responsiveness in semi-synchronous communication” 里讨论，这说明 IM 的体验不是只由内容决定，而是由时间结构决定。
早期 IM 研究也强调，IM 支持 quick questions、coordination、scheduling、keeping in touch 这类 informal communication，而且它的 immediacy 正是这些任务可行的原因之一。Nardi、Whittaker 和 Bradner 还提出 IM 有 “outeraction” 层面：很多消息不是为了传递信息本身，而是在维持可接触性、连接感和未来互动的可能性。
这就是 mute 的困难：
同一条消息流，既可能是 ambient social presence，也可能是 active coordination。
如果完全静音，active exchange 会断掉；如果完全放行，ambient stream 会变成长期打扰源。
所以问题不是“这个人重要吗”。亲密关系里的很多消息重要，但不紧急。也不是“这条消息语义上重要吗”。一句 “ok” 单独看很轻，但如果它发生在约时间、确认地点、处理误会、等待答复的 session 里，它的 interrupt value 可能很高。
通知系统真正要判断的是：
这条消息在这段 interaction 的当前状态里，是否值得现在打断 receiver？
## **现有 notification research 已经解决了一半问题**
这不是一个完全没人研究过的问题。Attention-aware 和 context-aware notification 很早就在研究 interruption cost。
Horvitz 的 attention-sensitive alerting 把问题写得很清楚：系统需要在 “deferring alerts 的上下文成本” 和 “interruption 的成本” 之间做权衡，而这个权衡需要考虑用户活动和通知内容的不确定性。
Mehrotra 和 Musolesi 对 intelligent notification systems 的 survey 也把目标定义为：通过推断 right time / right context 来提高用户对通知的 receptivity，并总结了 interruptibility、notification relevance、context-aware delivery 等研究方向。
Iqbal 和 Bailey 的 work 进一步说明，interruption 的时机本身会影响 resumption lag 和 annoyance；在更合适的任务边界打断用户，会比随机打断造成更少恢复成本和烦躁感。
传统 intelligent notification 更关注 user state：用户现在忙不忙、是否可被打断、通知内容是否重要。
Session-aware mute 关注 interaction state：这段关系中的这一次对话是否仍处于 active session。
**sender identity 之外，应该有一个 receiver-controlled interaction session 作为 notification permission 的作用域。**
## **现有产品只做到相邻层，还没做到 session lifecycle**
行业已经在往更细粒度 notification control 走，但没有真正解决 session lifecycle。
Slack 已经支持 thread-level notification。用户可以对单个 thread 选择收到新回复提醒或关闭回复提醒；在某些 thread 中，参与过、发起过或被 mention 过也会影响是否收到新回复提醒。
Android 11 把 Conversation 提升为系统级 primitive，支持 conversation notification 的 priority、alerting level、bubble 等；Android 12 又增加 Recent Conversations 和 Conversation Widget，允许用户更方便地调整最近对话的行为。
Apple Focus 允许按 people 和 apps 允许或静音通知，也支持 Time Sensitive Notifications；Apple Intelligence 进一步做 notification summaries、priority notifications 和 Reduce Interruptions Focus，用内容理解来筛选可能需要立即注意的通知。
这些都是重要先例，但它们处理的主要是：
- app/person/thread 的静态权限；
- notification 内容的重要性；
- receiver 当前 Focus context；
- thread subscription；
- 单条 notification 的 priority ranking。
它们没有把一个隐含状态建模出来：
我刚刚参与过这段对话，所以这个 thread 在接下来一小段时间里进入 active session；如果它延续当前 interaction，就可以轻量突破默认 mute；如果它变成新的 thought dump，或者超时，就自动回到 muted stream。
这就是 session-aware mute 的位置。把 thread subscription 从手动静态订阅，推进到 receiver-initiated、time-bounded、stateful session control。
## **一个更准确的模型：mute 是 baseline，session 是 override**
Session-aware mute 里至少有三层状态，不应该只做成 “mute / unmute”。
### **1. Baseline policy**
这是长期策略。
例如：
这个人默认 muted。
她的消息进入 inbox，但不 push。
这不是关系降级，而是 interruption 权限默认关闭。
Baseline policy 解决的是长期注意力保护。
### **2. Session state**
这是短期互动状态。
例如：
receiver 刚刚回复了 sender；
当前 thread 在 20 分钟内进入 active window；
如果后续消息延续同一话题，发送轻量提醒；
如果超时、话题切换、receiver 显式关闭、或系统置信度不足，则回到 baseline mute。
Session state 解决的是半同步对话中的等待成本。
### **3. Exceptional override**
例如：现实事务、时间敏感协调、receiver 预先授权的 priority ping。
但它必须非常克制。Priority ping 如果由 sender 任意触发，就会变成“绕过 mute 的按钮”。真正合理的设计应该是 receiver-authorized：接收者决定谁有额度、什么时候可用、超出后是否冷却、是否可以撤销。
这里的权力边界很关键：sender 可以请求注意力，但不能获得注意力。 receiver 才拥有 interruption 权限。
## **决策函数：“现在打断是否划算”**
```text
notify if:
expected value of immediate awareness
>
interruption cost
+ privacy risk
+ social pressure risk
+ notification fatigue cost
```
同一条消息在不同 session 中价值不同：
| **消息** | **单独看** | **在 session 中** |
| ------------------- | ------- | ----------------------- |
| “ok” | 低信息量 | 可能是在确认计划 |
| “到了” | 普通状态更新 | 可能需要立即看到 |
| “你刚刚说的是这个意思吗” | 普通澄清 | active exchange 中需要同步 |
| 一连串 random thoughts | 可能有趣 | 默认不该打断 |
| “晚点说” | 普通短句 | 明确 session close signal |
所以 session-aware mute 不应该只做 message urgency classification。它要估计的是：
message value within current interaction state。
这也是为什么只靠 keyword、sender priority 或 Focus mode 不够。它们没有建模 “这段对话现在是不是还活着”。
## 示例状态机
```text
default:
baseline = muted_stream
receiver replies:
enter active_session for 20 minutes
new message arrives:
if same_session and receiver_not_in_hard_focus:
notify_lightly
else:
queue_to_inbox
receiver sends close signal:
end_session
no interaction for N minutes:
enter cooling
cooling expires:
return to muted_stream
priority_ping:
notify only if receiver granted quota
```
没有 decay，session-aware mute 会退化成 person-level unmute。
没有 receiver initiation，它会退化成 sender-controlled interruption。
没有 same-session 判断，它会退化成“只要我刚回过你，你接下来发什么都能响”。
## **LLM 的位置：recognizer，不是 ruler**
LLM 在这里最合理的位置是 perception layer：
它可以辅助判断：
- 是否在回答刚才的问题；
- 是否延续同一话题；
- 是否明显开启新话题；
- 是否是 thought dump；
- 是否包含现实协调；
- 是否出现 session close signal，比如“先这样”“晚点说”“我去忙了”；
- 是否是低置信度情况，需要保守处理。
但 policy layer 不能交给 LLM。Policy 必须由规则和 receiver preference 控制：
- active window 多久；
- 谁可以进入 session-aware alerts；
- focus / sleep 是否硬阻断；
- priority ping 每天/每周多少额度；
- 模型低置信度时默认静音还是提醒；
- 是否允许某个 sender 使用该机制。
LLM 判断“这像不像同一个 session”；
系统规则决定“这有没有资格打断 receiver”。
最近确实已经有研究探索用 LLM 做 personalized notification urgency classification。例如 PersoNo 在 Mixed Reality 场景中用 LLM 分析用户回复行为模式来分类通知紧急度，并报告了 81.5% accuracy；它也强调 activity context、content、sender 都会影响 urgency 判断。
但PersoNo 主要是 urgency classifier。我要写的是 session controller。
Urgency classifier 问：这条通知急不急？
Session-aware mute 问：在 receiver 刚刚参与过的这段 interaction 中，这条消息是否仍属于同一个 active session，因此是否临时获得轻量提醒资格？
## **Threat model：风险来自社会关系**
notification system 会改变关系里的权力结构。
### **1. False positive：普通消息被误判为 active session**
结果：muted sender 又开始频繁打断 receiver。
设计约束：active alert 应该是轻量提醒；低置信度默认进 inbox；用户可以一键 “close session”。
### **2. False negative：真正的 active reply 被静音**
结果：receiver 又回到手动刷新 app 的状态。
设计约束：receiver 参与后的第一轮回复可以更宽松；现实协调类消息可以有更高权重；但不能无限放大。
### **3. Sender abuse：priority ping 变成绕过 mute 的按钮**
结果：mute 失去意义。
设计约束：priority ping 必须 receiver-authorized、限额、冷却、可撤销，并且 sender 不能知道自己是否“还剩几次有效突破”。
### **4. Social pressure：系统强化“你为什么不回我”**
结果：notification design 变成关系压力工具。
设计约束：session state 不能暴露给 sender。Sender 不该看到 “对方当前把你设为 active session / 关闭了 active session / 看到了但不回”。
### **5. Privacy leakage：系统开始推断关系状态**
结果：聊天软件从 communication tool 变成 relationship surveillance layer。
设计约束：尽量 local inference；最小化 message content processing；不要把 inferred state 用于广告、推荐、关系评分、社交排序。
### **6. State stickiness：active session 不退出**
结果：系统用“正在聊天”的名义，把一个高频 sender 重新变成常驻打扰源。
设计约束：强制 timeout、cooling period、topic drift detection、explicit close。
所以这不是一个“智能一点就好”的功能。它必须被当作 permission system 设计，而不是 ranking system 设计。
## **Product grammar：它应该长什么样**
一个合理的产品形态不是多一个总开关，而是把 person-level mute 拆成 baseline + session rules。
对某个联系人，用户可以设置：
```text
Default:
Muted stream
Allow:
Active reply alerts: on
Coordination alerts: on
Priority ping: 2/week
During Sleep Focus: off
During Study/Work Focus: inbox only
```
在对话里，系统可以显示 receiver-only 状态：
```text
Active session: 18 min left
Reason: You replied recently
Mode: Light alerts only
[Close session]
[Keep active for 1 hour]
[Always queue this person]
```
收到消息时，系统可以解释：
```text
Notified because this thread is still active.
Queued because this looks like a new topic.
Queued because Focus mode is on.
Notified because this sender used an authorized priority ping.
```
这类 explanation 很重要。没有 explanation，用户会觉得系统随机。
但 explanation 只能给 receiver 看，不能给 sender 看。
这个功能的设计原则可以总结成四条：
1. **Receiver sovereignty**：打断权限属于接收者，不属于发送者。
2. **Temporal boundedness**：任何 session override 都必须过期。
3. **State visibility to receiver only**：状态可解释，但不可社交化。
4. **Conservative automation**：模型可以辅助识别，但不能扩大 sender 权力。
## **衡量它是否真的有用**
如果要判断 session-aware mute 是否成功，不该只看 “通知点击率”。
更好的指标是：
| **指标** | **说明** |
| ----------------------- | ---------------------------- |
| manual refresh rate | receiver 是否减少反复打开 app 检查回复 |
| false breakthrough rate | muted sender 的低价值消息是否错误打断 |
| active reply latency | active session 中回复是否更容易被及时看到 |
| unmute/remute frequency | 用户是否少了手动切换通知设置 |
| session close usage | 用户是否理解并使用 close session |
| perceived control | 用户是否觉得自己控制了注意力 |
| sender abuse rate | priority ping 是否被滥用 |
| fatigue delta | 总通知疲劳是否下降，而不是换一种方式增加 |
这能把文章从 “feature wish” 拉到 “system proposal”。
## **总结**
Mute 解决的是长期打扰问题，但没有解决短期对话同步问题。
现有 notification system 太依赖 sender identity：这个人能不能通知我。
但 IM 的真实互动不是按人发生的，而是按 session 发生的。
同一个人可以同时是：
平时静音；
正在聊时轻提醒；
现实协调时优先；
睡觉或专注时完全不可打断；
特殊情况可用有限 ping。
所以更好的抽象不是 smarter notification priority，而是：
session-aware notification control。
它的核心不是让 AI 判断谁重要，而是把 notification permission 从 person-level static rule 改成 receiver-controlled, time-bounded, interaction-state-aware scheduler。
一句话：
Mute 不应该回答 “who can notify me?”
它应该回答 “under what interaction state can this thread interrupt me?”