用于通知提醒的 DSH 插件

通知插件为长任务收尾：桌面弹窗、聊天消息、webhook，以及把日志转发到已经在给你发告警的系统。当会话要跑几十分钟、而你不再盯着终端时，它们最为重要。在本目录里，成熟的形态是把你接到已经在用的频道上、并带会话级命令与按频道访问策略的桥接——但「本机通知」这一更简单的形态同样成立，这个中心现在两者都收。

这同时也是索引里最拥挤的品类，所以在按 star 挑之前值得知道：144 个仓库名字里带 “notif”，其中 119 个停在 0–2 star，25 个达到 3 以上，而超过 50 的恰好只有两个。缺的从来不是覆盖面，而是信号。下面这三个已收录条目，是读过真实来源之后留下来的。

比较它们时看投递保证和噪声控制。在每个工具调用上都触发的插件会训练你忽略它；只在完成、失败或请求审批时汇报的插件，几个月后仍然有用。如果频道还能被其他人发消息，访问控制就是通知设计的一部分，而不是事后补丁。

怎么评估

先看事件面：哪些生命周期节点会真正发通知（任务完成、失败、需要人审、会话空闲）。再看消息去向——操作系统通知、IM 平台、webhook，还是分页系统——以及谁能反向把指令打进 harness。最后核对身份：在默认开放的群里，能给 bot 发消息的人可能就在操纵你的 agent，除非有白名单。

优先选择能把聊天绑定到明确会话、不把密钥写进消息正文、并写清传输方式（WebSocket、长轮询、Socket Mode）以便推理断线与重连行为的插件。

什么样算好

强的通知路径在顺利路径上很无聊，在信任路径上很严格。长跑结束或需要人时，你收到一条清楚的消息；不会被中间工具噪声淹没。入站命令要么关闭，要么只对已知用户开放。频道凭证活在模型上下文之外，文档写明需要的平台与权限范围。

单机笔记本上的系统托盘提醒就够了。会话比你的注意力活得更久时，团队聊天桥才是对的工具——在你还没决定谁可以反向说话时，它就是错的工具。

常见失败

常见失败是默认开放群策略的「常开」桥：第一天方便，第二天变成远程控制你 agent 的入口。第二种是通知刷屏，把唯一需要的完成消息埋掉。第三种是假设所有 IM 适配器安全模型相同——只支持开放私聊的平台，不等于有收窄应用令牌和白名单的平台。

安装顺序与边界

通知桥先确认绑定的是哪一个会话，以及敏感内容是否会被推到第三方。完成通知有用；无界的「所有工具输出都推 IM」是事故放大器。