Activity

1. github-actions

   added

   priority: P2普通优先级普通优先级

   on Oct 6, 2026
2. github-actions commented on Oct 6, 2026

   

   github-actionsBot

   on Oct 6, 2026 – with GitHub Actions

   More 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.
3. tarazum commented on Oct 6, 2026

   

   tarazum

   on Oct 6, 2026

   More actions

   同一缺陷在 Telegram 桥同样复现 + 代码级根因定位（3.14.4.7912, Windows 26200）

   我的环境：ZCode Desktop 3.14.4.7912（win32 10.0.26200），Telegram 机器人，GLM individual coding plan + offpeak idle plan 两个账号计划同时连接。与楼上 A/C 项完全同源：/new 之后第一条消息即报「Bot 无法从目标 Host 解析 Submission 模型」。

   复现时间线（本机日志）

   • 21:58 活动任务中发消息 → 正常（resume 路径，task index 回填的模型是 account:zai-individual-coding-plan/GLM-5.3 + thoughtLevel:"max"，不带 $ 后缀，可解析）
   • 22:01:30 发送 /new → 231ms 后 bot-state.v3.json 的 draftOptions.modelSelection 被写为：

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

   • 22:01:58 起第一条普通消息 → 抛错，且同一 update 每 ~5.3 秒无限重投（见缺陷 3）

   根因（反编译 app.asar 定位，附函数名）

   缺陷 1：/new 把组合式模型 id 写进 draftOptions。
   消息处理器里 buildActiveTaskDraftOptions（注册名 ct）在 /new 时从活动任务读取当前模型字符串 provider/GLM-5.3$max，经 parseBotModelOptionValue（hH）解析后 $max 后缀残留在 modelId 里，而模型注册表键是 GLM-5.3（无后缀）。于是 draft 阶段：

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

   getView 对该 selection 返回 selectionIssue（模型注册表中不存在 GLM-5.3$max）→ 必抛。这解释了楼上「切到 GLM-5.3-Flash 后恢复」——换模型后走的是可解析的 id。另注：buildInitializedDraftOptions（He）本身不写 modelSelection，所以只有带活动任务的 /new 会投毒。

   缺陷 2（多账号计划用户叠加触发）：getView 的 account-plan 分支要求"恰好一个 current"。
   getView 实现（注册名 Nk）开头：

   if (n === "account-plan") {
     let l = Object.entries(e.accountStates ?? {})
       .filter(([u,p]) => p.current === !0 && e.classifyProvider(u) === "account-plan");
     if (l.length !== 1)
       return { effectiveSelection: null, selectionIssue: "account-connection-unavailable" };
     r = l[0][0];
   }

   current 缺省即视为 true（!== !1）。individual + offpeak idle 两个账号计划同时连接时 l.length === 2 → 任何显式 modelSelection（哪怕 id 正确）都被拒。/model 选择同样写入组合式 id，同样逃不过。

   缺陷 3（Telegram 特有）：失败的 callback 不推进 telegramOffset，无 dead-letter。
   抛错后 offset 停留在失败 update 上，getUpdates 每 ~5.3s 重新返回同一条消息，机器人每次都把错误文本回发到聊天——用户侧表现为每 5 秒一条错误刷屏，无限持续，只能进客户端手动停用机器人才能止血。远程无任何停止手段。

   附带小缺陷： 手工把 bot-state.v3.json 的 modelSelection 置为 null 会让整个 Bots 设置面板挂掉（Zod expected object, received null）——schema 是 modelSelection: <object>.optional()，不接受 null；本地止血只能整键删除。

   临时缓解

   退出客户端 → 删除 bot-state.v3.json 中 draftOptions.modelSelection 整个键 → 重启 → 重新启用机器人；在修复前不要从机器人发 /new（每次都会重新投毒）。

   建议修复方向

   1. parseBotModelOptionValue 剥离 $<level> 后缀进 options.reasoningLevel，modelId 只留基础 id；
   2. Nk 的 account-plan 分支改为"优先 selection.providerId 本身，无法匹配时才要求唯一 current"，或允许 selection 显式指定计划；
   3. callback 失败也推进 offset / 加入重试上限（dead-letter），避免错误风暴。