OpenClaw Invalid Beta Flag：定位被拒绝的功能与提供商配置

OpenClaw 的 invalid beta flag 要按“哪个提供商拒绝了哪个 beta、请求头从哪里加入”来修复。 先保存精确错误，确认实际模型与请求地址，再检查显式 anthropic-beta 配置、OpenClaw 自动加入的功能头以及中间代理的注入规则。对于不需要且不受支持的 beta，只移除那一项；对于任务必需的功能，修正功能资格或接口配置，不能靠关闭功能把任务变成“能聊天”。

不要把 beta_features: [] 或 params.context1m: false 当成通用答案。截至 2026 年 10 月 4 日，OpenClaw 的当前 Anthropic 文档已说明：列明的原生 1M 模型不需要旧的 1M beta，退役的 context-1m-2025-08-07 不再发送。修复后，需要分别确认配置校验、Gateway 实际加载和原路线完整响应。下面的操作依据官方文档，本文没有运行你的 OpenClaw、修改账号或执行付费 API 请求。

先确认报错确实指向 beta

在直接 Anthropic API 中，错误 beta 名称或组织不具备相应资格，会返回 HTTP 400 和 invalid_request_error。Anthropic 的 beta headers 文档说明了这些情况，但 400 本身不能证明是 beta 错误；模型名、请求体、工具参数等问题也需要依据各自的错误原文判断。

接收请求的服务可能是 Anthropic、云平台或团队代理，错误的外层格式也可能不同。先找到日志中最早的上游错误，记录下面这些信息：

在 Gateway 实际运行的主机、服务用户下依次检查。把 YOUR_AGENT_ID 换成发生错误的 agent ID：

openclaw --version
openclaw config file
openclaw gateway status
openclaw models status --agent YOUR_AGENT_ID
openclaw doctor
openclaw logs --follow

logs --follow 持续输出，读到相关错误后可用 Ctrl+C 退出。在原来失败的聊天会话里，还要查看：

/model status

agent 的默认模型与会话固定的模型可能不同。不要只查默认值，就认定失败请求一定走这条路线。上述检查没有加模型调用探测参数；它们用于定位，不能代替最终请求验证。首次接入或尚不清楚模型选择关系时，可先查OpenClaw 模型配置指南。

如果日志只写了 invalid beta flag，却没有具体名字，不要从旧教程猜一个。检查相关 provider 的显式 headers，再请代理或服务负责人按请求 ID 核对收到的 beta 名称。普通日志可能隐藏请求头，不能把“日志里看不到”当作“请求没有发送”。核查时保留 beta 名称、地址和请求 ID，遮蔽认证值与私人提示内容。

请求头在哪一层加入？

anthropic-beta 可以包含多个逗号分隔的名称，也可能作为重复请求头发送。只找到其中一个值，并不代表已经看到了完整列表。官方 beta 文档还要求按具体功能使用相应接口，不能把某个独立端点的 beta 直接套到所有 Messages 请求上。

按下表检查注入位置，修复发生在实际加入错误值的那一层：

OpenClaw 自定义 provider 文档说明：非直接 anthropic-messages 路线会抑制隐式 Anthropic beta headers。判断包含 provider 身份与 baseUrl：provider ID 不是标准 anthropic，或者给 anthropic 配置了主机不是公开 api.anthropic.com 的地址，都会影响这项处理。它并不等于“所有代理完全没有 beta”——你仍可以显式配置代理支持的 beta，代理也可能自行加入请求头。

如果当前文档描述应当抑制，但实际请求仍含被拒绝的值，继续区分显式覆盖、代理注入与旧安装版本。不要先把 Anthropic Messages 代理改成 OpenAI 接口：anthropic-messages 与 openai-completions 表示不同请求格式，选择哪一种应由端点真正支持的协议决定。

显式 header：只修改确认有问题的项

先用 openclaw config file 确认活动配置路径，再对自己真正使用的 provider 查询。下面以已存在的 my-proxy 为例；使用前替换为实际 provider ID：

openclaw config get 'models.providers.my-proxy.headers'

当前 config CLI 文档支持带引号的点路径和括号路径。引号尤其适用于 zsh，防止方括号被 shell 当成文件匹配。config get 返回脱敏后的配置快照，它不是 Gateway 对当前运行状态的确认。

