DeepSeek Harness 升级后报 unknown prompt variable {{cwd}} 怎么修

「unknown prompt variable "{{cwd}}" in section "deployment:persona-suffix"; registered variables: provider, model」——报错自己就把答案给了一半：当前只注册了两个变量，而 cwd 不在里面。 它不是拼错，是被上游删了；删它的版本是 0.2.1-alpha.2，而残留那一行在配置文件里，升级不会帮你清（#11152）。

DeepSeek Harness 发生前：旧版本把 cwd 当内置变量

在 alpha.2 之前，cwd 是注册过的提示变量，默认的 persona 后缀里就写着它。

1. 旧版本的系统提示里有一段 persona 后缀，形如「Your working directory is {{cwd}}。」
2. 这个后缀会被写进 profile 的配置补丁。
3. 只要版本还注册着 cwd，插值就正常，你看不到任何异常。
4. 这一层是「历史配置」，跟着你的 profile 走，不跟着发布包走。
5. 记住这一点：后面所有麻烦都来自「配置比代码活得久」。

DSH插件 发生时：alpha.2 删掉了注册与默认后缀

提交 79bd3d8da7（首个 dsh-v0.2.1-alpha.2 标签）删除了 cwd 的注册和默认 persona 后缀，把职责交给运行时上下文。

1. 删除后，提示变量只剩 provider 与 model 两个。
2. 工作目录改由运行时上下文 working-directory:current 提供。
3. 这是设计变更，不是缺陷——所以不会「等下一个版本修回来」。
4. 插值发生在请求组装阶段；未注册的名字在那里是硬错误。
5. 因此没有「原样输出」的降级路径，整轮直接失败。

DeepSeek Harness 发生后：残留那一行让每轮都失败

升级不重写你的配置，配置编辑器又整对象回写，于是旧值被冻结在 profile 里。

1. 残留的 {{cwd}} 位于三个可能的位置之一：profile 的 cordis.patch.yml、home 层的 patch、或某个 preset 行。
2. 升级只替换发布包内容，不会去改写这些文件。
3. 配置编辑器回写的是整个 config 对象，而不是刚编辑的字段。
4. 结果就是：旧版本物化进去的值被永久保留。
5. 每次请求组装都会撞上同一个未注册名字，表现为「每轮都失败」。

DeepSeek插件 时间线一句话总结

旧配置引用了一个后来被删的变量名，而删除发生在代码层、残留发生在配置层，两者永远对不上。

DeepSeek Harness 两条修法：删一行，或装 shim

持久修法是删掉那行；只想先跑起来，就装兼容插件。

1. 先定位文本：在 profile 的 cordis.patch.yml 与 preset 配置里搜 {{cwd}}。
2. 找到后把那一行（或整段 persona 后缀）删掉，或在需要工作目录时改用运行时上下文。
3. 改完重启，确认不再出现 unknown prompt variable。
4. 如果暂时不能改配置，安装社区 shim：

dsh plugin --profile <your-profile> add \
  "github:argszero/dsh-legacy-prompt-vars#808e73c2dd49208f373bbe6b077ba5d78fcbe6c8"

5. 安装后 --dump-config 里应出现 legacy-prompt-vars 挂载项，说明 dsh 自己插入了条目。
6. 社区在干净 profile + 0.2.1-rc.3 运行时上实测：命令退出码 0，条目存在。

DSH插件 shim 的边界

它只重新注册已退役的变量名，不修复持有旧文本的那一层。

1. 它让带 {{cwd}} 的 persona 后缀能重新组装，回合不再失败。
2. 但它不知道你配置里还有哪些旧变量，遇到没见过的名字仍会同样失败。
3. 它不在 npm 上，只能用 git 规格安装，版本要写提交号。
4. 它属于缓解，不是修复——真正该删的那一行还在你的配置里。
5. 因此建议：先用它止血，再安排时间删配置。

一分钟定位残留位置

报错里的 section 名 + 一次全量搜索，就能把范围缩到具体文件。

1. 记下报错里的 section，例如 deployment:persona-suffix。
2. 在 profile 目录里搜索 {{cwd}}，先看 cordis.patch.yml。
3. 再看 home 层 patch 与 preset 配置，三处都搜一遍。
4. 找到后对照 section 名，确认就是这一处而不是同名副本。
5. 改动前先备份文件，方便回滚。

注意事项

1. 别去改发布包。变量注册在核心代码里，改包会随下次升级丢失。
2. 别只在一个文件里搜。profile patch、home patch、preset 三处都可能残留。
3. 别把 shim 当长期方案。它维护的是已退役名字的兼容层。
4. 记录报错里的 section 名。deployment:persona-suffix 直接指向残留位置。
5. 升级前备份配置。这类问题的最佳排查材料就是升级前后的配置差异。

如果你的报错里变量名不是 cwd，逻辑相同：先看当前注册了哪些变量，再去找配置里那个旧名字。相关排查见 DeepSeek Harness 启动不了、dsh 启动报错怎么办？分层定位、Node 环境与 3080 端口排查。