前言¶
在 DeepSeek Harness（DSH）里做智能体，常见路径是等用户在桌面输入、再调工具回应。手机上的私信、通知却是另一路事件：来得零散、平台各异，有的还没有稳定协议，只能走 UI 自动化。若把「听通知 → 判断是否该回 → 真机在屏幕上操作 → 可选语音」串成一条可插拔链路，并默认以安全为先（少发、可确认、可急停），开发者就不必为每个 App 硬写一整条脚本。
下面介绍维护者 xiaozqi 的工作流类插件 dsh-dqy（包名 dsh-dqy，目录页见 SkillHub）。README 将其定位为面向 DSH 的事件驱动值守智能体：监听通知、过滤噪音、LLM 决策、护栏校验、UI 执行、语音输出。在 DSH 内可经宿主模型通道（host-llm）决策，README 与 package 描述均强调免独立 API key 的使用方式（具体以你当前 DSH 与 Cordis 配置为准）。
这是什么¶
dsh-dqy（项目 README 亦称「青鱼」）是挂在 DSH 上的 Android 自主体插件：通过 adb 驱动真机，用 LLM 决策环闭合「通知进 → 过滤 → 判断 → 动手 → 出声」。当前版本在 package.json 中为 0.3.0，许可证 MIT，要求 Node >= 22，peer 依赖含 @deepseek-ai/cordis 4.1.0 等。
与「只做执行器」的插件不同，本项目强调上层闭环：通知路由、过滤、护栏、状态机与 YAML 平台配方复用；执行层可选用 uiautomator2、adb 或视觉模板降级链。
核心功能¶
值守闭环¶
README 描述的核心链路为：
通知 → 过滤噪音 → LLM 决策 → 护栏硬校验 → UI 自动化执行 → 语音输出。
应用层包含自治循环（think→act→observe）、RunMode 运行模式（总开关 / 试运行 / 急停）、出站硬护栏、消息状态机与幂等，以及 dm-watch-pipeline 编排通知到发送的全过程。
平台与当前状态¶
README 用表格如实标注各平台优先级（节选）：
| 平台 | 状态 | 说明 |
|---|---|---|
| 抖音私信 | 核心验证链路 | 无可用个人协议，UI 自动化；v0.1 优先打磨该条 |
| B 站 / 微博 / 小红书 | 适配器已建，待配方化 | 优先级低于抖音稳定 |
| 协议优先 | 有成熟协议通道，不强行 UI 自动化 | |
| 支付宝 | 非目标 | 不做、不接受相关 PR |
v0.2 起的安全取向¶
README 写明 v0.2 优先修「会做错事」处，而非堆功能，要点包括：
- 出站策略闸：
RunMode.decide()为唯一判定点；/halt可拦住自主循环。 - 默认不开口：
autonomy.autoActions默认空；发消息、发图等默认进黑名单；需主人/confirm approve才执行。 - 提示注入边界：人格与通知入口 fail-closed（loopback、token、体积上限、App 白名单等）。
- 设备串行 + 超时：
SerialDevice互斥；工具带timeoutMs。 - 发送真实性：中文走 ADBKeyBoard base64；发送成功需「输入框清空 + 新气泡」等校验。
- 测试：
tests/safety.mjs与原有值守测试一并运行（npm test）。
项目声明：不做隐形代聊；使用时应告知对话方当前由 AI 值守应答。
模型与工具面¶
基础设施层提供 host-llm.ts（借用 DSH 宿主模型通道）与 http-llm.ts（OpenAI 兼容兜底）。接口层注册 fish_apps、fish_app_run 等工具，经 AdapterRegistry 按 App 能力派发，避免工具层写满 App 分支 if-else。
平台 UI 路径可写成 YAML 配方（示例见 assets/recipes/douyin.yml），步骤含 open_app、tap、input、send、verify 等，占位符 {peer}、{reply} 由运行时填充。
安装与启用¶
环境与依赖¶
从仓库 package.json 可见：
- 运行时：Node.js >= 22
- 构建：
npm run build（TypeScript 编译到lib/） - 测试：
npm test（tests/smoke.mjs、tests/safety.mjs）
README 三步上手中的安装表述为：在 DSH 里安装 dsh-dqy 的包目录（或按项目说明从 git 安装）。资料中未给出固定的 dsh plugin add … 单行命令；请以你使用的 DSH / Cordis 插件安装方式与仓库 cordis.patch.yml 为准，安装前阅读源码与 MIT 许可证。
连接手机与通知¶
- 手机开启 USB 调试，通过 adb 连接。
- 若要接收通知：编译安装
android/notify-listen，在系统「通知使用权」中授权（applicationId为com.dqy.notify）。
白名单与发送开关¶
先配置允许对话的对象，再逐步打开发送能力。README 示例：
control:
allowedPeers:
- com.tencent.mobileqq:张三
在 DSH 会话中使用值守相关命令（README 原文）：
/watch # 先看她现在为什么不说，照着提示配
/watch enable # 打开发送总开关（此时仍是试运行）
/watch live # 从试运行切到真实发送
默认状态下插件只观察、写日记、不对外说话。拟执行的对外动作进入确认收件箱：/confirm list 查看，/confirm approve <id> 后才真正执行。
典型用法与架构要点¶
设计原则（README）¶
- 默认关闭自动发送；试运行只记录拟发送内容。
- 规则模糊或校验失败时优先不回复。
- 消息与发送持久化，支持断点续跑与复盘。
- 有协议则走协议，UI 自动化为兜底。
- 执行层可换，新增 App 主要增加 YAML 配方。
分层结构¶
README 给出严格向内依赖的分层：入口 src/index.ts 装配；interface/ 适配工具与命令；application/ 决策与值守；domain/ 端口与模型；infrastructure/ adb、LLM、记忆、视觉与配方加载。UI 驱动经 FallbackUiDriver：主 uiautomator2 → 备 adb → 视觉模板。
与生态内其他项目的差异（README 表格）：例如 dsh-mobile-use 偏执行器，本项目是上层闭环；OneBot 类方案覆盖有协议平台，本项目侧重无协议私信场景的配方化 UI 路径。
适用场景与注意¶
适合谁：已在用 DSH、希望把 Android 通知驱动的私信值守（当前 README 以抖音私信为核心验证）接到宿主模型上，且能接受「默认静默 + 人工确认 + 急停」安全模型的开发者。
务必注意：
- 插件随 当前 dsh 进程权限运行，可访问你配置的 adb 设备与网络；安装前通读仓库源码与
tests/safety.mjs所覆盖的闸门行为。 - 真机自动化依赖环境与 App UI 变化，哔哩哔哩、微博、小红书等仍处于适配器待配方化阶段，勿按生产全天候话术预期。
- 资金类、支付宝相关能力为非目标；QQ 走协议优先路线，与纯 UI 配方路径不同。
- 社区目录 SkillHub 为独立站点，与 DeepSeek / 幻方无官方从属关系；版本与星标以各站点实时的仓库与目录信息为准。
结尾¶
dsh-dqy 把「通知驱动的真机值守」收成 DSH 里可配置的一条工作流：LLM 借宿主通道决策，护栏与运行模式约束出站，YAML 配方描述各 App 的 UI 路径。若你正在 DSH 上扩展能听手机、又默认少动的智能体，可从仓库 README 的「三步上手」与 control.allowedPeers、/watch 系列命令开始验证。
