跳到正文
FunCoding

搜索

搜索文档、Skill 和 MCP

连接组织模型网关

设置 Responses provider、凭据和模型目录,验证实际模型路由与客户端进程环境。

先向网关团队取得 HTTPS base URL、provider ID、模型名和凭据机制。若管理员已下发配置,先检查当前 profile、codex doctor 与会话 /status,避免重复定义同名 TOML 表。

配置 provider

下例 URL 与模型均为占位值,必须替换为管理员提供的值。顶层键放在第一个表之前:

model = "<model-name>"
model_provider = "enterprise-gateway"
web_search = "disabled"

[model_providers.enterprise-gateway]
name = "Organization Gateway"
base_url = "https://gateway.example.com/v1"
wire_api = "responses"
env_key = "CODEX_GATEWAY_API_KEY"

凭据通过启动 Codex 的进程环境传入,不写入 TOML。终端里设置的变量不一定能被从桌面启动的应用读取;保存配置后重启对应客户端。

自定义模型 alias 需要相匹配的 catalog。管理员提供该文件时,用顶层 model_catalog_json 设置已存在文件的绝对路径;目录元数据不会自动创建服务端模型路由。

其他认证方式

若网关使用 X-API-Key,使用 env_http_headers 替代 env_key:

env_http_headers = { "X-API-Key" = "CODEX_GATEWAY_API_KEY" }

如果组织提供 credential helper,改用 provider.auth 表里的 command、args、timeout_ms、refresh_interval_ms,且不要同时设置 env_key。helper 须预先安装,路径使用实际绝对路径。Windows TOML 可用单引号字符串保存反斜杠。

验证实际路由

启动新任务,检查 /status 中模型和 provider,再发送 Reply with exactly: gateway-ok。返回正确文本只证明有响应,仍需网关日志确认用户、alias 和上游路由;不要用模型自报名称作为验证。

管理员还需完成网关兼容性验收中的 streaming、工具和续轮测试。

常见失败

provider 不生效时查配置优先级和顶层键位置;认证失败查变量是否到达应用进程或 helper 能否续签;模型找不到时查 alias 路由;能力异常时查 catalog 与上游是否匹配。Streaming 卡住或后续回合失败,应查代理缓冲和 response.completed 事件。

网关凭据仅用于模型请求,不授予 MCP、插件或其他外部服务权限。