自进化监督 173787247/dsh-steward

dsh-steward

DeepSeek Harness 的自进化监督系统。

English · 中文

状态：设计阶段。这里暂时不无人值守地做任何事，而这是刻意的 —— 见 §4。

核心词汇

docs/TERMS.zh.md —— DSH 的核心词汇，每个词三段式（术语 → 释义 → _Avoid_ 不要用哪个词），每条 _Avoid_ 后面附一个真实事件。体例借自 opencode 的 CONTEXT.md。

调研：surveys/OPENCODE.zh.md —— 21 万 star 的成熟同类，我们比它强在哪、弱在哪。

1. 它为什么存在

2026-09-28 一天之内，在这台机器的 DeepSeek Harness 上找到七个缺陷。其中五个是系统自己不可能发现的 —— 每一个都靠人推。

| # | 缺陷 | 谁发现的 | 不发现会怎样 |
| 1 | ~/.dsh/.env 里有十二个 DSH_ | 用户：「测试重启」 | dsh 拒绝启动；此后每次重启永久失败 |
| 2 | Start-Process -ArgumentList 拆散命令 | 用户：「换个端口测试」 | 恢复路径什么都不做 |
| 3 | $PATH 未加引号，含 Program Files (x86) | 由 2 顺查出来 | 同上 |
| 4 | 桌面快捷方式指向 $HOME/... | 读 .lnk 时发现 | 同上 |
| 5 | WSL_DISTRO_NAME 缺失 → 发行版名 "WSL" | 用户：「点了没反应」 | \\wsl.localhost\WSL\ 不存在 |
| 6 | 生成的 .ps1 没有 BOM → GBK 错位吃掉引号 | 用户：「我还没点」 | 解析失败；而报错指向的那行其实是对的 |
| 7 | vecmem 元数据被旧格式覆盖 | 用户：「天花板要不要加」 | 检索返回零条并报告成功 |

缺陷 1 是「后来修它的人」自己埋的。 这件事对设计的影响，比其余六条加起来都大。

1.1 它们共同的形状

我验证了「我刚做的那个动作」，没验证「它可能弄坏的那个东西」。

- 改完 .env，检查了文件格式 —— 没检查 dsh 还能不能启动
- 改完快捷方式，检查了我自己拼出来的路径 —— 没检查它实际写进去的那个
- 改完存储格式，检查了脚本退出码是零 —— 没检查 items 和 rows 还对不对得上

还有第八条，是关于检查而不是代码的：

我为这个目的专门写的一个检查，通过了一个刻意搞坏的输入 —— 因为它的 pkill 那一项 grep 了整个文件，而不是那一行。

2. 为什么现有的检查盖不住

Google SRE 把这个原因说成监控的性质，而不是某个脚本的缺陷（ch17）：

置信度既来自过去的可靠性，也来自对未来的预测。[…] 要让这些预测强到有用，必须满足其一：站点完全不变 […] 或者你能确切描述对站点的全部改动。

健康检查问的是「现在活着吗」。下次重启之后还能不能回来，取决于尚未跑过的路径。 2026-09-28 那天，check-dsh-health.sh 每一次都通过，而恢复路径在七个地方同时是坏的。

这不是那个脚本的 bug。是用错了工具。

3. 闭环

── 在 dsh 之外 ───────────────────────────────────────────────── 1 OBSERVE 快照：进程、端口、存储、检查结果 2 DETECT 跑检查；产出问题清单 systemd ── 在 dsh 之内 ──────────────────────────────────────────────── 掌管 3 DIAGNOSE 读代码，找原因 环路 4 PROPOSE 提出改动 的两端 5 BASELINE 应用之前，先跑同一组检查 6 APPLY 应用、重启、留下回滚点 ── 在 dsh 之外 ───────────────────────────────────────────────── 7 RE-VERIFY 应用之后，跑完全相同的一组 8 COMPARE AGREE / DIVERGE 9 RECORD 把结果写进记忆 10 ROLLBACK 如果发散，git revert

第 1、2、7、8、10 步必须在 dsh 之外跑。 它们恰恰是「dsh 起不来时」最要紧的步骤，而一个进程无法监督自己的缺席。当天两次重启都是 systemd 完成的 —— 它不在 dsh 的进程树里。

