[Bug] 第三方插件把 @deepseek-ai/dsh-tools/cordis 副本带进 profile 依赖，导致所有会话所有工具调用报 "Cannot read properties of undefined (reading 'prepare')"

[NuanFeng801]

环境：npx @deepseek-ai/dsh web 安装，Windows 10，dsh 0.1.0-rc.6，deepseek-official 路由
现象：安装 dsh-find-plugin 后，任何会话（包括新会话）任何工具调用（web_search、pwsh 等）都报 Cannot read properties of undefined (reading 'prepare') + UNKNOWN，随后会话历史残留孤儿 tool_calls，之后 DeepSeek 持续返回 400 INVALID_REQUEST；纯文字对话一直正常
根因定位：profiles\web\package.json 被塞进了 @deepseek-ai/dsh-tools、@deepseek-ai/cordis 副本依赖 + dsh.profile.bundles 里的第三方 bundle；怀疑是 TOOL_RUNTIME_SCHEDULER 的 unique symbol 跨物理模块实例不同导致 ctx.tools[symbol] 为 undefined（可引用 packages/core/agent-loop/src/tool-calls.ts 的 startCall 处 ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare）
修复：从 package.json 移除三个依赖和 bundle 条目、删除 profiles\web\node_modules 下对应实体后恢复
建议：dsh plugin add 的 reconcile 应阻止核心包（@deepseek-ai/dsh-tools、cordis 等）被安装/落入 profile 依赖

之前的package.json：
{
"name": "dsh-profile-web",
"private": true,
"dependencies": {
"@deepseek-ai/cordis": "4.0.1",
"@deepseek-ai/dsh-tools": "0.1.0-rc.6",
"dsh-find-plugin": "^0.3.6"
},
"dsh": {
"profile": {
"bundles": [
"@deepseek-ai/dsh-base",
"@deepseek-ai/dsh-web-app",
"dsh-find-plugin"
]
}
}
}

修改后的package.json：
{
"name": "dsh-profile-web",
"private": true,
"dependencies": {},
"dsh": {
"profile": {
"bundles": [
"@deepseek-ai/dsh-base",
"@deepseek-ai/dsh-web-app"
]
}
}
}

报错截图：

（可能需要）删除的文件夹，我找到几个就删了几个：
dsh-find-plugin
@deepseek-ai\dsh-tools
@deepseek-ai\cordis

[argszero]

你的根因定位完全正确——这是一个已知家族的第二次报告（此前 #1337，taonokenshin，Windows 11 + 12 个社区插件 + pnpm hoisted，同样的 Cannot read properties of undefined (reading 'prepare')）。我在当前 master（47f943859b）上逐一复核了链路，并补两个报告里没引用的关键事实。

1. 机制确认（与你怀疑的一致）

• TOOL_RUNTIME_SCHEDULER 是 unique symbol（packages/core/tools/src/index.ts:466）——每份物理拷贝在磁盘上求值都会得到不同的 Symbol 实例，即使描述字符串相同。
• 崩溃点是 packages/core/agent-loop/src/tool-calls.ts:169：ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)——当前 master 上仍无防御检查。ctx.tools 落到外来拷贝的实例上 → undefined.prepare → code: UNKNOWN。

2. 你踩中的恰好是设计专门要防的洞

packages/boot/app-boot/src/profile.ts:133-137 的设计注释写明：hoisted 链接器下，外部插件缺失的 peer（cordis 和 friends）会回落（fall through）到 profiles/node_modules 的安装闭包回退（:204-208，每个包是安装清单闭包的符号链接），从而所有插件共享安装的单一 cordis 实例而非重复实例。

而顶层 dependencies 里出现 @deepseek-ai/dsh-tools / @deepseek-ai/cordis 时，pnpm 在 profiles/web/node_modules 平铺出第二份物理拷贝——回退机制被绕过（已存在拷贝就不再 fall through），插件解析到新拷贝 → 外来 Symbol → 崩溃。所以你的修复方向（reconcile 拦截核心包）与设计意图是一致的，这正是防线应该守的位置。

3. 对修复建议的评估：位置正确，但有一条局限

• apps/cli/src/plugin.ts:59-91 的 reconcilePlugins 目前只对账 dsh.profile.bundles 层列表，从不检查 dependencies 块——顶层核心包依赖会静默通过（dsh-tools 无 dsh.bundle 声明，只触发 :70-75 的"新增普通依赖"warning，不拦截）。加一臂即可：pnpm 成功后扫描 after.dependencies，命中核心包名单（@deepseek-ai/dsh-tools、@deepseek-ai/cordis 等）→ 明确报错或自动移除。名单可以很精确：profile 模板自身 dependencies: {}（profile.ts:159），顶层出现任何 @deepseek-ai/* 核心包都必然可疑。
• 局限：reconcile 拦不住第二条触发路径——插件把 dsh-tools 捆绑进自身 bundle（Community plugins resolving a second @deepseek-ai/dsh-tools copy crash the tool scheduler with Cannot read properties of undefined (reading 'prepare') #1337 的第二种触发路径，如 dsh-context-doctor@0.5.0 vendoring ToolRuntime），profile deps 里根本看不见。因此运行时防御仍然是必要的第二道防线：tool-calls.ts:169 加防御检查，调度器缺失时用干净的合成 tool result 收尾该调用（可失败但可恢复），而不是 undefined.prepare 崩溃。

4. "孤儿 tool_calls → 永久 400" 是这条链的放大器，且与 #1593 家族相连

崩溃前 appendToolCall 已把 tool_calls 事件提交进会话（tool-calls.ts:168，dispatch 之前）→ 崩溃后会话残留悬挂的 tool call id → 恢复时 llm-deepseek/src/serialize.ts:105-140 原样重放该 id（无配对校验）→ DeepSeek 持续 400 INVALID_REQUEST → 会话永久不可恢复。这正是 #1337 帖里记录的次生缺口 + #1593（第 4 条序列化毒化路径：悬挂 tool/result call id）的现场证据。所以运行时守卫不只是体验问题——它是"一次崩溃"与"会话被永久毒化"的分界线。

5. 给同样踩坑者的立即恢复

你已做的移除修复正确。另建议：pnpm why @deepseek-ai/dsh-tools 确认无残留，pnpm dedupe 或 pnpm.overrides 强制单一版本（#1337 的缓解措施）；已毒化的会话若无法恢复，导出后重建会话即可。