Kimi K3 错误与失败模式

错误长什么样

错误以单个 error 对象返回，带 message、type 和 code 三个字段：

{
  "error": {
    "message": "API key is missing or invalid",
    "type": "invalid_authentication_error",
    "code": null
  }
}

不要用 code 做分支判断。它可以为 null，而且在我们对月之暗面（Moonshot AI）官方直连触发的每一个错误里，它干脆整个缺失。每次都有值的字段是 type——按它来匹配。

走网关时，下面的鉴权错误和「模型不存在」响应体不会逐字节一致。错误的 key 会被网关自己的鉴权层直接拒掉，根本到不了月之暗面，所以你拿到的是网关的措辞，不是月之暗面的。但症状、成因和修法两边都成立。本页的行为层结论——空 content 陷阱、不做校验的参数——是模型本身的属性，在任何承载 K3 的地方都适用。

{
  "error": {
    "message": "Invalid Authentication",
    "type": "invalid_authentication_error"
  }
}

错误一览，按症状分

{"error": {
  "message": "Invalid Authentication",
  "type": "invalid_authentication_error"
}}

{"error": {
  "message": "Not found the model kimi-k3-chat
              or Permission denied",
  "type": "resource_not_found_error"
}}

{"error": {
  "message": "Invalid request: messages
              must not be empty",
  "type": "invalid_request_error"
}}

{"error": {
  "message": "Rate limit exceeded",
  "type": "...",
  "code": null
}}

不报错的失败

这一类才值得刻进脑子里。K3 不校验你的参数——我们发现两种明显不合法的请求，都返回了干干净净的 HTTP 200：

教训不止于这两条：K3 返回 200，不代表它按你的意图理解了请求。如果你指望某个参数改变行为，就去验证行为真的变了——不要因为没报错就默认生效。再叠上空 content 陷阱，规则就一句话：断言响应内容，别断言状态码。

上线前自检清单

1. 响应里的 model 回显为 kimi-k3——没有被网关静默换掉。
2. finish_reason == "stop"，而不是 "length"。
3. content 非空。
4. usage.total_tokens 非零，并且把 reasoning_tokens 记进日志。
5. 会碰长上下文的话，客户端超时按分钟设。
6. 所有你依赖的参数，都用观察到的行为验证过，而不是靠一个 200。

值得写进代码的那条断言，在 API 指南里。