Codex、Claude Code 用中转站：先固定渠道，再谈智能路由

代码刚改到一半，Agent 已经读过文件、跑过测试，也找到了报错的位置。你再发一句“按刚才的方案继续”，它却开始重复读文件，或者卡在一次工具调用上。最烦的不是失败，而是你分不清：出了问题的是代码、模型，还是中间那条线路。

如果同时开着自动选商家、自动换模型和失败重试，排查就更像猜谜。上一轮的日志和下一轮的账单未必对应同一条路径，单看终端里那句“请求失败”，很难找到答案。

所以，刚把 Codex 或 Claude Code 接到 API 中转站、准备做项目调试时，我更建议先用固定模型和固定渠道跑通一组任务，再决定要不要开自动路由。这是减少排查变量的方法，不是“固定商家必然稳定”，更不是“智能路由一定丢上下文”。

文档核对：2026-09-16。本文是基于官方接口说明的配置与排查建议，不是某家中转站的稳定性实测或排名；不同版本、网关实现和商家规则可能不同。

1. 01开发客户端

   组织项目上下文、历史与工具结果

2. 02中转站 / 网关

   鉴权、协议转发、路由与计费

3. 03所选商家 / 上游

   处理请求，返回文字与工具调用

示意图：固定商家主要约束路由选择，不替代客户端的上下文管理，也不保证商家内部永不换上游。

先看清 auto 到底在替你换什么

有的平台保持模型不变，只挑选不同上游；有的会根据任务改用另一种模型；还有的平时固定一条线路，只有失败才切备用。这三件事都可能被叫作“智能路由”，影响却不一样。

开发时先把它们拆开：模型选择、商家选择、故障回退分别由谁控制？固定了商家，是否仍允许平台切换？当前模型不可用时，是明确报错，还是悄悄换成别的型号？后台看不见这些信息，就向平台确认，不要把一个“专用 Key”自动理解成专用上游。

即使接口地址和模型名都没变，商家内部也可能使用资源池。你能锁定的通常是平台对外提供的线路选项，而不是某台机器。对开发者来说，可查的请求记录，比一个“绝对稳定”的标签更有用。

“忘了刚才的代码”，先分清上下文、缓存和服务端状态

这三个概念最容易混在一起。上下文是这次请求实际交给模型的信息；缓存是重复内容的计算复用；服务端状态则可能由响应 ID 等引用来继续。缓存失效和上下文丢失不是同一件事。

Claude Code 的缓存说明解释了客户端会在后续请求中重新携带会话上下文。只要需要的信息仍被正确发送，换一个兼容上游，并不会因为它没接待过上一轮就必然“失忆”。长任务中的摘要、上下文压缩、文件没有重新读取，也可能影响它此刻知道什么。

另一种情况才需要特别留意：应用依赖服务端保存的历史，只传上一条响应的引用。OpenAI 的会话状态文档描述了 previous_response_id 这样的续接方式。若目标后端无法解析这个引用，网关又没有正确恢复状态，续接可能失败。这是需要验证的实现边界，不能推断所有 Codex 请求都采用同一种方式。

缓存方面，Claude API 的缓存规则包含组织或工作区隔离及前缀匹配条件。换到不同缓存范围，可能失去原本的命中，增加耗时或费用；固定商家也不保证永远命中。判断时看缓存用量与账单记录，而不是凭回答语气判断“降智”。

能回答“你好”，不代表能接住一整轮开发

网页聊天可以只返回文字。编程 Agent 还要经历读文件、提出工具调用、接收结果、继续修改的多轮往返。一个网关能透传普通聊天，不等于能完整处理客户端需要的协议。

截至本文核对日期，Codex 配置参考将自定义提供商的 wire_api 列为 responses。挑选渠道时，应确认实际支持所用 Codex 版本的 Responses 请求和工具事件，不能只看商家写了“OpenAI 兼容”。

Claude Code 则要核对所选接入方式对应的协议、请求头与流式响应。官方网关兼容说明特别指出了转发缓冲和保活消息对流式连接的影响。终端一直转圈，可能是中间层没及时转发数据，不一定是模型还在认真思考；HTTP 200 也不代表后续流式响应已经完整结束。

遇到工具调用报错，先检查工具请求与结果是否配对。例如 Claude 工具调用规范要求结果对应正确的工具 ID，并按规定的消息顺序返回。客户端组装、代理转换、上游处理中的任何一环都值得检查，不能仅凭一次报错就认定商家换了模型。

