dsh-auto-restart

dsh-auto-restart

当前版本 1.2.1

已适配官方桌面端与官方网页端（dsh web），两种载体都跑通过真机重启。 第三方载体（非官方 Electron 壳、UtilityProcess 里跑 CLI、自定义启动方式）不在默认支持 范围内：插件检测出差异后不会贸然动手，由 agent 照 SETUP.md 征得你同意，再写一次启动计划。

由 agent 自己发起的重启，不是按钮。 agent 调一个工具，之后由插件接管：等这台机器上 所有 agent 与后台任务都空闲，走完可取消的倒计时，再重启 DSH，并唤醒原会话让 agent 接着说下去。

插件只负责判断「什么时候可以动手」；杀进程、跑命令、重启、唤醒，交给包里的 PowerShell 脚本。两边通过一个交接文件通信，谁也不猜对方的状态。

前置条件

• DeepSeek Harness 官方桌面端，或官方网页端（dsh web）
• Windows

重启动作由包里的 PowerShell 脚本完成。插件只在倒计时结束后调用它， 设置页里能看到它当前解析到的路径。想换成自己的实现也只要接住同样的参数。

安装

1. 把本目录放到任意位置（例如 D:\DeepSeek Harness\dsh-auto-restart）；
2. 在 DSH 里执行插件安装：plugin_manager install_bundle，target 填本目录的绝对路径；
3. 重启 DSH（Host 半边改动需要重启才生效）。

也可以直接改 profile 的 package.json 加一条 link: 依赖并写进 dsh.profile.bundles，效果一样。

用起来是这样

1. agent 调 restart_dsh 工具（唯一触发方式，没有开关、没有自动触发）；
2. 工具立刻返回，倒计时在后台走，界面浮出一张毛玻璃卡片；
3. 倒计时期间点一下鼠标、滚一下滚轮、按任意键 → 本次取消，界面给一张「已取消重启」页；
4. 倒计时走完 → 判一次空闲（这是唯一的判定点）：
   • 还有别的东西在跑 → 不重启，给一张「现在不能重启」页，列出是谁；
   • 全部闲着 → 写交接文件、拉起脚本，工具所在的这一轮可以继续说；
5. 脚本关掉 DSH、执行命令（如果有）、重新启动。关窗口走的是「请求你自己退出」， 宿主真的退不掉才强杀（默认给它 8 秒）；
6. 新进程里的插件读到交接文件，把唤醒词投进原会话，然后删掉它。

从触发到唤醒词出现，通常 15–20 秒。

调用参数

参数	必填	说明
command	否	DSH 关闭之后、重启之前执行的命令。可以留空——留空即纯重启，什么也不执行。没有默认值。
autoSay	否	重启后发给原会话的那句话，默认「已通过插件重启」。
countdownSec	否	倒计时秒数，3–600，默认 10。
timeoutSec	否	命令最多跑多少秒，10–3600，默认 600。超时就杀掉整棵进程树，照样启动 DSH。
wakeMode	否	重启后由谁唤醒原会话：plugin（默认，插件直投，不碰页面、不依赖调试端口）/ script（外部脚本用 CDP 往输入框注入，仅在插件不可用时才需要）。

命令失败（exit ≠ 0）或超时都不会阻止重启：退出码写进日志与 last-run.json，唤醒词自动补上「（命令失败：退出码 N）」或「（命令超时被中止）」。

空闲怎么判

倒计时结束的那一刻判一次，任一成立就算忙（宁可不动手）：

• agents.list() 里有 agent 的 status === 'running' —— 包括正在调用本工具的这一个。 子代理也在同一个注册表里，所以不需要另外接 subagents 服务；
• jobs 里任一 job 处于 running / stopping（逐个 owner 查，因为 jobs.list() 默认只返回 unowned 的）；
• 有消息在消息队列里排队：agent.inbox.nextTurn / nextStep 非空 （宿主是在队列被消费完之后才把状态置回 idle 的，这中间有一瞬间状态已经是 idle 但这一轮还没走完，得单独看一眼）；
• 该会话上挂着已武装的定时提醒：走宿主自己的 workspace/session-activity 瀑布取， 返回里有 kind === 'schedule' 的条目就算忙；
• 拿不到 agents 服务（没法确认，就当它在忙）。

