复用会话 resume 时 persona prefix 的 {{model}}/{{cwd}} 无值（dsh web 重启后必现）

[hZsFN]

现象

dsh web 重启后，复用既有会话的任务卡执行失败，报：

UNKNOWN
prompt variable "{{model}}" has no value for this assembly (section "deployment:persona-prefix")

同一个任务卡在重启之前可以正常执行。

环境

项	值
DSH	0.1.5-rc.2（@deepseek-ai/dsh-base / dsh-persona / dsh-agent-presets 均为 0.1.5-rc.2）
平台	Windows
相关插件	@linxin666/dsh-client-ui-task-board（任务板，任务卡开启了「复用会话」reuseSession: true）
preset	自定义 agent preset，其 persona 的 prefix 里使用了 {{model}} 与 {{cwd}}

复现步骤

1. 自定义一个 agent preset，persona 的 prefix 写成类似：
   你是「X」，由 {{model}} 模型驱动。你的工作目录是 {{cwd}}。
2. 建一个任务卡，开启「复用会话」，先让它成功执行一次（此时会话已存在）
3. 重启 dsh web（该会话随之进入休眠）
4. 再次触发这个任务卡（它会复用同一个会话）

期望

复用 / 恢复会话时，persona prefix 里的 {{model}}、{{cwd}} 能正常解析；或者变量取不到时优雅降级（省略该句）而不是中止启动。

实际

抛错并中断，agent 未启动。

⚠️ 另外注意一个可观测性问题：任务板把这次执行记录为 succeeded（大概是 prompt 投递成功即算成功），错误只发生在会话运行时。也就是说定时任务静默失效，从任务卡记录上完全看不出来。

观察与分析（不一定对，仅供参考）

• dsh-agent-presets 生成的 preset 模板里带一行注释：
  # '{{model}}' and '{{cwd}}' resolve from the agent's own route and workspace.
• 据此推测：resume 路径下 agent 的 route（模型路由）建立晚于 persona prefix 的渲染，变量在渲染时还没有值。
• 佐证：同一 preset 在新建会话路径下未见此错；差异只在 resume 时 preset 的重新挂载时机。
• 时间线证据（同一任务卡、同一会话）：
  • web 进程启动：当天 15:25
  • 该任务卡最后一次成功：当天 13:00（在重启之前）
  • 下一次触发：当天 19:00（重启之后）→ 失败，且会话日志文件有改动、但 executions 里没有新增记录（说明失败发生在很早期）

影响面

任何在 persona prefix 里使用 {{model}} / {{cwd}} 的 preset，只要遇到「web 重启过」+「复用/恢复既有会话」这个组合，就会失败。对长期复用同一会话的定时任务卡而言基本是必现的 —— 而这类场景恰恰是任务板的主用途。

本地规避方式

已把两个 preset 的 prefix 里的 {{model}} / {{cwd}} 换成固定文本（不再使用这两个变量），暂时绕开。

建议

1. 变量取不到时优雅降级（例如 {{model}} 解析失败就省略该分句），而不是抛错终止整个 assembly；
2. 或在 resume 路径上确保 route 就绪后再渲染 persona；
3. 任务板侧：把「agent 启动失败」如实记为该次执行为失败，避免定时任务静默失效。

（如果 {{model}} / {{cwd}} 在 resume 场景下本来就不保证可用，那么文档里也许值得写明这一点 —— 我当初看模板注释以为两者总是可用的。）

[PerryLink]

这个抛错是设计使然（有测试钉着）——但"重启后必现"这一半是缺陷，你的分析方向是对的

1. 先把抛错的来源定下来

那句错误来自 packages/core/system-prompt/src/index.ts:356：

throw new Error(`prompt variable "{{${name}}}" has no value for this assembly (${kind} "${input.name}")`)

而且这个行为是被测试明确钉住的——packages/core/agent-loop/tests/loop.spec.ts:579 里就有一模一样的断言：

'prompt variable "{{cwd}}" has no value for this assembly (section "deployment:persona-prefix")'

也就是说："引用了变量但这次装配里没有值 ⇒ 抛错"是有意的 fail-loud 设计，不是崩溃。你要的"优雅降级"目前不在设计里（想改成降级，那是一个需要讨论的变更，不是修 bug）。

2. 变量是谁给的——这决定了为什么"重启后必现"

装配体的变量是一个字典（system-prompt/src/index.ts:122：variables: Record<string, string | undefined>），而它是通过协作式瀑布填充的（同文件 :20 注释："Expert waterfall over the assembled sections, contexts, tools, and variables"）。渲染时（:281）用这份字典去插值，没被任何贡献者填过的变量就是 undefined，于是命中 :356。

⇒ 所以你的推测——"resume 路径下 route（模型路由）建立晚于 persona prefix 的渲染"——与代码形状完全一致：{{model}} 要有人把当前路由写进这份字典，{{cwd}} 要有人把工作区写进去；只要在 resume 那次装配里这两个贡献者还没跑，插值就会抛。你没有停在猜测上，而是给出了"新建会话不报、resume 才报"的对照，这正是关键证据。

3. 所以该提的是"哪一层"的问题（建议这样写）

不要把诉求写成"修这个报错"，因为它是有意的。建议写成二选一（或两者都要）：

1. resume 路径补齐变量：让 {{model}} / {{cwd}} 在复用/恢复会话的那次装配里也有值——即让贡献者在 prefix 渲染之前就位（这是治本，符合"同一个 preset 重启前能跑就该继续能跑"的预期）；
2. 或者明确降级语义：变量取不到时按"省略该句"处理，而不是中止启动。但这要与 :356 的 fail-loud 设计一起讨论——因为那条件是刻意写死的，改它会影响所有 preset。

4. ⚠️ 你顺手发现的那个"任务板记为 succeeded"值得单独报一条

这条我认为比主问题更严重：prompt 投递成功即算成功、而真正的失败发生在会话运行时 ⇒ 定时任务静默失效，记录上完全看不出来。这是可观测性缺陷，和 {{model}} 那个问题是两回事，建议单独开一条（附上你那段时间线证据：15:25 启动、13:00 上次成功、19:00 失败且 executions 无新增记录——那段非常有说服力）。

5. 版本提醒（很重要）

你那份环境是 0.1.5-rc.2，已经落后不少。当前最新是 0.1.7-rc.2（git tag dsh-v0.1.7-rc.2，npm next 也是它）。

⚠️ 别装 latest——npm 上 latest 仍停在 0.1.5-rc.3，比你现在用的还旧。要升就用：

npm i -g @deepseek-ai/dsh@next      # 当前 = 0.1.7-rc.2

升完先复现一次：如果仍然在 resume 时抛同样的错，那说明这条路径在 rc.2 上依然没被补上，你的报告可以直接按最新的行为来提，说服力更强。