固定的是可验证的线路，不只是客户端里的一个名字

我会先在中转站侧选择具体模型、商家或分组，确认该凭证适用的路由规则；如果平台提供自动切换与备用开关，先关闭未经测试的回退。随后发送几次小请求，查看日志中的实际商家或路由标识是否符合选择。平台不提供这类记录，就把“固定到什么程度”列为待确认项。

Codex CLI 的自定义提供商可以按下面的结构理解。这是占位配置，不是可直接使用的服务地址，也不会替你锁定商家。实际模型 ID、API 基址及绑定商家的凭证要由平台提供；编辑前保留现有配置，不要整份覆盖。

model = "REPLACE_WITH_SUPPORTED_MODEL_ID"
model_provider = "project_relay"

[model_providers.project_relay]
name = "Project relay"
base_url = "https://relay.example.com/v1"
env_key = "CODEX_RELAY_API_KEY"
wire_api = "responses"

env_key 指向存放凭证的环境变量，不是让你把 Key 写进文章或仓库。这里的 project_relay 只是本地配置名称，线路约束仍由网关执行。字段依据见 Codex 自定义提供商说明。

Claude Code 接入网关时，按平台说明设置 ANTHROPIC_BASE_URL 和一种正确的鉴权方式：Bearer 通常对应 ANTHROPIC_AUTH_TOKEN，x-api-key 对应 ANTHROPIC_API_KEY，不要不加区分地全填上。启动后用 /status 核对实际地址与凭证来源。CLI、桌面端与扩展的配置入口可能不同，照着 官方网关连接说明检查自己使用的入口。

使用平台发放的独立 API 凭证，不向商家提交个人 ChatGPT 或 Claude 的登录会话凭证。商业项目还要先确认代码、日志的保存与使用条件。路由固定不等于数据合规，域名已验证也不等于服务质量已实测。

用一次真实的小改动验收，而不是连上就充值

拿一个不含密钥和客户数据的小项目，让 Agent 完成“读两个文件 → 改一个函数 → 补测试 → 执行测试 → 根据失败信息修正”。这比让它输出一段示例代码，更接近接入之后每天要做的事情。

先做五次小规模试跑，找明显的协议问题；再准备一组二十个小任务，用同一份代码基线分别测试固定线路和候选备用线路。每次从独立的干净副本开始，尽量保持客户端版本、模型、推理设置和验收标准一致。这个数量是起步建议，不是统计学上的稳定性证明。

• 完成：任务有没有真正通过测试，而不只是最后说“完成了”。
• 连续：工具调用、长一点的输入、暂停后继续是否正常；分别记录失败位置。
• 耗时：从发出任务到验收通过要多久，重试花了多少时间。
• 费用：实际总扣费、缓存用量、重试次数能不能和请求记录对应。

同一模型本来就可能生成不同代码，不能拿两次输出不一样当作换模型的证据。比较时看任务是否完成、失败是否可复现，以及路由记录是否改变。

出了问题，按现象找证据

反馈给平台时，带上时间与时区、客户端版本、模型 ID、脱敏路由信息、错误文本和请求 ID；如平台返回上游请求 ID，也一并保留。别把完整源代码、Token 或带凭证的请求头直接贴进公共群聊。

便宜要按完成任务算，不按标价猜

自动路由并不必然导致虚扣，固定渠道也不会自动解决对账。网关完全可以统一记录多家上游；反过来，一家商家的记录不透明，同样难查。

需要特别核对的是重试：客户端显示失败时，上游是否已经处理了请求？重试是否发起了另一次实际调用？两次记录如何关联、失败如何计费？这些要以平台明细和条款核实，不能仅凭两笔相近金额认定重复扣费。

比较渠道时，我更愿意算这批测试的总扣费 ÷ 通过验收的任务数，再单独记上人工排查时间。举个纯算术示例：一批任务花 ¥2，只完成 5 个，是 ¥0.40/个；另一批花 ¥3，完成 15 个，是 ¥0.20/个。后者总花费高，却可能更划算。这不是任何商家的实测报价。

筛选候选渠道可以先看 AI 中转站价格与资料对照，或者 中转站与官方价格对比。价格表帮你缩小范围，实际开发任务帮你决定留下谁；不要把两步颠倒。

批量创作与独立任务，才是智能路由容易发挥价值的地方

