codex 远程压缩 远端压缩如何开启,对话历史切供应商消失如何解决,怎么写config.toml的完全解惑

发现很多佬对此有疑问,我尽量简明扼要的讲清楚 官方oauth登录不用往下读了,官方登录会自动写入好配置文件。 以下针对反代,其他模型api等等第三方情况。 必须要了解的前置知识 在一个智能体(比如codex和claude code)走第三方api,到底需要什么 API Key 一串密钥(sk-开头)...
codex 远程压缩 远端压缩如何开启,对话历史切供应商消失如何解决,怎么写config.toml的完全解惑
codex 远程压缩 远端压缩如何开启,对话历史切供应商消失如何解决,怎么写config.toml的完全解惑

发现很多佬对此有疑问,我尽量简明扼要的讲清楚

官方oauth登录不用往下读了,官方登录会自动写入好配置文件。
以下针对反代,其他模型api等等第三方情况。

必须要了解的前置知识

在一个智能体(比如codex和claude code)走第三方api,到底需要什么

  • API Key
    一串密钥(sk-开头),用来证明身份 + 计费。

  • URL(你的中转站,自己配置的反代,第三方模型供应商一定会告诉你这个地址)
    服务器地址,告诉智能体去哪请求 AI。
    例:https://…/v1

  • 为什么 codex 的 url 带 /v1,claude code 不带
    /v1 是接口的版本号,写在地址路径里。

    本质:两家接口规范不同,按文档/供应商示例填即可。在codex用的模型一定需要支持

codex接受什么模型

当然不是什么url都支持
无论什么模型(是的你可以在codex里面接入任何第三方模型,只要调用格式合法),必须支持「Responses API」(接口端点 /v1/responses)

  • 这是什么意思?
    OpenAI 有两套接口规范:

    • Chat Completions:老格式,为聊天设计。
    • Responses:新格式,为 agent 设计,codex 只接受这种格式。(Anthropic的Messages API当然不支持)
  • 我怎么知道我的url是Responses格式?
    反代:通常指把多个账号,供应商订阅聚合到某个云平台或本地平台,对话暴露统一的url和api key,主流的cpa和sub2api是一定支持的
    中转站:说白了就是大规模号池的盈利或不盈利的反代,商家会明说自己的url支不支持Responses。如果有人说仅支持Chat Completions,那就是不允许你在codex这类智能体里面使用。

一个codex的和鉴权相关的配置文件,有且仅有两个文件

用户\.codex\config.toml用户\.codex\auth.json
前者是设置文件,后者只负责鉴权(填api key)。下面会详细讲这两个文件怎么写

auth.json如何填写

这个文件非常简单,没有任何歧义,你只需要填你的api key。

{
  "OPENAI_API_KEY": "9bf9119......",
  "auth_mode": "apikey"
}
  • 注意:你会发现有的反代平台和中转站提供的api key是sk-9bf9119…
    sk- 是什么?
    sk = secret key(密钥)的缩写,OpenAI 起的头,
    各家中转沿用。它没有魔法,就是 key 字符串的开头几个字符。

  • 为什么有的时候加上sk-会提示api key无效,去掉sk-才能成功调用
    服务器是拿你填的「完整字符串」去库里比对,
    一字不差匹配上才放行。
    你这个中转站库里存的真值就是不带 sk- 的(9b… 才是真 key),
    所以:

    • 填 sk-9b… → 多了 sk-,比对不上 → 无效令牌
    • 填 9b… → 正好匹配 → 成功
      那个 sk- 多半是它后台 UI 给你"装饰"上去的,不是 key 本体。
  • 结论
    key 要原样填,以「能调通的那个」为准。
    下次遇到不确定,带 sk- 和不带 各试一次即可。

config.toml如何填写

这是一个有很高自由度的文件,在此我只讲他的最短配置,也是他必须承担的基础功能
如下,是一个最短配置需要包含的完整内容

  model_provider = "a"

  [model_providers.a]
  name = "b"
  base_url = "..."

(API Key 不在这里,在 auth.json)

