Codex 接入 Azure OpenAI / Foundry Models 教程：Endpoint、API Key 和模型配置

Codex 接入 Azure OpenAI 或 Foundry Models不是把普通 OpenAI API Key 换成 Azure Key 就结束。真正要处理的是 endpoint、认证方式、部署或模型名称、请求格式和 Codex 里的 provider 配置。任何一层不一致都会出现认证失败、模型不存在或请求格式错误。Azure OpenAI 和 Foundry Models 的控制台里通常会提供资源地址、部署信息和密钥。这里最容易复制错的是 endpoint。浏览器里的管理后台地址不是接口调用地址项目页面里的展示地址也不一定就是推理 endpoint。一定要回到对应服务的 API 或模型部署页面核对。接入前先明确自己要调用的模型或部署。Azure OpenAI 里常见的是 deployment 名称实际请求时可能用部署名而不是原始模型名。Foundry Models 也可能通过项目、部署、模型路由来决定最终调用目标。不要凭印象写模型名。在 Codex 里建议建立单独 provider把 endpoint、认证环境变量和模型配置写清楚。配置文件里不要写真实 key只写变量名。真实 key 放到系统环境变量、项目 secrets 或受控的密钥管理里。本地测试时可以先在空目录里启动 Codex问一个简单问题确认认证和 endpoint 通了。再进入一个小项目让它解释 README 或项目结构。短任务和项目任务都能通过才说明链路基本可靠。如果接入后出现 401先检查 key 是否属于当前 Azure 或 Foundry 资源如果出现 404先检查 endpoint 路径和部署名如果出现参数错误重点看 API 版本和请求格式。不同云服务的接口版本要求可能不同。如果大家想体验一线 AI 编程模型 codex 和 claude让它们帮你完成开发、排错和效率提升可以参考以下教程文档进行接入配置接入配置好后即可使用。文档教程https://my.feishu.cn/wiki/NIgLwuuj1ibzJIkLGM0cgVNinzg企业网络还要考虑代理和访问策略。你的个人电脑能访问 Azure 或 Foundry endpoint不代表 CI、同事电脑或服务器也能访问。最好把网络路径、代理要求和允许的域名写进接入文档。团队项目不要共用一把主密钥。可以按项目、环境或成员拆分 key并设置预算、权限和备注。这样出现异常用量时能快速定位来源也能单独禁用问题密钥。接入完成后建议做一组真实代码任务测试读项目、给计划、改小文件、跑测试、总结变更。这比普通问答更能暴露长响应、流式输出、超时和模型权限问题。如果未来要切换模型或 endpoint把配置集中管理会很省事。不要在多个脚本、多个项目和多个终端里分别写死地址。统一配置、统一文档、统一验证后期维护成本会低很多。Codex 接入 Azure OpenAI / Foundry Models 的关键是把 endpoint、API Key、部署或模型、provider 配置和验证流程拆开。每一层都能单独确认最终使用体验才稳。实际处理这类配置或接入问题时建议先把当前环境固定下来。记录系统版本、终端类型、客户端版本、配置文件路径、环境变量名称、模型名和最后一次测试时间。信息越完整后续排查越少靠猜。测试也不要只做一次短问答。短问答只能说明认证大概率没问题不能证明长任务稳定。最好再让工具读取一个小项目、解释目录结构、给出修改计划、生成一个很小的 diff并在最后总结改动。如果使用中转站或第三方网关最好单独准备测试 key。测试 key 只用于验证配置不用于长期生产任务。确认稳定后再换成正式项目的 key并设置额度、备注和必要的访问限制。团队协作时配置说明应该写成内部文档而不是靠截图传播。文档里写变量名、配置位置、测试方式和常见错误不写真实密钥。新人照着能跑通老同事换电脑也能复现。遇到错误时不要一次改很多地方。一次只改一个变量改完马上验证。今天换 key明天换模型后天换网关这样很难知道到底是哪一步解决了问题也很难复盘。安全边界也要提前说清楚。能读哪些目录能不能运行命令能不能访问外部系统是否允许处理客户代码都应该在任务开始前明确。AI 编程工具越能干越不能随便放开权限。配置成功后也要保留回退方案。保存一份当前可用配置记录备用网关或备用模型旧 key 不再使用时及时禁用。这样后续平台波动、模型调整或网络变化时不至于完全停住。维护阶段同样重要。每隔一段时间检查一次模型是否变化、网关是否调整、旧变量是否还在、文档是否过期。很多故障不是突然发生而是旧配置在新环境里慢慢失效。如果文章内容涉及团队推广最好先在低风险项目里跑一周。记录成功任务、失败原因、人工修改量和成本变化。数据比主观感觉更可靠也能帮助团队判断是否继续扩大使用范围。长期使用时还要把任务风险分级。公开资料、练习项目和普通脚本可以更灵活客户代码、生产系统、权限逻辑和密钥相关内容必须谨慎。先分级再决定工具权限和接入方式整体风险会低很多。写给新手的建议也很简单先跑通一个小任务再整理一份自己的配置笔记。不要一开始就追求复杂自动化稳定、可复现、能回退才是长期使用 AI 编程工具的基础。文章写完或文档交付前也可以自己快速读一遍开头和结尾。开头应该直接进入问题结尾应该回到操作建议中间应该有步骤和判断标准。这样读起来才像正常文章而不是一份生成提示词或关键词说明。真正稳定的使用方式不是第一次接入跑通就结束而是把接入、验证、排错和复盘变成固定流程。流程清楚以后Codex、Claude Code 或其他开发工具才能长期帮你节省时间。