yaoyao/docs/verification/2026-09-29-model-confirmation.md

普通聊天模型切换确认与 Grok 4.7 验证

问题与修复

普通聊天把 config.set 返回的本地模型确认写入 ChatRouteState.pendingApproval。随后普通聊天 transcript 快照中的 pendingApproval: null 会清除此卡片，但待切换模型仍在本地保留。下一次发送再次要求确认，表现为模型名称已经改变、消息却发送失败。

模型确认现在单独保存为响应式状态，按会话显示，不再被服务端工具审批快照覆盖。确认后正常提交模型设置；取消或重新选择会清理旧确认，过期确认不会误发为工具审批。等待确认期间重复发送不重复请求模型切换。

验证

• 新增回归测试在修复前复现：模型确认经过 transcript 更新后变成 undefined。
• 修复后验证确认保留、确认后发送、无重复模型切换、重新选择清理旧确认，以及与工具审批互不覆盖。
• 65 项聊天、模型、同步和消息失败相关测试通过。
• npm run typecheck 与 npm run build 通过；构建仍有既有的大资源包提示。

模型实际请求

2026-09-29 08:51 左右，通过瑶儿 Profile 使用的 Hermes xAI OAuth 凭据解析器，对同一供应商 Responses 接口发送独立的最小请求，未修改聊天内容或会话模型。

• 请求模型：grok-4.7
• 提示：Reply with exactly OK.
• HTTP 状态：200
• 返回模型：grok-4.7
• 返回状态：completed
• 输出：OK
• 耗时：3.89 秒

本机运行日志也显示问题会话当天成功调用过 Grok 4.7，后续会话实际模型是 Grok 4.6。最小请求证明该账号通道当时可用，不代表已在用户另一台电脑上完成客户端验收。

范围说明

Hermes 的长上下文切换确认默认阈值为 100,000 token，该会话最近一次实际输入约 181,833 token。确认是为了提示切换模型后的缓存失效，并非 Grok 4.7 不可用。费用及长上下文确认规则保持原样。

截图的 1015.9k 不能直接解释为当前上下文超限：当前 UI 在缺少上下文值时会回退到累计用量。此次未改动该显示逻辑。

首次排查完成源码修复与提交后，用户继续反馈卡片自动消失、点击允许无效，随后完成以下部署与验收。

实际部署与浏览器验收

• 运行服务原来是提交 6396efc，尚未包含此次修复。
• 执行 npm run desktop:build，通过 bin/desktop-service-sync.mjs 更新现有 15300 服务。同版本构建先后关系无法自动判断，核对目标后使用更新器的 force: true 覆盖流程，保留更新前数据备份。
• 当前服务构建：af061893a4e6471f06258af10d918b48dd92f722，资源摘要 d6bfeae0acc817a99917b09ab5b0845bf6733d969e5de0693a7fa9480687d3c1。/healthz、/readyz 均成功。
• 在新服务的真实认证浏览器页面中打开原会话并重新加载，选择器与服务器均返回 grok-4.7。
• Hermes 日志确认：用户 08:53:26 发送的“测试”已使用 grok-4.7，08:53:47 完成回复；此次验收没有额外向该会话发送聊天消息。
• 新增 tests/e2e/model-confirmation.spec.ts：在隔离测试服务中渲染完整聊天页面，模拟供应商模型确认响应，经过两次真实 transcript SSE 重连后卡片仍可见；实际点击“允许”发送 confirm_expensive_model: true，随后聊天提交成功。该测试使用假 Gateway，不计入真实供应商调用证据。
• 同一浏览器测试分别加载旧部署 UI 和新 UI：旧 UI 在重连后丢失卡片、测试失败；新 UI 全流程通过。
• 远端已打开的页面需要重新加载才能取得新资源；没有直接操作或验收用户另一台电脑的桌面进程。没有重启 Hermes。