Claude Code 接第三方 API 总报 400？检查 Artifact schema 和客户端版本

如果 Claude Code 更新后每轮请求都失败，错误又提到 Artifact 工具 input schema 中的无效正则表达式，先查客户端版本，不必立刻更换 Key 或模型。官方仓库中的用户报告 #92969描述了 2.1.265 和 2.1.266 中的回归：含 Unicode 属性转义的 schema pattern 被严格校验器拒绝。

这是特定的历史兼容性故障，不是所有 HTTP 400 的解释，也不应写成当前所有客户端都尚未修复的问题。Claude Code 官方更新日志在 2.1.268 中记录了第三方端点的相关修复。

先匹配报错，再套用修复

出现以下组合时值得检查本问题：故障始于受影响的客户端更新；请求走第三方 Anthropic 兼容端点；错误指向 Artifact 工具 schema，或提示某个 pattern “not a regex”。不同校验器的完整措辞可能不同。

schema 被拒绝发生在模型回答任务之前。因此，把复杂编程提示词改成问候语，错误可能仍不变。这不能证明模型坏了，问题可能位于请求携带的工具定义中。

这张表帮助选择排查方向，不能自动确诊。保存脱敏后的完整错误，对照原始 issue 的字段路径。不要因为一次请求失败就删除无关保护，或重写全部工具 schema。

确认真正运行的客户端版本

先查看命令输出：

claude --version

终端、IDE 和后台 worker 可能用着不同安装，各执行环境都要检查。按原有安装方式更新后，重启相关客户端或 worker，再查一次版本。

2.1.268 是包含该修复的历史版本，不是要求把较新版本降级到这里。采用组织支持的当前版本；如果环境有意锁定在受影响版本，应把锁定配置纳入诊断，按正常升级流程处理。

更新必须落实到构造请求的那个客户端。更新无关的本地终端，不会改变另一处部署的 worker。记录失败请求与复测成功请求分别由哪个进程发出。

受影响客户端的完整恢复步骤

先保存失败请求的 UTC 时间、完整报错和客户端版本。如果任务会自动重试，通过正常控制暂停它；反复提交同一份被拒绝的 schema 无助于定位原因。保留工作目录与会话，删除它们会丢失线索，也不是上游记录的修复方法。

在 macOS 或 Linux 中，下面的命令用于查看可执行文件位置和安装状态，不会发送模型请求：

command -v claude
claude --version
claude doctor

Windows PowerShell 可以用 Get-Command claude 查看程序位置，再运行同样的版本与 doctor 命令。把路径与实际出错的环境对照：终端更新后，IDE 可能仍保留旧进程；远程开发容器也可能有自己的安装和固定版本。

用管理这份安装的方式更新。官方安装指南 对适用的自主管理安装提供 claude update；Homebrew 用户应更新自己安装的 cask，例如 brew upgrade claude-code。组织托管的安装走既定更新流程。不要接连使用多个包管理器，否则可能新装了第二份客户端，原先出错的进程却没有变化。

更新结束后关闭并重启相关客户端，在同一环境重新执行 claude --version 并记录结果。如果下一次请求来自另一个程序，仅看到“更新完成”还不够。目标是包含 2.1.268 修复的受支持版本，而不是特意装回该历史版本。

先复测一个请求，再恢复长任务

第一次复测保持供应商和模型不变，用无副作用的小任务确认原来的 schema 拒绝是否还存在。更新后成功，可以支持对该配置的诊断，但不能据此认证供应商的全部功能。

随后验证真正需要的工具工作流，因为纯文本回复不能覆盖同样的工具序列。保存客户端版本、供应商路由、请求时间、脱敏错误与请求 ID。当前客户端仍报 schema 错误时，应比较新的字段路径，不要默认它就是原来的回归。

本文依据上游问题记录与发布日志，没有声称在 Ofox 生产环境复现，也没有跨网关成功率实测。

