跳转至

Provider 与路由修复

检查项 2b-2g 涵盖提供商覆盖、浏览器和 Chrome MCP 就绪性、OAuth TLS 前置条件以及路由清理。

检查项 2b-2g

2b. OpenCode 提供商覆盖

如果你在已安装并启用匹配的官方外部插件的情况下手动添加了 models.providers.opencode、opencode-zen 或 opencode-go,它会覆盖该插件提供的目录。这可能会将模型强制路由到错误的 API 或将成本归零。Doctor 会发出警告,以便你可以移除覆盖并恢复按模型的 API 路由和成本。如果没有匹配的插件,该条目仍然是有效的独立自定义提供商。

2c. 浏览器迁移和 Chrome MCP 就绪性

如果扩展驱动程序配置文件仍包含已退役的中继 cdpUrl,Doctor 会移除该 URL,同时保留 driver: "extension";当前扩展中继拥有自己的端点。Doctor 还会移除已退役的 browser.relayBindHost 设置。

当 browser.extensionRelay.allowLegacyAuth 启用时,Doctor 会发出警告。请将配对的 Chrome 扩展和外部 CDP 客户端升级到 Browser Relay Authentication v2,然后将该标志设置为 false。V2 客户端不会降级到旧版认证。

Doctor 不会检查个人浏览器配置文件的可选扩展就绪性或 cookie 导入可用性。它会将可导入的 cookie 数据库数量报告为不可用,而不是零。当存在稳定的 Chrome 扩展副本时,Doctor 会将其原生引导状态报告为未检查;openclaw doctor --fix 会跳过原生主机注册修复。

在托管 Chrome 的机器上,运行 openclaw browser extension status --json 以显式检查注册状态;这可能会请求浏览器配置文件访问权限。如果升级留下了过时的原生主机目标,请运行 openclaw browser extension install --no-store 通过显式安装器进行修复,而无需请求 Store 安装。安装器拒绝覆盖同名的外部清单或启动器。状态可以区分已请求的安装、Chrome 批准和原生主机注册健康状态;但它不能证明存在实时的中继连接。

对于初始设置,请运行 openclaw browser extension install。在 macOS 上,这还会请求在 Google Chrome 中进行官方 Store 安装;重新打开 Chrome,并在提示时批准或启用 OpenClaw。其他浏览器和平台需要手动进行 Store 安装。解压后的稳定路径仍然是开发备用方案,可使用 openclaw browser extension install --no-store 进行安装。显式 cookie 导入仍需要单独的同意。

当你使用 defaultProfile: "user" 或配置的 existing-session 配置文件时,Doctor 还会审计主机本地的 Chrome MCP 路径:

  • 检查默认自动连接配置文件所在主机上是否安装了 Google Chrome
  • 检查检测到的 Chrome 版本,并在低于 Chrome 144 时发出警告
  • 提醒你在浏览器检查页面中启用远程调试(例如 chrome://inspect/#remote-debugging、brave://inspect/#remote-debugging 或 edge://inspect/#remote-debugging)

Doctor 无法替你启用 Chrome 侧的设置。主机本地 Chrome MCP 仍要求网关/节点主机上运行本地的 Chromium 内核浏览器 144+,并启用远程调试,且已在浏览器中批准首次附加同意提示。

此处的就绪性仅涵盖本地附加的前置条件。Existing-session 保持当前 Chrome MCP 路由限制;高级路由如 responsebody、PDF 导出、下载拦截和批量操作仍需要受管浏览器或原始 CDP 配置文件。此检查不适用于 Docker、沙箱、远程浏览器或其他无头流程,这些流程继续使用原始 CDP。

2d. OAuth TLS 前置条件

当配置了 OpenAI Codex OAuth 配置文件时,Doctor 会探测 OpenAI 授权端点,以验证本地 Node/OpenSSL TLS 栈能否验证证书链。如果探测因证书错误而失败(例如 UNABLE_TO_GET_ISSUER_CERT_LOCALLY、证书过期或自签名证书),Doctor 会打印特定于平台的修复指南。在装有 Homebrew Node 的 macOS 上,修复方法通常是 brew postinstall ca-certificates。使用 --deep 时,即使网关运行正常,也会执行探测。

2e. Codex OAuth 提供商覆盖

如果你之前在 models.providers.openai-codex 下添加了旧版 OpenAI 传输设置,它们可能会遮蔽内置的 Codex OAuth 提供商路径。当 Doctor 在 Codex OAuth 旁边看到这些旧的传输设置时,它会发出警告,以便你可以移除或重写过时的传输覆盖并恢复当前的路由行为。自定义代理和仅标头覆盖仍然受支持,不会触发此警告,但这些自定义的请求路由不符合隐式 Codex 选择的条件。

2f. Codex 路由修复

Doctor 会检查旧版 openai-codex/* 模型引用。原生 Codex 框架路由使用规范的 openai/* 模型引用,但仅凭前缀绝不会选择 Codex。当运行时策略未设置或为 auto 时,只有精确的官方 HTTPS Platform Responses 或 ChatGPT Responses 路由且没有自定义请求覆盖时才符合条件。请参阅 OpenAI 隐式代理运行时。

在 --fix / --repair 模式下,Doctor 会重写受影响的默认代理和按代理引用,包括主要模型、回退模型、图像/视频生成模型、心跳/子代理/压缩覆盖、钩子、渠道模型覆盖以及过时的持久化会话路由状态:

  • openai-codex/gpt-* 变为 openai/gpt-*。
  • Codex 意图会移动到提供商/模型作用域的 agentRuntime.id: "codex" 条目,用于修复后的代理模型引用。
  • 过时的整个代理运行时配置和持久化会话运行时固定项会被移除,因为运行时选择是提供商/模型作用域的。
  • 现有的提供商/模型运行时策略会被保留,除非修复后的旧版模型引用需要 Codex 路由来保持旧的认证路径。
  • 现有的模型回退列表会被保留,其中的旧版条目会被重写;复制的按模型设置会从旧键移动到规范的 openai/* 键。
  • 持久化会话的 modelProvider/providerOverride、model/modelOverride、回退通知和认证配置文件固定项会在所有已发现的代理会话存储中进行修复。
  • Doctor 还会单独将过时的 agentRuntime.id: "codex-cli" 固定项(一个不同的旧版运行时 ID)修复为 "codex",涉及 agents.defaults、agents.entries.* 和 models.providers.* 模型条目。
  • /codex ... 表示“从聊天中控制或绑定原生 Codex 对话”。
  • /acp ... 或 runtime: "acp" 表示“使用外部 ACP/acpx 适配器”。
2g. 会话路由清理

Doctor 还会扫描已发现的智能体会话存储,查找您在将配置的模型或运行时从插件拥有的路由(如 Codex)移走后遗留的自动创建路由状态。

当所属路由不再配置时,openclaw doctor --fix 可以清除自动创建的过期状态,例如 modelOverrideSource: "auto" 模型固定、运行时模型元数据、固定的 harness ID、CLI 会话绑定以及自动 auth-profile 覆盖。显式的用户选择或旧版会话模型选择会被报告以供人工审查,并且保持原样;当不再打算使用该路由时,可使用 /model ...、/new 切换,或重置会话。

本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 cl/openclaw