DeepSeek Harness 升级前怎么留基线？dump-config 对比与漂移定位

升级 DeepSeek Harness 后“配置没动但行为变了”，通常是默认值、字段或配置层顺序发生了漂移。 最省时间的排查不是逐项点设置页，而是升级前留一份有效配置基线，升级后做一次 diff。官方提供的 --dump-config 与 --dump-config-schema 正好对应“值”和“字段”两类漂移。

DeepSeek Harness：升级前留哪几份基线

至少留两份：有效配置树与字段 schema；条件允许再留一份默认组合包基线。 三份各有用：（来源）

有效配置会叠加 profile 的 cordis.patch.yml、home 级 patch 与命令行 --patch，并带来源注释。它才是“现在真正生效的树”。

建议把基线放在 profile 目录之外，例如 /tmp/dsh-baseline/ 或单独的运维仓库；不要放在会被重建或清空的目录里。

DeepSeek Harness：升级后怎么 diff

diff 的目标不是“找出所有不同”，而是把差异归因到某一层。 按下面做：（来源）

# 升级前
dsh --profile web --dump-config > /tmp/dsh-baseline/config-before.yml
dsh --profile web --dump-config-schema > /tmp/dsh-baseline/schema-before.json

# 升级后
dsh --profile web --dump-config > /tmp/dsh-after/config-after.yml
dsh --profile web --dump-config-schema > /tmp/dsh-after/schema-after.json

diff -u /tmp/dsh-baseline/config-before.yml /tmp/dsh-after/config-after.yml

1. 先看有效配置 diff — 关注值的变化，不要被注释和路径差异干扰。预期：能列出新增、删除、改值的行。
2. 再看 schema diff — 关注字段增删、默认值变化与 partial 标记。预期：能解释“为什么同一个字段现在行为不同”。
3. 最后回看默认基线 — 如果有效配置没变但 schema 变了，用 --dump-default-config 判断是不是模板默认值变了。预期：区分“我的 patch 改了”与“新版本默认改了”。

diff 时建议先过滤注释行，再按插件名分组看。注释里带来源文件路径，路径变化会造成大量噪声。

DeepSeek Harness：三类 diff 结果怎么读

同样是“差异”，处理方式完全不同：默认值变化要评估，用户覆盖变化要回滚，字段删除要改配置。 三类：（来源）

1. 默认值变化 — 你的 patch 没动，但最终值变了。预期：查新版本配置目录或 release notes，确认是否有意调整；必要时在 patch 里显式固定旧值。
2. 用户覆盖变化 — 某个值被另一个层覆盖。预期：按来源注释找到具体 patch，调整层顺序或删掉重复覆盖。
3. 字段增删或改名 — schema 里出现新字段、旧字段消失或标 partial。预期：按新 schema 改写配置，不要继续写已删除字段。

如果 diff 里出现大量“只是顺序变了”的行，先确认是不是升级改变了组合包顺序；顺序变化可能影响“后层覆盖前层”的结果。

DeepSeek Harness：三种基线策略

一次性升级、CI 流水线、多机部署，留基线的方式不同。 三种策略：（来源）

1. 一次性升级 — 升级前手动导两份，升级后 diff 一次。预期：适合个人机器，成本最低。
2. CI 流水线 — 每次构建都导出 schema，和上一版做 diff。预期：提前发现字段破坏性变化。
3. 多机部署 — 每台机器导出有效配置，集中比对。预期：发现“同一版本不同机器行为不一致”。

多机场景尤其需要有效配置，而不是只看 schema；因为每台机器的 home patch 可能不同。

一份可以直接用的采集脚本：

tag="$1"
dsh --profile web --dump-config > "/tmp/dsh-$tag-config.yml"
dsh --profile web --dump-config-schema > "/tmp/dsh-$tag-schema.json"
printf '%s\n' "$tag" > "/tmp/dsh-$tag-version.txt"
dsh -V >> "/tmp/dsh-$tag-version.txt"

升级前后各跑一次，再把两份 YAML 做 diff -u。schema 是 JSON，建议先用 jq -S . 排序键再比，避免键顺序造成假差异。

DeepSeek Harness：注意事项与限制

dump 是检查工具，不执行插件，也不证明启动一定成功。 四点：（来源）

• 不要传应用参数 — --port、--host 这类参数会被 dump 拒绝，因为它展示的是解析应用参数之前的树。
• 可能含敏感信息 — 默认值、路径与插件错误可能带敏感数据，分享前脱敏。
• schema 可能 partial — 回调验证、不支持的正则等无法完整投影；partial 输出只能参考。
• dump 会初始化缺失 profile — 第一次对某个 profile 跑 dump 可能创建基础文件，这是正常行为。

另外，三种 dump 互斥，不要试图一条命令同时导出 YAML 和 schema。

保存基线时建议把版本号写进文件名，例如 config-before-0-11-2.yml。否则过几天回头看 diff，很容易忘了哪份对应哪个版本，反而增加排查成本。如果团队多人维护，基线文件里再记一条导出命令，别人才能用同样的层复现。

如果 diff 结果要贴进工单，附上导出命令与版本号，比只贴一段差异更有用；否则读者无法判断这是默认值变化还是某个 patch 造成的。

DeepSeek Harness 常见问题

Q：升级后没有 diff，但用户反馈行为变了，还查什么？ 查运行时输入、模型路由与会话日志。配置基线只能排除“配置漂移”，不能排除模型、网络或插件版本变化。

Q：能不能把 diff 做成自动告警？ 可以，但先过滤注释与路径，再按字段白名单比较；否则每次升级都会产生大量噪声。

Q：schema 里字段还在，但行为变了，为什么？ 字段还在不代表默认值或底层实现没变。对比默认值注释，并查版本变更说明；必要时在 patch 里显式写值。

一句话收束： 升级前留“值”和“字段”两份基线，升级后先 diff 再归因；没有基线，所有“行为变了”都只能靠猜。