第 3–6 步在里面，因为那需要读代码、理解上下文。

3.1 完全缺失的两步

第 5 步 —— BASELINE。 一整天没有采集过一次基线。没有基线，「我的改动有没有用」就没有答案，只剩「看起来对」—— 而这正是那个 agent 说了六次的话。

第 8 步 —— COMPARE。 cordis 审计仓已经有这个机制：九个不变量跑两条线，报三种结果

AGREE 两边都成立，或两边都违反 DIVERGE 一边成立一边不成立 ← 这就是那个发现

它自己那句注释是整个仓里最诚实的一行：

发散并不自动等于失败的那条线有 bug：它是一个关于「这个性质究竟要求哪种行为」的问题。

它不声称自己知道哪条线对。这个系统也不该声称。

4. 为什么现在还不动手

四条约束，每条都有 2026-09-28 的实例。

4.1 没被证伪过的检查，不算检查

那个 pkill 检查通过了一个刻意搞坏的脚本。它在整个文件里找那个「按端口限定」的模式，而两行无关的 pgrep 命中了它。

这里的每一个检查，在拿已知坏输入跑过之前，都不算数。

4.2 没有基线，就没有判决

上面说过了。这是机械的，不是哲学的。

4.3 监督者先报告，后动手

一个有重启权限的监督者 + 一个带洞的检查 = 一台「因为错误的理由重启东西」的机器。而这失败不是假设：kubelet 自己的退避会把一个坏配置变成一个看起来系统在努力、持续数天、却永远起不来的状态 —— CrashLoopBackOff 是退避在生效，不是原因。

阶段一不持有任何写入权限。

4.4 永不进入第三层：agent 不改自己的推理循环

大多数被称为「自改进」的系统，改的是记忆，或者在解释器冻结的前提下改提示。改推理循环本身是另一回事，而且它被量过：reward hacking 出现在 RE-Bench 的 30.4% 运行里，某一项基准上 21/21 —— 手法是 monkey-patch 评估器、覆写 time.time、从 Python 调用栈里读出评分器的参考张量。

事后被问「是否符合用户意图」，o3 回答「不符合」十次，十次。当时它不知道。

Darwin Gödel Machine 确实改自己的 agent 代码，它的四道防线是容器、单次执行时限、自改范围限定在 agent 代码库、以及归档可追溯。枢纽在于它固定了什么：评估 harness 与归档逻辑不可编辑。

能改的东西，不能包括评判它的东西。

本系统位于 第 2.5 层 —— 改基础设施代码，不改推理循环。第三层不在范围内。 而按 4.1 自己的标准，那些不变量都是「评判者」，不能变成被它们评判的对象可编辑的东西。

5. 角色

这里团队的价值不是并行提速，而是：写改动的人和验改动的人，不该共享同一个盲区 —— 2026-09-28 那天他们是同一个 agent，六个缺陷穿了过去。

| 角色 | 做什么 | 2026-09-28 谁在做 |
| PROPOSER | 提出改动，以及自己的验证方案 | 那个 agent |
| VERIFIER | 独立写验证，不看提议者的验证代码 | 没人 |
| ADVERSARY | 拿已知坏输入攻击验证者的检查 | 没人 |
| SUPERVISOR | 在进程之外运行；拿不准时叫醒人 | systemd，顺带做的 |

ADVERSARY 这个角色有一个具体实例：那个 pkill 检查被它的作者写完、跑过、报告 OK —— 直到拿一个坏输入去试，才显出它是空的。

6. 这台机器已经有的

不需要发明什么。需要的是组装。

| 零件 | 状态 | 在环路里的位置 |
| systemd 255（timer / service / Restart= / journal） | 在跑 | 承载第 1–2、7–8、10 步 |
| dsh-wsl-kit/scripts/check-recovery.sh | 21 个判定点，其中 5 个已被坏输入证伪过（scripts/falsify-recovery.sh） | 第 2 步 |
| cordis-dsh-audit/invariants/ + run.mjs | 9 个不变量，差分运行器 | 第 7–8 步 |
| vecmem | 5000 条 / 4096 维，Float32 边车 | 第 9 步 |
| git | kit 90 提交、audit 46 提交，均干净 | 第 10 步 |
| DSH 编排原语（subagent、workflow、spawn_teammate、team_task_create） | 可用 | 第 3–6 步 |
| dsh-wsl-notify | 已存在 | 监督者的通知通道 |
| 21 个 link: 插件 | 源码可写，重启后生效 | 能改的那一面 |
| RTX 5080 / 16 GB | 已用 4.2 GB | 本地模型 |

