GPT-6 Astra 怎么接入？Codex、DSH 配置与 Cline、Cursor 支持检查

在编程 agent 中接入 GPT-6 Astra，先把供应商、模型 ID 和 API 协议配对，再改默认模型。 OpenAI 当前要求 Astra 的工具调用使用 Responses，Codex 的自定义 provider 也只支持该协议。DeepSeek Harness 可以明确配置 Responses 路由；Cline 和 Cursor 则需分别核对客户端支持范围。模型出现在目录中，不代表完整的 agent 工具循环已经跑通。

配置与公开目录核对于 2026 年 9 月 16 日。下文是依据文档整理的配置示例，没有执行付费推理或端到端 agent 实测。

请求地址、key 和模型 ID 怎么配？

使用对应供应商签发的 key。Ofox 目录目前为 Astra 列出了 /v1/responses 和 /v1/chat/completions，上下文窗口为 1,050,000 token，最大输出为 128,000 token。目录可见、账户有权限、额度可用，以及客户端协议兼容，是不同的检查项。

OpenAI 模型指南列出的 reasoning effort 有 low、medium、high、xhigh 和 max，不支持 none。可以从 high 开始试用，但这不代表它在所有仓库中都是实测最优。提高档位前，比较任务完成成本和改动是否通过验收。价格说明把输出、缓存写入和缓存读取分别计费。

Codex：自定义 provider 改用 Responses

当前 Codex 配置参考规定，model_providers.<id>.wire_api 只支持 responses。旧教程里的 wire_api = "chat" 应当替换。

先运行 codex --version。OpenAI 使用说明要求 Astra 使用 Codex CLI 0.153.0 或更新版本；使用桌面入口时还需单独更新桌面应用。

把以下内容合并到 ~/.codex/config.toml，保留原有的其他 profile：

[model_providers.ofox]
name = "Ofox"
base_url = "https://api.ofox.run/v1"
env_key = "OFOX_API_KEY"
wire_api = "responses"

[profiles.astra]
model = "openai/gpt-6-astra"
model_provider = "ofox"
model_reasoning_effort = "high"

通过平时使用的密钥管理方式，在启动 Codex 的环境中设置 OFOX_API_KEY，然后选择这个 profile：

codex --profile astra

收到文字回答只是第一步。在可丢弃的工作副本中，先要求一次小范围的只读检查，确认工具调用、工具结果回传和最终回答全部完成；再做一次有现成测试的小改动。同时检查流式响应是否正常结束，以及用量记录是否完整。网关接受 Responses 格式的 JSON，并不能单独证明流式传输和工具续接都兼容。

直连 OpenAI 时，沿用 OpenAI provider，模型 ID 填 gpt-6-astra；不要把 OpenAI key 填进 Ofox profile。更多配置选择见 Codex config.toml 指南（英文）。

Cursor：先确认模型选择器支持哪条接入路径

Cursor 当前的 API key 文档把 OpenAI 自带 key 的支持范围写为标准、非推理聊天模型，并说明自带 key 用于聊天，Tab 等专门功能仍使用 Cursor 自己的模型。这些说明不能证明 Astra 推理模型可通过任意自定义 Base URL 接入。

先检查当前安装版本和账户的 Settings → Models 及模型选择器。如果 Cursor 自身提供了受支持的 Astra 接入方式，按该方式的计费和设置操作。如果自带 key 的流程没有提供受支持的 Astra 路径，仅改模型名称不能证明可以使用。此时可用明确支持自定义 provider 的客户端接入，或等待 Cursor 明确支持；不要把聊天连通等同于所有 agent 功能可用。

Cline：文字接通不等于工具循环兼容

Cline 的 OpenAI Compatible 文档列出了以下连接字段；这些字段说明兼容连接的填写方式，不代表 Astra agent 已验证可用：

OpenAI 当前模型指南要求 Astra 的工具调用使用 Responses。只走 Chat Completions 的 provider 路径即使文字接通，也不满足这个条件。确认当前安装的 Cline 集成明确支持所需的 Responses 工具流程，否则保留受支持的模型或使用文档明确支持 Responses 的客户端。没有网关文档和实际工具续接验证，不要假设网关自动转换了流程。上下文与输出限制应符合目录；不要虚构能力标记来打开界面选项。本文没有实测任何 Cline 版本与 Astra 的组合。

DeepSeek Harness：为自定义路由声明模型

DSH 官方 provider 文档要求自定义路由填写 API 协议、Base URL 和非空模型列表。$DSH_HOME/settings.yaml 中的配置示例如下：

llm-pi-ai:
  providers:
    ofox:
      apiKeyEnv: OFOX_API_KEY
      api: openai-responses
      baseURL: https://api.ofox.run/v1
      models:
        - id: openai/gpt-6-astra

apiKeyEnv 引用环境变量，因此不必把 key 本身写进文件。这里的 openai-responses 选择 Responses，符合官方 Astra 工具调用的要求。DSH 文档识别这个协议，但这仍不证明每个网关和账户都兼容完整工具流程。models 列表会替换该路由的模型目录，而不是追加；需要在这条路由选择其他模型时，也要把它们列入，或按文档使用适用的目录覆盖机制。

按所安装 DSH 版本的要求重启或重新加载配置，选好路由和模型，再做同样的小范围工具往返检查。本地 UNKNOWN_MODEL 可能意味着路由没有声明该模型；上游返回的权限错误需要另外排查。

设为默认之前，怎么验证迁移？

1. 保存原 profile 和客户端版本。查询供应商当前模型目录，再确认实际生效配置的地址和模型 ID。
2. 新建一个小任务，依次检查文字回答、工具调用与续接、完整的流式响应。排查期间保留旧模型，方便回退。
3. 在相同仓库快照、权限、上下文和验收测试下，让两个模型完成同一个有明确边界的任务。记录结果是否通过、重试次数、耗时和计费用量，失败尝试也要算进任务成本。
4. 按层排查：凭证与账户权限、地址与模型 ID、请求参数，再到工具历史和流式传输。基础请求成功，不代表剩下的问题一定只在客户端。

如果沿用旧的原始 API 请求预设，应移除不支持的 temperature、top_p、top_logprobs，以及 Chat Completions 的 logprobs，或 Responses include 中的 message.output_text.logprobs。官方模型指南明确列出了这些限制。应检查客户端最终发出的请求；不要把原始 API 字段直接当作客户端配置字段。

如果旧预设用了 reasoning.effort = "none"，迁移时要改为 Astra 支持的值。OpenAI 迁移指南还要求从 GPT-5.5 或更早模型迁移时，用 prompt_cache_options.ttl 替代 prompt_cache_retention；把原始 API 参数抄进客户端配置前，先确认客户端是否暴露这个字段。

决定预算时，可以一起看 Astra 与 Sol 对比和跑分评测。公开 benchmark 的节省结果值得拿来设计试用，但不能当作自己 agent 账单的保证。