这两项的取舍来自宿主 dsh-desktop-host 里 hasDesktopActiveTasks() 的实现， 那边是给「关闭窗口前能不能收摊」用的，口径一致。

插件自己创建的 job / 子代理不计入 —— 否则它会把自己锁死。 「这个会话上还挂着什么」这条瀑布如果抛错或超时，按「没挂东西」处理： 宁可偶尔多放行一次，也不要让重启被一个取不到数据的接口永久卡死。

占着忙就不重启，也不排队、不自动重试：提示页只负责告诉你是谁挡着。

为什么是倒计时结束才判

倒计时的作用就是给 agent 留时间把这一轮说完。所以工具不做拦截、立刻返回， 让调用它的这一轮继续输出；到点才判，此时自己也已经空闲了。

入口处既不判、也不预扫一遍忙闲——调用它的 agent 此刻必然在跑，扫出来永远有它自己。 能不能停，只由倒计时结束那一次决定。

倒计时被取消

任何输入都取消，不区分来源。 这张卡片问的是「现在还有没有人在操作这台机器」， 远程桌面、别的自动化工具、任何软件发出的键鼠输入，同样意味着有人在动。

所以判断只看有没有 pointerdown / wheel / keydown，不看事件来源。

设置页

「设置 → DSH 自动重启」里有五个默认值：唤醒方式、默认唤醒词、默认倒计时、 默认超时、日志保留份数。

没有「默认命令」，这是故意的。 命令只能由调用方当次传入。一条留在设置页里的 命令，最坏会在某次纯重启时被悄悄执行，而没人记得自己设过它。

它只是默认值：agent 每次调 restart_dsh 传的参数优先，没传才落回这里。 改动会存进 ~/.dsh/dsh-auto-restart/settings.json，DSH 重启后仍然有效； 文件损坏或字段非法时逐项回落到代码默认值。

页面下半截是只读的：脚本路径、状态目录、两个日志、交接文件，以及上一次运行的 结果（命令、退出码、是否超时）。

状态路由

路由前缀 /auto-restart/api，只服务于本插件自己的界面，不是对外 API：

路由	用途
GET /state	状态机快照（idle / counting / launching / blocked / cancelled / failed）
GET /probe	现扫一遍宿主：此刻谁在忙、各 agent 的状态
GET / POST /settings	读 / 写五个默认值
GET /last-run	上一次脚本运行的结果
POST /cancel	取消倒计时（body: { reason }）
POST /dismiss	关掉终止提示页

这个路由是加了闸的，因为一条 POST /restart 就能让整台机器的 DSH 重启一次， 而降级到一个「什么都不带」的简单 POST 处理器，等于给本机任何网页开了一个重启开关。 所以每个请求都得同时满足：

• 来源地址是本机回环，且没有 X-Forwarded-For / X-Real-IP 这类反向代理头 （带了说明前面有代理，socket.remoteAddress 到底是谁已经不可信）；
• 带 X-Auto-Restart: 1 —— 浏览器跨站发请求必带预检，自定义头过不了预检；
• 带了 Origin 时，它必须与 Host 同源。

不满足就 403，并记一行日志。只挡「网页脚本」这一类：本机 curl 或本机其它进程 只要补上那个头就能调 —— 它们本来就有能力杀进程，这里不假装能防住。

文件

