Codex接入Qwen/GLM死循环：Relay协议适配与递归防护指南
解析Codex通过Relay接入Qwen、GLM等第三方大模型时因/responses协议不兼容引发的死循环，提供递归深度限制、响应适配、压测与监控方案。
前言
在尝试将通义千问、GLM 等国产大模型接入 Codex 开发生态时，容易触发一类隐蔽的中间代理死循环缺陷。故障表现为：Codex 通过 Relay 代理转发请求至第三方模型接口后，请求持续陷入循环处理，最终整条业务链路完全崩溃。
该问题根源来自协议标准差异：Codex 逐步弃用传统 /chat/completions 接口，转向面向 AI 代码工作流全新设计的 /responses 协议；但通义千问、GLM 等国产模型原生返回结构无法完全匹配新标准，代理在自动补齐字段时会递归触发新一轮调用，形成无限递归。OpenAI 官方在 issue#7782 也明确区分：/chat/completions 属于 GPT-3.5 时代遗留协议，/responses 是面向长上下文、Agent、代码场景的新一代规范。本文完整拆解故障原理、分层修复方案、多模型适配代码、上线压测规范与运维监控标准。
一、Relay 代理正常工作流程与死循环触发条件
1.1 理想状态标准流程
完整调用链路：
Codex Client → /responses → Relay网关 → 第三方模型API → 标准化响应返回
Relay 中间层承担四项核心职责：接收客户端请求、路由到指定模型端点、完成协议结构转换、输出统一格式应答。整套流程执行一次即可结束。
1.2 死循环触发完整逻辑
当接入通义千问、GLM 这类第三方模型时，故障链路如下：
- 第三方模型返回的原始 JSON 响应缺少
/responses协议强制必填字段； - Relay 中间层启动自动补齐、标准化转换逻辑；
- 字段补齐处理逻辑内部再次发起模型远程调用；
- 重复执行转换流程，产生无限递归，形成死循环。
程序捕获标准报错日志：
[ERROR] cc switch local proxy failed while handling codex endpoint /responses
Provisioning loop detected in response formatting
一旦出现这条日志，代表递归环路已经形成，如果不设置最大递归深度限制，进程会持续消耗内存直至 OOM 崩溃。
二、分层修复架构设计
我们采用三层治理方案，从协议规范、代理防护、异常兜底三个维度消除循环风险：
- 协议适配层：完整实现兼容 OpenAI
/responses接口，保证created、choices、id等全部必填字段稳定存在； - Relay 代理防护层：新增递归调用探测机制，硬性设置最大递归深度，工程上推荐上限为 3 层；
- 异常兜底层：针对通义千问、GLM 特有返回结构单独编写适配转换器，增加缺失字段静态填充逻辑，尽可能减少运行时动态调用。
2.1 核心递归防护代码（Python）
class ModelRelay:
def __init__(self):
self.call_depth = 0
self.MAX_DEPTH = 3
async def forward_request(self, request):
if self.call_depth >= self.MAX_DEPTH:
raise RecursionError("Max relay depth exceeded")
self.call_depth += 1
# 模型转发、响应标准化逻辑
递归计数器跟随单次请求生命周期，达到阈值直接抛出异常，阻断无限循环。
三、主流国产模型针对性适配实现
不同厂商返回报文结构差异较大，不能使用同一套转换逻辑，需要独立适配。
3.1 通义千问（Qwen）适配要点
通义千问接口返回存在三类需要特殊兼容的结构：
multipleangles_3d多角度图像生成专属字段；- FunctionCall 函数调用外层嵌套结构；
- 蒸馏版、完整版模型响应字段不一致。
基础响应转换示例：
def adapt_qwen_response(response):
if "multipleangles_3d" in response:
response["choices"] = [{
"message": {
"content": json.dumps(response["multipleangles_3d"]),
"role": "assistant"
}
}]
return response
3.2 GLM 系列模型适配方案（GLM-5.2）
针对 GLM 5.2 需要重点处理：
coding_plan代码规划专属嵌套结构；- Lite 轻量版与完整版字段差异；
- namespace 授权相关字段映射。
基础配置模板：
glm-adapter:
v5_2:
coding_plan_fields: ["task", "steps", "output_spec"]
lite:
required_fields: ["code", "explanation"]
四、上线前压力测试规范
修复完成后，必须执行边界场景验证，仅正常用例测试不足以暴露递归隐患，推荐覆盖测试场景：
- 连续 100 次动态切换模型的混合请求；
- 长时间高并发负载下观测响应延迟波动；
- 构造缺失字段的异常返回报文，模拟上游模型不规则输出。
基础 HTTP 测试命令：
curl -X POST "http://relay/v1/responses" \
-H "Content-Type: application/json" \
-d '{
"model": "qwen",
"messages": [{"role":"user","content":"test"}],
"max_tokens": 50
}' --limit-rate 10k
五、生产环境监控指标配置
需要接入监控平台持续采集以下指标，及时发现潜在环路风险：
| 指标名称 | 告警阈值 | 采集频率 |
|---|---|---|
| relay_depth 当前递归深度 | >2 | 10s |
| model_switch_latency 模型切换耗时 | >500ms | 30s |
| error_4xx 客户端错误 | 每分钟>5次 | 60s |
一旦递归深度指标持续超过阈值，代表部分请求正在进入循环，需要立刻排查对应模型适配器转换逻辑。
六、线上故障排查完整指南
6.1 高频故障分类
- cc switch 连接失败 排查方向：确认上游模型端点连通性、API 密钥有效期、namespace 权限配置；
- 响应格式化循环告警
排查方向：检查
MAX_DEPTH配置，核对标准化转换函数内部是否发起新模型调用； - 通义千问图像生成结果异常
排查方向：确认
multipleangles_3d字段映射逻辑，补齐 3D 参数适配代码。
6.2 调试手段
- 开启中间层详细日志，打印原始响应与标准化之后的报文对比：
logger.debug(f"Raw response: {raw}")
logger.debug(f"Standardized: {standardized}")
- 开启环境变量启用完整调试模式
export RELAY_DEBUG=1
- 请求透传
X-Request-ID，实现整条链路日志串联追踪。
七、进阶生产架构优化
基础故障修复完成后，面向大规模线上环境可以继续优化架构：
- 缓存层：对重复高频请求结果进行本地缓存，减少上游调用次数；
- 批处理机制：合并相近时间到来的同类请求；
- 熔断策略：单一模型错误率持续超限后自动隔离，避免故障扩散。
优化后完整链路：
客户端 → 负载均衡 → Relay集群 → 模型路由 → 本地缓存 → 第三方模型API
企业平台同时接入多款国产、海外模型时，可以借助 koalaapi 统一网关完成多模型流量分发、协议标准化转换，集中管理各类模型适配器逻辑，降低维护成本。
八、总结
Codex 生态对接第三方模型出现的 Relay 死循环，本质是 /responses 新标准和国产大模型原始响应结构不兼容，字段补齐逻辑意外触发递归调用。依靠单纯修改 Prompt、限制并发并不能根治。标准解决方案需要三层协同：协议前置标准化、代理增加递归深度硬限制、针对每个模型单独开发响应适配转换器。
整套方案经过线上验证，稳定运行数月，可以实现通义千问、GLM、DeepSeek 等多款模型在 Codex 开发工具中的稳定接入。团队上线之前务必构造异常报文进行压测，并持续监控递归深度指标，提前捕捉尚未暴露的环路风险。
