# 主动触发机制设计（对标 Muse）

## Muse 是怎么做的（据官方复盘，2026-09）

三个要点，来源：[How We Designed Muse](https://introducing.muse.ai/)（2026-10-05 已核验原文；项目取舍见 [演进框架](evolution/README.md)）。

1. **日程与事件都能推进**：官方描述同时包括按日程和相关事件继续工作。邮件截止案例说明了主动发现的价值，但不足以推断底层采用推送还是轮询。当前 DSH 优先定时闭环，外部事件暂缓。
2. **唤醒与打扰分离**：后台工作完成后「先判断结果值不值得告诉你，只有有意义的新进展或需要用户参与时才通知」。心跳可以有固定频率，开口必须过判断门。
3. **门槛高且用户可调**：主动消息需要值得打断用户；用户可关掉/调低/调高频次。这是产品要求；仅凭设计文章不能推断具体训练方法。

另有第三种主动性：Ideas——持续根据目标、行为模式、对话信息生成「你能让我做什么」的建议（提示 / 想法标签页 / 主动分享）。

## 刻板感的真正来源

固定 30 分钟不刻板；**每次醒来都必定开口**才刻板。噪音 = 触发频率 × 说话率。Muse 的解法是压低说话率（判断门），而非消灭心跳。

## dsh-muse 的三层去刻板化

| 层 | 机制 | 状态 |
|---|---|---|
| 1. 静默心跳 | 无到期项不创建 turn；普通工作单元只在重要变化时通知 | 原生 routine 已实现，通知分寸仍需真实场景评估 |
| 2. 事件源 ingress | 规则/source 提供候选，预检后投递 | gate 有适配器；外部事件当前暂缓，不是下一优先级 |
| 3. 值得打扰判断门 + 用户可调频次 | 结构化 SAY/SKIP 判断；运行节奏有预算 | gate judge 已有，误报/漏报待按 E3 建基线；不宣称已具备完整设置 UI |

## 静默的边界（实测修正）

prompt 层的「静默」只能压低打扰度（不展开、内容最短），**不能消除痕迹**：静默检查本身是一个 turn，会留下活动记录。要「无痕静默」，判断门必须下沉到对话外——宿主侧代码在投递前预检（如脚本查信号文件），没事就不创建 turn。当前 gate 与原生 routine 巡检已有这类机制。

真正执行工作的轮次仍应留下可追溯记录；“不通知”不等于删除活动轨迹。普通任务的通知分寸仍部分依赖模型，须按 E3 同时验证误报和漏报。

## 演示验证中的一个真实发现

定时投递**需要会话空闲**：agent 忙碌（目标自动续跑轮次占用会话）时提醒被压住，空闲后补投。这意味着心跳语义必须考虑「醒来时可能已迟到 N 个周期」——投递侧是 at-least-once + 补投，不是精确时刻。与 Muse「永远在线的云端电脑」的差异再次指向冷唤醒/守护化（gaps.md 第 1、3 层）。