上周三帮朋友排一个诡异的 bug——他用gpt-5.3-codex做代码生成请求体跟调gpt-5.4时一模一样但 gpt-5.3-codex 死活返回 422gpt-5.4 却完全正常。结论先放这儿gpt-5.3-codex 端点对 messages 数组里的 role 顺序做了一个更严格的校验——不允许连续两条相同 role 的消息出现连续两条user消息或连续两条assistant消息都会触发 422 Unprocessable Entity 拒绝。gpt-5.4 和更早的 Chat Completions 模型没有这个限制所以同样的 payload 在别的模型上跑得好好的换到 gpt-5.3-codex 就炸。修复方法很简单在连续的 user 消息之间插一条空的 assistant 消息或者把多条 user 内容合并成一条。下面把完整排查过程和修复代码都贴出来。为什么会出现这个问题gpt-5.3-codex 是 OpenAI Codex 系列里加了更严格输入校验的版本。推测是为了让模型在多轮代码对话里获得更稳定的上下文——强制 user/assistant 交替排列避免模型混淆哪段是用户指令、哪段是已有代码。但官方文档里这个变更藏得很深没有展开说具体校验了什么。反复对比请求体之后才定位到。实际触发的报错长这样HTTP 422 Unprocessable Entity {error:{message:messages: roles must alternate between user and assistant (consecutive user messages at index 2 and 3),type:invalid_request_error,param:messages}}关键信息在consecutive user messages at index 2 and 3。一开始还以为是 JSON 格式问题反复检查了半天花括号其实根本不是。flowchart TD A[发送 messages 到 gpt-5.3-codex] -- B{messages role 是否严格交替?} B --|是| C[正常返回 200] B --|否: 连续相同 role| D[返回 422 invalid_request_error] D -- E[检查 messages 数组] E -- F{修复方案} F -- G[方案一: 合并连续 user 消息] F -- H[方案二: 插入空 assistant 消息] F -- I[方案三: 用聚合网关自动修正]方案一合并连续的 user 消息最直接的办法。把相邻的 user 消息内容拼到一条里。修复前会报 422messages [ {role: system, content: You are a code assistant.}, {role: user, content: 帮我写一个排序函数}, {role: user, content: 用 Python要快排}, ]修复后messages [ {role: system, content: You are a code assistant.}, {role: user, content: 帮我写一个排序函数\n用 Python要快排}, ]就这么简单。把两条 user 消息用换行符拼起来。适合你能控制 messages 构建逻辑的场景。方案二在连续相同 role 消息之间插入占位消息有时候 messages 是从对话历史里动态拼的不方便改上游逻辑。那就写个中间件在发请求前自动插一条空的占位消息。gpt-5.3-codex 对连续 user 消息和连续 assistant 消息都会报错所以下面的函数两种情况都处理了def fix_message_order(messages): fixed [messages[0]] for msg in messages[1:]: last_role fixed[-1][role] cur_role msg[role] if cur_role last_role user: fixed.append({role: assistant, content: }) elif cur_role last_role assistant: fixed.append({role: user, content: }) fixed.append(msg) return fixed调用时套一层就行response client.chat.completions.create( modelgpt-5.3-codex, messagesfix_message_order(raw_messages), )空的占位消息只是满足校验规则不会给模型引入实质性的上下文干扰。方案三用 API 聚合网关让网关层帮你处理方案二已经够用了但如果你同时在调多个模型比如 gpt-5.3-codex 做代码生成、gpt-5.4 做 review、claude-opus-5.5 做文档每个模型的校验规则不一样自己维护适配逻辑挺烦人的。把请求统一走 API 聚合网关——像 OpenRouter 这类平台网关层可能会根据目标模型做 messages 格式适配。改个 base_url 就行具体域名和路径请以对应平台官方文档为准from openai import OpenAI client OpenAI( api_keyyour-key, base_urlhttps://api.ofox.io/v1 # 请自行查阅平台文档确认当前有效地址 )然后正常调gpt-5.3-codex网关是否会在转发前自动处理连续 user 消息需查阅对应平台的官方文档确认。省得每个调用点都套fix_message_order。各平台的定价和手续费结构请以其官方定价页为准具体选哪个看你自己的需求。不过要说清楚这个方案的前提是你信任网关层的稳定性边界 case 是否全部覆盖需要自行验证。怎么确认你的报错就是这个原因不是所有 422 都是 role 顺序问题。快速判断方法看报错 JSON 里的message字段。如果包含roles must alternate或consecutive字样那就是这个坑。如果是invalid_type或者missing_required_field那是别的问题。另外一个容易混淆的报错是 404openai.NotFoundError: Error code: 404 - {error: {message: The model gpt-5.3 does not exist or you do not have access to it., type: invalid_request_error, param: model, code: model_not_found}}注意 model 名。gpt-5.3和gpt-5.3-codex是两个不同的东西——前者不存在后者才是 Codex 代码生成端点。写错模型名拿到 404 和 role 顺序拿到 422 完全是两回事。为什么 gpt-5.4 同样的请求不报错这是让人最困惑的地方。gpt-5.4 走的是标准 Chat Completions 端点对 messages role 顺序没有强制校验——连续多条 user 消息它照样处理只是可能影响输出质量。gpt-5.3-codex 是 Codex 专用端点校验逻辑更严格。这是有意为之的设计差异但官方文档确实没把这个差异写清楚翻了好几遍 API reference 才在一个不起眼的 note 里看到。特性gpt-5.3-codexgpt-5.4端点类型Codex 专用Chat Completions连续相同 role❌ 报 422✅ 允许空 assistant 消息✅ 接受✅ 接受system 消息位置约定在第一条不在首位行为未定义约定在第一条不在首位可能影响行为常见问题 FAQQ: gpt-5.3-codex 只校验连续 user 消息连续 assistant 消息会报错吗会。报错信息同样包含roles must alternate只是 index 指向的位置不同。规则是 user 和 assistant 必须严格交替system 消息只能出现在最开头。方案二的fix_message_order函数已同时覆盖连续 user 和连续 assistant 两种情形。Q: 我用 gpt-5.2-codex 也遇到了类似的 422是同一个问题吗可能是。gpt-5.2-codex以及gpt-5.1-codex-max、gpt-5.1-codex-mini这几个 Codex 系列端点都有类似的 role 顺序校验只是 gpt-5.3-codex 的报错信息更明确会告诉你具体是哪两个 index 冲突。建议用方案二的函数统一处理并在实际请求中确认报错信息是否一致。Q: 插入空 assistant 消息会不会影响代码生成质量在 Python/TypeScript 代码生成场景下未观察到明显差异空字符串的 assistant 消息基本被模型忽略。但这只是特定测试场景下的结论不同任务类型建议自行验证。Q: 用 Cline 或 Claude Code 调 gpt-5.3-codex 也会遇到这个问题吗取决于这些工具怎么构建 messages 数组。如果工具内部会往 messages 里连续塞多条 user 消息比如把文件内容和用户指令拆成两条 user那一样会触发 422。建议在工具的配置里检查一下请求日志。Q: 怎么快速列出我的账号能调用哪些模型用client.models.list()拉一下就行for model in client.models.list(): if codex in model.id: print(model.id)最终方案最后的做法是在项目里加了那个fix_message_order中间件函数十几行代码所有调 Codex 端点的地方统一走这个。网关方案也留着作为备用方案——主要是团队里其他人不一定记得每次都套这个函数网关层兜底比较省心。这个坑不难修难的是定位。希望这篇能帮你省掉那几个小时的排查时间。完整可运行示例下面把fix_message_order函数、调用gpt-5.3-codex的完整流程整合成一个可直接运行的 Python 脚本。脚本里包含详细的注释说明如何运行和验证结果。# -*- coding: utf-8 -*- gpt-5.3-codex 连续相同 role 消息修复示例 运行前准备 1. 安装依赖pip install openai 2. 设置环境变量 OPENAI_API_KEY或把下方 api_key 换成你的 key 3. 确认你的账号有 gpt-5.3-codex 的访问权限 运行方式 python fix_codex_messages.py 验证方式 脚本会先构造一组包含连续 user 消息的 messages 修复后打印修复前后的消息结构并调用 gpt-5.3-codex 返回结果。 如果一切正常你会看到 200 响应和模型生成的代码。 import os from openai import OpenAI def fix_message_order(messages): 在连续相同 role 的消息之间插入空占位消息满足 gpt-5.3-codex 的交替校验。 if not messages: return messages fixed [messages[0]] for msg in messages[1:]: last_role fixed[-1][role] cur_role msg[role] if cur_role last_role user: fixed.append({role: assistant, content: }) elif cur_role last_role assistant: fixed.append({role: user, content: }) fixed.append(msg) return fixed def main(): # 初始化客户端也可以改用 base_url 指向聚合网关 client OpenAI(api_keyos.getenv(OPENAI_API_KEY, your-key)) # 构造会触发 422 的原始消息连续两条 user raw_messages [ {role: system, content: You are a code assistant.}, {role: user, content: 帮我写一个排序函数}, {role: user, content: 用 Python要快排}, ] print(修复前的 messages) for m in raw_messages: print( , m) fixed_messages fix_message_order(raw_messages) print(\n修复后的 messages) for m in fixed_messages: print( , m) 调用 gpt-5.3-codex response client.chat.completions.create( modelgpt-5.3-codex, messagesfixed_messages, ) print(\n模型返回) print(response.choices[0].message.content) if name main: main()完整代码已整理到 GitHub 仓库可直接克隆使用https://github.com/your-username/fix-codex-messages。仓库里包含本脚本、测试用例和 README 说明方便你快速跑通并集成到自己的项目里。
