resume 后部分会话丢失全部 preset 工具且无报错

[Xu3Zhen1]

resume 后部分会话丢失全部 preset 工具且无报错

部分会话 resume 后只剩宿主层插件工具（32 个），preset 工具（26 个）及其提示段全部消失。

复现、预期与验收

• 复现步骤：

  1. 在装有 roster（agent-presets）的部署里正常使用一个会话若干轮（此时每次装配 58 个工具）。
  2. 让该会话 idle，之后再次唤醒它（resume）。
  3. 读该次 request/header 事件的 tools 数组与 system 长度。

• 实际结果：工具 58 → 32，丢失的恰好是 preset 注册的那 26 个；system 9893 → 4673 字符。丢失的 26 个逐名如下（跨工作区、跨三天完全一致）：

  ask_user_question, create_goal, edit, exit_plan_mode, get_goal, glob, grep,
  interrupt_agent, job_kill, job_list, job_output, list_agents, pwsh, ralph,
  read, read_image, send_message, skill, subagent, subagent_fork, todo_write,
  update_goal, web_fetch, web_search, workflow, write
  

  即整个 preset 工具面：tool-fs(read/write/edit) · tool-fs-search(glob/grep) · tool-pwsh · tool-jobs · tool-skill · tool-goal · tool-subagent(-control/list/fork/codex/claude-code) · tool-workflow · tool-ralph · tool-ask-user · tool-todo · tool-web。

  保留的 32 个全是宿主层插件工具（memory_* · board_* · s2s_* · session_* · calendar_* · rename_session）——丢失集里没有一个插件工具，保留集里没有一个 preset 工具，分界是完美二分。

  system 丢掉的 15 段全部是工具使用说明（read / write / edit / glob / grep / job / web_search / web_fetch / goal / workflow / ralph / subagent / subagent_fork 各自的指引），与那 26 个工具逐项对应；而身份段（persona）逐字仍在 ⇒ preset 身份没丢，丢的是它的工具与提示贡献。

• 预期结果：resume 后仍为 58。同一 preset、同一份组成文件，且文件从未改动（三个 preset 的 agent.cordis.yml mtime 全部是 2026-09-03，早于全部事件）。

• 环境：Windows 10.0.26200 · DSH master 76fda72979 · web profile · agentPreset: standard · provider dsh-api · 模型 deepseek-v4.1-flash

• 验收条件：resume 装配后工具集与 initial 装配一致；若确实无法保持一致，则该状态必须可归因（见下）。

全机普查（98 会话 / 274 次装配，脚本附后）：

7 次「平面转移」事件 —— 7/7 的 reason 全是 resume（无 initial/change/series）
丢失集合跨两工作区、跨三天【逐名完全相同】，不同集合种数 = 1
93 会话 preset -> preset（正常）；5 会话末次停在该状态

方向可逆 ⇒ 是竞态，不是持久损坏。session-162425ee 同一会话先丢后自愈：

2026-09-20T09:45:06  initial  26 tools  read=true
2026-09-27T09:41:20  resume   31 tools  read=false   ← 丢
2026-09-27T20:59:55  resume   32 tools  read=false   ← 仍丢
2026-09-28T04:13:10  resume   58 tools  read=true    ← 自行恢复

为何静默（这是我认为最该先修的一点）：packages/preset/agent-presets/src/invariant.ts:46-68 已经检查了「agent 未加入任何 preset」并在 system-prompt/assemble 处 fail()，其注释写明后果：

"An agent that joined no preset resolves tools, system-prompt, and skill against the empty global layer, so the model receives nothing — no error, no empty catalog, just an agent that cannot act."

但 .agents/notes/implemented/architecture/2026-08-10-host-plane-ownership-after-presets.md:45 明确：该 invariant 只在加载了 dsh-invariants 的组合里生效，发货态不加载；AgentPresets 侧的告警是 advisory。⇒ 发货部署里这个状态没有任何输出，用户只能看到模型回 unknown tool。

可疑点（未确证）：packages/preset/agent-presets/src/mount.ts:243-251 的 standingMountFor() 通过 scopeParentOf(agentKey) 在当前存活的 livePresetMounts() 里按 key 相等查找，对不上即返回 undefined。我试过并已排除「组成文件 stamp 变化导致换代」（index.ts:757/:766）——文件 mtime 未变，无从换代。所以触发条件仍未定位，上述只是把范围缩到该函数及其调用链。

建议：

