DeepSeek Harness 模型认证状态未确认怎么排查？绿黄提示、环境变量与凭据优先级

DeepSeek Harness 模型页的绿色、黄色和“未确认”不是在说“密钥对不对”，而是在说“有没有检测到凭据”。 绿色只代表列出的环境变量存在，黄色代表没检测到，未确认代表读取失败。三者都不验证密钥有效性，也不测试连接。把提示当成“连接成功”来用，就会在真正请求时撞上 MISSING_CREDENTIAL 或 401。

DeepSeek Harness：三态提示分别代表什么

先按提示分诊，再决定是补变量、重填密钥还是查读取失败。 对照如下：（来源）

绿色不是“通过”。官方写得很清楚：检测不验证凭据，也不测试连接。一个空的、过期的或指向错误项目的 key，同样可能让提示变绿。

黄色也不一定是“没配”。如果你用的是已保存凭据，卡片会显示“留空使用已保存凭据”，输入框下不显示状态文字；只有环境后备才显示检测提示。先看占位文字，再看颜色。

DeepSeek Harness：已保存凭据与环境后备

同一个输入框，留空时可能走两条完全不同的路径：复用已保存凭据，或读取环境变量。 区分方法：（来源）

1. 看占位文字 — “留空使用已保存凭据”表示已有保存值；“留空使用环境认证”表示走环境后备。预期：知道留空会发生什么。
2. 看输入框下提示 — 环境后备在留空时会显示检测提示；已保存凭据不显示状态文字。预期：不会把“没提示”误判成“没配置”。
3. 输入非空时 — 两种状态文字都会消失，实际使用你输入的值。预期：保存后页面只拿到脱敏描述符，明文不会回显。

密钥是只写的：保存后页面不会再收到明文，只有脱敏描述符。想检查当前输入，只能用眼睛按钮显示/隐藏；已保存值仍保持只写。

DeepSeek Harness：三类常见误判

认证问题之所以难查，是因为“看起来配了”和“实际可用”之间隔着三层。 三类误判：（来源）

1. 绿色 = 能用 — 变量存在但值为空、过期或属于别的项目。预期：发一次真实请求验证，而不是看颜色。
2. 黄色 = 没配 — 实际上用的是已保存凭据，或变量名不在检测列表里。预期：先看占位文字与 apiKeyEnv。
3. 没有密钥框 = 坏了 — openai-codex 这类没有原生密钥认证的 provider 默认不显示密钥字段，除非 profile 显式指定凭据引用。预期：查 profile 凭据配置，不要反复找输入框。

还有一类：AWS profile、Google 应用默认凭据等由提供商管理的凭据文件不在检查范围内。它们可能完全可用，但模型页不会给绿色提示；反过来，绿色也不代表这些机制被检查过。

DeepSeek Harness：一条最小配置对照

要判断环境后备有没有接上，直接看 profile 里的 apiKeyEnv 与启动环境是否同名。 示例：（来源）

- id: llm-pi-ai
  config:
    providers:
      my-gateway:
        apiKeyEnv: GATEWAY_API_KEY
        api: openai-completions
        baseURL: https://gateway.example/v1

如果这里写的是 GATEWAY_API_KEY，而 shell 里导出的是 GATEWAY_KEY，检测就会是黄色，请求则报 MISSING_CREDENTIAL。变量名是精确匹配，不是模糊匹配。

DeepSeek Harness：排查步骤

按“页面 → 环境 → 文件 → 请求”的顺序查，避免一上来就改配置文件。 步骤：（来源）

1. 回模型页确认 provider — 看 provider id 与模型名是否正确。预期：不是把 key 填到了另一个 provider。
2. 确认占位文字 — 判断当前走已保存凭据还是环境后备。预期：知道该查文件还是查环境变量。
3. 在启动环境里查变量 — env | grep -i <变量名>，注意是启动 dsh 的那个环境。预期：变量存在且非空。
4. 发一次真实请求 — 用当前模型发一条最小消息。预期：成功即通过；失败看是 MISSING_CREDENTIAL、401 还是其他错误。

如果是 MISSING_CREDENTIAL，优先重填密钥或补齐 apiKeyEnv 指向的变量；如果是 401，说明凭据被读到了但服务端拒绝，重点查密钥归属与权限，而不是继续找“为什么没检测到”。

DeepSeek Harness：三种凭据来源怎么选

已保存凭据、环境变量、profile 凭据引用，各有适用场景，不要混着用。 对比如下：（来源）

1. 已保存凭据 — 适合个人机器，界面填一次即写入 .credentials.yaml。代价：文件是明文敏感文件，不要提交。
2. 环境变量 — 适合容器与 CI，启动时注入。代价：变量名必须与 apiKeyEnv 一致，且要在启动环境里可见。
3. profile 凭据引用 — 适合需要显式控制凭据来源的 provider。代价：配置更绕，排查时要同时看 profile 与凭据文件。

一个实用规则：同一 provider 只保留一种来源。既保存了密钥又导出了环境变量，出问题时很难判断实际用了哪一个。

报错对照表

同一个“认证失败”现象，可能对应完全不同的错误码与处理路径。 对照如下：

先把错误码与提示颜色对上，再决定是改配置文件还是查服务端；不要看到“认证”两个字就重装。

如果同一 provider 在不同机器上表现不同，优先比较启动环境里的变量与 DSH_HOME，而不是比较界面截图。很多“时好时坏”其实是两台机器用了不同的凭据来源。

DeepSeek Harness 常见问题

Q：绿色提示下请求 401，是 DSH 的问题吗？ 不是。401 是服务端拒绝，说明凭据被读到了但无效或权限不足；查密钥归属、额度和 provider 侧配置。

Q：改了 .credentials.yaml 需要重启吗？ 不建议手改。界面保存后模型变更在下一次请求生效；手改容易破坏格式或与 settings 里的引用不一致。

Q：为什么换了 profile 后认证就失效了？ 凭据与 profile 的配置层是绑定的。换 profile 后，apiKeyEnv 或凭据引用可能指向另一套配置；回到该 profile 的模型页重新确认。

一句话收束： 认证提示只回答“检测到了什么”，不回答“能不能用”；绿色看请求结果，黄色看占位文字，未确认看读取环境。