如果确认 my-proxy 的 anthropic-beta 只有一个不受支持且不需要的值，并且该头不承载所选功能或认证依赖，可以仅移除这一字段：

openclaw config unset 'models.providers.my-proxy.headers["anthropic-beta"]'
openclaw config validate

不要删除整个 headers 对象，也不要删除 api、baseUrl、认证或模型目录。如果该头包含多个 beta，保留其他受支持且所需的值，只编辑被拒绝的项，再验证配置。一个 beta 字符串中的名称不是独立 JSON 数组成员，不能通过猜测数组下标来删除。

CLI 写入会验证配置，但允许开放参数的字段能通过 schema，并不证明服务商接受该值。unset 找不到对应的已写入路径时可能以状态码 1 退出且没有改动；这不证明错误值已经从实际请求消失。配置为只读或由 Nix 等方式管理时，CLI 也可能拒绝写入，应修改实际管理来源。

修改前记录原值以便回退；修改后按 CLI 给出的 reload/restart 提示检查运行状态。该提示说明预期动作，不是运行时已加载的回执。普通已安装 Gateway 服务若要求重启，可执行：

openclaw gateway restart
openclaw gateway status
openclaw logs --follow

使用容器或其他服务管理方式时，在真实部署环境完成相应的加载动作，不能把宿主机上另一个 Gateway 的重启当成完成。

Direct Anthropic：识别功能，不要误关 1M

直接 api.anthropic.com、API key、OAuth 与 Claude CLI 是不同调用和认证组合。同一个模型名字不能证明它们发送相同 headers。

当前 Anthropic provider 文档列出了直接 API key 路线上自动加入的功能 beta，包括特定模型的思考绑定处理、会话上下文处理和安全拒绝回退；服务端压缩则是显式启用的功能。发现自动加入的 beta 时，应把具体名称、模型、认证和功能放在一起核对。不能在不知道依赖的情况下删除全部 beta 或 OAuth 相关标记。

对于文档中的可选服务端压缩，anthropicServerCompaction: true 会加入 compact-2026-01-12，同时发送压缩所需的 context_management 请求内容。若错误明确拒绝这个 beta，而你暂时不需要服务端压缩，可以关闭相应功能；只删 header 却留下请求内容不构成完整修复。下面仅适用于已有的 anthropic/claude-sonnet-4-6 配置，并且你已经确认这就是失败模型：

openclaw config set 'agents.defaults.models["anthropic/claude-sonnet-4-6"].params.anthropicServerCompaction' false
openclaw config validate

对其他模型使用自己已配置、且文档支持该功能的准确模型引用。如果任务必须使用服务端压缩，停止这条“关闭功能”的临时路径，改查该账号、模型和端点是否支持它。自动加入且没有已文档化关闭方式的功能，则应核对安装版本和提供商支持，向负责对应适配器的一方提交精确错误；不要另造参数。

context1m: false 为什么不能通用修复？

当前文档列明的原生 1M 模型会自动使用对应窗口，其中包括 Opus 4.6、Sonnet 4.6 等支持自适应思考的 Claude 4.x 模型，以及文档列出的 Claude 5 系列模型。对于这些模型，旧 params.context1m: true 是无作用的兼容设置；OpenClaw 不再发送退役的 context-1m-2025-08-07，旧 anthropicBeta 中的同名项也会在请求头解析时丢弃。1M 上下文说明给出了模型范围。

因此，给这些模型改成 context1m: false，既不能解释另一个 beta 为何被拒绝，也不能据此承诺缩小原生窗口。若你确实在最终请求中看到退役的 header，查旧运行进程、显式自定义头和代理注入；当前文档的行为不能证明你安装的版本已具备同样处理。

Claude CLI 的上下文预算有独立规则，API 的 1M 可用性不自动等于 CLI 选择了扩展预算。另外，Extra usage is required for long context requests 的 429 是不同错误，应按实际账号与请求路线查资格或额度；不要继续按 invalid beta flag 删除请求头。

Bedrock、Vertex 与 Claude Platform on AWS 要分别处理

