dsh-notifier 是 DSH 的通知与远程操作控制面：零依赖 notify() API 覆盖 28 个出站渠道、6 个入站控制渠道，MIT 许可，Node 要求 >=22，v0.12.0 基线 1831 / 1831 测试通过；npm 包 0.10.2、54★，本站 2026/9/26 完成 L4 真实安装验证。本文记录它在阿里云 ECS 上的接入过程。
目标与前提
目标：Agent 跑完一轮、请求审批或报错时，群消息立刻到达，且真实可达。
前提：2 vCPU / 4 GiB 起步的 ECS 实例（Ubuntu 22.04 或 Alibaba Cloud Linux 3），已分配公网 IP 或绑定 EIP，否则访问不了 npm registry；一个企业微信群机器人，或钉钉机器人的 Webhook 与加签 Secret。
ECS 侧准备：安全组与出网
入方向只放行 SSH 22（源限定办公出口 IP，不要 0.0.0.0/0）与 DSH Web 端口（默认 8787）。插件的高级管理台只监听 127.0.0.1，不要为它开入方向端口，要看时用 SSH 本地端口转发。
出方向要放通 443：两类 Webhook 都走 HTTPS，而阿里云安全组出方向默认「允许全部」，改过策略的请确认没被拦。
登录后先验出网，返回 HTTP/2 200 再继续：
装 Node 22 与 dsh 引擎
engines 要求 >=22，基线 Node 22.19 满足：
接入企业微信与钉钉
安装后重启一次 DSH，从侧栏进入「通知与控制」（或 Plugins → dsh-notifier → 开始设置），新增渠道：企业微信群机器人 type 为 wecom，凭证是 Webhook key；钉钉自定义机器人 type 为 dingtalk，凭证是 Webhook 加加签 secret；企业微信若走应用消息则用 wecom-app。
headless 无 Native UI 时走 YAML bootstrap，secret 用 ${ENV:NAME} 占位：
验证一条真实通知
插件口径是「必须真实收到测试通知，首访才算完成」：点「保存并测试」确认到达，再让 Agent 跑个长任务，看 turn/end 是否自动推送；失败先查 443 出网与 Webhook。
四个高频坑与处置
坑一：装完侧栏找不到「通知与控制」，渠道也列不出来
现象。 安装命令返回成功，刷新后侧栏仍无新入口，渠道列表也是空的。
原因。 Host 插件与 Client Module 需要一次完整装载，才会注册入口与渠道投影。
解决方案。 安装完重启一次 DSH 再从侧栏进入，反复刷新替代不了这次重启。
坑二：改了入站渠道看到「等待重启」，以为已经生效
现象。 出站改完立刻生效，顺手改了入站渠道，结果手机发消息一直没反应。
原因。 v0.12 里出站是 Hot Apply，入站 transport 仍需重启。
解决方案。 出站保存后下次发送即用新配置；入站改动必须重启 DSH。
坑三：陌生账号给机器人发消息，居然触发了操作
现象。 名单外的手机号或账号发来消息被当成合法输入，甚至影响会话状态。
原因。 身份按 (channel,userId) 复合绑定，未知来源默认拒绝；跳过首次白名单配置，边界就会模糊。
解决方案。 首次配置就在 inbound 里设好 allowUsers，新用户走 /pair 配对，定期用 /whoami 核对。
坑四：在更低版本的 DSH 上安装，行为异常
现象。 步骤全对，但渠道数量对不上、Native 面板出不来，或激活后 RPC 报错。
原因。 声明兼容范围是 0.1.7-alpha.1 || 0.1.7-alpha.2 || 0.1.7-rc.1 || 0.1.7-rc.2，范围外没有验证证据。
解决方案。 先 dsh --version 核对版本，跨大版本前看 docs/compatibility-matrix.md。
总结
ECS 上的链路不长，成本主要在云侧准备与几处「看着生效其实没生效」的细节。想对照同类插件的完整清单与安装形态，见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：把 DSH 长任务状态推到手机或企业 IM 的开发者；用 ECS 长期跑 Agent、希望出问题第一时间被叫醒的人；想复用现有企业微信或钉钉群机器人的团队。
不适合：只在本机用、从不离开电脑的人；指望它解决网络策略或系统级监控告警的；不愿自备 Webhook 与加签凭证的。
标签：dsh-notifier、DeepSeek Harness、阿里云 ECS、企业微信机器人
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。
