【Bug】源码启动下所有工具调用失败:"Cannot read properties of undefined (reading 'prepare')" —— runtime 解析默认值导致 @deepseek-ai/dsh-tools 被加载两份,TOOL_RUNTIME_SCHEDULER Symbol 分裂

[gerry47231905]

问题概述

自提交 9ddef327a4("feat: resolution mode link to runtime",随 0.1.6-alpha.2 发布)起,源码启动(pnpm dsh web、pnpm dsh --profile …)下每一次模型工具调用都会失败:

TypeError: Cannot read properties of undefined (reading 'prepare')

界面上回合直接报错结束,日志中没有对应的 tool/result 事件。

根因是 @deepseek-ai/dsh-tools 出现了双模块实例:Loader 挂载插件走一个解析面,agent-loop 运行时 bundle 导入同一包走另一个解析面。模块级的 TOOL_RUNTIME_SCHEDULER = Symbol(...) 被求值两次,产生两个不相等的 Symbol,于是 ctx.tools[TOOL_RUNTIME_SCHEDULER] 解析为 undefined。

环境

• commit ddefc45fbc(master,0.1.6-alpha.2 发布合并);回归由 9ddef327a4(2026-09-17)引入
• Node v22.23.2,pnpm 11.7.0,Linux x64
• 启动方式:pnpm dsh web / pnpm dsh --profile headless(即源码启动:node --import tsx/esm apps/cli/src/bin.ts)
• 使用官方 profile、不装任何第三方插件即可复现

最小复现(无需 API key)

仓库自带的快照测试在开发默认的源码模式下即可复现:

npx vitest run --config vitest.snapshot.config.ts -t "bash-tool-turn"
stderr:
dsh: UNKNOWN: Cannot read properties of undefined (reading 'prepare')

FAIL snapshots/session/headless.snapshot.ts > … replays bash-tool-turn through dsh --profile headless
任意触发一次工具调用的交互任务同样失败。
根因
apps/cli/src/profile-boot.ts:
-  const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'link'
+  const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'runtime'   // 9ddef327a4
在 tsx 源码启动下,runtime 解析把 workspace 包图劈成两个平面:
1. Loader 把 @deepseek-ai/dsh-tools 插件经 tsx 加载(tsconfig paths → packages/core/tools/src/index.ts);
2. agent-loop 运行时 bundle(packages/core/agent-loop/lib/index.js)静态 import '@deepseek-ai/dsh-tools',由 Node 常规解析到 packages/core/tools/lib/index.js。
两份副本都会执行 const TOOL_RUNTIME_SCHEDULER = Symbol('@deepseek-ai/dsh-tools.scheduler'):
- 存活的 ToolRuntime 实例用符号 A(src 副本)作为调度器槽位键;
- agent-loop 用符号 B(lib 副本)查找槽位;
- ctx.tools[TOOL_RUNTIME_SCHEDULER] → undefined → startCall 中的 .prepare(…) 抛错(agent-loop/src/tool-calls.ts:170)。
插桩诊断证实:Object.getOwnPropertySymbols(ctx.tools) 里存在与 TOOL_RUNTIME_SCHEDULER 描述相同的 Symbol,但取值是 undefined —— 描述相同、对象不同。两次加载的模块 URL 分别观测为 …/packages/core/tools/src/index.ts(插件)与 lib 副本(bundle 导入)。
捕获的堆栈:
TypeError: Cannot read properties of undefined (reading 'prepare')
    at startCall (packages/core/agent-loop/lib/index.js:586:60)
    at fillPool (…)
    at runGroup (…)
    at executeToolCalls (…)
    at ReactLoopAgent.step (…)
为什么 CI 没拦住
快照/冒烟 CI 以 DSH_EXAMPLE_MODE=lib 运行,所有导入都解析到构建产物 lib/ —— 单一模块实例、符号一致,全部通过。只有开发默认的 src 模式(tsx)会踩中这次分裂。
修复建议
方案一:恢复非打包启动的原默认值:
const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'link'
本地已验证:改回 link 后 bash-tool-turn 快照端到端通过。
方案二:修正 runtime 模式,让源码启动下 workspace 包保持单一模块面(例如让 Loader 的插件解析与 tsx 使用同一套模块图)。
长期建议:加一个廉价的启动检查(或在 CI 中增加一条 src 模式快照),校验存活服务上 ctx.tools[TOOL_RUNTIME_SCHEDULER] 可解析,在启动时响亮失败,而不是在第一次工具调用时才暴露。
受影响用户的临时规避
本地把默认值改回上面一行,或完整构建后统一跑构建产物以避免 src/lib 混载。注意在上游修复落地前,git pull 会在这一行产生冲突。

[argszero]

Correction accepted in the useful direction: your attribution is right, and I can pin it to the line. I independently traced it before seeing your report and reached the same commit — you were the only one of four reports to name it, and you also named the mechanism (two module instances, module-level Symbol evaluated twice) correctly.

git show 9ddef327a4 ("feat: resolution mode link to runtime", 2026-09-17 20:08, contained only in tag dsh-v0.1.6-alpha.2, ancestor of ddefc45fbc) changes two files, one line each:

apps/cli/src/profile-boot.ts:263
-  … options.resolutionMode ?? 'link'
+  … options.resolutionMode ?? 'runtime'

So the regression is a pure default flip, not a resolver bug. Your "Loader 挂载插件走一个解析面, agent-loop 运行时 bundle 导入同一包走另一个解析面" is exactly it: profile-boot.ts:312 registers PluginPackages with { generation, behavior: 'enforce' } for any mode other than link, while agent-loop's static import (packages/core/agent-loop/src/tool-calls.ts:17) was linked natively before the client-side ESM bootstrap ran — and the design note says so itself: "The ESM bootstrap cannot affect static dependencies linked before its execution."

Crash site for completeness: tool-calls.ts:170 ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec) (also :153/:154), key = packages/core/tools/src/index.ts:463.

Worth knowing: the same commit flipped a second carrier and that half was already reverted. It also set apps/desktop-host/src/index.ts:21 to resolutionMode: 'runtime', and 39 minutes later the same author undid it in d9a55c7c0d ("fix: revert desktop"):

-    resolutionMode: 'runtime',
+    resolutionMode: process.argv[5] === 'runtime' ? 'runtime' : 'link',

Both in dsh-v0.1.6-alpha.2 — so desktop already defaults to link again and the CLI half is the part left standing. That should make the fix decision easier than the four threads suggest.

Full cluster write-up plus the Symbol.for sufficiency check: #7117.