AI Gateway 六个工具接入能力汇总

更新时间：2026-08-20（Asia/Shanghai）

1. 概述

本文汇总以下六个 AI 编程工具接入 AI Gateway 时的协议能力、验证要求和已知限制：

  • WorkBuddy
  • OpenCode
  • TRAE 国际版
  • OpenClaw
  • Kilo Code
  • Codex CLI

你可以通过本文确认：

  1. 每个工具可以配置哪些 API 协议；
  2. 选择模型时应该如何判断是否可用；
  3. 各工具已经确认的基础能力和已知兼容性限制。

本文提供能力概览。实际安装、配置和故障排查，请继续查看对应工具的配置指南。

示例 AI Gateway Base URL：

<https://cn-shanghai-alicloud-aimesh.api.clickzetta.com/gateway/v1>

2. 使用前必读

AI Gateway 的模型目录可能随 API Key 权限、套餐、路由和上游状态变化。请以当前 API Key 的实时查询结果为准，不要把历史模型名单当作长期有效目录。

模型最终能否使用，必须同时满足：

模型出现在当前 API Key 的对应协议目录中 ↓ 同协议标准请求返回 HTTP 200 和最终文本 ↓ 目标工具使用正确的 provider 或 API 格式 ↓ 目标工具实际消息返回最终文本

因此：

  • 模型出现在 
    /models
    /models
    中，只表示当前 API Key 可以看到它；
  • Chat 成功不代表 Responses 成功；
  • Anthropic Messages 成功不代表 OpenAI Chat 成功；
  • 标准请求成功不代表工具已经配置完成；
  • 某一个模型成功不代表同目录或同厂商的其他模型也成功；
  • 基础文本成功不代表流式、工具调用、多模态和长上下文均可用。

3. 六个工具的协议能力总表

工具OpenAI Chat CompletionsOpenAI ResponsesAnthropic Messages当前最重要的限制
WorkBuddy支持，是自定义模型的基础协议不支持自定义模型配置不支持自定义模型配置“自定义协议”只改变 URL 处理，不会转换请求格式；Claude 只有在 AI Gateway 提供 OpenAI Chat 兼容路由时才能使用
OpenCode支持，使用 OpenAI Compatible provider支持，需要单独配置 Responses provider支持，使用 Anthropic provider三个 provider 相互独立；一个协议成功不会自动切换或回退到另一个协议
TRAE 国际版支持，可在自定义模型中选择不支持自定义配置支持，可在自定义模型中选择自定义模型页面只有 Chat 和 Anthropic 两种 API 格式；Responses 成功也不能直接添加到 TRAE
OpenClaw支持，使用 
openai-completions
openai-completions
provider		支持，使用 
openai-responses
openai-responses
provider		支持，使用 
anthropic-messages
anthropic-messages
provider		必须按通过标准请求的协议分别建立 provider；模型 ID 前缀不会自动选择协议
Kilo Code支持，使用 OpenAI Compatible provider工具支持，但当前已知存在流式事件兼容问题支持，使用 Anthropic providerKilo Code CLI 7.4.22 测试中，Responses 标准请求成功，但客户端实际消息因 
SSE-Keep-Alive
SSE-Keep-Alive
事件解析失败
Codex CLI自定义 provider 不支持支持，也是唯一原生 wire protocol自定义 provider 不支持模型必须有 Responses 路由才能原生直连；仅支持 Chat 或 Anthropic 的模型需要转换层或其他客户端

4. 如何根据模型类型选择工具

这张表是选择第一条测试路径的建议，不是固定模型清单。最终仍以当前 API Key 的实时目录和实际请求为准。