1. 让 standingMountFor 返回 undefined 而 context.agent 存在时打一行可归因日志（含 agentKey 与期望的 standingKey）。当前该状态在发货态完全静默，这正是它能长期存在的原因。
2. 确认 AgentPresets 那条 advisory 告警是否覆盖「曾加入、后来对不上」的情形（不只是「发布时未加入」）。
3. 检查 resume 路径上 agent scope parent 的重建时序——本机 7/7 次转移都发生在 resume。

证据脚本（纯只读，扫会话日志按「装配带的是哪一层工具」分类每次装配）：

• probe-preset-tools-census.mjs —— 复现上表全部数字
• 样本会话：session-04743b35（丢）· session-87cf7656（丢）· session-162425ee（丢后自愈）

---

附：普查脚本（probe-preset-tools-census.mjs）

/**
 * 全机普查：按「装配带的是哪一层工具」分类每次 request/header，列出平面转移事件。
 * 判据用【集合成员】而非数量——数量已证明不可靠（58/57/32/31/26 都出现过，且同数量可不同集合）。
 */
import { readSessionLog, resolveLogPath } from 'F:/DSH/TTA/session-lifecycle/frames.mjs'
import { readdirSync, statSync } from 'node:fs'
import { join } from 'node:path'
import { homedir } from 'node:os'

const PRESET_PROBES = ['read', 'write', 'edit', 'glob', 'grep', 'pwsh', 'subagent', 'web_search']
const HOST_PROBES = ['memory_note', 'board_post', 's2s_message']

function planeOf(names) {
  const preset = PRESET_PROBES.filter(p => names.has(p)).length
  const host = HOST_PROBES.filter(p => names.has(p)).length
  if (preset === 0 && host > 0) return 'host-only'
  if (preset >= PRESET_PROBES.length / 2) return 'preset'
  return `partial(${preset}/${PRESET_PROBES.length})`
}

const parent = join(homedir(), '.dsh', 'sessions')
for (const ws of readdirSync(parent)) {
  const wsDir = join(parent, ws)
  if (!statSync(wsDir).isDirectory()) continue
  for (const name of readdirSync(wsDir)) {
    const dir = join(wsDir, name)
    if (!statSync(dir).isDirectory()) continue
    let file = null
    try { file = resolveLogPath(dir) } catch { continue }
    if (!file) continue
    const { records } = readSessionLog(file)
    const hdrs = records.filter(r => r.type === 'request/header')
      .sort((a, b) => Number(a.time) - Number(b.time))
    const seq = hdrs.map(h => {
      const names = new Set((h.data?.header?.tools || []).map(t => t.name || t[0]))
      return { at: Number(h.time), reason: String(h.data?.reason ?? ''), n: names.size, plane: planeOf(names), names }
    })
    for (let i = 1; i < seq.length; i++) {
      if (seq[i].plane === seq[i - 1].plane) continue
      const before = seq[i - 1].names, after = seq[i].names
      console.log(new Date(seq[i].at).toISOString(), ws, name.slice(0, 16),
        seq[i].reason, `${seq[i - 1].plane}/${seq[i - 1].n} -> ${seq[i].plane}/${seq[i].n}`,
        'lost:', [...before].filter(x => !after.has(x)).sort().join(','))
    }
  }
}

[Xu3Zhen1]

补充证据（Discussion #8204）：触发条件的源码级候选已定位

追加到已发布的 Discussion #8204。
原帖报告了现象与数据；本条补上源码级候选机制，以及明确排除掉的三个假设。
全部结论来自本机产物与检出 master 76fda72979 的源码，未做受控复现。

---

1. 边界已精确到「注册层」，不是按功能分

对同一次 58 → 32 事件逐段差分 system（session-04743b35）：

缺失段总数: 15   段总字数: 5190   反向新增: 0        ← 纯减法

15 段全部是工具插件的 prompt 贡献，且它们与丢失的 26 个工具同源。证据：packages/fs/tool-fs/src/read.ts:68-73 里，同一个 ctx 上手写了两件事——

export function applyReadTool(ctx: Context, caps: ReadToolCaps): void {
  ctx.systemPrompt.section({ name: 'tool:read', order: ..., text: 'Use the read tool — not shell commands like cat …' })
  ctx.tools.register(defineTool({ name: 'read', ... }))
}

同进同出。所以丢失的单位是「preset 层挂载的那些插件在 ctx 上的全部注册」，不是「某些工具被过滤」。

同一张 system-prompt 表里，宿主层段活着、preset 层段死了（实测）：

