OpenAI Codex 走向本地部署：Dell 合作意味着企业 AI 路由架构的哪些变化

大多数工程团队在采用 Codex 时面临的真正问题不是"要不要用"，而是"智能体在哪里运行，我们如何把流量路由过去"。OpenAI 于 5 月 18 日宣布与 Dell Technologies 合作，将这个问题彻底摆上台面——尤其是对于那些无法将最敏感代码发送到云端 API 的企业用户。

Codex 正在从纯云服务向混合部署演进。此次合作将 Codex 接入 Dell AI Data Platform（本地企业数据治理）和 Dell AI Factory（本地 AI 推理基础设施）。实际意义是：企业将首次可以在自有数据中心内运行 Codex 驱动的智能体，直接访问本地代码库、文档和业务系统，而无需将这些数据提取到 OpenAI 云端。

这将显著改变路由决策逻辑。在该部署路径正式上线之前，工程团队需要提前想清楚以下问题。

发生了什么

OpenAI 与 Dell 合作包含两个集成点：

Dell AI Data Platform 集成。 Codex 将与 Dell 的本地数据平台对接——这是企业用于管理代码库访问、文档和业务记录的存储与治理层。这消除了长期以来阻止受监管行业采用 Codex 的核心障碍：智能体可以推理内部上下文，而这些上下文完全不需要离开企业边界。

Dell AI Factory 集成（探索阶段）。 OpenAI 正在探索 Codex（以及 ChatGPT Enterprise）如何与 Dell 的本地 AI 推理基础设施对接，这意味着模型服务层本身可能也会迁移到本地——不仅仅是数据集成。这一方向尚处于探索阶段，但指向完全隔离（air-gapped）Codex 部署的可行路径。

与此同时，Gartner 同期发布的 2026 年企业 AI 编码智能体魔力象限将 OpenAI 评为领导者，并特别点名了企业治理、沙箱隔离、RBAC 权限控制、审批门控和可审计工作区治理等优势。Dell 合作正是这些治理要求的基础设施落地答案。

对 AI 工程团队的影响

数据本地化改变了智能体的可用范围。 Codex 的核心价值在于对大型代码库的推理能力。对于有严格数据驻留要求的行业——金融、医疗、国防、公共部门——将内部代码库发送到云端 API 一直是硬性障碍。Dell 集成消除了这个障碍，之前因合规问题拒绝评估 Codex 的团队现在有了可信的本地路径。

混合路由意味着流量分叉。 在部分 Codex 工作负载在本地运行、部分在 OpenAI 云端运行的架构下，路由层需要明确知道每条请求走哪条路径。公开代码库的代码补全？云端没问题。内部薪资系统的代码审查？只能走本地。这种区分不是大多数现有路由配置默认具备的能力——它需要基于项目或团队的细粒度路由策略，而不是单一统一的端点。

成本核算变得更复杂。 云端 Codex 按 API token 计费。本地 Codex 跑在 Dell 基础设施上，有自己的 CapEx/OpEx 分摊逻辑。统一的成本模型需要将两个来源的数据合并。目前仅从 OpenAI 计费 API 导出 token 用量的团队，将需要在此基础上叠加基础设施成本归因。

智能体状态需要会话亲和性。 Codex 智能体越来越多地在多轮交互中保持状态——本地运行环境、正在执行的测试套件、部分修改中的文件树。如果路由层在多个 Codex 实例（云端 + 本地）之间做负载均衡，必须将恢复的会话路由回持有该智能体状态的同一实例，否则任务会在执行中途丢失上下文。这是有状态语言模型应用一直面临的会话亲和性问题，现在同样适用于编码智能体。

治理控制必须横跨两个平面。 审批门控、RBAC 和可审计工作区治理只有在云端和本地 Codex 流量都统一适用时才真正有效。如果治理层只存在于云端代理，本地 Codex 调用将绕过它。

路由运营角度的深度分析

Dell 合作引入了企业 Codex 部署的双层架构：

团队请求
  │
  ├─ 公开/非敏感代码 → 路由代理 → OpenAI 云端 Codex
  │                   （标准 token 计费，云合规）
  │
  └─ 敏感/受监管代码 → 本地路由 → Dell AI Factory Codex
                        （数据不出边界，CapEx 计费，本地 RBAC 执行）

要实现这种路由分叉，工程团队需要在正式发布前提前规划四件事：

1. 数据分类策略。 定义哪些项目、代码库或数据类别可以离开边界。这成为路由规则本身，而不仅仅是一份策略文档。
2. 项目级路由配置。 路由规则需要作用于项目或团队维度，而不仅仅是用户维度。允许使用云端 Codex 处理公开代码库的开发者，必须被阻止将受监管代码路由到云端。
3. 统一可观测性。 日志、延迟指标、token/会话计数需要跨两个部署平面聚合。仅覆盖云端的监控看板，对本地流量将存在盲区。
4. 会话状态管理策略。 提前决定有状态智能体会话是仅限云端、仅限本地，还是可以在两者之间迁移。跨平面的中途迁移会带来极难调试的问题，在迁移工具成熟前应避免。

Dell AI Factory 的模型服务集成（探索阶段）是更为激进的选项。一旦它成为正式产品，企业将可以运行完整的 Codex 技术栈而无需任何出站 AI API 调用——从架构上看，类似于自托管 LLM 端点，但附带 OpenAI 的智能体执行框架和工具集成。其路由含义本质上等同于 BYOK（自带密钥）与提供商托管的对比，只不过作用范围提升到了整个智能体执行层。

TheRouter 用户需要关注和尝试的事项

• 现在就定义数据分层路由策略。 即使本地 Codex 今天尚未正式发布，它所带来的架构分叉已经清晰。在部署路径存在之前文档化哪些工作负载可以上云、哪些必须本地，比等工程师开始使用后再改规则要容易得多。

• 审查你当前的 Codex 会话处理方式。 如果你今天已经通过 API 代理使用 Codex，测试多轮智能体会话在现有路由配置下是否稳定。会话亲和性问题在今天可能只是小问题，但当有状态长时序任务成为主要 Codex 使用场景时，它会成为关键故障点。

• 关注 Dell AI Factory 的模型服务细节公告。 当前公告仍处于探索阶段。一旦 OpenAI 确认本地模型服务正式可用，采购和基础设施团队需要提前准备——Dell AI Factory 是服务器机架基础设施，不是 SaaS 开关，不能当天采购当天上线。

• 重新审视仅基于 token 的成本模型。 如果当前计费方案只从 OpenAI API 导出 token 成本，混合部署场景下将低估 Codex 的真实总成本。在本地路径上线前，提前设计能够叠加基础设施分摊的成本模型。

TheRouter 负责在 OpenAI 兼容的 API 端点之间进行路由。当 Codex 本地端点通过 Dell 集成正式可用时——无论是本地可达的 API，还是跑在 Dell AI Factory 上的模型部署——这些端点都可以作为提供商加入路由配置。上述针对项目或数据分层的路由策略，可以直接映射为提供商级路由规则：敏感工作负载路由至本地提供商，非敏感工作负载路由至云端提供商，fallback 和可观测性由网关层统一处理。