模型类型优先测试协议可以选择的工具需要特别注意
OpenAI GPT、Codex 等 OpenAI 系列OpenAI Chat 或 OpenAI ResponsesChat：WorkBuddy、OpenCode、TRAE、OpenClaw、Kilo；Responses：OpenCode、OpenClaw、Kilo、Codex CLI每个模型需要分别测试 Chat 和 Responses；Kilo Responses 当前有已知兼容问题
Anthropic ClaudeAnthropic MessagesOpenCode、TRAE、OpenClaw、Kilo CodeWorkBuddy 不能直接发送 Anthropic Messages；Codex CLI 需要 Responses 兼容层
DeepSeek先测试 OpenAI Chat；如目录提供，再测试 Anthropic Messages 或 ResponsesChat：五个非 Codex 工具；Anthropic：OpenCode、TRAE、OpenClaw、Kilo；Responses：仅在实际成功后用于支持 Responses 的工具不要根据 DeepSeek 名称推断 Responses 一定可用
Qwen先测试 OpenAI Chat；其他协议按目录逐项测试取决于该模型实际成功的协议某个 Qwen 型号成功，不能推断其他型号或其他协议成功
Gemini、Grok、Mistral、Meta、GLM、Kimi、MiniMax 等以 AI Gateway 实际提供的兼容协议为准选择支持该协议的工具厂商名称不是协议开关；必须查询目录并做最小请求

5. 验证范围与已知限制

下面列出各工具已经确认的协议接入能力和使用前必须完成的验收。没有列出某个模型，不代表该模型不可用；请根据当前 API Key 的实时目录逐个验证。

工具已确认的接入能力使用前必须完成已知限制或建议
WorkBuddyOpenAI Chat Completions 基础文本接入路径目标模型的 Chat 标准请求和 WorkBuddy 实际消息均返回最终文本不要把 Anthropic Messages 或 Responses 地址直接填入 WorkBuddy 自定义模型
OpenCode可分别配置 OpenAI Chat、OpenAI Responses 和 Anthropic Messages provider目标模型先通过同协议标准请求，再通过对应 OpenCode provider 返回最终文本三个 provider 相互独立；不能用 Chat provider 代替 Responses provider
TRAE 国际版可配置 OpenAI Chat 和 Anthropic Messages 自定义模型完成标准请求、TRAE 连通性测试和 Agent 实际消息不提供 OpenAI Responses 自定义格式
OpenClaw可分别配置 Chat、Responses 和 Anthropic provider完成标准请求、provider 配置、Gateway 检查和 
openclaw agent
openclaw agent
实际消息		模型必须加入与成功协议一致的 provider
Kilo Code CLI
qwen/qwen3.6-flash
qwen/qwen3.6-flash
已通过 OpenAI Chat 基础文本验证；
anthropic/claude-opus-5
anthropic/claude-opus-5
已通过 Anthropic Messages 基础文本验证		其他模型和协议仍需分别完成标准请求和 
kilo run
kilo run
openai/gpt-5.5
openai/gpt-5.5
的 Responses 标准请求成功，但 Kilo 实际消息出现 
text part SSE-Keep-Alive not found
text part SSE-Keep-Alive not found
，当前不建议使用该路径
Codex CLI支持 OpenAI Responses 自定义 provider目标模型的 Responses 标准请求和 
codex exec
codex exec
均返回最终文本		不支持直接配置 Chat 或 Anthropic Messages；需要 Claude 时必须提供 Responses 兼容层

6. 为什么模型列表需要实时查询

模型可用范围由以下条件共同决定：

模型数量和模型 ID = AI Gateway 当前路由 + 当前 API Key 权限 + 租户或套餐 + 上游实时状态

因此，同一个 Base URL 下，不同 API Key 可能看到不同目录；同一个 API Key 在 OpenAI 和 Anthropic 认证方式下，也可能看到不同目录。

直接使用历史模型名单可能产生以下问题：

  • 已下线或无权限模型仍被标记为可用；
  • 新增加的模型没有及时显示；
  • 目录可见被误写成协议可用；
  • 一个协议成功被错误套用到其他协议；
  • 标准请求成功被误解为所有客户端都成功。

