自托管 Skyvern 的容器日志出现 LLM 认证错误怎么排查【免费下载链接】skyvernAutomate browser based workflows with AI项目地址: https://gitcode.com/GitHub_Trending/sk/skyvern用 Docker Compose 自托管 Skyvern 后运行任务时容器日志里出现 LLM 认证authentication相关错误或者 skyvern 容器反复重启、起不来最常见的根因就是.env里 LLM 提供商的 API key 配置有问题。Skyvern 每个任务步骤会发起多次 LLM 调用截图分析、动作规划、结果提取认证不过就没有任何一步能执行所以这类错误必须优先排查。本文针对 Docker Compose 部署的自托管环境给出从定位日志到修复配置的完整排查路径Kubernetes 部署在文末单独说明。第一步在日志里定位 LLM 相关的错误先查看 skyvern 服务的日志# 只看 skyvern 后端服务 docker compose logs skyvern # 或持续跟踪所有服务的日志 docker compose logs -f文档把Missing or invalid LLM API key: look for LLM-related errors in logs列为容器立即退出Container exits immediately的常见原因之一也就是说如果docker compose ps显示 skyvern 服务不健康或反复重启先查日志里有没有 LLM 相关的报错行再决定往哪个方向修。注意区分两类不同的认证错误LLM 认证错误日志里指向 OpenAI、Anthropic、Azure 等 LLM 提供商的鉴权失败对应本文要处理的问题配置在.env的 LLM 变量里。Skyvern 自身 API key 错误调用 API 时返回 403Invalid credentials 或 Could not validate credentials这是 Skyvern 自己的x-api-key来自.skyvern/credentials.toml的问题与 LLM key 无关按 Docker Setup 的 Troubleshooting 一节处理即可。第二步核对 API key 配置官方 LLM Configuration 文档在 Troubleshooting 一节中针对Container logs show authentication errors容器日志出现认证错误给出的检查项是确认 key 设置正确没有多余空白字符whitespace——.env里 key 前后多出的空格、换行都会导致认证失败确认 key没有过期或被吊销expired or revoked必要时去对应提供商控制台重新生成如果是 Azure确认AZURE_API_BASE是包含https://的完整 URL。不同提供商对应的.env配置各不相同修改前对照下表确认自己的 provider 三件套启用开关、key 变量、LLM_KEY齐全Provider启用开关Key 变量LLM_KEY示例OpenAIENABLE_OPENAItrueOPENAI_API_KEYOPENAI_GPT5_5AnthropicENABLE_ANTHROPICtrueANTHROPIC_API_KEYANTHROPIC_CLAUDE4.7_OPUSAzure OpenAIENABLE_AZUREtrueAZURE_API_KEY外加AZURE_DEPLOYMENT、AZURE_API_BASE、AZURE_API_VERSIONAZURE_OPENAIGemini APIENABLE_GEMINItrueGEMINI_API_KEYGEMINI_2.5_PROVertex AIENABLE_VERTEX_AItrue服务账号GOOGLE_APPLICATION_CREDENTIALS指向 JSON 文件VERTEX_GEMINI_3_PROAWS BedrockENABLE_BEDROCKtrueAWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEYIAM 实例上可免 keyBEDROCK_ANTHROPIC_CLAUDE4.7_OPUS_INFERENCE_PROFILEOllamaENABLE_OLLAMAtrue无本地服务OLLAMA例如 OpenAI 的最小配置ENABLE_OPENAItrue OPENAI_API_KEYsk-... LLM_KEYOPENAI_GPT5_5LLM_KEY 与提供商不匹配时先确认这一点如果日志报的不是标准认证失败而是LLM caller not found说明配置的LLM_KEY没有匹配到任何已启用的提供商。文档给出的核对顺序是提供商已启用如ENABLE_OPENAItrueLLM_KEY的值与受支持的模型名完全一致模型名区分大小写是OPENAI_GPT5_5不是openai_gpt5_5。模型名完整列表在 LLM Configuration 文档各提供商的 Available models 表中。走 LiteLLM 等代理时的 401如果 LLM 请求经过 LiteLLM 或自建的 OpenAI 兼容端点ENABLE_OPENAI_COMPATIBLEtrue代理侧出现 401 时Local LLMs 文档给出的解法是把OPENAI_COMPATIBLE_API_KEY设置为代理接受的值。ENABLE_OPENAI_COMPATIBLEtrue OPENAI_COMPATIBLE_MODEL_NAMEgemma4 OPENAI_COMPATIBLE_API_KEYsk-test OPENAI_COMPATIBLE_API_BASEhttp://localhost:4000/v1 LLM_KEYOPENAI_COMPATIBLE该文档还提醒OPENAI_COMPATIBLE_API_BASE必须以/v1结尾URL 不对也会导致连接失败。第三步重启并验证.env修改后重启 skyvern 服务使配置生效docker compose restart skyvern然后做两项验证所有服务健康docker compose ps三个服务postgres、skyvern、skyvern-ui都应在 STATUS 列显示healthy。API 可用——用.skyvern/credentials.toml里的 key 调一次列表接口全新安装应返回空数组curl -s http://localhost:8000/v1/workflows \ -H x-api-key: YOUR_API_KEY_HERE如果认证错误消除后任务能正常跑起来排查到此结束仍失败则回到第一步重新读日志确认报错是认证问题还是其他问题如 Context window exceeded那是页面内容超出模型上下文属于另一类问题。Kubernetes 部署时的对应操作如果是按 Kubernetes 部署文档 部署的Backend crashes on startup后端启动即崩溃的常见原因中同样列出了Invalid LLM API key查看日志的方式是kubectl logs -n skyvern deployment/skyvern-backend定位到 LLM key 问题后修正 backend secrets 中对应的环境变量操作路径与 Docker Compose 一致。边界说明本文只覆盖 LLM 提供商侧的认证错误。Skyvern 自身 API 的 403key 截断、来自其他安装环境等走 Docker Setup Troubleshooting 中的API returns 403条目处理。响应变慢不等于认证错误文档说明 LLM 调用通常需要 2–10 秒更长时间多指向网络延迟、提供商限流或本地算力不足Ollama不属于认证排查范围。修改.env只需docker compose restart skyverndocker compose down会停掉全部服务Reset everything含-v删卷会清空所有数据排查期间不要执行。【免费下载链接】skyvernAutomate browser based workflows with AI项目地址: https://gitcode.com/GitHub_Trending/sk/skyvern创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考