分两步验收，每一步回答不同问题

先在相同配置下请求一段短文本。这会发送模型请求，可能消耗账户额度或产生供应商费用。可以使用下面的诊断提示词；保留固定英文返回值便于逐字比较：

Reply with exactly: connection check
Do not modify files or run commands.

预期是普通助手响应，而不是原来的 Artifact schema 拒绝。逐字返回测试的是基本响应链，不代表代码能力。如果出现新错误，另行保存；错误变化可能说明请求进入了不同的校验阶段，不一定代表全部修好。

再在临时目录放一个无敏感内容的 sample.txt，请客户端只读取并报告第一行，不修改文件。对照本地文件检查返回值，同时查看工具执行结果。如果正常配置包含内置 Artifact 定义，复测时保留它；把它禁用就不再是同一种请求构造。

这些是建议执行的检查，不是本文账户的实测结果。只有原 schema 拒绝消失、所需工具交换也完成，才恢复长任务。不要为了验证连通性，让客户端修改或部署真实项目。

“兼容 Anthropic”还不足以描述这个问题

兼容可能涵盖鉴权、消息结构和流式响应，但支持的 JSON Schema 特性仍有差别。上游记录讨论的是校验器如何处理内置工具定义中的 pattern，与模型理解代码的能力不是一回事。

不要盲目修改生成的正则，或在生产环境关闭校验。这样可能放过不应接受的值，也可能掩盖其他兼容性问题。优先采用上游客户端修复；仍有问题时，向供应商提交已脱敏的最小复现样例。

报告只需带上能展示被拒绝结构的最小 schema 片段，不必提供完整私有项目提示词。供应商排查校验器不需要你的源代码、环境变量或全部对话。

JSON 能解析，不代表正则校验能通过

JSON 文档可以在语法上完全合法，但 JSON Schema 的 pattern 与某个校验器不兼容。下面只是简化说明，不是上游完整工具定义：

{"type":"string","pattern":"^[\\p{L}]+$"}

JSON 解析得到的是一个含反斜杠和 p{L} 的字符串。把字符串解释为正则表达式是第二步，Unicode 属性能否识别取决于正则引擎和模式。因此，本地 JSON 解析成功不能证明供应商接受该 pattern。

把 pattern 替换成 .* 并不等价：它还改变了允许输入的范围。删除整个工具也改变了客户端能力。单纯验证上游客户端修复是否适用于你的配置，不需要这样改。维护网关时，应在测试环境复现校验问题并记录引擎及版本，不要为一个历史请求放宽全部生产 schema。

仍然失败时，提交最小复现

有效的支持记录可以控制在一屏：更新前版本、更新后版本、接口类型、所选模型、被拒字段路径、UTC 时间、供应商请求 ID、短文本复测结果、只读工具复测结果。供应商需要时再提供相关 schema 片段。删除令牌、私密提示词、仓库路径和与校验无关的文件内容。

如果更新后 Artifact 错误消失，但工具结果报错，继续使用文末的 tool-result 或 thinking-signature 指南。如果同一个 pattern 仍被拒绝，请供应商确认校验器实际收到的 schema，并检查代理或 worker 是否还在使用旧客户端。当前版本的最小复现仍失败时，保留证据提交上游，不要把所有 400 都归入这次回归。

恢复完成的判断是：正确的客户端向正确的接口发送修复后的请求，且无副作用的工具流程成功。这不等于所有模型或供应商全部功能都已验证。

其他 400 应单独排查

缺少 tool_result 的排查指南针对中断或格式不正确的工具交互；thinking signature 指南针对另一类消息保留问题。没有匹配的错误证据，就不能用 Artifact 解释替代它们。

有效的求助记录应先写观察到的故障：客户端版本、端点类型、被拒绝字段与完整错误。“Claude Code 用不了”不足以区分已修复的客户端回归和持续存在的供应商问题。