因此，具体模型清单必须使用当前 API Key 实时获取，并按目标协议和工具完成验证。

7. 获取当前 API Key 的模型目录

先在 Terminal 中安全加载 API Key：

read -s 'AI_GATEWAY_API_KEY?请输入 API Key：' echo export AI_GATEWAY_API_KEY export AI_GATEWAY_BASE_URL='https://cn-shanghai-alicloud-aimesh.api.clickzetta.com/gateway/v1'

查询 OpenAI 协议视图

curl -sS "$AI_GATEWAY_BASE_URL/models" \ -H "Authorization: Bearer $AI_GATEWAY_API_KEY" \ | jq -r '.data[]?.id'

这里返回的模型是 OpenAI Chat 和 OpenAI Responses 的候选，不代表两个端点都一定成功。

查询 Anthropic 协议视图

curl -sS "$AI_GATEWAY_BASE_URL/models" \ -H "x-api-key: $AI_GATEWAY_API_KEY" \ -H 'anthropic-version: 2023-06-01' \ | jq -r '.data[]?.id'

这里返回的模型是 Anthropic Messages 的候选，不代表已经通过目标工具验证。

查询完成后清理临时变量：

unset AI_GATEWAY_API_KEY unset AI_GATEWAY_BASE_URL

8. 一个模型怎样才可以写成“支持”

建议统一使用下面的状态名称：

状态判断标准可以对外怎么写
目录可见对应认证方式的 
/models
/models
返回模型 ID		当前 API Key 可以发现该模型
协议文本可用目标协议返回 HTTP 200，并有最终文本该模型的某协议基础文本请求成功
工具基础可用目标工具使用正确 provider 返回最终文本该模型已在指定工具完成基础文本验收
高级能力可用工具调用、流式、多模态等专项测试通过只声明已经单独验收的能力
稳定可用多时间点、多次请求和实际负载测试通过可以按测试范围描述稳定性

不要使用下面的推断：

/models 有模型 → 所有协议都支持 错误 curl 成功 → 所有工具都支持 错误 某个模型成功 → 同厂商所有模型都支持 错误 基础文本成功 → 工具、流式、多模态全部支持 错误

9. 按工具选择正确教程

目标工具应查看的配置教程首先确认的协议
WorkBuddyWorkBuddy 配置指南OpenAI Chat Completions
OpenClawOpenClaw 配置指南根据模型选择 Chat、Responses 或 Anthropic
Codex CLICodex CLI 配置指南OpenAI Responses
TRAE 国际版TRAE 配置指南OpenAI Chat 或 Anthropic Messages
Kilo CodeKilo Code 配置指南优先 Chat 或 Anthropic；Responses 注意已知兼容问题
OpenCodeOpenCode 配置指南根据模型选择 Chat、Responses 或 Anthropic

10. 最终速查

如果你只记住六句话：

  1. WorkBuddy 只按 OpenAI Chat 配置自定义模型。
  2. TRAE 自定义模型支持 Chat 和 Anthropic，不支持 Responses。
  3. Codex CLI 原生只使用 Responses。
  4. OpenCode 和 OpenClaw 可以为三种协议分别建立 provider。
  5. Kilo Code 支持三种 provider，但 Kilo Code CLI 7.4.22 的 Responses 测试存在 
    SSE-Keep-Alive
    SSE-Keep-Alive
    兼容问题。
  6. 任何模型都必须经过“实时目录 → 同协议 curl → 目标工具实际消息”三层验证。

本文只覆盖基础文本连接。流式输出、工具调用、代码修改、多模态、结构化输出、缓存、搜索、长上下文、并发和稳定性必须单独测试。

通过 cz-cli 进行模型管理
Workbuddy配置指南
Yunqi © 2024 Yunqi, Inc. All Rights Reserved.
联系我们
预约咨询
微信咨询
电话咨询
邮件咨询