文件	干什么
index.js	Host 半边：工具、空闲判定、倒计时状态机、生成启动计划、拉起脚本、状态路由
lib/launch-plan.js	启动计划：从宿主自述（argv/execPath/cwd/origin）算出「怎么再起来一次」，并校验
client.js	Client 半边：shell.overlay 上的倒计时页与终止页，settings.section 里的设置页
scripts/Restart-DSH.ps1	真正动手：先验计划 → 关 DSH → 跑命令 → 照计划启动 → 补交接状态
scripts/Start-DSH.ps1	被上一个脚本调用：照计划启动（exe/参数/cwd/端口/环境变量），等就绪
scripts/say.js	只在 wakeMode: 'script' 时用：CDP 往输入框注入
SETUP.md	给 agent 的说明书：默认覆盖不到的环境怎么一次性配好
cordis.patch.yml	bundle patch，把本包插进 profile 的 cordis 树
install.ps1	把插件装进 profile（-Profile web|desktop|both）
locale/*.json、icon.svg	插件市场与设置页里显示的标题、描述、图标

状态与日志

都在 ~/.dsh/dsh-auto-restart/ 下：

路径	内容
settings.json	设置页的五个默认值 + 两个适配兜底（launchCommand / allowAutoRestart）
launch-plan.json	启动计划，每次重启前重写；脚本只照它执行
wake-request.json	交接文件，只在一次重启流程中存在，投递完即删
last-run.json	上一次脚本运行的结果（命令、退出码、是否超时、时间）
logs/plugin.log	插件自己的日志（加载、倒计时、投递、失败原因）
logs/restart-*.log	每次重启流程一个文件，保留最近 N 份

脚本自己的日志在 Restart-DSH.ps1 同级的 logs/ 下。

交接文件怎么工作

只有一个文件，它的 phase 就是全部状态：

phase	谁写	含义
starting	插件	已经拉起脚本，但还没确认 DSH 启动成功
ready	脚本	DSH 真起来了，该投递了
failed	脚本	启动失败，不应该唤醒

插件读到 ready 就用 sessionController.prompt() 把唤醒词投进原会话 —— 走的是 正常的用户消息通道，不碰页面 DOM、不需要调试端口。投递失败退回 agent.followup()。

文件在哪都有讲究，处理完就删。 所以「文件在 = 有欠账，文件不在 = 没事做」， 状态目录不会积累。只有一种情况不删：读到 starting 说明脚本还没确认启动， 这时候删掉就再也等不到 ready 了。

两种载体

宿主不需要知道自己是哪一边。每次动手前，它把自己实际是怎么跑起来的写成 launch-plan.json（process.execPath + process.argv + cwd + webServer.getOrigin()）， 脚本照计划执行：该重放什么 exe、带什么参数、在哪个目录、绑哪个端口、给什么环境变量。

「dsh 装在哪」因此不再是一个需要回答的问题：shim（dsh.cmd / dsh.ps1）只是转发， argv[1] 已经是 …/@deepseek-ai/dsh/lib/bin.js 的绝对路径，原样重放即可。

计划不可用就不杀进程：校验（exe/入口存在、mode 认识、端口像样）发生在关进程之前， 校验不过这次重启直接作废 —— 先杀再发现起不来，是这类工具最伤人的失败形态。

真正的差别都在计划里：

	desktop	web
怎么关	按进程名（取自计划里的 exe 名）全杀	按谁占着计划里的端口找 PID，taskkill /T /F
怎么起	重放外壳 exe（删掉 ELECTRON_RUN_AS_NODE）	重放 node <bin.js> web …
就绪判据	主窗口出现	端口有响应（401 也算，说明服务在）

唤醒链路两种载体完全一样：交接文件 + sessionController.prompt() 直投。 wakeMode: 'script' 只有桌面端有。

网页端重启后，标签页会自己连回去（端口固定、cookie 持久、连接层带指数退避重连）， 不需要刷新；桌面端用随机端口，旧窗口等不到，由脚本重新开一个。

已知限制

• 官方桌面端与 dsh web 都在真机上完整跑通过；第三方 Electron 壳（UtilityProcess 里跑 CLI） 未经实测，插件判定不出「怎么原样再起来一次」时会拒绝动手，而不是猜着杀进程；
• 默认只覆盖官方桌面端与 dsh web 两种形态。其余环境由 agent 照 SETUP.md 征得你同意后 配一次 launchCommand（一条完整命令），插件不再猜安装位置；
• 容器 / systemd / Windows 服务等「杀不死」的托管形态不支持，检测不出时会由用户在 allowAutoRestart=false 上明确关掉，而不是把 DSH 停在起不来的状态；
• 真正动手那一刻需要一个「不在 DSH 进程树里」的子进程，否则 taskkill /T 会把它一起带走。 插件按 计划任务 → schtasks → WMI（Win32_Process.Create） 三级阶梯尝试，实测某些 机器上计划任务被策略拒绝（Access is denied.），此时自动落到 WMI；三级都不通会直接 报错并保持 DSH 运行，不会出现「关掉了但起不来」；
• 桌面端重启后窗口位置、大小由 DSH 自己决定，插件不介入。