OpenAI 推出 /v1/responses 协议后，Codex CLI、各类开发者 Agent 纹纷跟进适配。问题在于——DeepSeek、MiniMax、智谱、小米等国产模型只暴露 Chat Completions API，协议不对齐，工具链直接断路。GodeX 做的事很明确：在中间当翻译层，把 Chat Completions 的请求/响应结构桥接成 OpenAI Responses 格式，让上层工具无感切换模型供应商。v1.1.0 又加了 MiniMax-M3、多模态理解和原生搜索结果桥接，覆盖面再拓宽一层。
协议断层与桥接思路
OpenAI Responses API 和 Chat Completions API 的核心差异不在"对话"本身，而在结构化输出与工具调用的表达方式。Responses 协议把工具调用、搜索结果、多模态输入统一收进一个 output 数组，每项带 type 标注；Chat Completions 则把同类信息塞进 choices[0].message 的 tool_calls 字段，扁平且不区分输出类型。
GodeX 的桥接逻辑可以简化为：
Client (Codex / Agent) → /v1/responses → GodeX 网关
↓ 协议翻译
Chat Completions → 模型供应商
↓ 响应翻译
/v1/responses → Client
关键翻译动作包括：把 Responses 的 input 拆解成 Chat Completions 的 messages 数组；把模型返回的 tool_calls 和文本内容重新组装成 Responses 的 output 项。搜索结果和多模态内容在 v1.1.0 之前没有对应映射，现在被补上了。
v1.1.0 新增了什么
MiniMax-M3 支持——MiniMax 的 M3 模型进入了 GodeX 的供应商配置表，意味着你可以用 Responses 协议直接调用 M3 的长上下文和搜索增强能力，不需要单独对接 MiniMax 的 SDK。
多模态理解——图片、文件等非文本输入在 Chat Completions 侧通常以 image_url 或 content 多类型数组的方式传入。GodeX v1.1.0 把 Responses 协议中的多模态 input 项翻译成对应的 Chat Completions 格式，让视觉理解模型（如智谱的 GLM-4V）也能被 Codex 类工具直接调用。
原生搜索结果桥接——部分国产模型（如 DeepSeek 的搜索增强模式、MiniMax 的 search tool）在 Chat Completions 响应里返回搜索引用信息。v1.1.0 把这些信息映射到 Responses 协议的 output 中带 type: "search_result" 的条目，上层 Agent 可以直接消费搜索来源，而不是丢失在翻译过程中。
实操：五分钟跑起 GodeX 网关
以下示例假设你已经有一台能访问模型供应商 API 的机器。以 DeepSeek 为例，展示从安装到调用的完整流程。
1. 安装 GodeX
# 从 GitHub Releases 下载最新 v1.1.0 二进制
# Linux amd64 为例，其他架构替换对应文件名
curl -L -o godex https://github.com/godex-dev/godex/releases/download/v1.1.0/godex-v1.1.0-linux-amd64
chmod +x godex
sudo mv godex /usr/local/bin/
# 验证版本
godex version
# 预期输出: v1.1.0
2. 写配置文件
创建 godex.yaml，声明供应商和模型映射：
server:
port: 8080
host: "0.0.0.0"
providers:
deepseek:
api_key: "sk-your-deepseek-key-here"
base_url: "https://api.deepseek.com/v1"
models:
- id: "deepseek-chat"
responses_id: "deepseek-chat" # Responses 协议中暴露的模型名
minimax:
api_key: "your-minimax-key-here"
group_id: "your-group-id"
base_url: "https://api.minimax.chat/v1"
models:
- id: "MiniMax-M3"
responses_id: "minimax-m3"
zhipu:
api_key: "your-zhipu-key-here"
base_url: "https://open.bigmodel.cn/api/paas/v4"
models:
- id: "glm-4v"
responses_id: "glm-4v" # 多模态模型
multimodal: true
search_bridge:
enabled: true
# 将模型返回的搜索引用映射为 Responses 的 search_result 输出项
providers: ["deepseek", "minimax"]
注意：
api_key和group_id请替换为你自己的真实密钥。多模态模型需要标注multimodal: true，GodeX 会据此调整输入翻译逻辑。
3. 启动网关
godex serve --config godex.yaml
# 输出类似: GodeX v1.1.0 listening on 0.0.0.0:8080
4. 用 Responses 协议调用 DeepSeek
curl -X POST http://localhost:8080/v1/responses \
-H "Content-Type: application/json" \
-H "Authorization: Bearer sk-your-deepseek-key-here" \
-d '{
"model": "deepseek-chat",
"input": "用 Python 写一个快速排序，要求有类型标注和 docstring"
}'
返回结构遵循 OpenAI Responses 格式，output 数组中包含文本结果：
{
"id": "resp_...",
"model": "deepseek-chat",
"output": [
{
"type": "message",
"content": "def quick_sort(arr: list[int]) -> list[int]:\n ..."
}
],
"status": "completed"
}
5. 调用 MiniMax-M3 并触发搜索桥接
curl -X POST http://localhost:8080/v1/responses \
-H "Content-Type: application/json" \
-H "Authorization: Bearer your-minimax-key-here" \
-d '{
"model": "minimax-m3",
"input": "2025 年中国新能源汽车销量排名前十的品牌是哪些？"
}'
如果 M3 启用了搜索增强，返回的 output 中会包含搜索来源条目：
{
"output": [
{
"type": "search_result",
"url": "https://...",
"title": "2025年新能源销量统计",
"snippet": "..."
},
{
"type": "message",
"content": "根据最新数据，排名前十的品牌包括..."
}
]
}
6. 多模态调用（智谱 GLM-4V）
curl -X POST http://localhost:8080/v1/responses \
-H "Content-Type: application/json" \
-H "Authorization: Bearer your-zhipu-key-here" \
-d '{
"model": "glm-4v",
"input": [
{
"type": "image_url",
"image_url": { "url": "https://example.com/chart.png" }
},
{
"type": "text",
"text": "描述这张图表的趋势"
}
]
}'
GodeX 会把 image_url 和 text 翻译成智谱 API 要求的 content 多类型数组格式，模型返回的视觉理解结果再被包装回 Responses 的 output。
接入前想清楚几件事
- 延迟叠加：每次请求经过 GodeX 翻译层，增加一跳网络和一层序列化/反序列化。对低延迟场景（实时对话流），需要评估额外耗时是否可接受。
- 功能边界：Responses 协议的部分能力（如
stream细粒度事件类型、previous_response_id会话链）在 Chat Completions 侧没有完全对等的字段，GodeX 会做合理降级或忽略。使用前查阅项目的兼容性矩阵，确认你依赖的特性已被映射。 - 密钥管理：配置文件中集中存放多个供应商的 API Key，生产环境务必用环境变量或密钥管理服务注入，不要把明文密钥提交到版本库。
- 模型能力差异：协议对齐不等于能力对齐。DeepSeek 的推理链、MiniMax 的长上下文搜索、智谱的视觉理解各有擅长，按场景选模型，不要指望一个网关抹平所有差异。
GodeX 解决的是一个很具体的管道问题——让已经适配 Responses 协议的工具链，不用重写就能接入国产模型。如果你的 Agent 或 CLI 正卡在协议不对齐这一步，v1.1.0 值得试一下。