逐行说明:

  • model_provider 选用哪个 provider,值 = provider 的 id
  • [model_providers.a] 定义该 provider,这个 a 就是它的 id
  • name;可以认为是provider显示在codex内部的名字,他的作用决定走不走远端压缩(见第二部分),允许和前面的a不一样
  • base_url 服务器地址(往哪请求)

注意:

  • 两处 a 是同一个 id,必须完全一致,否则报错
    (可换任意英文,但两处要一样)

我怎么知道我写的config.toml合不合法?

配置文件字段不合法的体现是:无法设置沙盒,点击使用备份沙盒也不会有任何反应。当然也无法进行任何对话。
打开codex后会如下图所示

image

远端压缩是什么,如何开启

  • 压缩是什么?
    本质就是一个ai调用,让ai对上下文进行总结(必定会损失某些细节信息,codex的压缩做的不错,压缩后的上下文会保留用户的输入和最近的清晰历史,ai会自己阅读代码,文档后跟进最新情况)
    分为自动压缩和手动压缩,自动压缩临近上下文上限自动触发,手动压缩用/compact(codex app如果是中文版,是/压缩

  • 远端压缩是什么

    • 本地压缩:客户端自己叫模型把历史总结成「一段文字」存下来。注意这个“自己”。就是调用一次config存的url和auth存的api,让这个模型进行总结,和正常对话的模型是一个模型。

    • 远端压缩:客户端调用服务器端点 /v1/responses/compact,
      由「服务器」把历史压成一个加密块(blob)返回,
      客户端看不到也改不了,下一轮原样回传、服务器解密还原。
      "远端"二字就是指:压缩发生在服务器端,不在你本地。

  • 远端压缩有什么好处
    我不知道。众说纷纭,有人说压缩效果更好,期待有佬给出可信实证。

  • 如何开启

    1. 把 name 改成严格的 “OpenAI”(大写 O 和 AI,差一字都不触发):
      model_provider = “a”
      [model_providers.a]
      name = “OpenAI”
      base_url = “…”

      • 注意,远端压缩和前文说的provider的名字(就是那个得在两个地方一样的“a”)没有任何关系,只和[model_providers.a]里面的name有关。
    2. 压缩走 /v1/responses/compact,假如你自己部署反代(如cpa+new api)需要按照如下配置:

    • CPA 侧配置模型 alias(映射):
    oauth-model-alias:
      codex:
        - name: "gpt-5.5"
          alias: "gpt-5.5-openai-compact"
          fork: true
    
    

    含义:

    name  = 真实上游模型
    alias = 客户端请求模型名
    fork  = true 表示保留原模型,同时额外暴露 alias
    
    • 如果用new api:
    渠道管理 -> 找到指向 CPA 的渠道 -> 编辑
    
    

    在模型列表里同时保留:

    gpt-5.5
    gpt-5.5-openai-compact
    
    1. 不是所有的中转站都能远端压缩

    看到这里可以发现,要启用远端压缩,中转站必须有模型映射这样的单独设置。如果没设置映射,那就用不了,作为用户可以让商家添加,或者把name改成非OpenAI的任何名字即可(使用本地压缩)。

对话历史跟什么走

常见困惑:换了个中转站,怎么我之前的对话全不见了?

对话历史「仅仅」绑定 provider 的 id —— 就是那个要在两处
保持一致的 “a”。和块里的 name、api key、base_url 统统无关。

机制:每条对话在后台都记着「创建时用的 provider id」。

  • config 里把这个 id 改了 → 旧对话只是被隐藏,不是删除
  • 把 id 改回原来那个 → 这些对话又会重新出现

所以:换中转站(改 url / key)本身不丢历史,
真正让历史"消失"的,是顺手把那个 provider id 也改了。

(注意区分:远端压缩部分的 name 字段决定"压缩怎么走",
这里的 provider id 决定"历史归在哪"。)

所以对话历史换供应商消失如何解决:显而易见就是只改url和api key,不要动provider id

暂时只想到这么多,config.toml的其他配置后续有空再补充。任何错误欢迎各位佬纠正

1 个帖子 - 1 位参与者

阅读完整话题

来源: LinuxDo 最新话题查看原文