注册层	段	58 时	32 时
宿主/插件层	记忆系统段 · 记忆写入纪律 · 白板段	在	在
preset 层	tool:read 段 · tool:pwsh 段	在	—

⇒ 不是 system-prompt 坏了，是 preset 那一层的注册整体不在场。

---

2. 候选机制：挂载被剪枝，而 agent 的 scope parent 还指着它

packages/preset/agent-presets/src/mount.ts：

const mounts = new Set<PresetMount>()                       // :138

function pruneDisposedMounts(): void {                      // :156
  for (const mount of mounts) {
    if (mount.fiber.uid === null) mounts.delete(mount)      // :158  已销毁 ⇒ 删除
  }
}

export function livePresetMounts(within?: Fiber): PresetMount[] {
  pruneDisposedMounts()                                     // :174  读取路径上剪枝
  const all = [...mounts]
  return within === undefined ? all : all.filter(mount => withinFiber(mount.fiber, within))
}

export function standingMountFor(agentCtx: Context): JoinedPresetMount | undefined {
  const agentKey = scopeOf(agentCtx)
  if (agentKey === undefined) return undefined
  const standingKey = scopeParentOf(agentKey)               // :246  agent 指向的那一代
  if (standingKey === undefined) return undefined
  return livePresetMounts().find(                        // :248  只在【已剪枝】的集合里找
    (candidate): candidate is JoinedPresetMount => candidate.key === standingKey,
  )
}

因果链：

1. 某个 preset 的 standing mount 被销毁（fiber.uid 变 null）；
2. 下一次任何装配在 livePresetMounts() 里把它剪掉；
3. agent 的 scope parent 仍指向那一代的 key（绑定没有随销毁回滚）；
4. standingMountFor() 在已剪枝集合里找不到 ⇒ 返回 undefined；
5. 该 agent 的 tools/system-prompt/skill 解析到空全局层 ⇒ 26 工具 + 15 段一起消失；
6. 无报错。

为什么值得盯这一处：pruneDisposedMounts 的注释自己写明了这条路径的脆弱性（:143-151）：

"Records are pruned by observation rather than through a disposal hook… Reading is one such path, but not a reliable one: the only production reader is the invariant companion's service listener, and dsh-invariants is a development composition — a shipped host never loads it."

即：剪枝只在读路径上发生，而生产环境唯一的读路径承担者（invariant 伴生）在发货态根本不加载。 这与「缺陷只在发货态静默」是同一个成因。

与观测的吻合：该机制天然解释可逆性——重新挂载后 parent 又能对上（实测 session-162425ee 26→31→32→58，session-87cf7656 58→32→58）。

---

3. 已排除的假设（都试过，都被数据推翻）

诚实列出，免得重复走：

#	假设	证伪判据
1	s2s 唤醒导致（7/7 缺陷态均有 s2s 参与，一度很像）	反例：session-35bb18f0（09-28T03:13:52）与 session-8e93903e（09-27T21:02:33）都是 s2s 唤醒且 tools=58。同一会话 8e93903e 两次 s2s 唤醒结果相反（21:02→58，次日 05:05→32）⇒ s2s 是共现，非充分条件。
2	紧跟一次会话重启（session/end-seed）导致	交叉表：52 次紧跟重启却正常；2 次缺陷态没有重启。两个方向都不成立。
3	进程冷启动（机器级时间线出现空档）导致	缺陷组 5 个里只有 2 个在空档之后；正常组有 17 个在空档后 ⇒ 既不必要也不充分。
4	组成文件 stamp 变化触发换代（读 ensureStanding 时的第一直觉）	三个 preset 的 agent.cordis.yml mtime 全部是 2026-09-03，早于全部事件（09-27/28/29）⇒ 文件从未改动，无从换代。
5	换代本身会让已加入的 agent 失去工具	tests/mount.spec.ts:689-702 明确断言相反："The joined session keeps the generation it runs on"，且旧代不回收（index.ts:758 的 TODO）⇒ 换代不是原因。

结论：现象与边界已确证；触发「挂载为何被销毁」的上游条件仍未确证，§2 只是把机制缩到一个具体函数与其注释自陈的脆弱点。

---

4. 建议的下一步（可验证）

1. 给该状态补可归因输出（最重要）：standingMountFor() 返回 undefined 而 context.agent 存在时打一行日志，含 agentKey 与它期望的 standingKey。当前发货态下这个状态完全静默，这正是它能长期存在的原因。
2. 确认绑定与销毁的时序：bindings.set(agentKey, bindScopeParent(agentKey, standing.key))（index.ts:425）之后，若该 standing scope 被销毁，是否有任何路径重新绑定或失效该 agent 的期望？从源码看没有。
3. 剪枝时机：pruneDisposedMounts 目前只在读路径与挂载路径上调用（:174/:395）。若「剪枝前先核对是否有 agent 仍指向该代」代价可接受，可把「有 orphan 引用」变成可观测状态而不是静默删除。

