dsh-guardian

DeepSeek Harness 守护者 —— 始终活着的无模型底层,当 DSH 陷入不可逆状态时自动接管、诊断、回滚、重启、静默。

这是"agent 自己修复自己"的自举困境的答案:能改自己,就可能改坏自己;而改坏后 agent 跑不了,就需要一个不依赖 DSH、不依赖模型的底层来救场。

---

目录

• 设计哲学
• 工作原理
• 安装
• 配置
• 自动快照
• 模型如何第一时间发现问题
• 命令
• 与插件体系的关系
• 边界与局限
• 许可证

---

设计哲学

agent(模型)改坏文件 → DSH 起不来 → 模型自己也跑不了
        ↓
能救场的东西,必须不依赖模型和 DSH → 纯 shell 守护者

• 无模型:纯 bash + 系统命令(systemctl / curl / md5sum / python3),每一步确定、可预测;
• 进程外:独立 systemd 服务(Restart=always),DSH 死它不死;
• 静默:正常时只做只读健康检查,零干预;
• 通知:修复后把自愈事件写进 AGENTS.md 与事件文件,让恢复后的模型第一时间知情。

---

工作原理

systemd(始终活着)
  └─ dsh-guardian.service(独立于 DSH)
       ├─ 正常:只读健康检查(HTTP + systemd 状态),零干预 = 静默
       ├─ 异常(连续失败阈值):接管
       │    ├─ 诊断:journalctl + dump-config 验证组合
       │    ├─ 修复:回溯最近"可用"快照 → 重启 → 验证
       │    └─ 修复成功:通知模型 → 恢复静默
       └─ 快照:变更检测 + 定期基准 + 修复后基准

健康判据:

健康 = HTTP 探活返回 200(主判据,与启动方式无关)
     + (仅当配置了 systemd 服务且存在) 服务 active

所以 Termux / docker / 前台进程 / 任意服务名都能监控。

---

安装

# 本地
bash install.sh

# 远程(从仓库)
bash <(curl -s https://gitee.com/okmyapp/dsh-guardian/raw/master/install.sh)

安装自动完成:脚本 → systemd 单元 → enable --now(开机自启)→ 基准快照。幂等,可重复执行。

卸载:

bash uninstall.sh

---

配置

环境变量(在 systemd 单元 Environment= 里设置,或用你自己的启动方式注入):

变量	默认	说明
DSH_GUARDIAN_SERVICE	dsh-web.service	systemd 服务名;留空 = 无 systemd 场景(只靠 HTTP 监控)
DSH_GUARDIAN_URL	http://127.0.0.1:3080/	HTTP 健康探活地址
DSH_GUARDIAN_INTERVAL	30	健康检查间隔(秒)
DSH_GUARDIAN_THRESHOLD	3	连续失败接管阈值
DSH_GUARDIAN_SNAPSHOT_EVERY	600	定期良好快照间隔(秒)

---

自动快照

保护对象(组合/配置层,agent 最可能改坏自己的 3 个文件):

• ~/.dsh/profiles/web/cordis.patch.yml(用户组合层)
• ~/.dsh/profiles/web/package.json(bundle 注册表)
• ~/.dsh/settings.yaml(全局设置)

三层快照时机:

层	触发	作用
变更检测	组合文件 md5 变化(每检查间隔)	改配置自动留"后悔药"
定期基准	健康时每 SNAPSHOT_EVERY 秒	始终有近期良好快照
修复后	接管修复成功	良好状态存为新基准

回滚时逐份回溯,跳过结构不可用(YAML/JSON 解析失败)的快照,即使最近快照也被写坏,也能找到更早的可用那份。

快照位置:~/.dsh/guardian/snapshots/<时间戳>/,默认保留 10 份。

---

模型如何第一时间发现问题

守护者修复成功后:

1. 写结构化事件文件 ~/.dsh/guardian/last-heal.json(时间、原因、回滚快照、诊断日志位置);
2. 在 ~/.dsh/AGENTS.md 更新「最近自愈事件」区块(自动注入到模型每个会话/恢复的第一步)。

效果:DSH 恢复后,模型第一眼就看到"发生过一次自愈",再读事件文件排查根因——无需任何推送机制。

---

命令

/root/.dsh/guardian/guardian.sh snapshot   # 手动拍快照(改组合后调用)
/root/.dsh/guardian/guardian.sh status     # 查看状态
/root/.dsh/guardian/guardian.sh check      # 手动健康检查
tail -f /root/.dsh/guardian/guardian.log   # 守护者日志(含诊断现场)

---

与插件体系的关系

守护者(体外,无模型):   监控 → 回滚文件 → 重启 DSH     ← 急救员
auto-goal-resume(体内): DSH 活了 → 恢复任务 → 续跑     ← 康复师

• 守护者不是插件:它是进程外的 shell 脚本,DSH 死它不死;
• 两者配合:守护者保证"能启动",插件保证"启动后任务不丢";
• 配套插件:dsh-auto-goal-resume(重启后自动续跑活跃目标)。

---

边界与局限

• 修复范围:快照回滚只覆盖组合/配置层 3 个文件;核心代码/依赖层问题只能重启 + 保留现场等待外部介入;
• 重启手段:有 systemd 服务才 systemctl restart;无 systemd 时回滚文件后提示由外部 supervisor 负责;
• 不防硬件死机:机器断电/内核崩溃属于 systemd 与硬件层面;
• 无模型判断:守护者不做"为什么坏"的分析,那是恢复后模型的职责。

---

许可证

MIT