[实测补充] 0.1.6-alpha.2 prepare 报错：构建入口可恢复 Web 工具调用，附 Symbol 冲突证据与修复建议

[kingfs]

在 Linux aarch64、0.1.6-alpha.2（commit ddefc45fbc7f8e46dd73185e68295696d1297887）上独立复现了源码启动时的工具调用失败。不修改源码，改用 pnpm exec node apps/cli/lib/bin.js web 后，已手动确认 Web 对话可以正常调用工具。 希望维护者将这个可直接执行的临时启动方式补充到相关排障说明，并修复源码启动的模块解析。

关联讨论：#6974、#7011、#7030、#7035。与这些报告属于同类问题；本帖补充当前环境的运行中调试证据和实际 Web 验证结果。#7035 的社区回复也提供了等价的构建入口启动方式。

环境与复现：

• Linux aarch64；Node v24.16.0；pnpm 11.7.0。
• 仓库位于上述 commit，排查期间没有修改源码。
• 更新代码并执行 pnpm run build 后，用 pnpm dsh web 启动。
• 页面和模型响应正常，进入工具调用时出现：本轮运行失败Cannot read properties of undefined (reading 'prepare')。
• 在同一服务中新建只读诊断会话，要求仅执行一次 pwd，也复现同样错误。

实际堆栈（已去除本机目录前缀）：

TypeError: Cannot read properties of undefined (reading 'prepare')
    at startCall (<repo>/packages/core/agent-loop/lib/index.js:586:60)
    at fillPool (<repo>/packages/core/agent-loop/lib/index.js:626:10)
    at runGroup (<repo>/packages/core/agent-loop/lib/index.js:635:9)
    at executeToolCalls (<repo>/packages/core/agent-loop/lib/index.js:528:25)
    at ReactLoopAgent.step (<repo>/packages/core/agent-loop/lib/index.js:1116:33)

运行中调试确认同一进程已加载以下模块：

packages/core/tools/src/index.ts
packages/core/tools/lib/index.js
packages/core/agent-loop/lib/index.js

在 startCall 异常现场检查 ctx.tools，结果如下：

ctx.tools[TOOL_RUNTIME_SCHEDULER] === undefined              true
String(TOOL_RUNTIME_SCHEDULER)                              Symbol(@deepseek-ai/dsh-tools.scheduler)
实际存在的 scheduler 键的描述                              Symbol(@deepseek-ai/dsh-tools.scheduler)
实际存在的 scheduler 键 === TOOL_RUNTIME_SCHEDULER          false
typeof ctx.tools[实际存在的 scheduler 键].prepare           function

因此，这次失败的直接原因已经确认：注册端与调用端持有不同的 Symbol 对象，调用方无法取到实际存在的调度器。packages/core/tools/src/index.ts:463 使用模块局部的 Symbol('@deepseek-ai/dsh-tools.scheduler')；源码与构建产物各自求值会产生不同的键。调用点是 packages/core/agent-loop/src/tool-calls.ts:170。

**已验证的临时解决方式：**停止原 Web 服务，在仓库根目录用构建后的 CLI 启动，并打开新进程打印的访问地址：

# 已成功完成 build 且代码没有变化时，可以直接执行最后一行。
pnpm run build
pnpm exec node apps/cli/lib/bin.js web

该方式由我手动确认可以正常调用 Web 工具。另通过 node apps/cli/lib/bin.js --profile headless 运行只读诊断，真实调用 shell 执行 pwd，工具和 CLI 均成功退出。排查和验证过程中没有修改源码、删除数据库或清理会话。这里只确认后续工具执行恢复，没有验证此前失败轮次的历史会话恢复。

单独重新 build 不会改变 pnpm dsh web 的启动入口：该脚本仍执行 node --import tsx/esm apps/cli/src/bin.ts web。构建后的 CLI 则避开了这条 tsx 源码启动路径。

建议上游评估的修复方向（以下未在本环境实施）：

1. 修复解析层，确保配置加载的 tools 插件和 agent-loop 的包导入获得同一模块实例。源码启动和构建入口都应明确维持一致的模块身份。社区在 #6974 的回复中提出对 ESM fallback 的 route.entry.declarer 使用真实路径，再交给原 loader；这是一条值得评估的具体候选方案，其补丁验证属于该回复作者的结果。
2. 若采用恢复源码入口 link 默认值的方案，应明确区分 tsx 源码启动与普通 Node 构建入口，保留构建入口所需的 runtime 行为。我们尚未在本环境验证这一改动。apps/cli/src/profile-boot.ts:263 的默认值变更（9ddef327a4）与现象吻合，但本次没有做提交二分或回退对照。
3. Symbol.for(...) 可以作为共享键的补强候选，但仍需要验证模块兼容性和 HMR；单独改变这个键无法保证两份模块中的其他身份与状态一致。
4. 增加真正经过 CLI 启动路径的工具执行回归：在已有 lib/ 的工作区中，分别用 tsx 源码入口和构建入口执行一次受控工具调用，并检查结果与 turn/end，覆盖 native 和 PTC 调度。仅验证 --version、启动成功或页面可访问，无法捕获此次故障。

希望官方优先公布上述已验证的构建入口 workaround，并将解析层修复及实际工具调用回归一起纳入后续版本。

[coldxiangyu163]

你现场记录的 ctx.tools[TOOL_RUNTIME_SCHEDULER] === undefined、两枚 Symbol 描述相同但 !==，与我们在源码平面定位到的机制一致：profile 的 ESM 后备解析把 pnpm 符号链接下的 node_modules/.../package.json 作为 declaring 锚点，tsx 对含 /node_modules/ 的 importer 不应用 tsconfig paths，于是插件走 lib/、CLI 走 src/。

最小修复（锚点规范化为真实路径）+ 回归红绿 + A/B（有/无构建产物）+ 原句端到端复测见 #7048。你提到的构建入口启动方式可作为修复合入前的临时缓解。