---

5. 复现脚本（纯只读）

脚本	作用
probe-preset-tools-census.mjs	按「装配带的是哪一层工具」分类每次装配，列出平面转移（原帖数据）
probe-wake-source-vs-tools.mjs	假设 1 的交叉表与反例
probe-restart-vs-tools.mjs	假设 2 的交叉表与反例（52 vs 2）
probe-warm-mount-differential.mjs	假设 3 的差分与反例（17 vs 2）

样本会话：session-04743b35（丢）· session-87cf7656（丢后自愈）· session-162425ee（丢—丢—自愈）。

[Xu3Zhen1]

补充证据（二）· Discussion #8204：因果链已闭合，并附可运行的受控复现

承接 upstream-8204-addendum.md（该文定位了候选机制，并注明「未做受控复现」）。
本文把那一步做完：因果链逐环确证 + 阳性受控复现 + 新增两条排除，并更正前文一处推断。
全部基于检出 master 76fda72979，用真实 boot() 装载真实插件在隔离测试装置中复现，未改动产品代码。

---

1. 结论速览

根因不是「preset 被过滤」，而是「preset 那层注册的挂载记录被剪掉后，没有任何东西把 agent 重新接回去」，
且 ensureStanding 的缓存让这个状态可以无限期持续。

五环因果链（每环都有源码位置）：

#	环节	位置	后果
1	某个预设的 standing scope 被销毁	mount.ts:771（createScope(selfCtx, key)，standing scope 是 roster 行的子 fiber）	该代注册随之解绑
2	agent 的 parent key 不随销毁回滚	dsh-scope/src/index.ts:39,72-82,89：scopeParents 是 WeakMap，无销毁钩子；bindScopeParent 写一次即锁	agent 仍指向已死那一代
3	读取路径先剪枝再查找	mount.ts:156-160（按 fiber.uid === null 删记录）、:174（livePresetMounts 先剪枝）、:243-250（只在已剪枝集合里 find）	standingMountFor() 返回 undefined
4	undefined 是合法值，所以静默	mount.ts:236-240 文档注释：它同时表示「该 agent 未加入任何 preset」	无报错、无日志、无事件
5	缓存只按文件 stamp 判陈旧	index.ts:747-757：this.standing 按 presetId 缓存 Promise，sameStamp(mounted.stamp, current) 只比组合文件 mtime+size，从不校验该代是否存活	之后每次 mount() 都把死代发给新 agent，且成功返回

第 5 环是使缺陷「无限期 + 间歇 + 可逆」的那一环，也是前文完全没提到的。
恢复必须丢弃该缓存指针（进程重启，或编辑组合文件改变 stamp）——这正好解释为何它时有时无、重启即好。

---

2. 为什么 resume 是放大器

packages/api/session-controller/src/agent.ts:374-388 的 composeAgent() 在每次 resume 都调用
presets.mount(agentCtx, resolvedId)（resumeObserved :422-432、createOrAdopt :459-464 皆然）。

于是：一代死后，此后每一个 resume 出来的会话都被绑到一个谁也不服务的 key 上，而 mount() 不报错。
这与全机普查的口径完全吻合：7/7 次丢失都发生在 reason=resume（probe-preset-tools-census.mjs）。

---

3. 阳性受控复现（本次新增，可直接运行）

单测文件（放在检出里即可跑，不改产品代码）：

npx vitest run packages/preset/agent-presets/tests/probe-8204-teardown.spec.ts   # 机制逐环，6/6
npx vitest run packages/preset/agent-presets/tests/probe-8204-resume.spec.ts    # 复现 fleet 签名，1/1
npx vitest run packages/preset/agent-presets/tests/probe-8204-scope.spec.ts     # 排除 patch 热重载，1/1

probe-8204-resume.spec.ts 的实测输出：

--- first session (fresh mount)      : tools=["alpha"], presetSections=["preset:alpha"]
--- standing generation disposed     (服务缓存未清，即 fleet 的状态)
--- resumed session on the same preset: tools=[], presetSections=[]      ← 整层皆失
--- 会话状态                          : 仍注册、mount() 无报错
--- VERDICT: MATCHES THE FLEET SIGNATURE — preset layer gone from a LIVE agent, mount() silent

