[Bug] Bot 新建任务必现失败「Bot 无法从目标 Host 解析 Submission 模型」：/new 播种的草稿 modelSelection 混入思考等级后缀（GLM-5.3-Flash$max），目标 Host 永远解析失败（v3.14.4，附根因定位与临时解法）

[0xYiliu]

提交前确认 · Pre-submission checklist

• 已搜索现有 issue，确认非重复：最接近的是 [Bug] 飞书 Bot 发消息创建任务必现失败：「Bot 无法从目标 Host 解析 Submission 模型」（3.12.3，附根因定位） #697——同一抛错点（handleMessage draft 分支），但根因不同（[Bug] 飞书 Bot 发消息创建任务必现失败：「Bot 无法从目标 Host 解析 Submission 模型」（3.12.3，附根因定位） #697 是本地工作区、草稿无 modelSelection、registry fallback 落空；本案是草稿持久化了畸形 modelSelection 且 /new 会反复重新播种，发生在远程 SSH 工作区）。发送风暴相关现象与 【Bug】微信 Bot 桥回信失败（iLink /sendmessage "prepare failed"）导致同一条用户消息被无限重复注入会话 #862 / [Bug] 微信 Bot（iLink）空闲数小时后 sendmessage 持续 prepare failed：无重连/重试，本地任务完成但结果全部静默丢失 #530 关联。
• 已阅读 CONTRIBUTING.md

问题类别 · Category

其他 / 不确定 · Other / Not sure（Bot 通道 · 微信 iLink · draft 草稿模型选择）

涉及的 Agent 框架 · Agent framework

ZCode Agent（自研）

严重程度 · Severity

阻塞使用（/new 之后该 Bot 通道完全无法创建任务；且 /new 每次都会复播坏数据，/model 的修复会被冲掉）

复现频率 · Reproducibility

必现（/new 之后发送任意文本消息 100% 失败；用 /model 重选模型后恢复，再 /new 又复现）

---

问题描述 · Description

Windows 上的 ZCode Desktop v3.14.4，微信 Bot（iLink）绑定远程 SSH 工作区（remote:ssh:…@192.168.3.152:/home/peterhan/non-workspace）。

• 给 Bot 发普通文本消息必现失败，日志出现 provider callback failed … Bot 无法从目标 Host 解析 Submission 模型，消息不进任何会话；
• /new、/model、菜单数字选择等命令类消息正常（不涉及 Submission）；
• 已有任务（task 模式）的 resume 路径正常，只有 draft 建新任务的路径被堵死。

时间线：09-20 正常；09-21 06:35 起 draft 提交全失败；10-02 上午用 /model 重选供应商+模型后恢复，并成功创建、运行任务；10-03 早上发 /new 后再次全失败。状态文件对比确认：/new 会用桌面 App 当前选中的模型重新播种 draftOptions.modelSelection，且播种结果是畸形的（见下），这是反复复发的直接原因。

复现步骤 · Steps to reproduce

1. 微信 Bot 绑定任意工作区（本地/远程均可，本案为远程 SSH），发送 /new（重置到 draft 并重新播种草稿）；
2. 发送任意文本消息；
3. Bot 回复「处理机器人回调失败：Bot 无法从目标 Host 解析 Submission 模型」，日志同步出现 provider callback failed；
4. 微信 iLink 对失败回调每 ~6s 重投递一次（单日 1.2 万+ 次回调），形成重投风暴（参见 【Bug】微信 Bot 桥回信失败（iLink /sendmessage "prepare failed"）导致同一条用户消息被无限重复注入会话 #862）。

期望表现 · Expected behavior

正常创建新任务并投递消息开始运行；/new 后草稿的模型选择应可直接解析（或回退到目标 Host 默认模型）。

实际表现 · Actual behavior

每条消息立即失败。此时 ~/.zcode/v2/bot-state.v3.json 中该 Bot 的草稿为：

"draftOptions": {
  "provider": "glm",
  "modelSelection": {
    "providerId": "account:bigmodel-start-plan",
    "modelId": "GLM-5.3-Flash$max",
    "options": { "reasoningLevel": "max" }
  },
  "mode": "yolo"
}

两处异常：modelId 混入了思考等级编码后缀（应为纯 GLM-5.3-Flash，等级应只存在于 options.reasoningLevel）；providerId 还是本地桌面 App 当前选择的账号计划（bigmodel-start-plan），而目标远端主机连接的是 bigmodel-individual-coding-plan。

ZCode 版本 · ZCode version

v3.14.4（ProductVersion 3.14.4.7912，Windows 桌面版）

设备 / 系统 · Device / OS / Browser