Bedrock 不等于所有模型都使用 Converse。 OpenClaw Bedrock 文档既保留 Converse 配置示例，也说明现代 Claude 模型使用 Messages API Bedrock 端点的情况。应让目标模型匹配实际受支持的接口，不能从一个旧示例推导全目录。专用路线使用 AWS 认证与区域设置，直接 Anthropic API key 不能替代这些条件。

Claude Platform on AWS 对比表明确区分两种 AWS 服务：Claude Platform on AWS 支持标准 anthropic-beta，但有具体功能例外；AWS 运营的 Bedrock 路线不支持这个标准请求头。后者不表示 Bedrock 完全没有对应能力，功能可能通过该接口自己的字段提供。保留既有云端约束，按照所选服务的文档处理，不为了消除一条报错就随意更换数据处理方。

对于 Vertex，Claude 的官方接入文档说明了模型放在请求 URL、请求体使用 anthropic_version: "vertex-2023-10-16" 等差异。它不能被简化成“所有 Vertex beta 都禁止”。同时，OpenClaw Google provider 文档里的 google-vertex 描述的是 Gemini 与 Google Cloud ADC，不能据此构造一份“把 Claude 模型名填进去就能用”的配置。若你通过自定义适配器接入 Claude on Vertex，修复必须以该适配器实际支持的映射为依据。

怎么确认配置已经加载、调用已经恢复？

按照从本地到上游的顺序验证，任何一层通过都不能替代下一层：

1. 配置能通过校验。 openclaw config validate 没有报告阻塞错误，改动仅涉及已确认有问题的项。它不会启动 Gateway，也不能证明上游支持该参数。
2. 正确的 Gateway 加载了改动。 核对活动配置路径、运行主机、服务用户和版本，按提示完成加载；查看 Gateway 状态与相应时段日志。Runtime: running、RPC probe: ok 证明服务及连接检查正常，不证明模型接受请求。
3. 同一路线得到完整响应。 在原来失败的 agent 和会话里核对 /model status，发送一个不含私人数据的短请求，查看完整回复及相应日志。确认请求确实走预期 provider/model，未因失败自动切到其他模型；流式输出必须正常结束，出现首个 token 不算完成。
4. 所需功能仍能工作。 如果原任务依赖工具、思考或压缩等功能，再验证对应的最小任务。关闭功能后只成功返回短文字，不能证明原任务恢复。

验证应在你有权使用的账户与费用范围内完成。本文的命令只做了离线语法检查，未对真实 Gateway 或付费模型做上述恢复验证。

出现下面的结果时，停止重复同一修改，转向相应的问题：

如果需要向 OpenClaw、云服务或代理负责人提交问题，提供版本、失败时间、请求 ID、脱敏的 provider 配置、准确 beta 名称和改动前后错误。缺少最终请求头证据时明确说明缺少什么，避免把猜测写成确定根因。

常见问题

重启 Gateway 或 doctor --fix 能解决吗？

重启可能让正确的新配置生效，doctor 可以帮助发现安装、配置和服务问题，但它们不会让上游接受不支持的 beta。只有具体诊断要求修复本地问题时才采取对应修复；运行 doctor --fix 后 Gateway 正常，仍需要验证原来的模型请求。

没有写 anthropic-beta，为什么也会报错？

beta 可能由 OpenClaw 的特定功能或中间代理加入。先根据失败模型、认证方式与具体名称查Anthropic provider 文档，再比较代理转发前后的 headers。客户端配置没有这个字段，不能证明上游最终收到的请求没有它。

可以删除全部 beta，先让聊天恢复吗？

只有确认这些功能与认证依赖都不需要时，才考虑移除相应配置。更稳妥的排障是只改被拒绝且可选的项；直接删除全部 beta 可能留下不匹配的请求体，或者使原任务必需的功能失效。支持范围以具体 beta、模型、端点与账号为准。官方 beta 说明没有给出适用于全部功能的通用放行规则。

删完 header、配置校验通过，算修复了吗？

还不算。校验通过只说明配置符合本地要求；要确认正确 Gateway 已加载改动，并在原 agent、会话和提供商上得到正常结束的完整响应。若配置了回退，还要排除“原模型仍失败、另一模型成功”的情况。