做 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.com，API Key 通常以sk-开头，默认请求地址是https://api.openai.com/v1。常用的接口有两个：/v1/chat/completions负责对话补全，/v1/responses是较新的统一响应接口。鉴权方式是在请求头里加Authorization: Bearer <你的Key>。
Anthropic 这边，控制台在 console.anthropic.com，API 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( model="gpt-4o", messages=[{"role": "user", "content": "你好"}], ) from anthropic import Anthropic client_anthropic = Anthropic() # 默认读环境变量 ANTHROPIC_API_KEY response = client_anthropic.messages.create( model="claude-sonnet-4-5", max_tokens=1024, 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_KEY=sk-你的Key ANTHROPIC_API_KEY=sk-ant-你的Key然后把.env写进.gitignore，把.env.example提交到仓库，里面只放变量名不放真实值：
OPENAI_API_KEY= ANTHROPIC_API_KEY=代码里读取环境变量：
import os from openai import OpenAI client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))服务器端部署时，优先使用云平台的密钥管理或 CI 环境的 secret 配置，不要在启动命令里明文带 Key。团队协作时，每名成员用自己的 Key 开发，生产环境用独立的服务账号 Key，这样即使某个 Key 泄露，也能单独吊销，不影响其他人。
2.3 环境变量与配置文件示例
命令行工具通常会读环境变量。比如 Codex 这类 CLI 工具，设置好OPENAI_API_KEY之后直接可用。为了减少混乱，我会在~/.bashrc或~/.zshrc里加：
export OPENAI_API_KEY="sk-你的Key" export ANTHROPIC_API_KEY="sk-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_KEY"Anthropic 可以发一条最小消息：
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 Unauthorized | Key 无效、复制不完整、带空格 | 重新生成 Key，检查环境变量 |
| 403 Forbidden | 账号地区不可用、支付方式未绑定 | 确认账号状态和控制台提示 |
| 404 Not Found | base_url 或端点路径拼错 | 检查地址末尾是否多了/v1 |
| 429 Too Many Requests | 限流或余额不足 | 看响应头里的 Retry-After |
| 超时 | 网络延迟高或 timeout 设置过短 | 先用 curl 测延迟，再调大超时 |
| overloaded_error | Anthropic 服务端繁忙 | 做退避重试，不要立刻加大并发 |
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( timeout=60.0, max_retries=3, )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 2>&1 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、请求头、模型名这四样东西打印出来，逐项核对，大概率能定位问题。
