先分清“没读到 Key”和“Key 无效”
Kimi Code 0.33/0.34 的 kimi -p 可能直接报：
error: failed to run prompt: provider oai has no credential configured公开复现显示，同一个 provider、模型和环境变量，在 0.32 能发出请求；升级到 0.33/0.34 后，v2 readiness gate 看不到 process.env 中的 Key。把 Key 写入 config.toml 后，请求又能到达 provider。
这和 401 不一样：401 说明请求已经发出，只是凭据不被接受；no credential configured 说明请求还没走到 provider。
用无效测试 Key 做版本对照
不要把真实 Key 写入配置文件。准备一个隔离 HOME、一个 OpenAI-compatible provider 和故意无效的测试值：
export OPENAI_API_KEY=not-a-real-key
kimi -p "Reply with exactly PONG"命令中的 kimi 请按实际安装路径执行。0.32 若能到达 provider，应返回 401；0.33/0.34 若仍报 no credential configured，就复现了 readiness gate 回归。
CI 里不要用明文配置绕过
把 Key 写进 $KIMI_CODE_HOME/config.toml 能绕过旧版本的检查，但会让凭据落盘。临时措施应优先使用受控的 CI secret 文件挂载、短生命周期 Key 或回退到已验证版本，并限制工作区权限。
如果必须在当前版本运行，先检查是否能通过 provider 的 env 配置显式声明变量名，再用一次无害请求确认请求已到达 provider。不要在日志中打印环境变量值。
成功标准
成功标准是非交互模式能读取进程环境变量并发出请求；无效测试 Key 返回 401 而不是“没有凭据”；CI 日志只出现 provider、模型和状态码，不出现 Key 内容。
如果交互 TUI 能用、-p 不能用，优先比较 engine 和 readiness gate，不要重复修改 endpoint、模型名或权限。