DSH 模型能力字段丢失
DeepSeek Harness 自定义模型：Catalog Picker 丢失 reasoningEfforts
- 作者
- DeepSeekAgent.io 编辑部
- 发布
- 更新
DeepSeek Harness 的模型目录可以帮助用户快速添加模型，但目录条目并不一定包含自定义 Provider 的全部能力声明。社区在 DSH 0.2.1-rc.3 中发现：通过 Catalog Picker 新增模型时，手工声明的 reasoningEfforts 会被静默丢弃，模型仍能请求成功，编辑器却显示它不支持推理强度。
这类问题最容易被误判为模型或中转服务不支持 Reasoning。实际路由可以正常工作，缺失的是 DSH 本地模型配置中的能力元数据。
丢失发生在首次采用目录条目时
Picker 创建新模型行时，只复制它认识的固定字段，例如：
id与name；contextWindow与maxTokens；- 输入模态等目录能力。
用于展示推理档位的 reasoningEfforts 没有进入固定字段对象，因此首次新增、自定义 Provider、自托管模型和中转路由都可能失去该字段。保存后模型会物化为 reasoning: false，Composer 随之隐藏推理强度选项。
已有模型行通常不会受影响，因为合并逻辑会优先保留 byId 中的旧对象。删除后重新添加，则会再次走目录采用路径并丢失扩展字段。
为什么请求仍然能成功
模型 ID、Base URL、协议和认证信息仍然存在，Provider 可以继续接受请求。reasoningEfforts 主要告诉 DSH UI 和运行时“允许用户选择哪些推理等级”，并不一定是路由连通的必要条件。
因此诊断时要把两个问题分开：
- 模型是否可调用；
- Harness 是否完整认识模型能力。
仅用一次成功回复验证配置，会漏掉 Reasoning、图片输入、工具调用、最大输出与缓存等能力字段。
如何恢复配置
当前可在模型的逐项编辑界面重新声明推理等级，或通过 Profile Patch / YAML 把 reasoningEfforts 写回对应模型。修改后应重新打开模型设置与 Composer，确认推理档位能够选择，再执行一条带 Trace 的请求检查实际参数。
保存前后建议保留结构化 Diff，重点核对：
- 能力数组和自定义扩展字段是否仍在；
- 模型 ID 相同但对象是否被整体替换；
- 删除再添加是否产生不同配置；
- UI 显示能力是否与实际请求参数一致。
Picker 应采用怎样的合并语义
模型目录适合提供默认值，不适合成为覆盖用户配置的完整 Schema。更稳妥的规则是：
- 新增时复制目录字段，同时保留用户已经提供的未知字段；
- 更新目录信息时按字段合并，不整体替换模型对象；
- 删除能力字段需要明确确认；
- 对自定义 Provider 做保存—重开—再保存的 round-trip 测试；
- 把 Reasoning、Vision、Tool Use 和 Cache 作为可独立验证的能力。
如果你正在配置 DeepSeek V4.1 Flash，可配合模型接入 Harness 指南核对模型 ID、图片输入和推理参数。版本升级相关入口变化可参考DSH v0.2.1-rc.3 更新。