Replies: 16 comments 11 replies
|
这个 目前确认的共同机制是
源码 checkout 可暂时改用 |
|
我也遇到了，测试多智能体那个团队 上下文注入 仅可从已完成轮次的最后一条消息分支 用量 10.8K tok 用时 3秒 dsh-session-session-5f1c571a-c705-4e77-ab47-e9277a80d046.zip |
|
同样的问题 |
|
收到反馈。@LatteFang 麻烦补充升级前后的 DSH 版本，以及使用桌面安装包、npm 安装还是源码启动；历史会话的 |
|
v0.1.6-alpha.1->v0.1.6-alpha.2，pnpm clean ,pnpm install ,pnpm run build ,pnpm dsh web. |
|
v0.1.6-alpha.2 还是报这个错误 |
|
也是一样的问题，解决了么 |
|
同样的问题，修复了吗？ |
|
我晕，刚升级后 我一直以为是我自己搞的操作搞的。。😓。得回退了。 |
[0.1.6-alpha.2] 源码(tsx)启动下工具调用必然失败：
|
| 项 | 值 |
|---|---|
| 升级前版本 | 0.1.5-rc.2（commit c291e7961a，2026-09-14） |
| 升级后版本 | 0.1.6-alpha.2（commit ddefc45fbc） |
| 安装/启动方式 | 源码启动：pnpm dsh web。不是桌面安装包，也不是 npm 全局安装 |
| 其它 | Windows 10 x64，Node v24.14.1，profile 名 web；升级后执行过 pnpm store prune``pnpm install``pnpm run clean``pnpm run build再重启 |
| 回归提交 | 9ddef327a4 feat: resolution mode link to runtime（PR #4471 worktree-resolutionmode）—— 已验证不在升级前的 c291e7961a 树中 |
补充：
0.1.5-rc.2的apps/cli/src/profile-boot.ts完全没有resolutionMode概念（无条件调用healProfilesModuleFallback()）；runtime解析代是0.1.6-alpha.2新引入的，并在同一 PR 里把源码启动的默认值定为runtime。
2. 现象
错误 A —— 新会话的第一次工具调用（prepare 错误）
- 文案：
Cannot read properties of undefined (reading 'prepare') - 出现时机：每个新会话的第一轮，模型一旦发起工具调用就立即失败
- 抛点：
packages/core/agent-loop/src/tool-calls.ts:170即callSeqs[index] = appendToolCall(session, turn, step, call.block) // :168 ← 调用已先落盘 started++ const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec) // :170 ← 在这里抛
ctx.tools[TOOL_RUNTIME_SCHEDULER]为undefined，而同一对象的ctx.tools.executionMode()（:89）正常。
错误 B —— 该会话的后续轮次（tool 配对校验错误）
- 文案：
DeepSeek Messages tool calls need immediate results - 出现时机：错误 A 之后再发任何消息
- 抛点：
packages/llm/llm-deepseek/src/protocols/messages/serialize.ts:117
（注意：不是同文件:121的history ends with unresolved tools，说明悬空调用后面已经跟了新的用户消息 → 属于"已有新输入但历史里有未配对调用"这一支） - 关键特征：失败发生在本地序列化阶段，没有产生
request/header事件 - 不可自愈：
packages/core/session/src/repair.ts:82只在"存在未闭合的尾轮"时修复；A 留下的悬空调用位于一个已turn/end的轮次内，recovery 永远看不到它，因此该会话在 UI 中无法继续
A 与 B 的关系：B 是 A 的后果，不是独立缺陷，但两者是不同的代码路径、不同的错误码（
UNKNOWNvsINVALID_REQUEST），应当分开核对与验收。
4. 根因
源码启动时，同一个包被加载成两份模块实例：
- 新默认
resolutionMode: 'runtime'（apps/cli/src/profile-boot.ts:263）会为 Node 的 ESM/CJS 安装"解析代"（installProfileResolution）。Loader 加载插件行@deepseek-ai/dsh-tools时被路由到构建产物packages/core/tools/lib/index.js。 - 而 tsx 按
tsconfig.base.json:30的paths把工作区内的 import 解析到源码packages/*/src/*.ts，于是dsh-agent-loop侧拿到的是packages/core/tools/src/index.ts。 packages/core/tools/src/index.ts:463用的是非注册符号：export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol('@deepseek-ai/dsh-tools.scheduler')
Symbol()每次模块实例化都产生新身份 →ctx.tools[TOOL_RUNTIME_SCHEDULER]（由另一份实例提供）为undefined→:170抛 TypeError。
同类隐患（本次未触发，但机制相同）：packages/workflow/workflow-ptc/src/runtime.ts:271 的 error instanceof JsonSchemaError（跨包 instanceof，双实例下同样会失效）。
|
使用V4.1F升级deepseek-harness版本，并整理问题： [0.1.6-alpha.2] 源码启动（
|
| 项目 | 值 |
|---|---|
| 升级前版本 | dsh-v0.1.5-rc.1 = 183f08e9c6（release 提交 1ef9c1fa9a） |
| 升级后版本 | dsh-v0.1.6-alpha.2 = ddefc45fbc（release 提交 6b1808f432） |
| 途经中间版本 | dsh-v0.1.5-rc.2 = fb2c4b9e69、dsh-v0.1.6-alpha.1 = 0a15e36e7f（未在中间版本单独停留验证） |
| 安装方式 | 源码启动：git checkout + pnpm install --frozen-lockfile + pnpm run build（不是桌面安装包，不是 npm 全局安装） |
| 启动命令（出问题） | pnpm dsh web → 实际执行 node --import tsx/esm apps/cli/src/bin.ts web |
| 启动命令（正常） | node apps/cli/lib/bin.js web |
| 平台 | Windows 10 x64 |
| 运行时 | Node v24.19.0，pnpm 11.7.0 |
| profile | web（~/.dsh/profiles；其 node_modules 是指向 checkout 的 Junction 农场） |
| 复现率 | 100%，与启动入口严格相关（非偶发、非并发） |
现象
- 报错：
本轮运行失败 Cannot read properties of undefined (reading 'prepare') - 出错时机：每个工具调用都失败（首个工具调用即失败），纯文本/推理正常。
- 关于"是否只影响历史会话"：本次出错发生在恢复的历史会话里；但同一个历史会话在换用构建产物入口后工具完全正常 —— 因此可以确定这不是会话历史/事件流内容导致的，而是启动入口决定的进程级问题。
- "新会话在
pnpm dsh web下同样失败。
触发条件
| 位置 | 内容 |
|---|---|
packages/core/agent-loop/src/tool-calls.ts:170 |
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec) ← 报错点，每个工具调用的必经路径 |
packages/core/tools/src/index.ts:463 |
export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol('@deepseek-ai/dsh-tools.scheduler') |
packages/core/tools/src/index.ts:798 |
readonly [TOOL_RUNTIME_SCHEDULER]: ToolRuntimeScheduler = {...}（ToolRuntime extends Service，构造期类字段；:829 super(ctx, 'tools')） |
tsconfig.base.json:484 |
"@deepseek-ai/dsh-tools": ["./packages/core/tools/src"]；root tsconfig.json:9 "extends": "./tsconfig.base.json" |
root package.json scripts |
"dsh": "node --import tsx/esm apps/cli/src/bin.ts" |
| 0.1.6-alpha.2 release note | 「插件依赖解析模式调整为运行时解析，插件管理支持运行时卸载，请开发者检查插件加载和卸载逻辑」← 引入混合解析的改动 |
ctx.tools 本身存在（否则报错会呈现 reading 'Symbol(...)'），是它上面的 symbol 键取不到值，所以只能是"同一个包被实例化了两次、写入方与读取方各自持有不同 Symbol()"。
|
就是0.1.6-alpha.2出现这个问题的
…---原始邮件---
发件人: ***@***.***>
发送时间: 2026年9月19日(周六) 晚上9:38
收件人: ***@***.***>;
抄送: ***@***.******@***.***>;
主题: Re: [deepseek-ai/deepseek-harness] 【bug report】升级后出现本轮运行失败Cannot read properties of undefined (reading 'prepare') (Discussion #6986)
v0.1.6-alpha.2 还是报这个错误
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
0.1.6-alpha.2-ddefc45 100% 触发这个bug |
|
确实，我也以为我折腾坏了呢 |
|
还没修复吗 |
|
目前还没有查到包含这个问题修复的可用版本，最新发布仍是 |
|
这是来自QQ邮箱的假期自动回复邮件。你好，我最近正在休假中，无法亲自回复你的邮件。我将在假期结束后，尽快给你回复。
|
|
回退老版本可以么 |
|
回退到你此前能正常使用的版本，可以作为临时尝试，但不能保证已经出错的旧会话也能恢复。尝试前先退出 DSH 并备份现有数据，保留原副本；回退后先用全新会话验证，不要删除旧会话或重置数据目录。回退是否适用于你的具体环境，目前还没有核实。 |
|
old session eventually get broken |
|
Yes. I’m not lamenting the time. I just routinely noticed that DeepSeek Harness had been updated, so I pulled it, compiled it, and ran it. It turned out to be completely unusable. This is a problem that shouldn’t exist. Running any test would have revealed it, yet they still released this seriously flawed code as a versioned release. This isn’t a minor glitch. Because of the version update, even rolling back to an older version leads to other baffling problems. |
Agent Note: 让 tsx 源码启动保留 link 解析Status: implemented English | 中文 问题
决策修复 import { reportStartupFailure } from './startup-diagnostics.ts'
+// The repository script runs this entry through tsx, whose tsconfig `paths`
+// map resolves a built plugin module's workspace imports back to `src`. Runtime
+// package resolution loads plugin entry points from built `lib`, so a package
+// reached by both planes would exist as two module instances and lose symbol
+// identity. A source launch therefore keeps the native link backend; a plain
+// Node launch of the bundled bin keeps the runtime default.
+const sourceLaunch = fileURLToPath(import.meta.url).endsWith('.ts')
+
@@
await runProfile({
environment: loadLayeredEnv('dsh'),
profile: invocation.profile,
fromDefaultProfile: invocation.fromDefaultProfile,
patchFiles: invocation.patches,
args: invocation.args,
+ ...(sourceLaunch ? { resolutionMode: 'link' as const } : {}),
})验证：工具调用能进入工具流水线，而不是在 引入来源该回归由 其目的是让普通 Node 启动获得打包可执行文件与 Electron Host 已在使用的 runtime 后端：runtime 启动只安装一份进程内不可变的包 generation，不物化、更新或退休 fallback symlink 与代理 manifest，而后者会让选包结果跨进程和安装版本持续存在，需要协调与加锁，也无法原子表示进程内变更（profile 解析 generation）。该改动把所有非 pkg 启动都当作普通 Node，其中包含 tsx 源码入口——而它的 tsconfig 路径映射会把插件导入解析到另一个平面。在模式工作之前，profile 启动始终物化磁盘 fallback，并把解析交给 Node 加 tsx，因此同一个工作区包只有一个模块实例。 没有任何 CI 门禁覆盖 tsx 下的 runtime 解析： 考虑的替代方案源码启动继续用 runtime，并禁止 tsx 对 把调度器键改为 把所有启动方式的默认值改回 link。 构建树的纯 Node 启动、打包或 Electron 载体需要 runtime 解析，以避免启动时写入或清理 fallback 链接；对它们而言该默认值是正确的。 后果源码启动会再次物化或复用 profile fallback 链接，并放弃 runtime 独有的“不写磁盘”特性；换来的是工作区包在插件入口与其传递导入之间只有一个模块实例。构建与打包启动不变，继续使用 runtime 解析。这是对 profile 解析 generation launcher 默认值的部分例外，该默认值对其他所有纯 Node 调用方仍然选择 runtime。 |
|
一样，拉取更新，安装，构建，启动。对话就出错了 |
|
我从1.1-rc.2升到1.5-rc.2然后在调用工具时就一直出现Cannot read properties of undefined (reading 'prepare') |
|
找到解决方法到了 |
|
找到问题了、然后点开 Discussion 一看发现其实是共性问题…… 一个简单的解决办法如下、 亲测有效。 |
Uh oh!
There was an error while loading. Please reload this page.
在升级完成后新开窗口，提示：本轮运行失败Cannot read properties of undefined (reading 'prepare')
历史数据则提示：历史加载失败：stored session "session-0044855e-a830-4522-af74-e29528d21c5b" is corrupt: stored session "session-0044855e-a830-4522-af74-e29528d21c5b" failed validation: Error: session event at seq 4714 message must have tool source（gateway/internal）
All reactions