Codex CLI、Claude Code、OpenClaw 这类代码 Agent 和普通聊天客户端最大的区别是：它们不是只发一条 prompt，然后收一段文本。它们会维护多轮会话、工具调用、审批状态、上下文压缩和 reasoning 元数据。通过 DeepAI API 中转站 接入 Responses API 或 GPT-5 Codex 类模型时，如果中转层或客户端没有完整保存 response item 与 reasoning item，就可能出现“第一轮能答，第二轮直接 400”的问题。
msg_* 与 rs_* 这类 item 链路也要完整保留。问题背景：第一轮成功，第二轮缺 reasoning item
这个问题可以从 openai/codex Issue #6375 和 Issue #5990 看到。用户使用 Codex CLI 连接 Azure OpenAI Responses API 部署的 gpt-5-codex 或类似模型时，第一条消息能正常回复；但发送第二条用户消息时，服务端返回 400，错误大意是某个 message item 缺少它必需对应的 reasoning item。
unexpected status 400 Bad Request:
{
"error": {
"message": "Item 'msg_...' of type 'message' was provided without its required 'reasoning' item: 'rs_...'",
"type": "invalid_request_error",
"param": "input"
}
}
相关修复方向在 PR #3528 中合并。PR 说明提到 Azure Responses API 与 store:false、response items 的交互存在特殊情况，因此增加了 Azure URL 检测和 workaround，以保留 reasoning item IDs 并发送 store:true。这对任何 API 中转站都有启发：Responses API 的会话状态不是一段字符串，而是一组需要成对保存、回放和排序的结构化 item。
为什么 API 中转站容易放大这个问题
DeepAI API 中转站的价值是统一入口、统一 Key、统一日志和多模型路由。但当客户端使用 Responses API 时，中转站不能只按传统 Chat Completions 思路处理 messages。Responses API 会产生不同类型的输出 item，例如 message、reasoning、tool call、function output 等。代码 Agent 在下一轮请求中可能会把上一轮 item 作为输入回放，如果其中一个被丢掉，服务端就会认为会话链路不完整。
在 Issue #6375 里，用户的假设是 Codex 只记录了增量事件，而 Azure 可能把 reasoning block 放在 response.completed payload 中。于是下一轮回放了 msg_*，却没有对应的 rs_*。无论具体实现在哪里，这类问题的排查重点都一样：看中转站日志里上一轮响应是否完整保存了 reasoning item，以及下一轮请求是否把它一起带回。
DeepAI API 中转站排查步骤
- 确认 Codex CLI 使用的是 Responses API 还是 Chat Completions API。Responses 场景重点看
/v1/responses、input、previous_response_id、response items。 - 在 DeepAI API 中转站日志里对比第一轮响应和第二轮请求，检查
msg_*与rs_*是否成对出现。 - 如果使用 Azure 或自定义 Responses 后端，确认是否需要启用
store:true或等价的 response item 持久化策略。 - 升级 Codex CLI 到包含相关 Responses/Azure workaround 的版本，避免旧客户端遗漏
response.completed中的 reasoning item。 - 如果中转站会重写模型名、截断响应或只存可见文本，先关闭这些转换，保留完整原始事件用于验证。
Codex CLI 自定义 Provider 配置建议
使用 DeepAI API 中转站时，Codex CLI 的自定义 Provider 要尽量明确 wire API 和模型能力。不要只看模型是否能返回文本，还要确认它是否支持 reasoning item、工具调用、流式事件和多轮回放。
model = "gpt-5-codex" model_provider = "deepai" model_reasoning_effort = "high" model_reasoning_summary = "auto" [model_providers.deepai] name = "DeepAI API 中转站" base_url = "https://api.deepai.wang/v1" env_key = "DEEPAI_API_KEY" wire_api = "responses"
如果你的中转站当前只稳定支持 /v1/chat/completions，而不完整支持 Responses item 链路，那么对 Codex CLI 这类代码 Agent，建议先使用 Chat wire 做基础验证；需要 GPT-5 Codex 深度 reasoning、摘要和 item 回放时，再切到 Responses wire 并确保日志能看到完整 item。
如何用日志验证是否修复
最小验证不需要复杂任务。你可以让 Codex CLI 先回答“Hello”，再追问“再说一句”。如果第一轮成功、第二轮失败，说明多轮状态回放有问题；如果两轮都成功，再测试工具调用、文件读取和长上下文压缩。
# 第一轮 codex --profile deepai "Hello" # 同一会话第二轮 Say goodbye in one sentence.
DeepAI API 中转站日志里应该能看到：第一轮 Responses 返回的 reasoning item 被记录；第二轮请求没有只带 msg_*，而是保留了服务端要求的完整上下文 item。修复后的表现是第二轮不再出现 message missing reasoning item，而是正常流式返回或给出后续回答。
常见坑位
- 只保存可见文本：Responses API 里的 reasoning item 可能不展示给终端用户，但对下一轮请求仍然必需。
- 把 Responses 当 Chat Completions：
messages和input items不是同一个抽象，不能简单互相替换。 - 模型名被中转站改写：如果模型名加了
openai/前缀，客户端基于 slug 的能力判断可能失效，要用日志确认实际传参。 - 忽略
store：某些 Responses 后端需要服务端保存 item 才能正确处理后续轮次。 - 旧 Codex 版本：升级前后要重新跑同一两轮对话，用中转站日志确认请求体变化。
DeepAI API 中转站的 SEO 与产品价值
搜索“Codex CLI missing reasoning item”“Responses API 第二轮 400”“GPT-5 Codex Azure 400”“API 中转站 Responses 多轮失败”的用户，往往已经在真实开发环境里遇到了问题。DeepAI API 中转站如果能在日志中展示 request body、response item、模型路由、状态码和错误字段，就能帮助他们快速区分：是客户端没保存 item，是中转站没转发完整事件，还是上游 Responses 后端需要特殊 store:true 策略。
对站长来说，建议把 DeepAI API 中转站文档拆成三类：普通 OpenAI-compatible Chat Completions、Anthropic Messages、Responses API。Codex CLI、Claude Code、OpenClaw、Dify、n8n 等客户端对协议的期待不同，文档越清楚，越能减少“能回第一句但第二句炸掉”这种隐蔽问题。
参考资料
- openai/codex Issue #6375：Azure Responses second turn missing reasoning item
- openai/codex Issue #5990：Codex follow-up 400 missing reasoning item
- openai/codex PR #3528：Add Azure Responses API workaround
- OpenAI Responses API Reference
- Codex config.toml 官方配置参考
总结
Codex CLI 接入 DeepAI API 中转站使用 Responses API 时，如果第一轮正常、第二轮报 message missing reasoning item，不要只看文本内容是否保存。重点检查 msg_*、rs_*、response.completed、store 和下一轮输入 item 是否完整。升级 Codex CLI，并让 DeepAI API 中转站完整记录和转发 Responses item 链路，才能让 GPT-5 Codex 类代码 Agent 在多轮任务里稳定运行。
