问题描述、复现和解决方案：tool call fails with Cannot read properties of undefined (reading 'prepare')

[WXY-YXW996]

问题概述

按 README 的方式启动 dsh（pnpm dsh <profile>，实际执行 node --import tsx/esm apps/cli/src/bin.ts）时，
@deepseek-ai/dsh-tools 会被求值两次，来自两个不同的文件：

• 源码中以裸包名 @deepseek-ai/dsh-tools 导入的地方，被 tsx 按 tsconfig.base.json 的 paths
  别名解析到 packages/core/tools/src/index.ts；
• 而真正挂到 ctx.tools 上的 ToolRuntime 实例，是由该包自己声明的入口
  packages/core/tools/lib/index.js 构造的。

TOOL_RUNTIME_SCHEDULER 的声明是 Symbol('@deepseek-ai/dsh-tools.scheduler')，每次模块求值都会产生一个
新的、互不相等的 symbol，二者仅仅是 description 相同。于是
packages/core/agent-loop/src/tool-calls.ts 用其中一份 symbol 去查找，而 ctx.tools 是用另一份作为键
写入的，查找结果静默变成 undefined：

// packages/core/agent-loop/src/tool-calls.ts:170
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)
//                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ undefined

结果是该进程内所有会话的每一次工具调用都会失败（ToolRuntime 是 host 层单例），100% 必现。
本轮对话以如下方式结束：

{"type":"turn/end","data":{"turn":3,"reason":{"kind":"error",
  "error":{"message":"Cannot read properties of undefined (reading 'prepare')","code":"UNKNOWN"}}}}

这个错误被折叠进了轮次结果里，服务端控制台不会打印任何内容，所以从外部看只是"模型用不了任何工具"，
很难定位。

改用编译产物启动（node apps/cli/lib/bin.js <profile>）则不复现。

环境

dsh	0.1.6-alpha.2（master，ddefc45fbc）
Node	v24.21.0
pnpm	11.7.0
tsx	4.22.4
操作系统	Linux 6.18.33.2-microsoft-standard-WSL2

复现步骤

不需要 API key、浏览器或任何会话——符号失配在启动时就已经成立。在干净的检出上执行
pnpm install && pnpm run build 之后，把下面的脚本保存到仓库根目录并运行：

node --import tsx/esm repro-scheduler-symbol.ts

实际输出

=== Part 1: module identity of @deepseek-ai/dsh-tools ===
  bare specifier      -> file:///.../packages/core/tools/src/index.ts
  package.json entry  -> file:///.../packages/core/tools/lib/index.js
  same module instance? false
  TOOL_RUNTIME_SCHEDULER identical across both loads? false
    load A symbol: Symbol(@deepseek-ai/dsh-tools.scheduler)
    load B symbol: Symbol(@deepseek-ai/dsh-tools.scheduler)

=== Part 2: the composed runtime ===
  ctx.tools constructor    : ToolRuntime
  own symbols on ctx.tools : [ 'Symbol(cordis.tracker)', 'Symbol(@deepseek-ai/dsh-tools.scheduler)' ]
  scheduler key came from  : load B (package.json entry copy)
  TOOL_RUNTIME_SCHEDULER in ctx.tools? false
  ctx.tools[TOOL_RUNTIME_SCHEDULER]  : undefined

RESULT: BUG REPRODUCED

其中 scheduler key came from: load B 正是问题所在的不对称：真正的服务实例上带的是 lib/ 那份副本
铸造的键，而源码里每一处
import { TOOL_RUNTIME_SCHEDULER } from '@deepseek-ai/dsh-tools' 拿到的都是 src/ 那份铸造的键。

期望结果

TOOL_RUNTIME_SCHEDULER in ctx.tools 为 true，工具调用正常派发。

repro-scheduler-symbol.ts

import { readFileSync } from 'node:fs'
import { resolve } from 'node:path'
import { pathToFileURL } from 'node:url'
import { TOOL_RUNTIME_SCHEDULER } from '@deepseek-ai/dsh-tools'

const PORT = process.env.REPRO_PORT ?? '8099'
const TOOLS_DIR = resolve(process.cwd(), 'packages/core/tools')
let reproduced = false

console.log('=== Part 1: module identity of @deepseek-ai/dsh-tools ===')
const bareUrl = import.meta.resolve('@deepseek-ai/dsh-tools')
const manifest = JSON.parse(readFileSync(resolve(TOOLS_DIR, 'package.json'), 'utf8'))
const entry = manifest.exports?.['.']?.default ?? manifest.main
const entryUrl = pathToFileURL(resolve(TOOLS_DIR, entry)).href
console.log('  bare specifier      ->', bareUrl)
console.log('  package.json entry  ->', entryUrl)

const viaBare = await import('@deepseek-ai/dsh-tools')
const viaEntry = await import(entryUrl)
const identical = viaBare.TOOL_RUNTIME_SCHEDULER === viaEntry.TOOL_RUNTIME_SCHEDULER
console.log('  same module instance?', viaBare === viaEntry)
console.log('  TOOL_RUNTIME_SCHEDULER identical across both loads?', identical)
if (!identical) {
  reproduced = true
  console.log('    load A symbol:', viaBare.TOOL_RUNTIME_SCHEDULER.toString())
  console.log('    load B symbol:', viaEntry.TOOL_RUNTIME_SCHEDULER.toString())
}