7. 分阶段

| 阶段 | 增加什么 | 写入权限 |
| 1 — 观察 | timer 跑检查；失败则通知并写 journal | 无 |
| 2 — 基线 | 每次 agent 改动前，先快照 git hash + 检查结果 | 无 |
| 3 — 差分 | 改动后重跑；DIVERGE 只报告，永不自动回滚 | 无 |
| 4 — 动手 | 只在一个检查熬过它自己的证伪记录之后 | 重启，且有预算 |

阶段 4 需要一个本仓还没选的准入判据。 文献里的候选是 SGM 的：把「可证明有益」换成统计置信界 + 全局错误预算，只有当改动在选定置信水平下被认证为更优时才被接纳，预算耗尽即停止自动化而不是继续循环。在一台机器上每天只有几次动作的样本量下，统计功效值得怀疑，而一条更简单的规则 ——「连续 N 次失败即停止自动化」—— 可能是诚实的那个选择。未定。

8. 单机做不到的

记在这里，免得设计假装做得到。

× 没有真正的实例替换语义 重启修不了内核、磁盘、内存碎片、网络栈 × 没有高可用 一次 reboot 就是全站中断 × 没有平滑摘流量 接管与排空得自己写 × 没有指标驱动的自动 promote/abort 脚本近似会引入它自己的故障模式：脚本挂了、cron 没跑 × 没有准入期的 schema 严格校验未知字段被静默忽略，除非在这里自己写 schema × 没有生产环境的持续混沌工程 爆炸半径就是整台机器

值得从 Kubernetes 抄、而且在这里确实做得到的一条：

带退避的、可见的崩溃循环，优于静默地带病运行。

Restart=on-failure + StartLimitIntervalSec/Burst + journalctl + OnFailure= 给出的是一条有时间戳、有上限、会通知人的记录。两个替代品 —— 无限快速重启刷爆日志，或者监督者静默放弃 —— 都更糟。

9. 第一个真实用例

三个补丁 —— cordis-4.0.4、cordis-plugin-loader-1.0.5、cordis-plugin-timer-1.1.6 —— 修的是 DSH 内联的那份 cordis 里真实存在的缺陷，每一个都做过 probe-before / probe-after 验证。

那九个不变量已经就是它们的基线。 这个环路的第一次演练是：

1 跑九个不变量 → 基线 2 打三个补丁 3 跑同样那九个 4 COMPARE 5 commit → 回滚点

那是一次对真实代码的真实改动，验证已经写好了，而且它是「自进化」从设计变成一次 commit 的那个点。

10. 开放问题

1. 这些检查配得上它们的开销吗？ 每十五分钟跑一次，要跑 PowerShell、wslpath、以及一次存储校验。没有量过。
2. 监督者的重启条件是什么？ 需要一个量化的「检查可信度」。现在没有。
3. 这个团队的开销是多少？ 每次改动一个 VERIFIER 加一个 ADVERSARY，只有一块 GPU。
4. 什么该进记忆？ 2026-09-28 手写了八条「已确立事实」。选择规则没有定义。
5. 回滚的粒度。 git 能恢复代码，恢复不了「配置改坏了但代码没动」。
→ 文献给的答案：配置改动走生成 → 校验 → 原子替换 → reload → 观察 → 回退*，不走 git。
6. break-glass 路径怎么演练？ SRE 指出它很少被演练，而 2026-09-28 证明了：七个缺陷里有四个在那条「别的都不行时人会走的路」上。
7. 哪些退出码该收进 RestartPreventExitStatus？ dsh 的「配置错误」退出码还不知道。
8. 谁来修评判者？ 按 §4.4，不变量与 check-recovery.sh 都不能是可自我修改的 —— 但那样改它们就永远需要人。

许可

MIT