llm.discoverModels always fails: "no model discovery is registered" — registerDiscovery has no callers in the repo

[Kugua-GG]

Issue 草稿（中文版）: llm.discoverModels 始终失败：NO_DISCOVERY — 仓库中 registerDiscovery 无任何调用点

标题

llm.discoverModels always fails: "no model discovery is registered" — registerDiscovery has no callers in the repo

描述

环境： dsh v0.1 开发者预览版（@deepseek-ai/dsh 最新版，2026-08-14），Windows 10，web profile（dsh web），默认 standard agent preset。

复现步骤

1. 启动 dsh web，打开 http://127.0.0.1:3080。
2. 打开 Settings → Models。
3. 点击 Fetch models（或让页面触发模型发现）。

预期行为

应获取并列出当前激活 provider（deepseek-official）的模型目录（V4 Flash / V4 Pro 已存在于 dsh-llm-deepseek 的 DEFAULT_MODELS 中）。

实际行为

UI 显示 Failed to fetch (internal)。后端返回：

POST /api/llm.discoverModels
{"result":{"ok":false,"error":{"code":"model-discovery-failed",
"message":"no model discovery is registered for \"llm-deepseek\""}}}

底层错误是 LlmService.discoverModels 抛出的 LlmError(..., "NO_DISCOVERY")（packages/llm/llm/src/index.ts）：

const discover = this.discoveries.get(settingsNs);
if (discover === void 0) throw new LlmError(`no model discovery is registered for "${settingsNs}"`, "NO_DISCOVERY");

根因

registerDiscovery（同样位于 packages/llm/llm）在仓库中没有任何包调用它——全仓库搜索 registerDiscovery 返回零调用点。Web UI 暴露了发现流程（api.llm.discoverModels，dsh-client-ui-settings-models 中的 fetch 按钮），但没有任何 provider（包括随发行版提供的默认 provider dsh-llm-deepseek）注册 discovery 实现，因此该功能永远无法成功。

影响

• Settings → Models 中的 Fetch models 按钮必然报错，显示令人困惑的 "Failed to fetch (internal)"，看起来像网络问题。
• 由于模型路由本身正常（配置驱动的 listModels 可用，llm.providers 健康），这属于 UX/功能缺口而非硬阻塞——在 discovery 实现落地之前，值得先提供一个优雅的"不支持"UI 状态。

建议修复（二选一）

1. 在 dsh-llm-deepseek 中实现 discovery（例如使用配置的 apiKeyEnv 调用 DeepSeek 模型列表端点），或
2. 让 UI 检测到没有注册 discovery 时隐藏/禁用 fetch 操作，并显示说明性提示，而不是暴露内部错误。

环境

• dsh 版本：@deepseek-ai/dsh 最新版（2026-08-14）
• 平台：Windows 10 Pro
• 浏览器：Chrome（最新版）
• Provider：deepseek-official（apiKeyEnv DEEPSEEK_API_KEY）

[Kugua-GG]

补充两个同类缺陷（错误处理不健壮），与主贴同主题，一次汇总：

缺陷 2：未知工具名触发前端崩溃（而非"tool not found"）

复现：Web UI 会话中让 agent 调用一个不存在的工具名（例如 mcp_kugua_negentropy_dash，单下划线，而实际注册名是 mcp__kugua__negentropy_dash 双下划线）。

实际：agent 发起 Tool call 后，会话立即报错：

Cannot read properties of undefined (reading 'prepare')
UNKNOWN

预期：工具调度器应返回"tool not found"类错误，由 agent 修正工具名重试；模型在 agent 日志中也看不到"该工具不存在"的明确反馈。

影响：工具名一个字符之差（单/双下划线）就导致整个会话前端状态崩溃，且崩溃后该会话历史残缺（见缺陷 3），需要新建会话。

缺陷 3：并行工具调用中断 → 会话历史永久残缺 → 后续请求永远 INVALID_REQUEST

复现：

1. Web UI 会话中让 agent 同时发起多个工具调用（如"检查环境 + 健康状态，并行执行"）
2. 执行中被中断（例如 dsh 的"仅可从已完成轮次的最后一条消息分支"限制触发拒绝，或用户 Stop）

实际：之后该会话的任何请求都失败：

An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'.
(insufficient tool messages following tool_calls message)
INVALID_REQUEST

根因：被中断的轮次在会话日志中留下了带 tool_calls 的 assistant 消息，但没有对应的全部 tool 消息；deriveMessages() 忠实投影这段残缺历史，每次请求都带上它，被 API（DeepSeek OpenAI 兼容端点）拒绝。会话永久报废，无法自愈，只能新建。

影响：这是预览版最伤体验的问题——一个并行调用失败就废掉整个会话，且错误信息（INVALID_REQUEST）对用户毫无提示性。

建议：

• 并行调度被拒绝/中断时，要么完整写回所有 tool 消息（含中止标记），要么从历史中原子移除该轮次
• 或至少在会话层面提供"清理残缺历史"的恢复路径（如修复工具、或 session.fork 跳过坏轮次）

规避（供其他用户参考）：agent-loop.maxParallelToolCalls: 1（settings.yaml）强制串行可大幅降低触发概率；会话报 INVALID_REQUEST 后直接新建会话。

[udsy19]

The symbol is registerModelDiscovery, not registerDiscovery — that's why the repo search came back
empty. It has exactly one in-repo caller on current master (b150a551b).

