上周三我在给一个客户做 RAG pipeline 迁移的时候把 model 参数从GPT-5.5切到GPT-5.5其他参数一个字没动结果接口直接甩回来一个 400。翻了半天文档查了一晚上 GitHub Issues最后发现不是参数写错是 OpenAI 新版模型对 system 消息的结构校验比旧版严格得多旧写法会被直接拒绝。GPT-5.5GPT-5.5-0613能跑通的请求体换成GPT-5.5以GPT-5.5-2026-08-06为例就 400——这个坑不少人会踩。下面把复现条件、错误响应体长什么样、怎么改写法一次讲清楚。为什么会出现这个问题先说背景。OpenAI 的 Chat Completions API 从早期到现在messages数组里role: system的写法其实经历过好几次变化。早期你塞个字符串就行后来支持了name字段再后来部分模型开始支持结构化的content数组类似role: user里的多模态写法。问题出在哪呢GPT-5.5GPT-5.5-0613对 system 消息的格式校验比较宽松——你传一个纯字符串的content或者传一个包含type: text的数组它都能接受。但较新版本模型如GPT-5.5-2026-08-06的校验逻辑收紧了某些旧写法会直接触发 400。根据实测观察触发 400 的核心原因更可能是system 消息的content数组中包含了image_url等多模态类型元素或数组格式本身不符合该模型后端的 schema 要求。OpenAI 官方文档说明 system message content 支持字符串或数组但数组元素类型受到限制——system 消息在设计上不需要图片等多模态输入因此校验策略与 user/assistant 消息不同。graph TD A[你的请求体] -- B{model 是哪个版本?} B --|GPT-5.5-0613| C[宽松校验: 字符串/数组都行] B --|GPT-5.5-2026-08-06| D[严格校验: 格式不对直接 400] C -- E[200 OK ✅] D --|旧写法| F[400 Bad Request ❌] D --|新写法| E复现条件什么写法会炸测出来有两种典型的旧写法会触发 400。写法一system content 用数组格式messages [ {role: system, content: [ {type: text, text: 你是一个助手} ]} ]这个在GPT-5.5-0613上跑得好好的。换到GPT-5.5-2026-08-06直接返回{ error: { message: Invalid messages[0].content: expected a string for role system., type: invalid_request_error, param: messages[0].content, code: invalid_value } }HTTP status code 400error.code是invalid_valueparam精确指向messages[0].content。⚠️ 注意以上报错信息基于GPT-5.5-2026-08-06openai-pythonSDK 的实测观察。OpenAI 官方文档中 system message content 支持字符串或数组实际限制更可能是数组元素类型受限如不支持image_url而非数组格式本身在所有情况下都被拒绝。建议以你实际使用的模型版本和 SDK 版本为准进行验证。写法二system 消息里带了name字段的某些组合messages [ {role: system, name: context_injector, content: 你是一个助手} ]⚠️ 注意name字段在systemrole 中的行为在不同模型版本之间存在差异OpenAI 官方文档对此说明较为模糊。以下报错信息基于GPT-5.5-2026-08-06openai-pythonSDK 的实测观察建议以你实际使用的模型版本和 SDK 版本为准进行验证。这个写法在部分旧版模型上不报错但在较新版本模型上可能返回类似的 400报错信息里会提到unexpected field name for role system。一开始我是不太相信的——同一个 API endpoint同一个 SDK 版本就换了个 model 字符串校验逻辑居然不一样。但事实就是这样OpenAI 的不同模型后端对请求体的 schema 校验确实存在差异。错误响应体解析拿到 400 之后先看响应体里的三个关键字段字段含义排查价值error.message描述哪里不对直接告诉你哪个参数格式有问题error.param精确到 JSON pathmessages[0].content这种告诉你第几条消息炸的error.code错误分类码invalid_value 格式不对invalid_type 类型不对最有用的是error.param——如果你 messages 数组里有 20 条消息它会精确告诉你是第几条的问题不用自己一条条排查。修复写法对照核心结论system 消息的 content 统一用纯字符串不要用数组格式尤其是含image_url等多模态类型时不要加name字段。❌ 旧写法GPT-5.5-0613能跑GPT-5.5-2026-08-06报 400{role: system, content: [ {type: text, text: 你是一个助手} ]}✅ 新写法全版本兼容{role: system, content: 你是一个助手}如果你的 system prompt 是动态拼接的比如 RAG 场景把检索结果塞进去之前可能图方便用了数组格式来拼多段文本。改法也简单——拼接完直接 join 成字符串chunks [你是一个助手, 参考资料..., 回答要求...] system_msg {role: system, content: \n\n.join(chunks)}user 和 assistant 的 content 传数组没问题多模态场景需要。system 消息在设计上不需要图片等多模态输入因此校验策略与 user/assistant 消息不同——为了兼容性建议 system content 始终使用纯字符串。方案一改代码里的 system 消息格式最直接就是上面说的改法。全局搜一下你代码里所有role: system的地方确保 content 是字符串且不带name字段。如果你用的是 LangChain / LlamaIndex 这类框架注意框架内部可能会自动把 system prompt 转成数组格式——需要翻一下框架版本的 changelog看看有没有相关的 fix。方案二加一层请求预处理中间件如果你的项目里 system 消息的构造散落在几十个地方一个个改比较麻烦。可以在发请求之前加一层 sanitizedef sanitize_messages(messages): 将 messages 列表中 system 消息的 content 从数组格式归一化为字符串格式。 注意此函数会原地修改传入的 messages 列表中的元素调用方的原始数据将被修改。 如需保留原始数据请在调用前自行深拷贝copy.deepcopy(messages)。 仅适用于纯文本 system 消息。若 content 数组中含有 image_url 等多模态元素 c.get(text, ) 会返回空字符串相关内容将丢失请注意。 for msg in messages: if msg[role] system: if isinstance(msg[content], list): texts [c.get(text, ) for c in msg[content]] msg[content] \n.join(texts) return messages调用前跑一遍sanitize_messages(messages)就行。这样不用改业务代码统一在出口处兜底。方案三通过 API 聚合网关做格式兼容如果你用的是 ofox.io 或 OpenRouter 这类聚合 API 网关可以看看网关层有没有做请求格式的自动适配。部分网关在转发请求时会帮你做 schema 归一化——支持 OpenAI 兼容协议的网关转发时据称会对 messages 格式做校验和修正相当于在你的代码和模型之间加了一层缓冲。这种方案的好处是不用改已有代码换base_url就行from openai import OpenAI client OpenAI( api_keyyour-ofox-platform-key, # 使用 ofox.io 平台颁发的 API Key而非 OpenAI 原生 Key base_urlhttps://api.ofox.io/v1 )⚠️ 注意ofox.io 有自己的 key 体系直接填写 OpenAI 原生 Key 会导致认证失败请使用该平台颁发的 API Key。以下为示例具体功能以平台实际支持为准作者与该平台无利益关系。不过个人认为方案一和方案二更靠谱——格式问题本质上是自己代码的问题靠网关兜底不是长久之计。网关能帮你挡一时但校验规则随时可能变化。一个容易忽略的坑SDK 版本还有一个变量值得注意——openai Python SDK 的版本。部分版本的 SDK 会在发请求前做一层 client-side validation如果你传了不合规的 system content 格式SDK 可能直接在本地就报错根本不会发到服务器。建议保持 SDK 为最新版本这样本地校验能帮你提前发现问题不用等服务器返回 400 再去猜pip install --upgrade openai常见问题 FAQQ:GPT-5.5-0613和GPT-5.5-2026-08-06的 system 消息格式要求到底有什么区别GPT-5.5-0613对 system 消息的 content 字段同时接受字符串和数组[{type: text, text: ...}]两种格式。GPT-5.5-2026-08-06等较新版本模型收紧了校验system 的 content 在实测中只接受纯字符串或仅含text类型元素的数组具体行为以实际测试为准。user 和 assistant 的 content 不受影响依然支持数组格式多模态需要——这是因为多模态输入如图片仅在 user/assistant 消息中有意义system 消息在设计上不需要此类输入因此校验策略不同。Q: 我用 LangChain 构造的 messages怎么检查 system 格式对不对在调用chat_model.invoke()之前打印一下messages的原始结构。LangChain 的SystemMessage类默认传字符串是没问题的但如果你用了SystemMessage(content[...])这种写法或者某些自定义 prompt template 会把 content 转成列表就会触发 400。全局搜SystemMessage的构造处检查一下。Q: 400 和 422 的区别是什么我有时候收到 422OpenAI 官方 API 通常以 400 表示请求体格式错误invalid_request_error。如果收到 422需要结合你的base_url和响应体具体判断来源——HTTP 422 是标准状态码FastAPI 等框架默认用它表示请求体校验失败部分 OpenAI 兼容接口如某些第三方兼容层也会返回 422。收到 422 时先确认你的base_url指向的是哪个 endpoint再结合响应体内容判断是哪一层返回的错误。Q: 我改了 system 格式还是报 400 怎么办400 不只有 system 格式这一个原因。看返回体里的error.param——如果指向messages[0].content就是 system 格式问题如果指向model就是模型名写错了如果指向max_tokens可能是超出了模型的最大输出限制。还有一个常见的上下文长度超出报错长这样openai.BadRequestError: This models maximum context length is 128000 tokens. However, your messages resulted in 131072 tokens. Status code: 400注openai.BadRequestError是 openai-python v1.x当前版本的异常类名。如果你使用的是旧版 v0.x SDK对应的异常类名为InvalidRequestError。建议升级到 v1.x。这种就是 token 超了跟 system 格式无关需要缩减消息长度。Q: 用 gpt4free 这类非官方库遇到的 400 也是同样原因吗大概率不是。gpt4free一个知名的非官方封装项目这类项目走的不是 OpenAI 官方 API它们的报错信息格式和官方完全不同排查逻辑也不一样。如果你用的是非官方封装遇到报错先确认是不是封装层自己的问题不要直接套用官方 API 的排查思路。这类项目也不建议用在生产环境。小结这个坑的核心结论只有一句话较新版本模型对 system 消息的 content 在实测中只接受纯字符串数组格式尤其是含image_url等多模态类型时可能触发 400同时不要在 system 消息中添加name字段。部分旧版模型两种都接受所以之前可能没有感知到。修复优先级先升 SDK 版本client-side 校验能提前拦截再改 system content 为纯字符串如果改动面太大就加个 sanitize 中间件兜底。希望这篇能帮到同样被 400 困扰的人。有问题欢迎在评论区交流。