console.log('\n=== Part 2: the composed runtime ===')
const { runProfile } = await import(pathToFileURL(resolve(process.cwd(), 'apps/cli/src/profile-boot.ts')).href)
const { loadLayeredEnv } = await import('@deepseek-ai/dsh-app-boot')
const { ctx, shutdown } = await runProfile({
  environment: loadLayeredEnv('dsh'),
  profile: 'web',
  fromDefaultProfile: undefined,
  patchFiles: [],
  args: ['--port', PORT, '--no-open'],
})
try {
  const tools = ctx.tools as object
  const present = TOOL_RUNTIME_SCHEDULER in tools
  const live = Object.getOwnPropertySymbols(tools)
    .find(s => s.description === '@deepseek-ai/dsh-tools.scheduler')
  console.log('  ctx.tools constructor    :', tools.constructor?.name)
  console.log('  own symbols on ctx.tools :', Object.getOwnPropertySymbols(tools).map(s => s.toString()))
  console.log('  scheduler key came from  :',
    live === undefined ? '(absent)'
      : identical ? 'loads A and B share one symbol'
        : live === viaBare.TOOL_RUNTIME_SCHEDULER ? 'load A (tsconfig-alias / source copy)'
          : live === viaEntry.TOOL_RUNTIME_SCHEDULER ? 'load B (package.json entry copy)'
            : 'a THIRD load, distinct from both A and B')
  console.log('  TOOL_RUNTIME_SCHEDULER in ctx.tools?', present)
  console.log('  ctx.tools[TOOL_RUNTIME_SCHEDULER]  :', (tools as Record<symbol, unknown>)[TOOL_RUNTIME_SCHEDULER])
  if (!present) reproduced = true
} finally {
  await shutdown.shutdown(0)
}
console.log(reproduced ? '\nRESULT: BUG REPRODUCED' : '\nRESULT: not reproduced (scheduler key intact)')
process.exit(reproduced ? 1 : 0)

为什么偏偏是这一个 symbol 出问题

TOOL_RUNTIME_SCHEDULER 似乎是整个仓库里唯一一个用裸 Symbol() 创建、且被当作跨包（经裸包名）
共享对象的属性键来使用的 symbol。其余模块级 Symbol()（DYNAMIC_TOOL、REMOTE_EVENT_NEXT、
OVERSIZED、CDP_METHOD_NOT_HANDLED）要么是模块私有，要么只在本包内通过相对路径导入使用——相对
路径只可能解析到同一个文件，不存在两份。其他 unique symbol 则都是 declare const 的纯类型 brand，
运行时并不存在。

而本仓库所基于的 cordis 框架本身，早已在所有跨边界符号上规避了这个坑
（vendor/cordis/src/utils.ts）：

shadow:  Symbol.for('cordis.shadow'),
tracker: Symbol.for('cordis.tracker'),
isolate: Symbol.for('cordis.isolate'),
effect:  Symbol.for('cordis.effect'),
// ……所有跨边界符号一律使用 Symbol.for

这恰好解释了为什么在同一个被重复加载的 ctx.tools 对象上，Symbol(cordis.tracker) 照常工作，唯独
scheduler 这个键失效。

建议的修复

packages/core/tools/src/index.ts:463

-export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol('@deepseek-ai/dsh-tools.scheduler')
+export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol.for('@deepseek-ai/dsh-tools.scheduler')

Symbol.for 按字符串走进程级全局注册表，因此无论模块被求值多少次，这个契约都能保持一致。它与
unique symbol 类型兼容，也与 cordis 既有的写法保持一致。

已在同一份检出上本地验证：仅改这一行并重新 pnpm run build 后，上述复现脚本的结果变为
TOOL_RUNTIME_SCHEDULER in ctx.tools? true，工具调用正常派发，
npx vitest run packages/core/agent-loop packages/core/tools 保持全绿（36 个文件 / 843 个用例）。

补充说明

1. 这个改动修的是契约，不是重复加载本身。 修复之后 same module instance? false 依然成立——模块
   仍然被求值了两次。dsh-tools 中其他依赖跨副本同一性的假设（instanceof、类的身份、模块级缓存）
   仍然是暴露的。更彻底的修法是让两条解析路径归一，例如运行时不启用 tsconfig 的 paths 别名，或让
   插件加载器与进程其余部分走同一套别名解析。

2. 可能与 discussion [Bug] 所有工具调用都报 "Cannot read properties of undefined (reading 'prepare')" — ToolRuntime 调度器未注册（rc.6） #1677 相关，该讨论报告了相同的错误信息。这里单独提交，是因为本机上的重复
   并非重复安装：该包在本机只有一份物理副本（所有 node_modules/@deepseek-ai/dsh-tools 都是指向
   同一目录的符号链接，没有 injected 或复制出来的实例），两个 symbol 来自同一份文件树经两条解析
   路径被求值了两次。

3. README.md 中写明 pnpm dsh web "uses those built artifacts without rebuilding"，但 dsh 这个
   脚本实际是通过 tsx 从源码运行 apps/cli/src/bin.ts 的。无论哪一个才是预期行为，二者目前是不一致
   的——而上述 bug 只存在于源码运行这条路径上。