假设要给二十件商品各写一段介绍，或为不同选题生成脚本初稿。这些任务各自带齐素材，不依赖上一条回答，适合由应用并发提交，再让路由在合格渠道之间分配请求。一家排队时，其他有可用额度的渠道有机会继续接活，整批任务就不必只等一条线路。

并发由应用或任务调度器发起，路由负责分配；打开 auto 不会自动把一篇文章拆成多个任务，也不等于每条请求同时发给所有商家。实际速度仍受客户端并发、平台总限额、上游容量和重试开销影响，不能承诺增加几家就提速几倍。

其他值得测试的用途还有：独立文档的摘要和翻译、彼此隔离的代码检查任务，以及高峰期的请求分流。若是连续修改同一个项目，任务之间有依赖，就保留清晰的会话与文件边界；不要让多个 Agent 无协调地同时改同一份文件。

自动选择也可以服务于不同目标：交互式任务优先响应速度，长文本批量任务看输出速度，预算有限时在符合要求的渠道中比较价格。以 OpenRouter 的提供商路由文档为例，它提供负载分配、按价格或速度排序、候选提供商限制及回退选项；不同策略不一定同时生效。这是已有实现的例子，不代表所有中转站或客户端都支持相同参数。

因此，我会把连续开发会话和互不依赖的批量创作分成两套策略：前者先建立固定线路基线，后者在验收过的渠道池里测试调度。保留同样的质量标准，比较整批完成时间、可用成果数量和总费用，而不是只看某次回答有多快。

挑几家合格商家，建一条有边界的夜间路由

固定线路的代价也很明确：它坏了，你就可能停下来。所以我的建议不是永远禁用自动化，而是先让单线路可排查，再让多线路可控。

准备一条独立凭证或独立配置的备用线路，验证同样的工具与上下文要求。切换前保留当前改动和测试结果，检查是否还有正在执行的命令或请求；若上一轮结果不确定，先确认文件及外部操作状态，不要盲目重放。手动换 Key 也不保证服务端会话引用能直接迁移。

当候选线路都通过验收，路由有清晰的模型限制、价格上限和错误日志，才值得测试自动回退。长会话还要确认是否支持会话亲和，也就是在需要时尽量把同一会话留在同一路径；有状态续接则要单独验证切换后的恢复方式。这些是选网关时要核对的能力，不是假定所有平台都有的按钮。

更实用的折中方案，是选两三家已经用自己的任务验证过的商家，创建独立的开发路由或预设，只允许在这个小范围内切换，并为它使用单独的凭证和账单记录。白名单不只是“优先尝试这几家”，还要确认全部失败后不会继续扩展到名单外。同一模型可以优先在合格商家间切换；允许换型号的任务，再另建明确的模型白名单。

夜里让任务继续跑，这样的专用池有机会减少单条线路故障造成的停工，但防止“人睡了、任务卡着、费用还在涨”，不能只靠路由。提交前至少把以下边界落到真正执行它们的系统里：

• 费用：使用可执行的项目或凭证总预算限制，配合单次输出上限。每百万 tokens 的最高单价，不等于整晚消费上限；并发中的请求也可能在停止后继续产生费用。
• 次数：限制每个请求的重试次数、商家切换次数和整个任务的最大步骤；避免客户端和网关各自反复重试，叠加出大量调用。
• 时间：设定请求超时、任务最长运行时间，以及长时间无有效进展时的停止条件。一直重试同一个错误，不算任务有进展。
• 结果：连续失败、预算触线或工具状态不明时，保存已有文件、日志与检查点，停止并等待人工处理；不要靠换模型把失败掩盖过去。
• 权限：无人值守不等于无限授权。发布、付款、删除重要数据等操作仍保留审批或单独的执行边界，不让备用线路盲目重复这些动作。

这些控制通常需要平台、客户端或任务调度器共同完成。只有消费提醒、没有硬性停止功能的平台，不能当作已设好预算；如果平台不支持专用池或强制限制，就由支持这些能力的网关或调度器管理，否则不要把重要长任务当作已经可以放心托管。提醒也不能替代自动停机。

比较这套策略时，记录完成率、切换次数、被及时停下的失败任务和实际扣费。它不是“睡一觉保证全做完”，而是能继续的有条件继续，不能继续的及时止损，醒来能看清完成了什么、花了多少钱。先固定渠道验收，再用小范围智能路由提高可用性，比一刀切地开或关更有意义。