正在打开每日关注
正在打开每日关注
OpenCodex 1.2.0 以分流桥隔离原生 GPT 与第三方模型，并支持子智能体独立路由。
🚀 OpenCodex 1.2.0 框架彻底重构完成！ 这一次，我们重构了底层模型路由，并加入了「Provider Split Bridge 智能分流桥」，区别于市面上几乎所有的第三方网关代理方式⚡ 过去的 OpenCodex 和其他第三方网关一样，采用全局代理模式：所有模型都经过网关。一旦网关崩溃，原生 GPT 和第三方模型会一起失效，只能还原原生模式才能恢复使用。 现在，模型路由彻底分离： 🟢 原生 GPT 永远直连 OpenAI 无论网关开启、关闭、崩溃，还是第三方模型异常，都不会影响 GPT。除非 OpenAI 官方服务本身发生故障，否则 GPT 始终正常运行。 🔵 第三方模型按需接入网关 网关开启时，第三方模型正常运行；网关关闭或崩溃时，第三方模型停止服务，但不会牵连原生 GPT。 🌉 Provider Split Bridge 智能分流桥 网关启动时自动接入，自动识别官方模型与第三方模型，并将它们分别送往正确的服务通道。 🤖 Native Subagent Bridge 子智能体接力桥 当主会话通过 spawn_agent 派发任务时，子智能体请求会通过独立桥接通道进入网关，再由网关按照任务指定的模型和推理档位进行智能分流。主会话仍然保持原生直连，不会变成全局代理，也不会影响 GPT 的正常会话。 🔄 会话完全互通 会话列表、聊天记录和上下文完整继承。同一会话中可以自由切换 GPT、Gemini、DeepSeek 等模型，互不影响，也不会丢失上下文。 OpenCodex，从「全局代理」进化为「官方直连 + 第三方隔离」的双通道智能架构。 官方模型永远稳定，第三方模型按需接入。🛡️✨
是什么 这条推文介绍 OpenCodex 1.2.0 的模型路由重构，核心主张是把原生 GPT 与第三方模型拆成两个故障域：GPT 始终直连 OpenAI，Gemini、DeepSeek、MiniMax 等第三方模型按需经过网关。这样网关异常时，第三方能力不可用，但不会拖垮原生会话。
核心设计 Provider Split Bridge 负责识别模型并分发到对应通道；Native Subagent Bridge 则把 spawn_agent 派生的子任务单独送入网关，同时保留主会话的原生直连。推文还强调会话列表、聊天记录和上下文可跨模型继承。截图展示了三类子智能体分别执行浏览器、代码和端口检查，形成可观察的验证闭环。
关键洞察 价值不只是增加模型数量，而是缩小第三方网关的爆炸半径，把路由决策放到请求或子任务边界，并让模型能力成为可插拔通道。这种设计适合需要多模型协作、又不能牺牲官方模型稳定性的 Agent 工作流。
边界与风险 现有材料是推文与操作截图，并未提供仓库代码、协议细节或故障演练证据，因此不能据此确认桥接实现的完整性。上下文互通还取决于消息格式、工具调用和推理状态兼容性；截图中的模型切换性能提示也说明多模型切换可能有额外代价。