The seam is keyed by settings namespace, not by provider route — packages/llm/llm/src/index.ts:531:

registerModelDiscovery(
  settingsNs: string,
  discover: (request: LlmModelDiscoveryRequest) => Promise<readonly LlmDiscoveredModel[]>,
): () => void {

The one caller is dsh-llm-pi-ai, for the llm-pi-ai namespace — packages/llm/llm-pi-ai/src/index.ts:254:

ctx.llm.registerModelDiscovery(NS, request => discoverModels(request, () => storedApiKey(request.provider)))

(const NS = settingsNamespace('llm-pi-ai'), packages/llm/llm-pi-ai/src/index.ts:90.)

dsh-llm-deepseek registers configurable providers
(ctx.llm.registerConfigurableProviders([…]), packages/llm/llm-deepseek/src/index.ts:442) but no
discovery, so discoverModels('llm-deepseek', …) hits the throw at
packages/llm/llm/src/index.ts:563-565:

const discover = this.discoveries.get(settingsNs)
if (discover === undefined) {
  throw new LlmError(`no model discovery is registered for "${settingsNs}"`, 'NO_DISCOVERY')
}

So: Fetch models works for routes under the llm-pi-ai namespace and fails with NO_DISCOVERY for
llm-deepseek. Whether llm-deepseek should also register one is a maintainer call — I can only
confirm it currently doesn't.

[weijiafu14]

@udsy19 那条更正是决定性的（符号是 registerModelDiscovery、按 settings namespace 而不是 provider 路由建索引、全仓唯一调用点在 dsh-llm-pi-ai），主帖到此已经答完了。我想说的是你自己在评论里补的那两条——它们没人接，而其中一条属于一个我在这个社区反复见到的类。

缺陷 3 值得单独开一帖，它不是"错误处理不健壮"

被中断的轮次在会话日志中留下了带 tool_calls 的 assistant 消息，但没有对应的全部 tool 消息；deriveMessages() 忠实投影这段残缺历史，每次请求都带上它，被 API 拒绝。会话永久报废，无法自愈，只能新建。

这条的定性应该是**"一次工具调用中断导致会话永久损坏"**，而不是"错误处理不健壮"。前者是数据损失，后者听起来像文案问题——装在哪个标题里，得到的优先级会差很多。

而且它有一大群同类。这个形状我这两天数到第五个了：

帖	检查/投影本身	因为没有恢复路径而变成
你这条	deriveMessages() 忠实投影残缺历史	会话永久 INVALID_REQUEST，只能新建
#2915 / #1627 / #1703	replay state 块数与内容不匹配 → 抛	会话永久无法继续
#3561	会话含图片就拒绝切到文本模型	视觉模型额度用完后无任何可用模型，窗口卡死
#3489	MCP 会话过期当普通工具错误抛	模型重新规划 61 次，500 多秒
#3568	工具参数解析失败 → 空 {}	server 报缺参，模型原样重发，17 步死循环

每一条的检查/投影本身都是对的，每一条的后果都比它防住的东西更糟。 共同缺的是同一样：不一致被发现之后，除了"停"以外还能做什么。

值得一提的是 replay-state 那一族已经有了官方修复，而它的做法恰好印证了这个视角——不是去消灭不一致，而是给不一致加一条降级路径（错位的 replay state 退回 provider-neutral 重放，而不是永久弄坏会话）。你这条的对应做法就是你自己建议的那个：中断时要么把 tool 消息补全，要么把那条残缺的 assistant 消息一起丢掉，别让它进入之后每一次请求。

如果你去单独开帖，我建议把这张表引上——一个失败模式有五份独立复现，比任何单帖都更能说明它是结构性的，而且能把诉求从"修我这一处"提到"投影层遇到不一致时的通用处置"。

缺陷 2：那个报错串至少有两个来源，值得留个心眼

Cannot read properties of undefined (reading 'prepare') / UNKNOWN

同样这串报错在 #3751 里有一个完全不同的根因：dsh-tools 的 TOOL_RUNTIME_SCHEDULER 是模块级 Symbol()，当这个包在依赖树里被求值两次时，ctx.tools[TOOL_RUNTIME_SCHEDULER] 拿到 undefined，然后炸在 .prepare 上——和工具名对不对完全无关。

我没法判断你遇到的是哪一个（你的复现是故意写错工具名，指向"工具查找返回 undefined"；#3751 指向"调度器本身是 undefined"）。但这件事本身就值得说：同一串报错对应至少两个成因，而报错文本不区分它们。 如果你还能复现，值得留意一下换个正确的工具名会不会也炸——如果也炸，那你踩的是 #3751 那个，和你的假设完全不同。

（顺带说，你这条的诉求同样属于上面那张表：模型在 agent 日志里看不到"该工具不存在"的明确反馈，于是它没有任何据以纠正的信息。#3568 里模型 17 步重发同一个坏参数，是一模一样的机制。）

边界与利益相关

我们不修 DSH 自家组件——llm 的 discovery seam、工具调度器、deriveMessages() 都在 DSH 里。上面全是归类和串联，没有一条是我能替你落地的；我也没有复现过你那三条，缺陷 2 那段是从报错串的形态推的，不是结论。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——会话历史一旦残缺，装任何第三方插件都不会让它重新合法。