前言¶
在 DeepSeek Harness（DSH）里，你在界面或配置里选定的模型 id，与中转或上游在 HTTP 响应里声明的模型名，并不总是一致。常见情况是请求 mimo-v2.6-pro，上游回的是 xiaomi/mimo-v2.6-pro——此前对话界面不会把这类差异摆出来，排查路由、中转或计费问题时只能翻日志或抓包。
下面介绍社区插件 dsh-upstream-model-audit（维护者 QuanhuZeYu，分类：客户端）。它在每一条助手消息下方列出：本次 DSH 路由选定的请求模型、上游响应里声明的模型名，以及两者差异的客观分类；必要时还会补充 host 侧旁路观察到的「实际发出」模型名、服务档位、上游多次声明不一致等事实。
这是什么¶
dsh-upstream-model-audit 是一个 DSH web 插件：在每次模型调用（step）对应的助手消息下，显式展示上游实际返回/声明的模型名，并与请求侧模型名对照。
- 仓库：QuanhuZeYu/dsh-upstream-model-audit
- 社区目录：SkillHub 插件页
- 许可证：MIT（见仓库 README）
- 当前 package 版本：0.3.0（见仓库
package.json）
插件分 host 半（Node：fetch 旁路观察 + 补写 replay 元数据）与 浏览器半（读取 durable 事件并渲染）。展示路径不新增事件类型，仍走 DSH 已有的 assistant/message 与 replayState。
核心功能¶
界面展示¶
每个 step（一次模型调用）一行，紧跟该步的助手消息。两个名字原样显示：不归一化、不剥后缀（-latest、日期快照都保留）、不判定严重性。
差异只做客观分类：
- 仅厂商前缀不同
- 模型名不同
逐字相同则不显示（没有可呈现的差异事实）。上游未声明模型名时不显示（不猜、不补）。
示例形态（来自 README）：
（助手消息）
上游返回 xiaomi/mimo-v2.6-pro 请求 mimo-v2.6-pro · 仅厂商前缀不同
当 host 半旁路观察到额外事实时，可能多一行附加信息：
- 实际发出的模型名（与请求名不同才显示）
- 档位（OpenAI
service_tier归一值 / Anthropicusage.speed） - 上游先后声明过的多个名字（上游自相矛盾时照实列出，不挑一个「正确」的）
数据字段¶
展示主要使用 durable assistant/message 事件中的字段：
| 字段 | 含义 |
|---|---|
message.source.model |
DSH 路由选定、本次请求的模型 id |
message.source.replayState.response.responseModel |
上游响应声明的模型名 |
各通道对 responseModel 的写入并不完整（见下节）。插件在不改 DSH 源码的前提下，用 host 半旁路补全缺失字段，补写后的值仍由 DSH 持久化，浏览器半继续读 replayState.response.responseModel。
host 半旁路补全（概要）¶
- fetch 观察点：仅在本插件建立的调用作用域内克隆响应体（
Response.clone()），按与 sub2api 相近的语义解析 SSE / JSON 帧；观察失败、超时、格式不认识时静默降级，不影响模型调用。 - 观察内容：上游声明的模型名、服务档位、请求体里实际发出的模型名、响应体形状；必要时读响应头（
x-upstream-model/openai-model/x-model/upstream-model）等兜底。 llm/stream中间件：在finishchunk 上只在缺失时补写response.responseModel与response.upstreamAudit；原生值永远优先。- 清理：调用结束或中止时取消旁路读取，避免悬挂的 tee 分支。
不变量：观察失败或非 SSE/JSON 响应一律静默降级，绝不影响模型调用。
安装与启用¶
DSH 生态里插件通过 CLI 安装；本插件面向 web profile。官方安装命令如下：
dsh plugin --profile web add github:QuanhuZeYu/dsh-upstream-model-audit
装好后重启一次 DSH。README 说明 host 半要在 Node 进程里装观察点，热重载不覆盖它；之后改配置或刷新页面即可看到界面效果。
插件以当前 DSH 进程权限运行。安装前建议在 GitHub 上阅读源码与 MIT 许可证，确认符合你的安全与合规要求。
典型用法与显示规则¶
安装并重启后，正常使用 DSH 对话即可：无需额外配置项（资料中未列出独立配置文件字段）。
当某次 step 的请求模型与上游声明不一致时，对应助手消息下方会出现一行审计信息；完全一致或上游未声明 model 时，该行不出现。
需要理解的一点：覆盖率取决于通道与 replay 元数据。README 给出的适配情况包括：
| 通道 | 原生是否有 responseModel |
说明 |
|---|---|---|
openai-completions |
仅在响应名 ≠ 请求名时 | pi-ai 只在名字不同时写入 |
openai-responses / azure / codex |
从不 | 这些分支不写该字段 |
anthropic-messages |
仅在上游换了名字时 | replay 层按不等条件取值 |
自研 deepseek-messages |
从不 | envelope 里只有请求模型 |
旁路观察对走 globalThis.fetch 的 provider 有效；没有 replayState 的调用（如中断、未正常结束）无法补写，插件不伪造载体。
适用场景与注意¶
适合谁
- 使用中转、聚合或多厂商路由，需要确认「界面选的模型」与「上游回写的模型」是否一致
- 排查前缀差异（如厂商 slug）、模型名被改写、或上游多次声明不一致
- 需要对照 OpenAI / Anthropic 等服务档位字段时
已知边界（摘自 README）
- 必须重启一次 DSH 后 host 观察点才生效
- 原生 Trajectory 标签页不显示这些记录
- 若上游或中转把响应 model 改写成请求名，两侧名字相同，插件只对 DSH 侧可见事实负责
- 节点锚点
anchorSeq = 消息 seq + 0.01依赖 ui-chat 取 assistant 消息 seq 的语义，DSH 大版本升级后需复查
社区目录 SkillHub 与 GitHub 仓库由社区维护，与 DeepSeek / 幻方无官方从属关系；星标与版本以各站点当时展示为准。
结尾¶
dsh-upstream-model-audit 把「上游实际返回的模型名」从日志里搬到每条助手消息下方，并尽量通过旁路观察补全 pi-ai 未写入的 responseModel，对调试路由与中转行为很实用。安装命令见上文；细节与开发说明见 GitHub README，入口页见 SkillHub 目录。