签名与线上逐项吻合：工具与提示段同灭、会话存活、零报错。

---

4. 关键佐证：检出器存在，但发货态不加载

包自己的 invariant 伴生就是为本缺陷写的，且措辞逐字对得上
（packages/preset/agent-presets/src/invariant.ts:60-71，挂在 system-prompt/assemble 上）：

agent "…" addressed a model without joining any agent preset while a roster is composed;
its tools, prompt sections, and skill catalog resolve against the empty global layer

复现中它确实抛了 InvariantError——说明这个状态是可判的。但它只在测试拓扑下被挂载：
scripts/test-invariants.ts 是 vitest 的 setupFiles（用 import.meta.glob 装载所有伴生），
发货态 composition 里没有 invariants 行。这一点 mount.ts:143-151 自己写在注释里：

Pruning therefore has to happen on a path this module owns. Reading is one such path, but not a
reliable one: the only production reader is the invariant companion's service listener, and
dsh-invariants is a development composition — a shipped host never loads it.

「测试里响亮、发货态静默」不是猜测，是两侧源码与实测共同印证的。

---

5. 对前文的更正与新增排除

5.1 更正：pruneDisposedMounts 单靠自己不足以致缺陷

前文 §2 把因果落在「剪枝发生在读路径上」。更准确的说法是两条独立路径的组合：
pruneDisposedMounts() 主动删除记录 + standingMountFor() 只在该集合里按 key 查找。
若只有前者（残留记录）或只有后者，standingMountFor 仍能按 key 命中，不会致缺陷。
即：删除与只查已删集合缺一不可。

5.2 新增排除：live patch 层热重载不是触发者（有机制，非印象）

patchReload: 'live' 的 profile 会装 watchUserPatches（apps/cli/src/profile-boot.ts:283-309），
其回调对根 Include 调 entry.update({...})（packages/boot/app-boot/src/index.ts:262-274）。

我用真实 boot() + 真实 watchUserPatches 驱动它，得到的是不同签名：

after reload: servicesReplaced = { agents:true, tools:true, prompt:true, presets:true }
              oldSessionRegistered = false          ← 整个运行时被替换
after reload: 新会话 tools=["alpha"]                 ← 重建后的树对新会话完全正常

⇒ 该路径重建整棵运行时，把 agent 一起带走；而 #8204 的会话始终存活（否则无从观察到后续装配）。
它无法产生「活着的、被剥光的会话」，故排除。

5.3 累计已排除（前文 5 条 + 本次 2 条）

#	假设	证伪判据
1	s2s 唤醒	反例 + 同一会话两次 s2s 结果相反
2	紧跟 end-seed 重启	52 次跟重启却正常、2 次缺陷无重启
3	进程冷启动	缺陷组仅 2/5 在空档后；正常组 17 个在空档后
4	组合文件 stamp 变化	三个 preset 文件 mtime 全为 2026-09-03
5	换代本身让已加入 agent 失工具	mount.spec.ts:700-701 断言相反
6	live patch 层热重载（本次）	它重建整个运行时、agent 一并消失，与「存活且被剥光」不符（§5.2）

---

6. 建议修法（按性价比）

1. ensureStanding 校验存活（一行级，直击第 5 环）：缓存命中后不仅比 stamp，还确认该代的 scope fiber 仍活着
   （u !== null / 未 dispose）；不活则重建。这一条就能把缺陷从「无限期」压成「最多影响一代」。
2. standingMountFor 返回 undefined 且 context.agent 存在时补可归因日志：含 agentKey 与它期望的
   standingKey。当前该状态完全静默，这正是它能长期存在的原因。
3. 把剪枝从「读路径」改成「有 orphan 引用的可观测状态」：pruneDisposedMounts 删除前先核对是否仍有 agent 指向该代。
4. composeFrom / mount 在 parent key 已死时报错，或在 dsh-scope 补销毁钩子（scopeParents 目前无失效通知）。

---

7. 复现脚本一览（全部纯只读，不改产品代码）

文件	作用	结果
probe-8204-teardown.spec.ts	机制逐环：销毁 standing scope 后 agent 静默失层	6/6
probe-8204-resume.spec.ts	resume 路径复现 fleet 签名	1/1
probe-8204-scope.spec.ts	反证 patch 热重载（整树重建）	1/1

仍未定：触发第 1 环的那个外部部署侧事件（谁先销毁 standing scope）。它需要线上日志；
但机制、持久化、复现与排除项均已确证，修法 1 也不依赖它。