dsh-smart-restart：DeepSeek Harness 的验证型重启方案

前言¶

重启一个正在运行的进程本质上是破坏性的。现有的做法通常要么需要 root 权限（调用 systemctl restart），要么仅发送一条“服务已重启”的通知。这种方式留下了两个关键问题：服务重启后是否真的健康，以及请求者之前正在进行的工作如何恢复。

dsh-smart-restart 插件旨在填补这两个空白。它允许在无需特权的情况下重启 Harness，并在重启后进行健康检查，将检查结果和恢复指令反馈给发起请求的会话。

核心功能¶

1. 无特权重启
   默认模式下，插件仅终止进程，让 systemd 根据 Restart=always 配置将其拉起，不需要 sudo 或 polkit 权限。systemctl restart 作为备选模式供已有权限的环境使用。
2. 启动后健康检查
   每次重启后，插件会检查服务状态、注册工具数量、单元的 ActiveState/MainPID/NRestarts，以及监听端口是否由单元内的进程拥有（基于 cgroup 检查）。最终输出 ok 或 degraded 判决及失败详情。
3. 会话报告
   在重启前记录意图（原因、恢复目标）。重启后，该意图和健康检查结果会传回发起请求的会话，使工作得以基于事实继续，而非猜测。
4. 循环保护
   如果 10 分钟内重启次数超过 3 次，插件会拒绝新的重启并报错，防止重启失败被无限循环掩盖。
5. 设置卡片
   在 DSH 插件列表中提供图形化的设置界面，支持中英文配置。

安装与启用¶

通过 DSH 包管理器安装该插件：

dsh plugin --profile <profile> add @goodandready/dsh-smart-restart

安装后，插件会自动注册其工具和启动检查机制。

典型用法¶

插件提供了两个核心工具和两种重启模式。

1. 执行重启 (dsh_restart)¶

调用该工具需要提供参数：

• reason: 重启原因
• resume: 恢复时执行的指令或上下文
• confirm: 是否确认执行
• delayMs: 延迟毫秒数

示例：

await dsh_restart({
  reason: "manual_check",
  resume: "continue_last_task",
  confirm: true,
  delayMs: 3000
});

2. 查看状态 (dsh_restart_status)¶

查看最近一次启动信息、停机时间、健康报告、待处理的意图以及窗口内的重启次数。

3. 重启模式 (restartMode)¶

• kill（默认）：仅终止进程，依赖 systemd 自动拉起。无特权，但会丢失当前未完成的 turn。
• systemctl：直接调用 systemctl restart <unit>。需要相应的权限，但能保留更多进程状态（尽管文档指出 kill 模式下 in-flight turn 仍会丢失）。

适用场景与注意¶

• 系统依赖：默认模式要求 Harness 由 systemd 管理（例如 dsh-web.service），且该单元必须配置了 Restart=always。插件会从进程的 cgroup 中自动检测单元名称。
• Linux 限制：端口和 cgroup 检查仅支持 Linux 系统，在其他系统上这些检查会自动跳过。
• 用户单元：如果使用 systemd 用户单元，插件会自动应用 --user 标志。
• 状态丢失：在 kill 模式下，当前未完成的 turn 会丢失，这是设计使然。恢复工作依赖于重启后记录的 resume 指令。

结语¶

dsh-smart-restart 解决了 DSH 环境中重启操作“既不安全也不透明”的痛点。通过验证型重启和会话回传机制，它为智能体系统的运维提供了更可靠的保障。

• 插件目录页
• GitHub 仓库