DSH 里最难处理的从来不是一问一答，而是那种跑起来就停不下来的长任务：全量编译、批量抓取、多轮重构。人在工位上还能盯着终端，一旦离开座位，任务要么卡在某次审批上没人点，要么闷头跑偏了没人知道。dsh-notifier（仓库 THEWOLFWALKER/dsh-notifier）盯的正是这一段，它把通知与远程操作合成一个控制面，出站覆盖 28 个渠道、入站开放 6 个控制渠道，手机端可以完成审批、提问与会话切换。想先横向看一眼同类插件的中文清单与安装形态，可以对照 DeepSeek Harness Hub 插件清单。
先把它可核查的基本盘放上来：Star 54、周下载 1,484、综合分 53.8、MIT 许可、运行时依赖 0、自动化测试 1831 个；npm 上发布的是 dsh-notifier @ 0.10.2，README 已经写到 0.12.0；Node 引擎要求 >=22；声明兼容的 DSH 范围是 0.1.7-alpha.1 || 0.1.7-alpha.2 || 0.1.7-rc.1 || 0.1.7-rc.2。信任档位标的是「已验证（L4 真实安装 2026/9/26）」，不是静态推断。另有一处数字出入要说明：站点简介写 27 个渠道，README 当前版本写 28 个，以版本化文档为准。
下面不铺功能清单，只讲四个真的会遇到的离席场景，以及每个场景里最容易踩空的地方。
场景一：任务跑了十几分钟还没结束，你想知道它是不是卡死了
turn/end 只告诉你「结束了」，但长任务的麻烦往往出在中途：它到底还在干活，还是挂在一个没人看见的提示上。这里用到的是 events.turnStart / events.longRunning / events.stall 这条状态线，配置大致长这样：
events:
turnStart: true
longRunning:
firstAfterMs: 900000
stall: truelongRunning.firstAfterMs: 900000 对应十五分钟：任务开始十五分钟仍未结束时，会推一条「还在跑」出来。这条通知的价值不是催你，而是把「沉默」和「卡死」区分开——以前你要么回去看终端，要么只能干等。再配合 events.exclude: ["heartbeat"] 这类防打扰设置，把纯心跳事件挡在门外，留下的就都是需要人判断的节点。
场景二：审批卡在你身上，而你正在地铁里
这是它在离席场景里最实用的一段。approval/asked 事件会触发远程审批，Telegram 与飞书可以直接用卡片里的原生控制按钮，QQ 是 C2C 原生按钮，其他目标自动回退到安全文本或编号回复。也就是说，你不必回到家点确认，在地铁上按一下就能放行。
这里要记住它的设计原则：裁决是一次性、fail-closed 的。它不会因为超时就默认放行，安静地放着不点，任务就会一直等下去。审批超时之后的行为由 approval 模块决定（超时、编号回复、升级提醒，mode: answer），但升级提醒也只是再提醒你一次，不会替你批准。想清楚这一点，才不会把它当成一个「默认允许」的开关。
场景三：它理解偏了，你想立刻拉回来
直接回一条纯文本，就是给 agent 的输入；而 ! 前缀是中途纠偏用的，任务已经在跑的时候也能打断方向，不必等它跑完。手机打字容易断成几段，所以有 conversation.mergeWindowMs: 1500 这个合并窗，把碎片拼回一条完整输入。
我自己的用法是：像「方向不对，改用增量方式」这类判断，在地铁上就发出去，比回到电脑前才发现白跑了半小时划算得多。
场景四：手机上把任务与会话切到正确的那个
多任务并行时最容易搞混的是「我现在这句指令到底发给谁」。私聊里有一组只读投影与控制命令：/tasks 看活跃任务、/use 选择任务、/sessions 看会话概览与 attention、/status 看当前路由与会话状态、/stop 停当前 turn（必须裸 /stop）、/quiet 与 /unquiet 静默或恢复某个会话的出站推送（不影响远程对话）、/whoami 核对身份与绑定状态。这些命令都走私聊，且要求已绑定身份。把它当成一个「口袋里的状态面板」，而不是又一套后台。
坑一：装完在侧栏怎么也找不到「通知与控制」
现象。 按说明去 DSH 侧栏找那个入口，翻不到，渠道列表也是空的。
原因。 Host 插件与 Client Module 需要一次完整装载，装完当次不会自动出现。
解决方案。 安装后重启一次 DSH，再从 DSH 侧栏进入，或者走 Plugins → dsh-notifier → 开始设置。首访完成的判据是真的收到一条测试通知，不是界面上点了保存就算。
坑二：想用 Gotify 或企业微信应用回消息遥控，发过去没反应
现象。 出站通知一切正常，于是顺手回了条消息想停任务，结果石沉大海。
原因。 开放入站控制的只有 6 个渠道：telegram、feishu、qq-bot、wxpusher、wechat、dingtalk；其余渠道只做出站，收到入站消息会自动回退成安全文本或编号回复，不具备控制语义。
解决方案。 需要双向遥控就固定用这 6 个之一当控制通道，其他渠道专门做通知分发，别指望它回传指令。
坑三：以为某个渠道能发图片或文件，实测发不出去
现象。 看到某个渠道在列表里，就默认它和 IM 一样能发图、发文件。
原因。 媒体与文件能力以 capability matrix 与真实平台验证结果为准，「代码已接线」不等于「真机已验证」。
解决方案。 先用渠道编辑里的「保存并测试」真推一条；要发媒体，先去查 capability matrix，再在自己的那个渠道上实测一次。
坑四：手机上没点审批，任务却没继续
现象。 以为放着不管就等于默认同意，结果任务停在那里。
原因。 裁决一次性、fail-closed，沉默永远不等于批准；未知或未绑定的来源也默认拒绝。
解决方案。 需要批准就明确点了再走，超时后的行为按 approval 配置走升级提醒。别把它当成「默认允许」来设计流程。
总结
离席场景被真正改变的只有三件事：状态从「要么盯着要么干等」变成按状态线主动推给你，审批从「必须回到电脑前」变成手机上一次点击，纠偏从「等它跑完再说」变成 ! 前缀当场打断。想对照同类插件的中文清单与安装形态，见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：经常把长任务丢下去开会或通勤的人；审批频繁、又不想守着终端的人；需要同时推进多个任务、要在手机上确认「指令发给谁」的人；已经在用 Telegram 或飞书、想顺手把控制通道也搬上去的人。
不适合：只在本机做短会话问答、从不离开工位的人；希望一套配置把所有渠道都当双向遥控用的人（入站只覆盖 6 个渠道）；以及不愿意给机器人单独准备渠道凭证的人——28 个出站渠道里绝大多数要你自己备 token 或 webhook。
标签：dsh-notifier、DeepSeek Harness、远程审批、移动办公
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。