做 AI 应用开发的人最近绕不开两个词OpenAI 和 Anthropic。前者是 GPT 系列和 Codex 的开发者后者是 Claude 系列的开发者。很多工具现在都同时支持这两家 API但真正上手时第一个坎往往不是模型能力而是账号、地址、鉴权方式和连接错误。这篇文章就围绕 OpenAI 和 Anthropic 的 API 接入、Codex 开源工具和 VSCode 配置把从注册到跑通、再到排查的思路完整过一遍。看完之后你至少能自己判断连接不上时到底是 Key 的问题、地址的问题、网络的问题还是服务端限流。1. 先看两家 API 的差异账号、地址、鉴权方式很多人以为 OpenAI 和 Anthropic 的接口能直接互换结果换了个客户端就连不上。实际上两家 API 的地址、鉴权方式、请求体结构完全不同只是 SDK 用起来长得像而已。1.1 OpenAI 和 Anthropic 的 API 基本结构OpenAI 这边控制台在 platform.openai.comAPI Key 通常以sk-开头默认请求地址是https://api.openai.com/v1。常用的接口有两个/v1/chat/completions负责对话补全/v1/responses是较新的统一响应接口。鉴权方式是在请求头里加Authorization: Bearer 你的Key。Anthropic 这边控制台在 console.anthropic.comAPI Key 通常以sk-ant-开头默认请求地址是https://api.anthropic.com。对话接口是/v1/messages。鉴权方式不太一样需要单独传x-api-key请求头还得带一个anthropic-version头例如2023-06-01不带它会被拒绝。用 SDK 的时候这种差异会被封装掉一部分。Python 里常见的写法是from openai import OpenAI client OpenAI() # 默认读环境变量 OPENAI_API_KEY response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: 你好}], ) from anthropic import Anthropic client_anthropic Anthropic() # 默认读环境变量 ANTHROPIC_API_KEY response client_anthropic.messages.create( modelclaude-sonnet-4-5, max_tokens1024, messages[{role: user, content: 你好}], )注意一个细节Anthropic 的messages.create必须传max_tokens不传直接报错。OpenAI 在部分模型上可以不传但生产环境我也会显式带上。这类“必须参数”的差异是接入时最容易踩的坑。1.2 为什么“OpenAI 兼容”不等于完全一致现在很多工具会写“支持 OpenAI 兼容接口”Anthropic 也提供了 OpenAI SDK 兼容层可以用 openai 客户端指向 Anthropic 的地址。这时候要注意兼容层解决的是“能不能连上”不是“所有参数都一样”。实际差异至少有三个层面模型名不同。OpenAI 用gpt-4o、gpt-4.1这类名字Anthropic 用claude-sonnet-4-5、claude-opus-4-1这类名字。模型名写错接口会直接返回 404 或 model not found。消息格式不同。OpenAI 把 system 提示放在 messages 列表里Anthropic 在 Messages API 里把 system 作为独立顶层参数工具调用和流式输出的结构也不完全一样。参数语义不同。比如max_tokens在两边的含义接近但不完全等价temperature的默认值和生效范围也有差别。所以我的建议是能用官方 SDK 就用官方 SDK只有工具本身只支持 OpenAI 协议时才走兼容层。兼容层适合“临时连通”不适合“长期稳定复用”因为一旦两边更新接口你的代码要跟着两头改。2. API Key 的获取、保存和常见误用2.1 获取 Key 的常规流程OpenAI 和 Anthropic 的 Key 获取流程大致一样注册账号、完成邮箱验证、进入控制台、在 API Keys 页面创建 Key然后立刻复制保存。因为 Key 只在创建时完整显示一次之后控制台只显示前缀。创建 Key 之前通常需要先确认账号状态。免费额度用完或者没有绑定支付方式时请求会返回 429 或 403看起来像连接问题其实是账号层面的额度问题。这里补一句网上经常有人搜索“openai api key分享”“openai api key获取方法”。获取方法可以自己看官方文档但“分享 Key”这个行为千万不要做。Key 本质是账单入口泄露之后别人可以拿你的额度跑任务轻则余额被刷光重则触发风控导致整个账号被限制。我见过不止一个团队把 Key 写在 Git 仓库里然后被爬虫扫到最后收到大额账单。2.2 不要把 Key 写进代码或公开分享正确做法是走环境变量或密钥管理服务。本地开发时在项目根目录建一个.env文件OPENAI_API_KEYsk-你的Key ANTHROPIC_API_KEYsk-ant-你的Key然后把.env写进.gitignore把.env.example提交到仓库里面只放变量名不放真实值OPENAI_API_KEY ANTHROPIC_API_KEY代码里读取环境变量import os from openai import OpenAI client OpenAI(api_keyos.getenv(OPENAI_API_KEY))服务器端部署时优先使用云平台的密钥管理或 CI 环境的 secret 配置不要在启动命令里明文带 Key。团队协作时每名成员用自己的 Key 开发生产环境用独立的服务账号 Key这样即使某个 Key 泄露也能单独吊销不影响其他人。2.3 环境变量与配置文件示例命令行工具通常会读环境变量。比如 Codex 这类 CLI 工具设置好OPENAI_API_KEY之后直接可用。为了减少混乱我会在~/.bashrc或~/.zshrc里加export OPENAI_API_KEYsk-你的Key export ANTHROPIC_API_KEYsk-ant-你的Key注意如果机器上存在多个 Key建议按项目维度区分而不是全局只用一个。比如接 Codex 用 A Key接 Claude Code 用 B Key两个 Key 的额度模型不同混用之后你很难判断账单和日志到底是谁产生的。3. 连接失败Unable to connect的排查顺序“Unable to connect to Anthropic services”和“Failed to connect to api.anthropic.com”是高频报错。这类问题最容易误判因为现象的归因很杂。我一般按下面这个顺序排查不要一上来就改代码。3.1 先确认请求到底发到了哪里第一步不是看报错而是看你实际请求的地址。SDK 会拼地址很多报错其实是 base_url 被工具或配置覆盖了。先做最小验证用 curl 直接打一次对方接口。OpenAI 可以拉模型列表curl https://api.openai.com/v1/models \ -H Authorization: Bearer $OPENAI_API_KEYAnthropic 可以发一条最小消息curl https://api.anthropic.com/v1/messages \ -H x-api-key: $ANTHROPIC_API_KEY \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d {model:这里填你账号可用的模型ID,max_tokens:16,messages:[{role:user,content:ping}]}如果 curl 能通说明网络、Key、接口地址都没问题问题在工具或代码层。如果 curl 也不通再看下面几步。3.2 再检查鉴权和请求头curl 不通时先看 HTTP 状态码不看状态码只看“连接失败”是排查不下去的。常见情况可以整理成一张表现象最常见原因先查什么401 UnauthorizedKey 无效、复制不完整、带空格重新生成 Key检查环境变量403 Forbidden账号地区不可用、支付方式未绑定确认账号状态和控制台提示404 Not Foundbase_url 或端点路径拼错检查地址末尾是否多了/v1429 Too Many Requests限流或余额不足看响应头里的 Retry-After超时网络延迟高或 timeout 设置过短先用 curl 测延迟再调大超时overloaded_errorAnthropic 服务端繁忙做退避重试不要立刻加大并发Anthropic 有一个常见错误码是-90通常表示服务端过载。这类错误不是你本地能修复的正确做法是指数退避重试第一次隔 1 秒第二次隔 2 秒第三次隔 4 秒最多重试 3 到 5 次。另外注意Anthropic 请求缺anthropic-version头时即使 Key 正确也会被拒绝。如果你是自己拼 HTTP 请求而不是走 SDK这个头很容易漏。3.3 生产环境还要看限流、超时和重试本地单条请求通了不代表生产环境稳定。实际跑批量任务时我遇到过几种情况没有做重试遇到 429 直接失败。超时设置太短模型生成时间长一点就报错。并发开得太大打满账号的 RPM 和 TPM 限制触发连环 429。SDK 版本太旧接口已经更新字段对不上。所以生产代码里至少要处理三件事超时时间、重试策略、并发上限。在 OpenAI SDK 里可以这样配置from openai import OpenAI client OpenAI( timeout60.0, max_retries3, )Anthropic SDK 里也有类似的重试机制但不同版本写法有差异建议以你正在使用的 SDK 文档为准。先跑通再调参不要一上来就追求“一次成功”。4. Codex 开源版下载与本地跑通Codex 是 OpenAI 开源的编码智能体方案。热词里提到的“openai 全面开源 codex harness”“github.com/openai/codex”指的就是这个仓库。它解决的问题很简单直接在命令行里让 AI 读取你的代码仓库、修改文件、执行命令像一个能自己动手的编程助手。4.1 安装和登录Codex 的安装方式以官方仓库 README 为准常见写法是npm install -g openai/codex也可以从源码构建。源码是 Rust 写的构建前需要 Rust 工具链具体命令看仓库说明。安装完成后先确认命令存在codex --version认证有两种方式一种是codex login通过 OpenAI 账号登录适合普通使用另一种是设置OPENAI_API_KEY环境变量适合脚本化和服务器使用。我推荐在服务器上使用后者因为登录态在无界面环境下不好维护。4.2 单条任务与批量任务先跑一条最简单的任务验证整个链路codex exec 写一个 Python 脚本读取当前目录下所有 txt 文件的行数exec表示非交互式执行适合脚本调用。如果只是自己用直接codex进入交互模式也行。本地开发时我习惯先进入项目目录再执行cd ~/my-project codex 修复 tests 目录里失败的单元测试Codex 会读取项目文件、生成修改计划、尝试执行命令。默认有沙箱机制限制部分命令的执行。第一次跑任务时建议盯着输出看它是怎么决策的不要直接放它大批量改代码。批量任务要小心。假设你有 20 个小任务要跑不要写一个 for 循环无脑发 20 个并发请求。正确做法是串行执行每个任务单独记录日志失败后保留错误信息最后统一检查for task_id in 01 02 03; do echo $task_id codex exec 处理任务 $task_id 的描述 logs/$task_id.log 21 echo exit code: $? done这样即使某个任务失败也不会影响其他任务的日志和输出。4.3 本地配置与输出检查Codex 的配置文件一般在用户目录下例如~/.codex/config.toml。里面可以改默认模型、API Key 读取方式、沙箱模式等。原始材料没有给出明确的默认配置项和版本号落地时先打开仓库 README 和codex --help对照确认。任务跑完重点检查两件事它是否真的修改了文件。用git diff查看改动确认没有误删或乱改。它是否执行了预期命令。看日志里的命令历史和退出码。我见过最典型的问题不是“连不上”而是“跑通了但改了不该改的文件”。所以接入 Codex 的团队一定要在 Git 分支里做变更审查不能让 AI 直接往主分支提交。5. 在 VSCode 和常用工具里接入两家 API热词里有“vscode配置openai”这其实是很多人日常真正的需求。VSCode 本身不直接调用大模型你需要装一个支持自定义 Provider 的插件比如 Continue、Cline、Roo Code 这类工具。5.1 插件配置的关键字段在 VSCode 插件里接入 API核心要配置四个字段Provider选 OpenAI 或 Anthropic或者自定义兼容 Provider。API Key填环境变量名不要直接填明文。Base URL默认是官方地址如果有网关或转发服务改成你的网关地址。Model填你账号可用的模型名。把 Key 放在用户级环境变量里再让插件读取是更稳妥的做法。例如在settings.json或插件配置界面里写openai.apiKey指向环境变量而不是直接粘贴 Key。5.2 Continue / Cline 类工具的通用套路这类插件的原理都是把编辑器里的对话、代码上下文转成 API 请求。你只需要记住一个排查逻辑插件连不上时先用第 3 节的方法验证 SDK 或 curl 能不能连通。如果 curl 通而插件不通问题通常出在插件的配置项上比如 base_url 末尾多加了路径、模型名填错、或者 Key 读取方式不对。如果你同时用 OpenAI 和 Anthropic 的模型可以在插件里配置两个 Provider 或两个模型别名。建议给模型起容易识别的名字比如gpt-4o-local、claude-sonnet-prod避免团队协作时互相看不懂。6. 真正上线前要先想清楚的几件事6.1 性能判断标准不要用“能连上”来评价一套接入方案。判断标准至少包括单次请求耗时从发起到首字返回的时间以及完整返回时间。错误率连续跑 100 条请求失败多少条失败原因分布是什么。稳定性批量任务跑到一半有没有卡死、有没有静默失败。可恢复性失败后重试能否续上日志能否定位到具体请求。如果只是学习默认配置够用。如果要跑批处理或接入生产我建议先跑一个 20 条的小样本统计错误率和耗时再决定要不要调并发和超时。6.2 成本与限额API 调用的成本主要来自 token 数量。同样的任务提示词写得多、输出长、反复重试费用会明显上升。控制成本可以从这几处入手设置合理的max_tokens不要让模型无限制生成。批量任务里对输入做截断或摘要减少不必要的上下文。关注缓存能力。OpenAI 和 Anthropic 都提供输入缓存相关机制重复前缀可以降低成本但具体参数和计费规则要以官方文档为准。给账号设置额度告警避免异常调用把预算打穿。6.3 我建议的落地顺序踩过几次坑之后我现在的落地顺序很固定用 curl 验证 Key 和网络。用官方 SDK 写一个最小请求确认参数格式。在命令行工具里跑单条任务确认输出符合预期。再接入 VSCode 等编辑器工具。最后才做批量任务、队列和重试。这个顺序看起来慢但能少走弯路。很多连接问题不是模型能力不够而是前置环境和输入材料没有处理干净。比如 Key 多了空格、地址拼错、模型名写错、网络策略变化这些都会以“连接失败”的形式出现但真正修起来跟模型一点关系都没有。如果你现在正被某个连接报错卡住先别急着换工具或换模型。把请求地址、Key、请求头、模型名这四样东西打印出来逐项核对大概率能定位问题。