Windows 11 x64（10.0.26220）/ ZCode Desktop v3.14.4 / 微信 Bot（iLink）/ 目标 Host：Ubuntu（SSH 远程工作区）/ 模型通道：bigmodel 个人 Coding Plan（GLM-5.3-Flash）

---

根因定位（供开发参考，基于 v3.14.4 app.asar 反解，函数名为 bundle 内保留名）

handleMessage（bots 模块）draft 分支建任务前：

let ke = P.context.draftOptions ?? await He(P.context),
    Ve = await de(P.context, ke.modelSelection),        // readModelSelectionView → 目标 Host 的 model-selection.getView
    Je = ke.modelSelection ? Ve?.effectiveSelection : Ve?.preferredSelection;
if (!Je || (ke.modelSelection && Ve?.selectionIssue))
  throw new Error("Bot 无法从目标 Host 解析 Submission 模型");

目标 Host 侧 resolveEffectiveModelSelection（Nk）用 registry.models.find(l => l.modelId === t.modelId) 精确匹配；注册表中的 modelId 是纯 GLM-5.3-Flash（同一远端上正常会话的 provider runtime-headers 请求可见 modelId: 'GLM-5.3-Flash'）。带 $max 的 modelId 必然 model-not-found → effectiveSelection: null → 抛错。

写入侧才是本案根因：模型选择的字符串编码格式是 provider/model$level（formatBotModelSelectionValue/ju 一系，用于显示与选项值；对应的完整解析在 Mu，会把 $level 拆进 options）。但 /new 重建草稿、把"当前模型选择"播种进 draftOptions.modelSelection 的路径上，经过的是只按 / 分隔的 parseBotModelOptionValue（hH）——$level 后缀被留在 modelId 里，reasoningLevel 又从另一路写入 options，于是持久化了上面那个两边各存一半、谁也解析不了的畸形对象。/new 每次都会重新播种，所以 /model 的修复总会被下一次 /new 冲掉。

次要观察：account-plan 类选择在 Nk 中还要求目标 Host 上有且仅有一个 current: true 的账号型连接（多计划场景，如同时连接 zai + bigmodel，会命中 account-connection-unavailable 走到同一报错）；本地与远端同时连接多个计划时建议一并核对这条分支。

临时解法（已实测有效）

1. 退出 ZCode，编辑 ~/.zcode/v2/bot-state.v3.json，把 draftOptions.modelSelection 换成干净形式（实测立即恢复，下一条消息成功建任务）：

   { "providerId": "account:bigmodel-individual-coding-plan", "modelId": "GLM-5.3-Flash", "options": { "reasoningLevel": "max" } }

2. 或者：不要发 /new，直接发 /model 重选供应商+模型（该路径会经 completeNewModelSelection 写入干净选择）。

期望修复方向

• 播种与解析两侧统一走 Mu 风格的 provider/model$level 解析（写库前拆掉 $level），或干脆禁止 modelId 携带 $ 后缀入库；
• 与 [Bug] 飞书 Bot 发消息创建任务必现失败：「Bot 无法从目标 Host 解析 Submission 模型」（3.12.3，附根因定位） #697 的建议一致：fallback 落空 / selectionIssue 时给用户可操作提示（如引导 /model），而不是整条消息失败。

---

截图 / 录屏 / 日志 · Screenshots / Recordings / Logs

~/.zcode/v2/logs/2026-10-03.log（已脱敏）：

06:59:40 [bots] provider callback provider=weixin bot=bot-3a02e5bf-… text=/new            ← 重置 draft，重新播种畸形 modelSelection
07:00:02 [bots] provider callback provider=weixin … text=你看下这个视频…（抖音分享）
07:00:02 [bots] provider callback failed … : Bot 无法从目标 Host 解析 Submission 模型
（此后 iLink 每 ~6s 重投递，当日 1.2 万+ 次失败回调）
07:38:17 （修正 bot-state.v3.json 后）provider callback 不再失败
07:38:40 任务 sess_62a8be05-… 创建成功，agent 正常开始运行

关联 issue：#697（同一抛错点、不同根因：本地工作区 + 空 modelSelection）、#862 / #530（iLink sendmessage "prepare failed" 与失败重投风暴）。

[github-actions]

👋 感谢你的反馈，我们已经收到。

• 维护者看到后会尽快回复你。
• 状态保持为 status: 待评估，你可以随时补充信息。
• 信息不全时我们会打上 needs: 更多信息 标签并 @ 你。

---

👋 Thanks — we've received your issue.

• A maintainer will get back to you as soon as we can.
• Status stays at status: 待评估 (Triage); feel free to add context.
• If we need more details, we'll add needs: 更多信息 and ping you.